struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <>
Subject Re: Does Struts really need two frameworks? (long)
Date Wed, 21 Jun 2006 08:09:23 GMT
Hi everybody!

I've read this thread a couple of times, because I was having a
somehow weird sentiment while doing it. Now, I think I have figured it
out :-). So, please bear with me for the short following paragraphs (I
am not a good writer yet):

1. even if I don't know too many details about Struts history, I
somehow agree with Don's opinion that changing it to be an umbrella
project may become confusing for the existing users, for new users and
for users that might consider migrating to newer approaches. But...

2.  this single package, solve-all idea, is something that RoR prooved
to be the wrong approach. I am playing now with RoR and I frankly
don't see anything in RoR over WebWork (really). But, what I am seeing
behind RoR is a very simple idea: drop it in and it will help you
build very quickly an web app (or at least some of them). And the
single-package-solves-all is exactly the opposite. People will not be
able to just drop in a couple of jars (for people knowing RoR, read it
a couple of gems) with their dependency managed directly and start
working on your app in a couple of seconds. It will be something like:
drop this in and now let's start and think: what other piece do I
need? Is it actions? Is it JSF? Is it X or Y? What dependencies should
I use for X over Y? And so, we are once again gonna fail the
simplicity that RoR proposed to web development (and IMO this is the
sole real contribution). Convention over configuration cannot work
with a big-solve-all package/framework. And this will leave the Java
web apps world for another period as a "zombie in the dark".
WebWork has tried to adapt to this new approach proposed by RoR. And
it was nice to see it. We may have a few more ideas to make it even
simpler in the near future. But this will not work with the
big-solve-all approach.

Indeed, this may look at the first glance as another, but opposite
radical view. It is only my opinion, as a guy being involved in the
Java world for 10 years and seeing everywhere people thriving to take
a decission. IMO another big-all-solve-all approach will not be able
to solve this problem, nor to simplify it in the future.


.w( the_mindstorm )p.

On 6/21/06, Don Brown <> wrote:
> Ted Husted wrote:
> > As for making the UI tags an independant extension, a al Tiles, that
> > sounds good too. (Even better if we include the "value added" Ajax
> > support.) But I don't know if we want to hold back the SAF 2.0.0 to
> > make it happen. But, for phase 2, sure!
> Actually, I'm thinking splitting off the tags would help us get SAF
> 2.0.0 out the door sooner.  A lot of our remaining tickets are for AJAX
> tags, which would be in this new project.  As for the Tiles comparison,
> that is exactly what I was going for.
> And to be clear, the tags, at least for the near term, would stay
> dependent on Struts Action 2.  The reason to split them off would be to
> give them their own release cycle and make Struts Action 2 releases more
> focused and quicker.  The tags have their own group of interested
> committers, so I don't see a repeat of our last spinoff attempt. :)
> Don
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message