Martin Fey 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.
absolutely!
So I want to share my considerations:i don't understand how spring could add value to pages. pages are already incredibly easy in wicket and a lot of the work is on the shoulders of designers. wicket is not in favor of making pages XML configurable because that is explicitly against the framework philosophy. if you're new to wicket, just trust me on this for a little while. you are NOT going to want to wire up wicket pages in any other way than the way that wicket wires them up.
- 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.
i'm sure we can achieve this once we understand the problem. but again, i don't think there is any value in having spring construct pages. it's already easy enough. wicket has a very transparent, OO, MVC methodology for doing all this.
- Automatic injection of the ApplicationContext in a Wicket page, so
that I don't have to query for the ApplicationContext:
if there are reasons to want the context in a page that have to do with data models or other things, we can figure out how to make it available for those purposes.
but the bottom line is this: wicket is already full on swing-like MVC. there's no need to improve on this! please look at the examples and use the framework and you'll see what i mean.
=> 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;
}
}
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
------------------------------------------------------- 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
------------------------------------------------------- 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
