Re: [Wicket-user] Re: Wicket, Spring and Hibernate

[Igor Vaynberg]

i was just falling asleep and thought of something (still sleepy so dont know if this will make sense in the morning). with all this talk of testing why not borrow a page from spring's book. have a IInitializingPage { void afterPropertiesSet(); } and have the injector check for this and call it after its done populating the page. I know this isnt as clean as spring because the order is a bit out of wack - afterPropertiesSet is called before the constructor of the page is finished but if you leave your constructor blank and move everything into that method i think it should work. and you can have total control over dependencies in unit tests w/out anything special just set the injector to a noop injector and call afterPropertiesSet() yourself.

how does that sound? will this make things easier or dirtier?

-Igor

On 12/7/05, Jim McLaughlin < [EMAIL PROTECTED]> wrote:

John Moore wrote:
> Jim McLaughlin wrote:
>
>> I just started up a project using wicket, spring, and hibernate
>> following the instructions in
>> http://www.wicket-wiki.org.uk/wiki/index.php/Spring . While it is not
>> full step-by-step boiler plate, a half hour to an hour of noodling
>> around this page and the wicket-phonebook example should have you up
>> and running.
>
>
>
> Which approach did you go with? Application Object or Proxy Based? I'm
> all for an easy life and thus the Application Object approach is rather
> more appealing. I'd like to know a bit more about the downsides, though.
> The wiki says:
>
> "Application class might get cluttered if the application has a lot of
> dependencies"
>
> I can't see that being a particular problem for this project unless I've
> misunderstood something, so I'm interested in anyone else's thoughts on
> this.
>
> John
>
>
We are using the proxy based approach. This is what is given to you if
you use the SpringInjector provided by wicket.contrib.spring. Just set
this in your InjectorLocator when your webapp starts up. I think the
point of both appraches is to let you operate in a clustered
environment, but the proxy approach is way more elegant. If you use the
Application Object approach, you need to manually fetch your
dependencies from it, which diminishes some of the advantages of spring d-i.

The only disadvantage to the proxy approach is the way it interferes
with unit testing, but there are a bunch of clever ways around that as
shown in the previous thread.

hth,
Jim



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user