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
