* unified API
* consistent behavior, performance
* growing industry support
* single-point of functionality management

scriptlets tend to be ad-hoc, slap-together and
not consistent across all JSPs.

performance-wise, i'm unsure.  i'm don't have enough
experience in JSPland to know the subtle details, but
i'm definitely sure that taglibs can be tuned whereas
scriptlets would have to be handled one-by-one.

just my $0.02 though.  i really believe that most java
code should vanish from JSPs.  it's a separation of
church and state sort of belief...  why should UI guys
have to know any java?

also, of interest, is the jakarta taglibs project which
has a very interesting XSL taglib which seems to have all
kinds of potential when thinking about XML...
i think craig contributed to it, so there must be some
struts interest in its functionality.

c

At 09:46 AM 4/26/2001 +0100, Firmin David wrote:
>Hi all,
>Members of my team are gradually turning against using the Struts taglibs
>and resorting to scriptlets.
>IMHO: scriptlets bad,  tags good. I've had more experience in using them
>than the others, but I'm finding it difficult to fight my corner in the face
>of ever increasing skepticism.
>Could anyone out there with really valid arguments as to why the use of the
>Struts taglibs (especially the logic tags as they're getting the most grief
>from my team at the moment) or taglibs in general is "good", or why the use
>of scriptlets is "bad" help me out (in the interest of fairness, vice versa
>arguments also happily received!)??
>
>Thanks in advance
>
>Regards
>David
>
>************************************************************************
>The information in this email is confidential and is intended solely
>for the addressee(s).
>Access to this email by anyone else is unauthorised. If you are not
>an intended recipient, you must not read, use or disseminate the
>information contained in the email.
>Any views expressed in this message are those of the individual
>sender, except where the sender specifically states them to be
>the views of Capco.
>
>http://www.capco.com
>***********************************************************************

Reply via email to