Many people use Struts without using the custom tag libs. Struts itself is primarily a front controller, the taglibs are provided as convenient way to access the controller's "model" or "configuration".
The Actions hae full access to the request and response, and anything else you can do with a Java Web application can be done there. In Struts 1.1, we've added a ContextHelper object to make the configuration available to more presentation systems. Velocity templates and the JSTL for example. Eventually, the JSTL will a very positive impact on using JSP tags in development. But that's still around the bend. In the meantime, there is a lot of good things to be said about Velocity. The syntax is very light, but also very powerful. Most people, especially page designers, can up and at it after only a few minutes. It also works well from inside visual HTML editors. It's mature, and forms the basis of most Turbine applications, including Jetspeed. The Velocity team has come up with a toolkit and adapter that works with Struts 1.0. This will really give you something to wonder about ... http://husted.com/struts/resources/velstruts.zip -Ted. Jack Frosch wrote: > > Having only worked with Struts for a couple of months, I'm beginning to > wonder about the costs and benefits of using Struts, or any other JSP tag > library, for that matter. > > At one level, it adds a great deal of support for maintaining session state > and managing work flow in a web application. I really like being able to > use a declarative approach to workflow; i.e. If this action is invoked, go > to A. If it succeeds, go to B. If there's an error, go to C. Trying to > manage all the possibilities in code is a real headache. The Form support > is also quite useful, especially with its validation and error reporting > mechanism. > > However, I'm not sure about the value of many of the tags. The literature > talks about how custom tags allow web developers and Java developers to work > independently. It is said that, using custom tags, we can keep Java code > out of web pages. Thus, Java developers don't have to learn HTML to > generate it in their code and web developers don't have to learn Java to > understand all those JSP code snippets. > > However, it's my observation that a custom tag library becomes almost a > third language that neither web developers nor Java developers understand. > So instead of forcing web developers to learn Java, or forcing Java > developers to learn HTML, custom tags force both groups of developers to > learn a unique semantics for a custom tag framework. > > Now, if a Java developer does learn HTML, s/he's added a skill with wide > application. If a web developer learns a bit of Java, s/he's added a skill > with wide application. If both parties learn a custom tag API, they've > added a skill that's only useful with that particular custom tag API. If > one goes to a different project using different custom tag libraries, one > has to start learning a new custom tag API all over again. > > I'm not interested in starting some kind of religious war by this post. I'm > just wondering how much the benefits outweigh the costs of using Struts on a > project. > > Jack > > -- > 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]>
