>From: Mario Ivankovits <[EMAIL PROTECTED]> > > Hi! > > If the view-controller stuff is an optional feature of Orchestra I'd be > fine with directing the users to the shale-view stuff. > However, there is a single feature (@ConversationRequire) which has to > be in Orchestra core15 which requires a view-controller like framework. > > Given the number of jars and the impact shale/shale-view has I am unsure > to force it as an required dependency. > > With impact I mean e.g. that it replaces the UIViewRoot implementation > to catch all the exception stuff.
I'm not very happy with this approach but at the time I didn't see another way. It only works with the myfaces 1.1 runtimes anyway since the sun 1.1 ri doesn't use the application factory to create the view root in the view handler. The basic idea was to make sure the callback events were invoked and provide a pluggable handler implementation. >The shale-tiger stuff replaces the > VariableResolver with something which explicitly checks the tree scopes > to decide if it has to create the bean by itself. The VariableResolver > will work with Orchestra as it won't find the bean definition, but some > shale-tiger annotations wont work then. This seems like a problem that we could solve. > Resulting in a documentation page where we direct the user to the > shale-* stuff, but telling them what Shale stuff will NOT work is also > not a nice thing. > agreed > What I mean is, we can direct the users to shale-view/shale-tiger for > the ViewController stuff, but many of the other functions do not work - > also some - ok; at least one ;-) - I don't think that it would be a requirement for shale view controller to remove the beans. The destroy callback can be invoked from the same place. The only reason for explicitly removing is to make the request attribute listener fire (same mechanism). The reason is to make sure that it is fired while the FacesContext is still alive. >ViewController event wont work as > shale-view explicitly tries to remove the ViewController from the > request-map to force a destroy() event at the end of the request. > I know, in Shale a ViewController has to be a request-scoped bean. I > don't think we should force the user in this question. > The shale view controller needs to be in request scope but there are session and application scoped beans that fire create and destroy methods. The ViewController provides the prerender and preprocess callbacks in addition to bean create and destroy. > I wont argue against Shale at all - it is fantastic what has been done > there! > What I wanted to do is just something like "cherry picking". > > IF we find a way how to provide a @ConversationRequire thing without the > need of a ViewController framework we can drop Orchestras implementation. > Though, everything which came in my mind so far results in ugly code. > I can crop our ViewController that it just supports this single > annotation .... > I understand your concern about the lack of integration. It would not be good to say use this but if you use this, that won't work. I'd rather see us find a way to make it work together even if that means merging codebases or structuring libraries. > Ciao, > Mario > Gary
