I agree. I think Spring integration stuff should be left out of the core
distribution personally. I was just throwing that out for the sake of
letting it be known that the option was there. Since Stripes already has
Spring integration that does not meet the full functionality that Spring
users would expect to have, I figured it may be desired to include in the
core.
Another idea would be to keep Stripes very minimalistic (which I like) and
create a sourceforge project that contains extensions that expand upon the
core Stripes. In this scenario it might be a good idea extract the existing
core Spring support and combine it with Stripes-Spring to provide a fully
comprehensive Spring support extension that can be made available along with
other maintained extensions.
RE: why constructor injection...
The reason for constructor injection comes down to 2 things really...
1) Testability - It is easier and safer to unit test a class that has
constructor injection. There are certain instance variables that you would
not want to make available via a setter/getter. Additionally, it is easier
to pass in a mock object via a constructor when testing.
2) Clarity of functional expectation. The constructor helps define what is
expected for the class to be complete. If you define a constructor you
define what is *required* for the class to function.
RE: why an optional ability for spring managed action beans...
Since constructor injection itself is a desirable feature, it opens up the
option to accomplish this in Spring itself. This allows for Spring users to
use standard Spring xml definitions to do this. I personally don't use this
aspect. But, I can see users who may want this in order to retain
constructor injection configuration consistency.
Brandon Goodin
On 10/2/07, Kai Grabfelder <[EMAIL PROTECTED]> wrote:
>
> Hi Brandon,
>
> thanks for your addition!
>
> I would create a child page of [1] (just register and you should be able
> to contribute in this section),
> describing your addition in short and linking to the relevant parts of
> your website. I could also link it from
> somewhere else in the wiki, if you find a good place to link it let me
> know.
>
> Whent it comes to putting your extension into the core I'm not really sure
> if this should be done. I think Tim
> wants stripes to stay quite minimalistic and I don't know right now if
> constructor based injection and the
> option to define action beans in the application context is really needed.
> Maybe you want to create a Jira
> issue for this? Maybe you could mention why exactly you want to be able to
> define your actionBeans in an
> applicationContext?
>
>
> Regards
>
> Kai
>
>
> [1] http://mc4j.org/confluence/display/stripes/User+Additions
>
> --- Original Nachricht ---
> Absender: Brandon Goodin
> Datum: 02.10.2007 18:26
> > Hey All,
> >
> > Is there a place to list extensions in the Stripes wiki? I have
> developed
> > Stripes-Spring which expands on the existing Spring support in Stripes.
> It's
> > a small extension that is OSS under an Apache 2 License. You can view
> the
> > site at http://www.silvermindsoftware.com/stripes/. I would like for
> users
> > to know about it and I figured the wiki would be a good place to start
> > listing extensions. I'm also not opposed to the source being absorbed
> into
> > the Stripes core. However, I don't want to be presumptuous.
> >
> > Thanks,
> > Brandon Goodin
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Stripes-development mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/stripes-development
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
