Hi! > 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 do not have any good argument why I didn't go the shale way. Maybe I was just to shy to convince the shale people about the surely required API change which might have been resulted in an huge patch .... And I just doesn't know at the time of writing this stuff what the exact API changes in Shale would have been.
I'd say, Orchestras implementation is just a lightweight variant of the shale stuff. If we would like to go the shale way, we have to add the shale, shale-view and shale-tiger jar to the project which requires the view controller stuff. Doesn't really help in lowering the stack required to startup an Orchestra application, does it? > 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? > If, we have to use the (never ;-) ) upcoming myfaces-commons project. Are you willing to volunteer? > 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: > We also have the AnnotationsViewControllerManager which uses the @ViewController annotation where you can configure which view-ids the bean belongs to. > I would rather > see something based on the JSF12 approach of phase-listeners attached to > views. Ah, I should finally take some time to have a look at the new stuff in JSF12 (- any good summary about that somewhere?) > 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 > Woho .... I wonder why the page designer should bother invoking the right phase methods on the backing bean. Isn't it the same (let's say) "wrong" concept than the t:saveState where every now and then people arguing that this has nothing to do in the view? > 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. > However, if people think this is the way to go, I am sure it is easy to create such a JSF tag too. Ciao, Mario
