Yes. =:o)
Of course, if a presentation layer had very specific requirements, it may still need to do something on its own. So, the ContextHelper should first expose the raw elements, so a helper servlet could use those directly. But, it should also provide a series of convenience methods that presentation layers like Velocity and JSTL could call directly. I'd also like to take a closer look at what X2 is doing, and develop a ContextHelper that will serve the needs of Velocity templates, XLST, other DOM-based systems, JSP tags, and even (ugh!) JSP actions and scriptlets. (Anyone else out there?) All of these systems need the same things from the controller, they just have different ways of wrapping the data up once they get it. The JSP taglib support was a necessary proof of concept, but it's time to move past that now. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Gabriel Sidler wrote: > > Ted, > Thanks, that's good input. If I understand you right you > are basically saying > > - Define your optimal view API, not worrying much about the > existing JSP view API > - From the view API we'll derive a controller API. Ideally, this > controller API should be able to satify the needs of all view API. > > Am I correctly interpreting your input? > > Gabe > > Ted Husted wrote: > > > > 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]> > > -- > Gabriel Sidler > Software Engineer, Eivycom GmbH, Zurich, Switzerland > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
