Gabriel Sidler wrote: > The focus has be more on proofing the concept that Velocity > and Struts without major changes on either side.
As a Struts committer, I'm of the opinion that the controller should be doing more to make its API accessible to other presentation systems, like Velocity, JSLT, and DOM-based system. The controller's API exposes elements defined in the Struts configuration file and the message resources. In Struts 1.0, a special helper class, RequestUtils, gives JSP tags access to the controller's API. Now that we are past that proof of concept, the next step is to generalized those utilities into an API object that more presentation systems can use. My first pass at the object was the ContextHelper, http://husted.com/struts/resources/ContextHelper.java In Struts 1.1, this can be created by the controller, or perhaps by an optional service. In Struts 1.0, it could be created by a helper servlet. Craig picked up on the idea of a request-based helper, and rolled into a larger plan for supporting multiple configuration files. The changes were sweeping, and now I have to go back and retrofit the ContextHelper (or its successor) for the new controller. If you want to build a Velocity-specific tool, that is of course your perogative, and I will do whatever I can to promote the use of that tool. But originally I hoped that we could collaborate on a way Struts could expose the controller's API to various presentation systems, to minimize, or eliminate, the need to build view-specific helpers. While I appreciate the sentiment of not requiring changes to Struts, it's easy for that to devolve into a bandage that doesn't address the core issue. Which, for me, is how can Struts best expose the controller's API to the presentation layer. Personally, I would suggest avoiding looking at the controller API and the view API as part of the same banana. The controller API should provide data to the view API, and the view API should then package that data for the presention system (e.g. HTML). So, once the view API is defined, we should work backward and ask what data can the controller API provide so the view API can do it's job. The type of data that the controller can provide involves these elements: ActionForwards - provide a logical name for an URI, so it is not embedded in the page. ActionForms - a JavaBean "buffer" for HTML controls, with a hook for automatic validation. ActionMappings - a configuration object for a server-side Action. Most often the target for a HTML form. MessageResouces - provides localised messages and labels. My concern is that if the focus is placed on the superficial aspects of the Struts taglibs, then the deeper issue of what the tags are trying to do will be lost. The forest won't be seen for the trees. The taglibs are the JSP View API, and trying to shoehorn that into another presentation system may not be worthwhile. The missing link is a coherent controller API that can be leveraged by the JSP View and all other view APIs (like "X2", for example). Since many of the controller API elements live in the request, the only place a complete API object can live is in the request. What would be most useful to me, would be if work progresses on the ContextHelper object - or one like it - that could be generated for Struts 1.0 applications, and migrated back a standard part of the Strus 1.1 control flow. Moving forward, there will be an object like this in Struts 1.1. It's just a matter of whether you would like to use it in this package, or roll your own. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
