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 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. 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 people. 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 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? 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 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. 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.. Regards, Simon
