I agree 100% with you. I've had some bitter experiences with that myself
(and that's why I'm writing a book on tag libraries right now - AND Struts
!). But you must concede that, as in my case, there are environments where
life is not made to be that easy.
But you must to concede that, even with tag libraries life don't become that
easier. Reuse is a tricky thing to acquire. You can't reuse too much neither
too few. There are other risks with tags, while components, like component
super overloading (too few tags that make too MANY things) or component
superabundancy (too many of them doing ALMOST the same things). Or, as I
commented, what if the tags just aren't adequate ?
What I was trying to say there is that the argument must be based in all the
shades of gray, and there's no such thing as "THE TRUE POWER" of Struts in
rigid application models. As far as I'm concerned, I see the true power of
Struts in its ability to accommodate all those situations and still
providing a sound and elegant alternative for each case. It is that what
seduced me into the project.
Regarding the article, I see it providing some interesting ideas for a
problem Struts has: excess of beans we have to code for LARGE applications.
There's no technical argument to break the resistance against a BORING
procedure (culture ALWAYS breaks technique - we must remember that). I
provided once a tentative solution creating some tool (FBBuilder - form
beans builder) to try to figure the beans out automatically. Didn't get much
response (I can understand that). This is another approach, generalising the
bean concept. We will have to figure out something about that problem, and
this seems to be a good candidate. Regarding the idea of changing BeanUtils,
ok, why not sub-classing it with an AutoBeanUtils class instead ?
Wellington
-----Original Message-----
From: Dave Harms [mailto:[EMAIL PROTECTED]]
Sent: 06 December 2000 03:26
To: [EMAIL PROTECTED]; Dave Harms
Subject: Re: Article on JavaWorld
Wellington,
> but...what if the company has only Java programmers as
> JSP designers ? Most of these arguments are based on
cultural more than
> technical reasons.
There are still problems with, for example, scriptlets even
in a
situation like this. JSPs are not a particularly
code-friendly
environment. And re-use is more difficult. So I think even
if the Java
programmers are designing the pages, using scriptlets will
tend to make
life more difficult. I think these are sound technical
objections.
Dave
Dave Harms
[EMAIL PROTECTED]
