Jonathan,
until now, I cannot see any elegant way to Spring-enable the Wicket
pages transparently (by injection or something similar). Perhaps I will
have a valuable idea later on (than I will share it) or another one will
find a good solution.
While I was searching for another approach to make Spring managed beans
transparently accessible in Wicket, I had a closer look at the user's
guide, the javadocs and the source code. I discovered, that the model of
a component / the component's model is something like a core concept of
Wicket therefor providing the interfaces IModel and IDetachableModel and
the implementations PropertyModel and StringResourceModel.
My idea is that the IDetachableModel could be the integration point for
Spring. I choose IDetachableModel in favour of IModel, because the
Spring ApplicationContext is not serializable, but can be easily
accessed from the RequestCycle.
To provide a useful SpringBeanModel (extends DetachableModel), it
should feature (a part of) the power of PropertyModel. Because the
methods doAttach and doDetach of PropertyModel are final, I cannot
subclass it and overwrite theses methods (with code pooling for the
ApplicationContext). But I can delegate to a PropertyModel-member in the
SpringBeanModel-class and using the OGNL-power this way. This
PropertyModel-meber will be constructed with a project spezific
SpringAwareModel, which is able to access a Spring-managed bean of a
spezific type. E.g.:
1.) public class User implements Serializable {
String userRef = null;
public void setUserRef(String userRef) {
this.userRef = userRef;
}
public String getUserRef() {
return userRef;
}
}
2.) spring.xml:
<bean id="user" class="User" singleton="false">
<property name="userRef"><value>Ernst Meister:
987654</value></property>
</bean>
3.) public abstract class SpringAwareModel implements IModel {
public SpringBeanModel springBeanModel = null;
/** Creates a new instance of SpringAwareModel */
public SpringAwareModel(SpringBeanModel model) {
this.springBeanModel = model;
}
public final ApplicationContext getApplicationContext() {
return this.springBeanModel.getApplicationContext();
}
public abstract void setObject(Object object);
public abstract Object getObject();
}
4.) public class UserModel extends SpringAwareModel {
private User user = null;
public UserModel(SpringBeanModel model) {
super(model);
}
public void setObject(Object object) {
this.user = (User)object;
}
public Object getObject() {
if( user == null ) {
user = (User)getApplicationContext().getBean("user",
User.class);
}
return user;
}
}
4.) In a page's constructor: add(new Label("user", new
SpringBeanModel(UserModel.class, "userRef")));
With such a mechanism it would be possible to access Spring in a page
or any other component without knowing how to get it. Spring bean access
is encapsulated in specific model classes.
I'm currently working on such a solution and I can share the code if
you like.
Martin
>>> [EMAIL PROTECTED] 11.01.05 17:18 >>>
i see. well, if we can get the session for a page already, why should
we commit to Session.get() as a public API? it's an implementation
detail that the session is available through a thread local. there
wasn't any other way to pass the session implicitly to the Page
constructor. that's why its implemented like that. if Session.get()
is
really required somewhere, we can think about making it public. in the
meantime, its only accessible internally, which is probably good.
Martin Fey wrote:
>OK, but the method Session.get() is not public but package protected.
On
>the other side the method Session.set() is public.
>
>Is it possible to make both methods public?
>
>Martin
>
>
>
>>>>[EMAIL PROTECTED] 10.01.05 22:42 >>>
>>>>
>>>>
>you're completely right. It got in my BasePage back in october and I
>never reviewed that piece since than. thanks
>
>Juergen
>
>
>On Mon, 10 Jan 2005 09:47:28 -0800, Jonathan Locke
><[EMAIL PROTECTED]> wrote:
>
>
>> /**
>> * Constructor.
>> */
>> protected Page()
>> {
>> // A page's componentName is its id, which is not determined
>>
>>
>until
>
>
>> // setId is called when the page is added to the session
>> super(null);
>>
>> // Get thread-local session and add this page. This ensures
>>
>>
>that
>
>
>> // all the nice attributes of a page, such as its session
>>
>>
>and
>
>
>>application
>> // are accessible in the page constructor.
>> Session.get().addPage(this);
>> }
>>
>>the last line here adds the newly constructed page to the current
>>session (which is
>>available as a ThreadLocal). the result is that once your
>>
>>
>constructor's
>
>
>>super() method
>>is called, the page is attached to a session. there should be no
>>
>>
>need
>
>
>>to use checkAccess()
>>this way and you should not use it this way.
>>
>>furthermore, if you just need the session, ANY thread can get it
>>directly with Session.get().
>>
>>there should be no reason for BasePage or init(). if you think you
>>
>>
>have
>
>
>>a reason, let's
>>fix the framework instead.
>>
>> jon
>>
>>Juergen Donnerstag wrote:
>>
>>
>>
>>>>I can ever get the Spring ApplicationContext from within a page
>>>>constructor just like this (assuming that the page is already
>>>>
>>>>
>associated
>
>
>>>>with a session):
>>>>
>>>>ServletContext sc =
>>>>getSession().getHttpServletSession().getServletContext();
>>>>ApplicationContext context =
>>>>WebApplicationContextUtils.getRequiredWebApplicationContext(sc) ;
>>>>
>>>>Unfortunately, this is not an elegant way to obtain a reference.
>>>>
>>>>
>That
>
>
>>>>is not very IoC-ish.
>>>>But is a Wicket page already associated with a session while under
>>>>construction
>>>>
>>>>
>>>>
>>>>
>>>Unfortunately it is not. Within my Wicket apps where I need the
>>>Session to initialize my Page I subclass checkAccess(). It is one
>>>
>>>
>of
>
>
>>>the first methods called after the page request. And it is
>>>
>>>
>guaranteed
>
>
>>>that a Session will be attached at that point in time. I know it
>>>
>>>
>not
>
>
>>>obviuous to use this method, but it works. To make my code look a
>>>little bit better, I almost always have a BasePage which subclasses
>>>checkAccess() and calls a new method init(), which I than use to
>>>initialize the Page.
>>>
>>>
>>>
>>>
>>>
>>>>If not, the ApplicationContext needs to be put in the
>>>>ApplicationSettings or in a subclass of HttpApplication at
>>>>
>>>>
>application
>
>
>>>>start up. I would be nice, if one could store arbitrary objects in
>>>>
>>>>
>the
>
>
>>>>ApplicationSettings.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>I agree. I made a similar suggest a couple of days before. Not sure
>>>though I opened a feature request. Mind you checking it and
>>>
>>>
>creating
>
>
>>>one? That way we keep track of features still to be implemented and
>>>don't forget any. Thanks
>>>
>>>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
>>>
>>>
>>>
>>>
>>>
>>-------------------------------------------------------
>>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
-------------------------------------------------------
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
