Hi, I've been reading up on Trinidad Dialogs (including "pageFlow" feature), and comparing them with Orchestra conversations.
It seems to me that there is some overlap in features here. I'd appreciate your help in getting a fair comparison together. I'm mostly looking at these three pages: http://myfaces.apache.org/trinidad/devguide/communicatingBetweenPages.html http://myfaces.apache.org/trinidad/devguide/dialogs.html http://myfaces.apache.org/orchestra/myfaces-orchestra-core/conversation.html The orchestra docs give the following reasons for using conversations instead of session-scope: (1) at end of a flow, discard related beans to save memory (2) at restart of flow, start with clean beans, not leftovers from previous run (3) support multiple concurrent windows there is also an undocumented (because somewhat debatable) additional one: (4) support "back" button by keeping snapshots of user data (either client or server side). Trinidad pageFlow provides some kind of support for (1) and (2). However views that are expected to be used in dialogs must use EL expressions that reference pageFlow.*, ie must be written for it. The backing beans for such screens are "normal" beans, and therefore are created directly in their declared scope (request/session). Any non-request-scoped bean will not be cleaned up on dialog end; only pageFlow is. So it seems to me that the correct way to use Trinidad dialogs is: * always use request-scoped backing beans only * EL expressions can read data from the pageFlow map, eg display outputText. However they need to explicitly write "#{pageFlow.foo}" to get the data. * EL expressions don't write to the pageFlow map; any input components map to properties on the request-scoped bean. Of course those values get lost after render, but on postback the input components send that data back. * If the backing bean wants to store any "computed" data, it must put() it into the pageFlow map, and later read it back out again (with a typecast). This map is probably best injected into it; the bean just needs to know that this object can be used to externalise its state (if any) into. Is this correct? In my experience, it's pretty hard to write a JSF app wth backing beans that are only in request scope; I find myself using Session scope a lot despite its drawbacks. Request-scoped beans are just too hard to use in some circumstances. It seems to me therefore that Trinidad pageFlow (and the Dialog support that is built on top of it) are really focused on page sequences a couple of pages in length, where the pages don't do any clever or complicated logic. Is this the general goal? And that converting an application that currently uses session-scoped beans to using Trinidad dialogs extensively would be significant work? I guess one of the objects in the pageFlow could be effectively "the real stateful backing bean", combining both logic and state into one instance. However it would have to be explicitly put there by something rather than allowing the VariableResolver to just create it in its natural scope when an EL expression accessed it. And all accesses to it would be clumsy as they either would have to be delegated via the request-scoped bean, or the EL expression would need to use "pageFlow.*" again. So I presume this is not really a recommended approach? Re (3), the "page flow key" is kept as a URL param, so I guess that as long as all the backing beans are request-scoped this would allow a user to have multiple windows open on the same or different dialogs. But it will not work for any backing bean that is stateful itself. Re(4): snapshots of the pageFlow map can easily be made. This is sufficient, however, only if the application uses only request-scoped beans (no session-scoped beans at all). Note that I'm not trying to criticise pageFlow or Trinidad dialogs here, just get an understanding of how they are expected to be used, and what the pros/cons are. Regards, Simon
