On Fri, 27 Aug 2004 10:21:58 -0700 (PDT), Woodchuck <[EMAIL PROTECTED]> wrote: > sorry to bring this up on a Friday...
Yah, I didn't know we could have serious discussions on Fridays any more :-). > > does everyone here have pure Struts/JSTL jsp pages that is absolutely > void of scriptlets? Except for some unit tests (where scriptlets are used to configure the initial conditions), yes. > > or do you have jsp pages that use a combination of Struts/JSTL and > scriptlets, all living together harmoniously using whichever method is > easiest/cleanest? > > is mixing Struts/JSTL with traditional scriptlets a bad thing? > It is too simplistic to say such a thing is "good" or "bad" on any absolute scale. As with every other design decision, you have to trade off the impacts of any particular decision on your overall goals -- and nearly every reasonable choice you might consider has some positive impacts and some negative impacts. > i have to say that i would prefer to *not* mix scriptlets with > Struts/JSTL but in some situations it seems scriptlets is the better > solution (in terms of code maintainability). that is, it would be > easier to use a little snippet of scriptlet here and there instead of > making a round-about (albeit clever) and more verbose way of doing the > same thing without scriptlets... > > any opinions is welcome! i want to be able to sleep without nightmares > about this!! :) My reasoning for not using scriptlets is based around technical issues (see below), but they are fundmentally driven by an 80/20 rule I've observed that hasn't been articulated in this thread yet ... 80% of the investment you will make in the lifetime of the application wil be maintenance, versus 20% on the original development. To the extent that this ratio is true, then, it behooves me to choose design approaches that minimize the long term cost of dealing with changes -- and, as we all know, the only constant in life is that it's gonna change. Given this bias, then, my problem with scriptlets: (1) Scriptlets, since they are Java code, require someone at least passably familiar with Java to change them later. If you have folks that are primarily page authors, you are faced with a cost of teaching them enough about Java syntax to make the code it needs to do, or having to involve two folks in every page (a page author and a Java developer), or paying Java developers to maintain HTML. None of those approaches is appealing to me. (2) Scriptlets, since they are Java code, bind you to a particular representation of your data to a much higher degree than scripting expressions do. Take your favorite Struts action form, and implement it first as a DynaBean (because it's faster to prototype that way), and use tags like <html:text> when building your input forms. Now, lets say a requirement changes such that you have to do some specialized work when a form bean property is set or retrieved, such that you need to switch to a regular ActionForm implementation instead. If you used the Struts tags, how much did you have to change the JSP source? None -- the "name" and "property" expressions work with either dynabean action forms or POJO ones. On the other hand, if you used scriptlet expressions, you'd have to change every single one of them. (3) The custom tags do more for you than just set and retrieve data. Here's just a couple of examples where using the tag gets you extra benefits for free: * In order for sessions to work on browsers with cookies disabled, you have to call an extra method to encode them. <html:link> does it for you ... a dynamic scriptlet call does not. * In order to avoid cross site scripting attacks, you want to be careful about writing out dynamic content that was originally entered (on an input form) by users, where it might have "<" and ">" characters in it. The tags filter for you (unless you turn it off) -- naive calls to out.println() does not. (4) Scriptlets, since they are Java code, can do anything that Java can do. This creates the potential for developers to "cheat" and mix business logic and presentation logic together (in the JSP page) in ways that makes maintenance harder (i.e. more expensive) later. Yes, you can catch such things by having your architects and leads do aggressive code reviews, but I'd rather have my architects designing, and my leads managing the development, instead of policing for this sort of thing. None of this is to say that you can't be productive when using scriptlets. But my experience has been that whatever boost they give you tends to be short term; over the long run, you're generally better off desigining for minimum maintenance, rather than designing for minimum initial development. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
