Nathan Bubna wrote: > overall my impression of the vel-struts package so far is that it is written > to mimic the functionality of the struts taglibs. frankly, i think that is > the wrong approach.
I agree. The focus should be on the controller's API, which flows from the elements defined in the Struts configuration. ActionForward - provides 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. The Struts taglibs are one way to access this API ... among other things. The vast majority of the Struts tags are not even relevant to the controller's API, but strive to provide generic functionality already built into Velocity. Personally, I believe it would be better to provide a "flat" object to access the core controller API, which is what I started to do here: http://husted.com/struts/resources/velservlet.zip Once you remove the HTML-generation, bean-access, and logic-access features of the taglibs, which are not relevant to Velocity, there is not so much left. Most of it is encapsulated in this (demo-grade) helper class, designed to be created by the controller and inserted into the rquest. http://husted.com/struts/resources/ContextHelper.java Once the dust clears on the recent changes to the Struts controller, I think we will get back to providing a controller API object like this in the request that any reasonable presentation device, like Velocity or JSTL, can access without modification. -- 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]>
