myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [orchestra] ViewController stuff
Date Sat, 18 Aug 2007 11:37:58 GMT
> There is already an implementation of this sort of thing in the Shale
> project's view-controller module:
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.


View raw message