Hmm... perhaps I didn't explain that well, but the ContextTool won't help me serialize the VelocityContext to disk... at least as far as I can tell by looking at the source and the documentation... for that matter ContextTool itself isn't serializeable so if it were in something I was trying to write to disk, it would throw an exception.

Unless of course I'm not understanding its use as you meant it.

Thanks,

J --

On Aug 26, 2008, at 9:38 PM, White, Tim wrote:

This isn't a complete answer, but you might take a look at the ContextTool.

________________________________

From: Jason Chodakowski [mailto:[EMAIL PROTECTED]
Sent: Tue 8/26/2008 8:11 PM
To: Velocity Users List
Subject: Serializing VelocityContext



Greetings,

I'm throwing this out there because I'm just not cool or smart enough
to come up with a better way of doing what I'm going to describe...
I'm hoping someone has a better idea.

My company has an ongoing webish effort which makes extensive use of
Velocity. As more folks start to use our stuff, one of the
overwhelming questions we get is, "How can I get a WYSIWYG view of
your templates so that I can edit them." The difficulty in this is due
to our templates being highly nested - one template may load (parse)
four or more templates depending on what's in the Context. Then
there's also the issue of the Context, which in our case is the soul
of any rendered page.

We are working on some solutions to this. The path that we're
currently on would do the following:

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.

I'm sure you know then where this is going... VelocityContext is not
serializable, and neither are many of the VelocityTools that we put
into the Context. We are contemplating creating a completely
serialized version of the Velocity source tree, including tools -
mostly because there's not much to do beyond implementing
Serializable. Now I'm not requesting that the Velocity team do this
for us unless they're already working on something similar, but I just
don't know a better way to do it. I'm aware that Hibernate or perhaps
something else under the JBoss umbrella can serialize non-serialized
objects, but I can't find out exactly where this is addressed or how
it is fixed... Hibernate, for instance does a lot of internal code
altering to make their stuff work, and while I'm very impressed at how
that all works, there is a massive startup overhead associated with
recompilation that we don't want to incur. We were shooting for
something "simple" - I know, it's never "that" simple.

In many ways it all boils down to time... we need to solve our problem
quickly, but I'm hoping perhaps someone else on this list, who is more
clever than I am, has addressed this issue or one like it.

Let me know if I need to explain more.

Thanks,

Jason Chodakowski





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to