What is "the full power of Struts" ?
I was misled to believe it was flexibility !
I remember seen in this list few months ago some messages about Struts being
VERY flexible in terms of usage scenarios. I can use just the MVC main
process and forget about the tag libraries.
One can use just the i18n mechanism and implement out all the other stuff.
Or the forms.
Here where I work, Struts i18n mechanism would be happily ignored, just
because we have our own stuff. STILL it's MVC nucleus is very fine and the
validation stuff...hmm... there's this problem too: we do prefer don't use
the massive number of beans real big sites will demand from Struts.
Who cares if you use scriptlets ? I also believe using tags massively will
reduce the complexity of a page, will enable massive reuse, a very fine
separation of roles, but...what if the company has only Java programmers as
JSP designers ? Most of these arguments are based on cultural more than
technical reasons. If a company has a culture devoted to light design more
than programming, maybe one would like to use tags to encapsulate.
Otherwise, if the environment is made of JSP freaks that use HTML mock-ups
to build applications upon, the aim would be reuse. Otherwise, if the
environment is made of Servlet freaks, who will care about JSP ???
Maybe, being a first article on Struts, it could pass a personal view more
than an "institutional", so ?
Wellington
-----Original Message-----
From: Jean-Baptiste Nizet
[mailto:[EMAIL PROTECTED]]
Sent: 05 December 2000 15:09
To: [EMAIL PROTECTED]
Subject: Re: Article on JavaWorld
Thor Kristmundsson wrote:
> It would have been a good idea to ask this list first.
Unfortunatly I didn't
> know the list existed until a few days ago. A few weeks
back I looked for
> contact information on the Struts website and found an
email address
> reserved for "the press".
If you had looked with a little more attention, you would
have found the various
Struts mailing lists at the bottom of the Struts home page.
It always impresses
me how technical "gurus", writing in the press about
technical products, don't
even evaluate them in details.
> I sent an email to this address asking for a phone
> number of someone to talk to about the article but got no
response. It even
> occured to me that the project might be dead. I agree that
the whole of
> Struts deserves attention. Not just the tag libraries. And
I'm glad to hear
> that books and articles are on their way to cover the
whole. I can't see
> though how focusing on the tag libraries is harmful.
It's harmful because you ignore the full power of the
framework and thus
reinvent the wheel. For example, Struts has a wonderful
validation mechanism,
but, unfortunately, lacks some tags for displaying the
validation errors in an
elegant way to the end user (the errors tag is not
sufficient, IMHO). You
focused on the tag library, saw that these tags were
lacking, and thus
reimplemented the whole validation mechanism. On the other
hand, I know what
Struts is able to do in terms of validation and thus just
implemented two
additional tags for displaying them in a more elegant way
(See below for
details, if you're interested).
>
> Thor Kristmundsson
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Dienstag, 5. Dezember 2000 12:41
> To: Struts List
> Subject: RE: Article on JavaWorld
>
> On 12/4/2000 at 4:49 PM [EMAIL PROTECTED]
wrote:
> > As Jean-Baptiste said, surely the right way to do it is
to add or
> extend classes?
>
> Developers in the open source community have always
patched code to
> meet specific requirements. A prime argument for open
source is the
> ability to choose between patching and extending.
Obviously, developers
> who patch take the responsbility for applying the patch
again later.
I agree completely with all this, but I think that
1. Extending should be preferred to patching when possible
2. A product should not be patched if it already has the
functionality provided
by the patch (ex: validation)
>
> And, of course, Thor could have posted questions about his
patch to the
> list first. But now that the article is published <
>
http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html >,
> lets ask the questions:
>
> "How could Struts accomplish the same result without a
patch?"
>
> and/or
>
> "Should these patches be added to Struts?"
>
> If alternates turn up, they could be posted somewhere as
an addendum to
> the article. (Or, in a followup article?) It might also be
nice to see
> another addendum that addressed the shortcomings Craig
mentioned <
>
http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg00891.ht
> ml >.
>
> But, let's see some code, guys.
>
Here's the doc of two tags I wrote to handle validation
errors. They allow to
display a message, or an image, or anything else, just next
to the field the
error is associated with, by leveraging the Struts
validation mechanism. Te code
of these tags is trivial. I leave it as an exercise for the
reader to implement
them ;-)
ifErrorExists - tests if a specific error exists, for a
specific property
Executes its body if a specific error is found. If name is
not specified, the
tag checks if one or more errors exist for the specified
property. If name is
specified, then the tag checks that the specific error
exists for the specified
property. If not specified, the property defaults to the
"global" property,
i.e., the tag searches for global errors, not associated
with any property.
Attribute Description
Should be omitted in most cases. Name of the
request scope bean
errorsName under which a String[] object has possibly been
stored. [The value
of the org.apache.struts.Action.ERROR_KEY
constant string].
name Name of the specific error to test.
property Name of the property the error is associated
with.
ifErrorMissing - tests if a specific error exists
Executes its body if a specific error is not found.If name
is not specified, the
tag checks if one or more errors exist for the specified
property. If name is
specified, then the tag checks that the specific error
exists for the specified
property. If not specified, the property defaults to the
"global" property,
i.e., the tag searches for global errors, not associated
with any property.
Attribute Description
Should be omitted in most cases. Name of the
request scope bean
errorsName under which a String[] object has possibly been
stored. [The value
of the org.apache.struts.Action.ERROR_KEY
constant string].
name Name of the specific error to test.
property Name of the property the error is associated
with.
>
> Personally, I think Thor's interfaces seem useful, and I
may add his
> patches to my own code base.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/
--
Jean-Baptiste Nizet
[EMAIL PROTECTED]
R&D Engineer, S1 Belgium
Kleine Kloosterstraat, 23
B-1932 Sint-Stevens Woluwe
+32 2 200 45 42
