I don't have a prepared sample, but that's a great idea. I will put
one together (perhaps with Iolite).
// Daniel
jalbum.net
Daniel do you have any sample code for this. Could be cool with a
small
quickstart, you could even use the Iolite for this, and drop it's
ldms...
2009/10/16 Daniel Frisk <dan...@jalbum.net>
Of course, serialization isn't always necessary but in this case
the idea
was to _enforce_ serialization.
The cost of serialization compared to the actual page construction
time
(often with database accesses and such) seems to often be very small.
Scalability is the same as for using explicit LDMs in your code.
Once you
have set it up you can never "forget" to detach stuff and end up
with an
overstuffed session. You don't have to serialize to disk either you
can keep
the data in memory or in your Terracotta cluster or whatever.
I think it has clear advantages to explicit model proxies. Models
proxies
are still necessary in some cases, but usually you can just put an
entity in
your component and it will work as if you had used LDMs.
I'm not saying this is a golden... But it's a really nice
alternative in
many cases.
// Daniel
jalbum.net
probably because serialization is not guaranteed. you can use a http
session store on a single node cluster and never have anything
serialized.
-igor
A third option, which from my POV is perhaps the most elegant, is
to roll
your own page store that serializes the pages instantly after the
request.
The serialization have special hooks to replace entites or
whatever that
you
would prefer to have as LDM with a placeholder that just stores
the type
and
id when serialized. When/if the page is later deserialized you
get the
entity fresh from your object repository (cache).
Why is this elegant? You get the programming model of push with the
benefits
of pull without writing any code for model proxies. I have
communicated
this
idea before but nobody but me seems to prefer it, I'm actually
surprised
:-)
// Daniel
jalbum.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
