[JBoss-user] [JBoss Seam] - Re: Question - JSF Render Response phase and Data access
Maybe I'm missing something, but it still seems to me that your problem is easily handled by context variables and view mappings. I assume you are using a standard MVC architecture? You are not limited to just failure and success outcomes... and the event that is fired (the method invocation) is only very loosely tied to the outcome. True, you can probably create custom view handlers to resolve the views after the InvokeApplication phase, but I don't think that's necessary in your case. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3912489#3912489 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3912489 --- 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=7637alloc_id=16865op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [JBoss Seam] - Re: Question - JSF Render Response phase and Data access
Typically, persistent entities are placed in a context (application, session, conversation or event/request) during the InvokeApplication phase. The render response will then have access to these entities. It may or may not hit the database to render the page, depending on whether the entities have lazy-fetched associations, however this is mostly transparent to the developer, esp. if you are using JSF/Seam/EJB3. InvokeApplication is where you normally code your business logic, or call other layers that implement the biz logic. In the JSF/Seam/EJB3 stack, this code resides in a JSF backing bean which can be an EJB session bean. Seam acts as the glue which makes the EJB session bean appear to JSF as a backing bean. anonymous wrote : | I understand that most applications will not want to go to the database twice - once for the event update and the second to obtain the new pages data. However, there are a class of applications where this is very important - as a example personalized apps. | This cannot be avoided. Unless you want to code a stored proc for each instance of these interactions, you will have to hit the db at least twice. After all you are issuing two SQL statements (an UPDATE and a SELECT). This really isn't an issue with webapps, since the webapp and the db layer are both on the server side, and there is very little network latency. Add connection pooling, prepared statements and caching and you wind up with a highly performant stack. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3912144#3912144 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3912144 --- 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=7637alloc_id=16865op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [JBoss Seam] - Re: Question - JSF Render Response phase and Data access
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=bbop=viewtopicp=3912237#3912237 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=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=7637alloc_id=16865op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
