Re: [Wicket-user] Spring Integration

Jonathan Locke Tue, 11 Jan 2005 08:07:15 -0800

yes. your use case makes total sense to me. i think that what you're trying to do should be made as easy as possible and should ideally not involve downcasts.

Martin Fey wrote:

Hi,
I understand that you do not want to use Spring for wiring up the UI components; you follow another approach as you point out in the users' guide. So the Wicket pages don't need to be Spring managed (also it would be nice for the purpose of injecting business beans as Kevin also pointed out), but it would be great if they are Spring enabled, i.e. having access to the ApplicationContext in a transparent way. That is why I try to inject the Spring ApplicationContext to a Wicket page.
Spring gives me access to my service objects containing the business
logic and I would like to access the services from within my Wicket
pages in a non invasive way. Another point is, that it is very popular
to access Hibernate via Spring managed beans, because Spring has a good
DAO abstraction. E.g. I would like to populate the model for a table
component with data from this Spring managed Hibernate bean and that is
why I need access to Spring from within the constructor of a Wicket
page.
It is possible to create a custom subclass of HttpApplication for
storing a reference to the ApplicationContext, but I need to downcast to
that particular class in my Wicket page. This works, but it's not very
elegant, I think. Comparing to this solution I would prefer setting the
ApplicationContext in the ApplicationSettings and therefor
ApplicationSettings should support storing arbitrary objects.
Martin
[EMAIL PROTECTED] 10.01.05 19:03 >>>
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: - 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 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.
- Automatic injection of the ApplicationContext in a Wicket page, so that I don't have to query for the ApplicationContext:

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.
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
-------------------------------------------------------
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

Re: [Wicket-user] Spring Integration

Reply via email to