Ted, I finally got around to study your post from last week regarding the ConfigHelperInterface. See below.
Ted Husted wrote: > > This look quite good Gabriel. I also made a pass on the original > ContextHelper object, and reduced it to an interface, which essentially > dovetails with this API. There are some minor differences, which I will > need to give some additonal thought. > > http://husted.com/struts/resources/ConfigHelperInterface.java > > The name change corresponds to the new support for multiple Struts > configurations. The goal would be to provide an object that worked with > both 1.0 or 1.1, and supported multiple configurations when they are > being used. My original object compiled fine, but I need to test it, and > then add the new configuration support. > > Currently, the default type for other Struts controller elements, > ActionMapping, ActionForward, et cetera, can be specified in the > ActionServlet configuration. I'm thinking that we could do the same with > the ConfigHelper. There would be a default base object type, but another > could be specified. For example, a Velocity ConfigHelper might provide > signatures that didn't bother with the get* convention, and provide > additional helper methods. That's an interesting way to look at it! But, it raises a few concerns and/or questions on my side. - It would be difficult to support applications that use multiple view technologies at the same time. - You would need to maintain multiple version of the ConfigHelper. - I don't see ConfigHelper being used directly as a context tool in Velocity for several reasons: o We have the concept of a toolbox that contains the context tools. Tools need to implement the ContextTool interface. This allow the toolbox to manage the tools. o I believe it is better to have several small tools rather than one large tool. o The context tools should be on the Velocity side of the fence to give the view people the flexibility in building view tools. On the other side, I wish very much to be able to build on a "Struts Views API" that offers all the functionality the controller framework offers to views. The ContextHelper you wrote contains a lot of framework know-how. Having this on the Velocity side would be wrong. The only reason I moved ContextHelper to the Velocity side in the past, was that this allowed me to support Struts 1.0. In the medium to long term this should be on the Struts side. 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? 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? Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
