DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33918>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33918 ------- Additional Comments From [EMAIL PROTECTED] 2005-04-21 06:49 ------- I did not know that saveMessage() could auto-remove messages from the session. Are we talking about protected void Action::saveMessages(javax.servlet.http.HttpSession session, ActionMessages messages)? It was brought to my attention that RequestProcessor removes them automatically, once accessed. Is this true? Since when? On the other hand, this is not enough. I can suggest the extension of this enhancement :) Here is a broad idea: page does not simply show text, input boxes and error messages. It shows objects. In case of page, the objects are NOT business objects (BO), they are UI objects (UO). UO aggregates a BO and some other assosiated UI information like error messages or window title. UO is basically a wrapper for BO, making BO suitable for user interaction. Error messages depend both on state of BO, as well as on client actions. Thus, UO aggregates two types of errors: business errors (BE) and user errors (UE). (I don't know, should there types be clearly defined, or it should be possible for infinite types of messages? I had come up with business errors first, then I thought about user errors, and that is all for about two or so years. Maybe someone else can add to this list.) BE are generated by BO rules. BE _belong_ to BO, thus as long as the same BO exists, BE should not be cleared. "Exists" means that BO instance which is aggregated into particular UO is not destroyed. In my own implementation I use a single instance of UO for editing items. First I show a list of items, than when a user selects an item, I create UO, load BO into it and display it. BO is now ready to be updated. Thus another term that I have for UO is "current item", it is current in terms that user interacts with it right now. UE are generated by user actions, like submitting an item, or deleting an item. These errors belong to a particular action that the user undertook. Refreshing a page or going back and forward DOES NOT mean that the user performed the same action again, thus UE must be cleared when the same UO is shown for the next time. And of course, this whole thing must work with redirect, to provide better user experience and to avoid implicit double submits. So, how should this work? There should be a standard UO class. Form bean can be an UO, but action can have only one form bean. It is possible to forms from previous actions if they have session scope, but this wacky. I don't know is it OK to instantiate form beans directly, by calling constructor. How the whole reset/populate/validate sequence will work for them? There should be an API between UO and BO to set error messages, because business rules are buried in the BO and it is not good to pass ActionMessages to business layer. Or BO can just return an error code, and actual message would be set in UO, based on locale and other UI-specific stuff. Another feature is BO read/write caching. BO instance aggregated in UO is not a real BO, it is a copy. Thus, it is ok to modify its fields without risking to update real data. Thus, when BO-in-UO is edited, its fields are set unconditionally, then business rules validate input, errors are generated and stored in UO, and then UO is displayed. voila! If BO was updated and shold be persisted, then it is copied to persisitence layer. If UI asks for particular BO, then UO checked first. If it contains needed BO, it is shown, database is not bothered. If new BO is created, it is stored in UO first. If later user decides not to persist it, BO is destroyed and database is not bothered. The hardest thing is when BO and messages should be cleared from UO. The easy case is when another BO is requested. But if not? Two different use cases look the same for the server: (1) refresh the page, which was displayed by redirect. Must show the same object. (2) Go back or just close the window. Object is not needed anymore and must be destroyed. I guess either Javascript or let it live there, it will be invalidated sometime later when another BO is requested. In my test CRUD application I invalidate UO when I "exit" to the item list. And the icing: there can be different types of UO, like for editing or for viewing. Thus, you can open two windows with the same object, and view it in one window, and edit in another. Until edited copy is not persisted, viewed copy will show original data, OK to refresh. I don't post links to the my article and the source code, I think I put enough self-advertising in last couple of days :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
