Hi All, Orchestra currently includes "ViewController" code to implement callbacks on backing beans for different "lifecycle events", eg on creation of view (init), and pre-render.
These kinds of callbacks are very useful, but is Orchestra really the right place for this? There is already an implementation of this sort of thing in the Shale project's view-controller module: http://shale.apache.org/shale-view/index.html I see from a brief look at the Orchestra code that the orchestra version does have some conversation-related stuff in there too, but perhaps it would be better to add that as a layer on top of another view-controller implementation than to rewrite one? If the orchestra view-controller code is significantly different from shale (I don't know the shale code very well) then perhaps it could be merged into Tomahawk rather than exist in Orchestra? And separately, both Shale and Orchestra ViewController implementations depend upon having managed beans with names that "match" viewIds in order for the controller to figure out which bean to invoke methods on. I'm not very enthusiastic about this approach as it seems fragile: rename a view and the callbacks silently stop happening. I would rather see something based on the JSF12 approach of phase-listeners attached to views. This also limits callbacks to one bean (though I suppose it is possible to write a bean to proxy calls to other beans). In JSF12, the UIViewRoot component can now have phase listeners attached to it, and they get invoked for processing phases. These listeners are attached by adding f:phaseListener tags to the page. As a convenience, there are also attributes on f:view to configure a default phaseListener: <f:view beforePhase="#{backingBean.doBeforePhase}" afterPhase="#{backingBean.doAfterPhase}"> <f:phaseListener binding="#{backingBeanPhaseListener}"/> Something similar to the f:phaseListener tag should be pretty easy to emulate in JSF1.1; just have a tag that adds phaselisteners to the attribute map for a UIViewRoot, and then have a PhaseListener that retrieves them and invokes them. This approach keeps the mapping between view and bean in the page, so renaming a page doesn't break the association. It is also clear to the reader of the page what callbacks are occurring when that view is executed, rather than then having to search the managed bean defs for beans whose names "match" the viewId. Note that although the f:phaseListener tag does require the target to implement PhaseListener, I'm not suggesting that this point directly at the backing bean. Requiring a backing bean to implement PhaseListener is not very nice. There are a number of possible solutions to this that I can post if people think this approach is worth investigating further. Regards, Simon
