struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <mr...@twdata.org>
Subject Re: Should I announce SmartURLs or wait?
Date Wed, 12 Sep 2007 00:12:54 GMT
It shouldn't be too hard to create a struts2-standard.jar, which
contains the contents of struts2-core plus several choice plugins.
Spring puts out a spring.jar, which contains their trusted modules,
and I don't see why we couldn't do anything similar.  Of course, we'd
have to choose plugins that don't conflict and we'd have to write a
tool that would combine their struts-plugin.xml into one file, but
both should be trivial.

Don

On 9/12/07, Brian Pontarelli <brian@pontarelli.com> wrote:
>
>  Ted Husted wrote:
>  On 9/11/07, Brian Pontarelli <brian@pontarelli.com> wrote:
>
>
>  If we keep it a plugin then I would suggest removing zero-config from core
> so that they don't conflict. I'd probably also want to rework the
> DispatcherFilter to make it more pluggable so that the majority of the work
> is from injections and then it can be changed without modifying the web.xml.
> Lastly, the configuration providers need to be easier to setup. This would
> probably require a more robust configuration mechanism that would pre-inject
> configuration providers and then inject the rest of the container.
>
>  I think this is the strongest argument for plugging in as much as
> possible ourselves. If we can do it, then someone else can do it too!
>
> Don put in the plugin architecture less than a year ago, and our first
> stable release was only four months ago. Already, we have a couple of
> dozen plugins, including SmartURLs, and we're learning how to extract
> other functionality like Ajax and Portlets into plugins too.
>
> I'd say we should continue to exploit the plugin architecture, so that
> Struts becomes a lightweight core adorned with plugins. We should
> encourage people to think of Struts plugins they way we think about
> Eclipse or Maven plugins.
>
>  I do think this sounds pretty good. I like the plugin architecture, but it
> needs more functionality and extensibility to make it a complete solution.
> Right now not enough of the core infrastructure is exposed to plugins and it
> is difficult to make things just drop in and work.
>
>  I think it can be done, it just needs some good discussion and some changes
> to core.
>
>
>
>  However, all that said, I think this should be in core. The beauty of
> frameworks like Rails and Grails is that they give all the conventions right
> out of the box. I feel like Struts should try to strive to match the ease of
> these other frameworks. Otherwise, it requires the users to actually know
> that the plugin exists, go find it, install it and then learn it all.
>
>  I'd say it's way too early to say we've hit the best and brightest way
> to do this. (Or that Rails or Grails has either!)
>
> If we starting rolling things like this into the core, then as you
> pointed out, we start to foreclose possibilities for alternate
> plugins, or at least make it harder for other people to innovate.
>
> There is a lot more to Rails or Grails type functionality than zero
> configuration and code behinds. To really do "Struts on Rails", we'd
> need to encourage people to use Maven prototypes to create starter
> applications, which could easily include items like the CodeBehind 2
> plugin, along with starter actions and pages, test cases, and so
> forth. We also need to think about items like Hibernate or iBATIS
> plugins.
>
>  I'll definitely agree on that point. In fact I've already started work on a
> system just like the one you describe. However, I selected the frameworks
> and unlike systems like AppFuse, I decided to not give choices for
> frameworks, but give more functionality. It's called Vertigo and it contains
> an entire build system with project creation (based on Ant and Savant for
> dependencies), database migrations, emailing via FreeMarker and concurrency
> utils, environment aware configuration with a hierarchy, injection via
> guice, JPA support, security (via ACEGI, which does require Spring, but that
> will soon be refactored), common actions like country drop downs, ECommerce
> transactions (currently only via authorize.net), a good set of domain
> classes and base classes, and more is being added all the time.
>
>  Take a look if you guys get a chance:
>
>  http://code.google.com/p/vertigo-java
>
>
>  One compromise would be to keep CodeBehind/ZeroConfig as a plugin, in
> its own JAR, but to ship it in the struts-lib distribution, and make
> it a standard part of any applications or prototypes we offer. People
> won't have to go and get it, because it will already be there. But, if
> someone wants to try something different, they can pluck it out.
>
>  I like this the best. I think Struts should have a standard convention
> based system that comes with the distribution and is part of the core
> documentation. Folks that don't want it, just yank the JAR out of
> WEB-INF/lib. Those that want it, have it. I think the key is to have it as
> part of the core documentation so that folks know about it up front.
>
>  -bp
>
>
>

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


Mime
View raw message