Just a Note:
Open-source aside, making medications (patches) to
code for work around in libraries, frameworks,
even compilers and os, has always been part of software development.
Maybe we should have a Struts offramp.
- Malcolm
> -----Original Message-----
> From: Lacerda, Wellington (AFIS) [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 06, 2000 3:00 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Article on JavaWorld
>
>
> 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]
