As others have pointed out, the magic of IModel works better than you
think (or thought) it does. I often have two constructors for pages, one
taking bookmarkable parameters and another taking an IModel so that I
don't always have to reload DB objects page to page. It's a cinch.

But I get your point, when you say that this method is "mostly adapted
to the old MVC style of web programming." You're right. The
one-session-per-request style is the conventional wisdom that we should
be questioning here on the cutting edge.

On the other hand, we have to be careful of getting TOO far ahead of the
curve. This listserv used to get about one question a week about
Wicket's crazy practice of actually using the session store. Those Qs
have turned into general concerns about about load, high volume, etc.
The fact that Wicket has a system of detachable models that can
repopulate themselves from DB each request cycle is enormously
comforting to people.

This system works very well and practically everyone uses it, but that
shouldn't stop you from trying something else. Whatever you come up with
just might be the way we all do it in a few years, when server resources
dwarf those available today. I like IModels fine, and will like them
even more when they're strongly typed, but I'll admit it would be easier
to just pass around the objects they contain. Significantly easier for
new users.

So please do give it a shot. (I'm assuming your app is high-complexity,
low-volume, or that you have small data objects.) I can't think of
anything in Wicket that would slow you down, other than the minor
annoyance of having to wrap objects in new Model(Serializable o) before
passing them to some framework components.

And let us know how it goes!


Iman Rahmatizadeh wrote:
> The problem with #1 is, first its a bit ugly, second you discard every 
> persistent instance in each cycle (which is less efficient than #2 or 
> #3), third you lose the advantages of working & passing POJO's between 
> pages, Like you would call 'new ProfilePage(person.getId())' instead of 
> 'new ProfilePage(person))' and retrieve the person from database again 
> in the profile page. As Nathan said, despite the disadvantages, it's the 
> easiest and the most straight forward, and mostly adapted to the old MVC 
> style of web programming.
> With wicket, I would like to pass objects around to pages and methods, 
> keep them in memory during the unit of work, and persist the changes at 
> the end. The problem is I make a new Hibernate Session in each request 
> cycle, so I have to re-attach the objects from the previous cycle to the 
> new Hibernate Session each time (as in #2). This can get quite 
> cumbersome and would easily get out of control.
> With all that said , I guess I'm alone in this case and everybody agrees 
> on using #1. Still if anybody has any experience with #2 or #3, I would 
> be happy to know about it.
> Iman

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to