Thanks for the thoughtful response Patrick. Maybe a Use Case would help me explain better. Say the application has a Global Processing Rule - that if there is unsaved dirty data on a page the user will always be provided the option to save it before the system processes all navigation requests - but that the "save request" and the navigation need to be accomplished in one round trip. (This rule is a requirement that is included in most of the apps I have worked on.)
With a left navigation "frame", potential top and/or bottom navigation controls, and content boxes throughout the pages a user could navigate to/from a particular functionality from 50+ different pages - all of which could be subject to the save/update event of the global processing rule. An example of this would be a user who is entering a batch of accounts payable invoices suddenly selects to edit/add a vendor (or GL number / or any number of other functionalities). When the user selects to save (within the global processing rule), the user request will be to update of the current invoice batch information, and then secondarily to navigate to manage vendors which requires separate domain information. I can see how the inclusion of the navigation URI becomes a variable in the user event. However, the user event request has to be the save operation on the save invoice batch when the user requests it. The URI the user wants to navigate to can easily be managed as the second tier return string from the InvokeApplication phase (first tier "success" / "failure" etc. for a normal submit). However, somewhere there needs to be a mapping of a URI to the application service which provides the domain data for the page. My original thinking is that it would be the most efficient to have that mapping within the page navigation definition. Thus a page would know the service responsible for obtaining the necessary domain information. The fallback position is to maintain a separate mapping that would be accessible within the app layer (InvokeApplication phase) but then you have a duplicate mapping that needs to remain in sync with the navigation mapping - something that is always problematic. Currently the only way I can think of to accomplish the first choice would be to have a callback capability within the Navigation Handler to support the obtaining the necessary data after the page has been determined (i.e a configuration of the service which obtains the data). So the problem is not going to the database 2 or more times - the problem is from any page a user can navigate to numerous other pages - but the user event still needs to remain an "update source page data" event. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3912237#3912237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3912237 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
