I'm saying that the framework should be exposed to the View through a coherent object, which we've been calling the ViewContext.
The ViewContext would be the cannonical means by which any rendering component interacts with the framework, including our own JSP tags. As far as a View technology would know, the ViewContext would be Struts. Rather than create a monolithic ViewContext, I'm now suggesting that we create it as a facade over a standard set of Velocity Tools. Developers could then plug in replacement tools, or add other application-specific tools to the context, for their own use. -Ted. On Wed, 16 Feb 2005 10:18:51 -0800, Don Brown wrote: > Hmmm...now I'm confused. As I understand, the point of Velocity > Tools was to create a framework that would allow tools that would > be "pushed" into a context to be used by the view. You are saying > the tools would be used themselves outside the view by the > framework? > > Don > > Ted Husted wrote: >> On Tue, 15 Feb 2005 17:26:21 -0800, Don Brown wrote: >> >>> For implementation, I would favor adding a >>> ActionContext.getViewContext() method that returns a generic >>> Context map. The request processing chain could have a command >>> or chain of commands after the action executes to process the >>> ViewContext, adding in any other objects the view might need. >> >> >> This might be the best way to say it: >> >> * ViewContext is a non-static TagUtils class >> >> made available through request-scope. >> >> Originally, I was thinking of the ViewContext as an augmented >> Context, like the ActionContext. Essentially, the portion of the >> Struts API that we need to write the taglibs: Methods like >> getLocale and getTokenName, but without irrelevant methods that a >> rendering technology doesn't need. >> >> When I started to looking at the Velocity Tools for an example of >> just such an API, I realized that the tool mechanism itself is >> also quite useful. Rather than come up with a static API, we >> could take the Velocity route and put objects (or "tool") into >> the ViewContext. The tools would then provide access to the >> Struts internals, rather than the context itself. >> >> A synergistic approach might be to augment the ViewContext with >> the methods we need to write tags and other rendering devices, >> but implement those methods as a facade that calls into a >> standard set of tool objects. >> >> So a call to >> >> * viewContext.getLocale >> >> might be implemented as >> >> * return textTool.getLocale((); >> >> where "textTool" is a private member instantiated when the >> ViewContext is created for this request. The same TextTool would >> also be available under a standard key through >> ViewContext.get(String). >> >> We would plug our own "framework" tools into ViewContext and let >> applications do the same with their own tools. >> >> The advantages being >> >> * No more static TagUtils >> * Coherent API for tags and other rendering tools * Pluggable, >> extensible implementation >> >> The best part is that the Velocity crew has already done all the >> foundation work. We just have to adopt and adapt :) >> >> -Ted. >> >> >> ------------------------------------------------------------------ >> --- To unsubscribe, e-mail: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
