Understood, and that was our first consideration. That has some
benefits, and some issues too... mostly because those mock objects may
have no meaning to the web developer. A "saved" context "could"
contain objects that are relevant to the customer's data, and
therefore affecting the layout the web designer is working on.
As for serializable objects, all of ours (or rather, everything we put
in the context) is serializable. Part of this is just due to other
requirements - RMI and Hibernate for instance.
I don't know enough about the Velocity internals to know if the
runtime-only variables will affect us. Considering that, 1) we would
have a new "instance" of Velocity, and 2) that you can construct a
VelocityContext with another VelocityContext object, I still don't
know if this is an issue.
As for why "you" might need a serializable context, I don't know. I
just know that for "us" it would be handy. Had Nathan not suggested
that we contribute a patch to make it so, we would probably just made
a version for our own use. Then again, with the points you bring up, I
just don't know... and we're just going to have to experiment.
Perhaps I should have asked the original question this way: does
everyone on this list do their own template editing, or do you have a
division between your web designers and java coders. If the latter,
how/what do your web developers use to edit templates and how did they
learn your system? We've had mixed results... I've had a sit-down with
several web developers who "get" my system within an hour or two. I
also have web-developers who just don't get it, and sadly I need them
on my side too... I'm just trying to find a way to make their life
easier.
Thanks for the questions.
Cheers,
J --
On Aug 27, 2008, at 8:30 AM, Christopher Schultz wrote:
Jason,
Jason Chodakowski wrote:
By adding something onto the URL (we're using serialize=true) we
wanted
to write the entire Context of a given request/response to disk...
that
way an web-editor-type could use our widget to gather a fully-formed
Context, loaded from disk, without needing live connections to a
database, an application server container, etc. to view an
assembled/parsed page - just a small Java program which can load that
Object from disk, and then do a mergeTemplate type action to produce
completed HTML for the editor-of-choice.
Instead of worrying about serialization, you could just write your
program to load sample objects that you either hard-code or put into
properties files or something. I suppose more complex objects could be
serialized, too.
Since serialization of the Context would require every object inside
of
it to be serialized, you could just serialize each name/value pair
from
the Context separately, and then re-build the Context in your little
mack-up program. This would avoid you having to hack around the
Context
code, etc.
Oddly, both InternalContextBase and VelocityContext contain
serialVersionUIDs, but do not implement Serializable.
InternalContextBase also contains some runtime-only data, such as the
template (name) stack, macro (name) stack, and a few other things.
Most
of this sounds like it could be transient, and ignored for
serialization
purposes (but you have to be careful to re-initialize those resources
after a de-serialization).
Simple serialization would require the following classes to be made
serializable:
- Context (the interface)
- InternalContextBase (relatively easy, but has deps)
- AbstractContext (trivial)
- VelocityContext (trivial, assuming that the Map used is
Serializable)
- EventCartridge
- EventHandler & friends
- Resource & friends
Ugh.... I give up. Why do we need serializable Contexts again?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
