I'm building a desktop application with Castle ActiveRecord and want to be able to do the equivalent of 1 nHibernate session per window form. Any ideas on how can I do this with Active Record?
Specifically, I have a main window that allows you to browse the data (read-only) and then you can open separate forms to edit the data.
Each time a form is opened, I want to create a new session, get a copy of the data to edit (so it can be changed without yet impacting the data in the main window). I then want to be able to manipulate that copy via data binding. And finally, either commit the changes (if the user chooses to Save) or roll them back (if the user chooses to cancel).
Any ideas?
If you don't need lazy loading, don't use a SessionScope. You can simply databind and call entity.Save() on Save. Since your objects are detached without a SessionScope, you don't have to do anything on cancellation of the form.
If you need lazy loading, then this won't work with plain ActiveRecord yet. A ConversationalScope that allows using CpBT (in your case Conversation per Form Instance) is planned, but not available yet.
One possibility is to try Rhino Commons which has a unit-of-work-implementation for ActiveRecord. This could allow what you want with current AR, but I didn't use it for about 2 years.
Edit:
A basic CpBT implementation is now available from trunk. Check-out and build with nant. See this link for how to use it:
https://svn.castleproject.org/svn/castle/ActiveRecord/trunk/src/Castle.ActiveRecord.Tests/Conversation/ConversationScenarioTest.cs
It is not production ready yet, but I'd love feedback on it.
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
In my Sitefinity back-end there is a user section that I would like to add some setting. Something like DisplayLink where it would be a boolean value that I can set on Login of the user. Is there a way I can do that? I am using sf 14 and can't find anyway to add some setting for the user.
I believe this is what you need ...map the view externally and modify.
However keep in mind these views pull in the XHR JSON and you just expose it to the grid... Open your console and view the XHR network traffic to see the JSON object per user. There's a "Comment" field you might be able to leverage, but man the best way would be to just use a ROLE... because they can be filtered, and already come across in that JSON.
Another thing to note, is this is an OLD UI screen and likely will get revamped in the next few releases of Sitefinity rendering everything you're doing pointless... (have to re-do it with likely the new AdminApp Extensions)
How to refresh the interface after you add a strip of data to the backend database in Vue.js?
I mean, if I add a item data to the database. there are two case for refresh the interface.
refresh the list api to get the page data.
append the added item data to local list.
what is the best way to do this?
I think both the solutions are valid it depends on what kind of write operation we are planning to do. Given that you do all the validations on the front-end which leaves lesser chance for errors on the backend. I do the following based on the use case.
Add/Update the item locally and then based on the response from the server I remove it again in case of an error. This is an optimistic technique used by a lot of websites and worls really well for CRUD kind of operations.
Let's say that your new operating is going to creaate a new user in a 3rd party api. So doing an optimistic thing might not be the best. So what I do is make the request, show a toast/alert that the request is happening, and then use sockets or long polling to get the changes. When the request is finally done show the data. In the meanwhile you can insert a dummy item showing loading.
In my application, users are accessing data that are specific to a station.
Because a user is able to switch from a station to another one, I would like to clean filter modules every time the current station is changed.
Icing on the cake, I would like to warn the user if exist some updates unsaved.
One idea would be to chain a reset all filter modules action to the one that allows the user to switch its station.
Unfortunately, there is no built-in action that restarts all the application filter modules, but it would not be much complicated to write one. The idea would be to iterate through all the workspace / modules hierarchy and to restart each module.
In order to restart a module, you can have a look to the standard org.jspresso.framework.application.frontend.action.module.ModuleRestartAction (source here). You could even inherit this action and simply override the execute method in order to deal with all the application modules instead of only the selected one.
Of course, if you feel like it could be a good addition to the framework standards, feel free to submit a RFE or even a PR.
As a tester, I'd like to know whether it is possible to restrict the manual creation of new objects by the user. The restriction should be done programatically in ABAP, not by removal of permissions.
Background information: we have quite complex objects which are hard to set up manually. Therefore we have implemented a wizard, which does all the condition checking etc. when creating the object. Also, if the wizard shall work, the user must have appropriate permissions to create the object.
Is it possible to remove the object type for that complex object from the list which appears when creating a new object (pressing the New button)?
As I'm only a tester for this part of our software, I can't show any existing code. I just got the feedback "It's not possible" and that's hard to believe for me at the moment. Usability really suffers, because people try to create those objects manually and can't make it work.
I also don't need a working code example, just a hint (class or method or setting) for the developer where to find a solution. I'll then insist that he implements it :-)
Update
Today, the user can click the "New" icon. Then, a dialog appears with 4 choices. 3 choices are for simple objects which he shall create like this. However, the first item in that list is for the complex object, which is impossible to create manually (why we have the wizard). I'd like to know whether it is possible to remove that item from the list programatically.
ᵺṓᵯᶏᵴ, the information you have provided is still a bit vague. However, here is an idea that may work for you.
It might not be possible to completely automate this process, but you could ask your developer to enhance the code that processes the New button, so that it would reject any attempt to bypass the wizard for the first item on the list.
Your developer can tell you if it is feasible in your case, to have the enhancement raise an error (message of type E) to stop the user from proceeding.
This would have to be combined with end-user training to tell people to avoid the New button for that item, and use the wizard instead
ᵺṓᵯᶏᵴ, it looks like a custom dialog so it should be possible to remove it the option, alternatively if it is a standard dialog in a SAP app there is always a way to restrict it, it can be as simple as disallow entry from specific transaction codes. for example the developer could set a variable at the start of the wizard and then check for that variable when creating the object, if it not there he can show a dialog "Please use the Wizard we carefully crafted for your use......" Ok maybe you wont say all of that but you get it.
So the answer to your query is yes it can be done but the approach will depend on what it is your changing custom or standard object etc,.
Later..