Ok, thank you for your detailed opinion about the subject.

 

I can realy use it, because I am going to give a presentation about Wicket soon, and I need to present a solution of integrating with Spring, and I was sure people would start complaining if I showed them the private field thing. Now I can explain why this solution is chosen.

 

Tom


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Igor Vaynberg
Sent: maandag 20 maart 2006 21:32
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] New features Wicket 1.2

 

On 3/20/06, Tom van Zummeren <[EMAIL PROTECTED]> wrote:

Ok it does the same, but it doesn't feel like normal java usage.

this project is not meant to map 1:1 to the way spring works. it is meant to make it easy to get the beans from spring context "injected" into your components.  so what you are saying is that we should check if the page implements InitializingBean and call afterPropertiesSet() on it. but the page is not a bean, so why would it implement InitializingBean interface? what would you put into that method that you cannot do in your constructor?

And besides, you're basically saying that we don't need setters at all, because you can use reflection to set private fields on objects.

no, what i am saying is that in this situation i see no value in adding setter support. we are already doing something dangerous - setting class fields before the class' constructor is executed. this is why you cannot do @SpringBean Dao dao=null; because first the injection code will set the dao to the bean, and then the cosntructor will override it back to null. setters open an even bigger hole here in that you can now have code executing on an uninitialized object. so in order to be safe all your setter has to do is set the dependency and not touch anything else, but then what is the point?

another argument against this is that wicket components initialize in their constructors (good citizen pattern), so in constructor you have to have all dependencies available - so you can only use the injection mechanism since a manual call to a setter is already too late.

wicket components are unmanaged so its more difficult to apply aop type constructs to them. if you really want to have setter support you can create it youself, it wont be very hard.

-Igor

 

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Igor Vaynberg
Sent: maandag 20 maart 2006 17:54


To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] New features Wicket 1.2

 

we can write a traversal for setters, but i really dont see value in it, what is your setter going to do - stick it into some private field.

as far as afterPropertiesSet() callback, you already have it - it is the constructor of the component with @SpringBean annots :)

-Igor

On 3/20/06, Tom van Zummeren <[EMAIL PROTECTED]> wrote:

Ok thanks,

 

By the way, is this the best way to inject dependencies? It works like a charm but it isn't Spring-like to inject a dependency with only a private field. Spring normally uses a setter to do so, and if the bean implements InitializingBean it calls the afterPropertiesSet() method afterwards (to do some validation of the just set dependencies)

Is there an option to do it like this?

 

Tom

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Igor Vaynberg


Sent: Monday, March 20, 2006 5:17 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] New features Wicket 1.2

 

there is more info here:

http://www.wicket-wiki.org.uk/wiki/index.php/Spring

-Igor

On 3/20/06, Johan Compagner <[EMAIL PROTECTED]> wrote:

One warning don't do this:



@SecuredWicketPage public class EditAccountPage extends Template{
    private String repeatedPassword;

    @SpringBean   

    private AccountService accountService = null;



    public EditAccountPage() {
        Form form = new Form("form", new CompoundPropertyModel(this)) {

(the = null)

Because then youre accountService will be null again when the page is fully constructed.


johan

 

On 3/20/06, karthik Guru <[EMAIL PROTECTED]> wrote:

> Spring support for injecting your business logic into your web pages in a non-intrusive manner, while still being able to use the
> convenient Wicket idiom for creating pages (using the Java
new operator).

Yes - this one is my favourite! . ..actually even IAuthorizationStrategy and Ajax support rocks.!..now am not sure which is the best 1.2 feature. May be we s'd have a vote :)

You can inject spring-ified objects into your page / components just by specifying an annotation @SpringBean. Then wicket-spring module takes care of resolving all those dependencies when the component is instantiated.
It does it by using the cool 1.2 feature that allows you to register as many IComponentInstantiationListener as you want.
These listeners get called when the component is instantiated.

wicket-spring registers a IComponentInstantiationListener that runs through your page/components looking for fields that require injecttion (the ones that have @SpringBean specified) and resolves them through Spring's ApplicationContext.

So you just do this -

@SecuredWicketPage public class EditAccountPage extends Template{
    private String repeatedPassword;

    @SpringBean   
    private AccountService accountService;

    public EditAccountPage() {
        Form form = new Form("form", new CompoundPropertyModel(this)) {



and by the time you actually get to use accountService, wicket w'd have already resolved it for you with the help of Spring...and as you can see its all non-intrusive (yeah as long as you are ok with specifying @SpringBean :)) )

wicket team rocks!! - and in this case igor & eelco.. ..great job!

 

On 3/20/06, Tom van Zummeren <[EMAIL PROTECTED]> wrote:

I was wondering if there are any examples yet of new features in Wicket 1.2

 

Because on the wicket site I saw a list of new features in Wicket 1.2, but it didn't say how the new features are implemented.

In this case I'd like to know the following:

 

Spring support for injecting your business logic into your web pages in a non-intrusive manner, while still being able to use the convenient Wicket idiom for creating pages (using the Java new operator).

 

What is this non-intrusive manner?

 

 

Tom

 

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006



--

-- karthik --

 

 

--
No virus found in this incoming message.


Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006

 

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006

 

 

Reply via email to