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]>
