Gabriel Sidler wrote: > My proposal is the following: > > 1) Struts defines and implements a "Controller API for Views" that > offers methods to work with the controller resources. For commonly > used tasks, it provides convenience methods. This API is independent > of a specific view technologies. It offers a super-set of the functionality > that all possible view technologies might want to use. Your class > ContextHelper could be the start for this. RequestUtils seems to fulfill > a similar purpose, right?
RequestUtils was the precursor for the ConfigHelper, but RequestUtils was targeted for JSPs. > 2) In Velocity we define a set of context tools that implement the > interface ContextTool. They don't access Struts controller resources directly > but build on the Struts "Controller API for Views". These context tools > basically are a layer above the "Controller API for Views". > > I see the following advantages: > > - The struts framework know-how that is relevant for views is kept on > the Struts side of the fence AND in one place. > > - The views have all the flexibility to make the Struts resources > available in a way that well suits their needs and specific properties. > Specifically, in Velocity the functionality would be divided into serveral > tools and the method signatures would be adapted to benefit from the specific > features of Velocity. In some cases we might add convenience methods > or VelociMacros. > > How do you think about this? Can you also say something about how > RequestUtils fits/does not fit in the picture? That sounds fine. The ultimate goal would be to have the tags use the ConfigHelper too, and eliminate the need for the RequestUtils. -- Ted Husted, Husted dot Com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
