Comments below... Robert McIntosh
-----Original Message----- From: Jack Frosch [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 12:14 PM To: Struts Users Mailing List Subject: Wondering About Struts... 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. -- As I am sure you are aware, Struts is more than just a tag library... 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. -- This is a nice feature of Struts, but the 'workflow' is a tad limited, which is why we created a scripting engine (using XML scripts) that can be used behind Struts (only one Action need be used for most cases). 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. -- This is a bit of a pipedream, but in some large organizations, it does happen this way. Not all, but some. 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. -- This is true too, but then again some web developers are more comfortable working with XML tags, since it is so much like HTML tags. I know a few of them. It could also be argued that there are few web developers anymore who do not build dynamic pages of some sort, so adding in scripting to a page is not all that difficult. Not really a 'correct' way to do things, but that's what happens. 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. -- Again, good points. One of our clients has more web developers than Java developers, and thus anything that can be done without Java code is better for them (this applies to any of the above statements as well). However it should be noted that quite a few of the tags used by Struts will made available outside of the Struts arena, namely into the Common Taglibs. I don't necessarily agree with ALL of the tags that Struts uses, but they are there if you want them. Most of them you don't HAVE to use, but they make things easier, like the <bean> tags for example. Personally, I don't use the tags unless it is needed. i.e. not every one of my forms is built using Struts form tags. Only those that are going to be prepopulated, or need to be validated use Struts forms (not all forms need validation of course!). Using tags can cause some overhead on the servlet engine, depending on how it handles tags, so some load testing might be called for. 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]>
