Hi! >> 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.... > No, tomahawk is not dead, it is just that tomahawk should be a component library only while myfaces-commons has something like validators, phase-listeners, etc but no components. One might argue this should be part of Shale .... I don't know.
>> 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... > I think the whole separation between page author and bean developer works as long as you have beans just providing a "service" and a page uses many different beans to render its output. If you have a controller bean which gathers all the data required for the page they are coupled .... whatever you'll do. > It still feels a little wrong to me though. </snip> > 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. > Ok, so what we can try is to create a jsf tag which allows one to configure (all) the bean-name(s) acting as view-controller for the page. > 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? > It is a question of what happens first :-) I think first a view will be created acting as prototype and later the bean will be developed. But I won't get cumbersome on this. > 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.. > No, the ViewController stuff in Orchestra is just to have a simple ViewController and based on this the @ConversationRequire annotation working. The dynaForm do not require it. Ciao, Mario
