--- Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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 :-).
Monday is just as bad i guess... nobody is serious on Mondays :)
>
> >
> > 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
i guess it would have been too easy to be a black and white issue.
damn you, grey!! damn you!! lol
> -- and nearly every reasonable choice you might consider has some
> positive impacts and some negative impacts.
uh oh, don't get me started on my English teacher's "Everything is
Connected" philosophy... lol
>
> > 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.
i had always thought the 80/20 rule was 80% design, 20% development..
but your version is true too! (maybe we can say your 80/20 is a
'top-down 80/20 rule' and the one i've always known is a 'bottom-up
80/20 rule') :)
> 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.
lol, tell that to my employers! <sobbing>i'm mr. one-man web app guy,
have to do HTML, javascript, css, java everything
(model,view,controller), jdbc, database design, build deployment (ant),
server admin (tomcat), vss (source control admin)...</sobbing>
<hears whip crackle coming.../>
>
> (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.
great point.
>
> (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.
yea, that's true, i wouldn't want to have to manually maintain URL
rewriting.
>
> * 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.
awesome point. i keep forgetting that tags are really a filter for
this sort of thing.
>
> (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.
yea, that tends to happen. the more scriptlets there are the more
likely they will have some business logic creep into them.
>
> 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.
thanks, Craig. i see your point. tags development may cost a bit more
in the beginning but the benefits later on are well worth it!
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
