On Mon, 10 Jan 2005 13:08:47 +0100, Martin Fey <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I had a look at the Spring integration approaches of Wicket. It would be
> nice, if the Spring ApplicationContext is not only available from a custom
> subclass of Wickets HttpApplication as proposed so far. The adoption of your
> framework would be higher with a good and more transparent Spring framework
> integration.
> So I want to share my considerations:
> - Wicket pages a Spring managed beans
> => I think this is problematic by now because most often the default
> constructor of a Wicket page isn't used by the Wicket framework, but one of
> the other constructors (e.g. the one passing PageParameters). For Spring
> management the default constructor would be needed, as I can see so far.
>
This is not completely true. In order for a Page to be bookmarkable it
must either have a PageParameter constructor or a default constructor.
But in all other cases your Page constructor might as many arguments
as you like. This is very handy to pass parameters from one to another
without the need to make that Page bookmarkable. setPage(new
Page(...)) is at the bottomline the code which dertemines the next
page to render. Not neccessarily makeing Page bookmarkable, could be
seen as a security feature as well.
> - Automatic injection of the ApplicationContext in a Wicket page, so that I
> don't have to query for the ApplicationContext:
cool
> => I tried it like this:
> 1.) A Wicket page interested in the ApplicationContext implements the
> org.springframework.context.ApplicationContextAware interface
> 2.) Provide the subclass SpringPageFactory:
>
> public class SpringPageFactory extends PageFactory implements
> ApplicationContextAware {
>
> private ApplicationContext springContext = null;
>
> public ApplicationContext getSpringContext() {
> return springContext;
> }
>
> public void setSpringContext(ApplicationContext springContext) {
> this.springContext = springContext;
> }
>
> public void setApplicationContext(ApplicationContext applicationContext)
> {
> this.springContext = applicationContext;
> }
>
> /**
> * Constructor
> *
> * @param application The application object
> */
> public SpringPageFactory(final IApplication application) {
> super(application);
> }
>
> protected Page newPage(final Constructor constructor, final Object
> parameter) {
> Page newPage = super.newPage(constructor, parameter);
> Class[] interfaces = newPage.getClass().getInterfaces();
> if( interfaces != null ) {
> for( int i=0; i<interfaces.length; i++ ) {
> if( interfaces[i] == ApplicationContextAware.class ) {
> ((ApplicationContextAware)
> newPage).setApplicationContext(springContext);
> }
> }
> }
> return newPage;
> }
> }
your extending the default implementation and are subclassing just the
"core" method. Once the page object has been created (constructor
called), you call setApplicationContext(). Is that correct? It is kind
of transparent (automatic) as well, right? If Page implements the
interface, it'll get the apps context. No changes necessary to
existing apps. I like it.
Just thinking .... The application context factory is static, correct?
Does that somehow help to solve the "apps context not available in
constructor" problem?
>
> 3.) Configure the wiring:
> <bean id="wicketController"
> class="wicket.examples.springframework.SpringApplicationController">
> <property name="application"><ref local="wicketApp"/></property>
> </bean>
>
> <bean id="wicketApp" class="WicketApp">
> <property name="settings"><ref local="wicketSettings"/></property>
> </bean>
>
> <bean id="wicketSettings" class="wicket.ApplicationSettings">
> <constructor-arg><ref local="wicketApp"/></constructor-arg>
> <property name="pageFactory"><ref local="pageFactory"/></property>
> </bean>
> <bean id="pageFactory" class="de.bluvo.wicket.SpringPageFactory">
> <constructor-arg><ref local="wicketApp"/></constructor-arg>
> </bean>
> The disadvantage of this approach is, that I cannot access the
> ApplicationContext in the constructor without querying for it, because the
> ApplicationContext will first be injected after the constructor is called.
>
> Martin
>
>
I'll like it. And I'm sure you'll will find a solution for the open
issues as well. I'm happy to discuss your ideas.
Juergen
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
