Wicket doesn't require anything. And that is both good and bad. It is
good because it gives you - the developer - complete freedom on how
you do things, including building in support for Spring integratoin.
It is bad because, as we don't manage the lifecycle, it is harder to
come with a default schema of such support.
What I am looking for is some default IoC integration that proves it
can be done. I primairily would like to do that because it will
probably expose weaknesses/ inflexibilities in the process, which can
then be fixed.
To be honest, for me personally, it is not such a big deal because I
am not a Spring user, nor do I have problems with the service locator
pattern. But there are a lot of people that want the 'right'
integration with Spring, so we should keep on searching after it. See
whether we can combine the different ideas we have now, and whether we
can come up with a few new ones. Then hopefully, just as I hope will
happen with the different database/ hibernate packages we have now,
we'll end up with consensus on what would work best for Wicket.
Eelco
On 8/22/05, Joni Suominen <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-08-22 at 12:31 +0200, Martin Fey wrote:
> > The serializable-thing is one reason why there is a integration
> > contribution in form of a pull model: SpringBeanModel
> >
> > I'm not yet convinced that Spring-managing Wicket-components (or parts of
> > them) is a really good idea, because of all the issues discussed earlier in
> > this mailing list (e.g. unavailability of Spring in the constructor). I
> > think the Model-interface is the best extension point for integrating other
> > tools and frameworks.
> >
> > But I'm curious about the other ideas.
>
> Does Wicket require one to add components on constructor? In Spring we
> often do initialization by implementing InitializingBean interface.
> Spring bean factory ensures that all properties are injected before
> calling the interface method:
>
> public class MyForm extends Form implements InitializingBean {
> private transient MyDao myDao;
>
> public void afterPropertiesSet() {
> Assert.notNull(myDao);
> ...
> add(new MyOtherComponent());
> ...
> }
>
> public void setMyDao(MyDao myDao) {
> this.myDao = myDao;
> }
> }
>
> --
> Joni Suominen <[EMAIL PROTECTED]>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
