Grokbase Groups Struts dev June 2006
FAQ

[Struts-dev] Does Struts really need two frameworks? (long)

Dakota Jack
Jun 22, 2006 at 10:12 am
That's right. The problem is the presence of any and all JSF hacks.
On 6/21/06, Alexandru Popescu wrote:

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.

BR,

./alex
--
.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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
reply

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions