Question - JSF Render Response phase and Data access

[timpii]

I am a newbie to most of this stack - JDK 5, EJB3, JSF, Seam, etc. One of the concerns that I have had regarding JSF is the life cycle event structure (Restore View, Apply Request Values, Process Validations, Update Model Values, Invoke Application, Render Response). I like everything up to the Render Response.

At that point it is my limited understanding that when the Navigation Handler determines the next page it is too late to go back and obtain persistent data for the page. Thus each page is dependent upon the previous page event process for obtaining its necessary data. In my mind then we have a very tight coupling between pages - that does not work for alot of applications.

So my questions are:
First - is my JSF understanding correct, or am I missing something?
Second - is there functionality in Seam that allows the Render Response phase to obtain persisted data after selecting the next page?
Third - Is there anything in the (future) jBPM Navigation configuration for Seam that will allow the Render Response phase to obtain persisted data? (BTW - I am excited about this functionality)
Fourth - If none of the above - any suggestions on how to create a generic capability to access persisted data once the next page is determined via the Navigation Handler?

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.

Thanks in advance for your thoughts.

Tim

[patrick_ibg]

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.

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.

[timpii]

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.

[patrick_ibg]

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.