That's right. The problem is the presence of any and all JSF hacks.
On 6/21/06, Alexandru Popescu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
