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
