On Fri, 11 Feb 2005 06:30:04 -0600, Joe Germuska wrote: >> The last sentence is the use-case for a ViewContext. >> >> The use-case is not within the RequestProcessor >> but without. The ViewContext is the specific API we want to >> expose to the presentation layer, as opposed to the control >> layer. So, the ViewContext has no semanticas in regard to >> navigation and may have additional semantics in regard to >> rendering. Following the well-worn Velocity philosophy, we want >> the ViewContext to be read-only, free of HTTP and navigational >> semantics, and easy to mock for testing view tools (and only view >> tools). >> >> What you see is what you want :) >> > OK; technically the ContextBase exposes the base > context, so we'd have to decide if the ease of > not copying or proxying for each specific > property outweighs the risk of exposing that for > those who want to play with fire. > > Thanks for weighing in! > > Joe
The thing with the ViewContext is that it is not so much a subclass or superclass of the ActionContext, but a helper class, like TagUtils. A good model for us to follow would be the VelocityTools for Struts. If the ViewContext exposed this API, and nothing else, the Velocity gang have already shown that these methods are all we need to render the V in MVC :) * http://jakarta.apache.org/velocity/tools/struts/ The tools are helper beans which we could combine into a single API, and call it the ViewContext. Ideally, the ViewContext should make an extension like VelocityTools obsolete. If these tools are all Velocity needs to integrate wth Stuts, then I'm sure this API is all that tags and other rendering systems really need too. I'll try to put something together and add an interface and base implementation to o.a.s.chain.contexts so that we have something to play with. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
