myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <>
Subject Re: [orchestra] ViewController stuff
Date Sun, 19 Aug 2007 12:47:29 GMT
On Sat, 2007-08-18 at 13:37 +0200, Mario Ivankovits wrote:
> If, we have to use the (never ;-) ) upcoming myfaces-commons project.
> Are you willing to volunteer?

What, is tomahawk dead? I must check the myfaces archives....

> > And separately, both Shale and Orchestra ViewController
> > depend upon having managed beans with names that "match" viewIds in
> > order for the controller to figure out which bean to invoke methods
> > 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.

Hmm..this really tightly couples the source code of the bean to the
current JSP structure. Moving a JSP page means changing the source code
for a class...

In JSF, pages reference beans via EL expressions. There is no avoiding
the fact that the presentation layout depends upon the code that
provides the actual data to present.

But backing beans don't reference pages except in corner cases, like
explicit lookups of components by their id. JSF encourages the approach
of data being "pulled" from backing beans, then updates being "pushed"
to backing beans. This approach means that the dependency is only
one-way, ie backing beans don't care what views they are used in.

In practice, I guess it's only an optional feature that people can use
or ignore. When the backing bean author and the page author are the same
person I suppose it's ok (which is the case much of the time). JPA
annotations have the same theoretical problems (having the database
table names etc hard-coded on the bean) but in practice work for many

It still feels a little wrong to me though.

> > 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
> > to it, and they get invoked for processing phases. These listeners
> > attached by adding f:phaseListener tags to the page. As a
> > 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
> every now and then people arguing that this has nothing to do in the

The JSF spec defines a number of "roles" for people involved in creating
an app:
* Page Authors
* Component Writers
* Application Developers

Yes, in the purist approach a "page author" should be able to create
view and lay data out within them without caring about anything but
where to fetch the relevant data from, and which action methods to
invoke. In particular, they shouldn't really need to know that a backing
bean's lifecycle methods need to be invoked.

The perfect solution would be for JSF to automatically figure out what
beans are referenced by a particular view, then invoke lifecycle methods
on them. That's quite tricky to implement, however. Maybe a custom
VariableResolver could somehow keep track of what beans are referenced
in a page and invoke the right lifecycle methods on them, but I wouldn't
want to be the one to implement that :-).

An alternate solution would be to force a page to "declare" all the
beans it uses at the top of the page, and for it to be an error for any
EL expression to reference a variable that has not been "declared". The
declarations could then be inspected to find beans to invoke lifecycle
methods on. However that's not part of the JSF spec.

So in *practice* someone has to manually create a list of the beans that
need to have lifecycle methods invoked on them for a particular view.
Now as the "page author" is the one who knows what views exist, surely
it must be this person who is also responsible for defining the
view-to-bean mappings. How can the "application developer" who writes
the backing beans do this when the views (theoretically) are not written
until later?

With the approach of mapping view lifecycle events to backing bean
methods via magic bean names, or external files, the "page author" then
needs to mess with faces-config files or similar which seems ugly to me.
Allowing them to define these mappings directly in the views they are
already creating only seems logical. The "page author" will presumably
be referencing some documentation created by the "application designer"
that lists what backing beans exist, what properties they expose, and
what action methods are available. So for this documentation to also
specify that certain property getters or action methods cannot be
invoked unless certain lifecycle methods are configured for that backing
bean doesn't seem unreasonable.

BTW, t:saveState tags don't seem unreasonable to me either. Again, only
the page author knows how many views are part of a conversation, and
what backing beans those pages want to access. So surely it is the page
author that needs to associate the needed backing beans with the
conversation scope. And as the page author is already editing pages, why
should this (bean, conversation) coupling be defined anywhere else?

> > Note that although the f:phaseListener tag does require the target
> > implement PhaseListener, I'm not suggesting that this point directly
> > the backing bean. Requiring a backing bean to implement
PhaseListener is
> > not very nice. There are a number of possible solutions to this that
> > can post if people think this approach is worth investigating
> >   
> However, if people think this is the way to go, I am sure it is easy
> create such a JSF tag too.

Am I right that the whole point of this ViewController stuff is just to
allow the dynaForm component to work? If so, maybe what we need to do is
not debate the ViewController stuff but look at whether dynaForm can be
implemented in a way that doesn't need it..



View raw message