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. 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. 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. 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 ;-) - 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. 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 .... Ciao, Mario
