The tool will let you enumerate everything in the Context, so you could serialize it manually from inside the Velocity template. Still not clear 100% what you are trying to do, just tossing out ideas on how you can enumerate the Context w/o it being necessarily Serializable.
________________________________ From: Jason Chodakowski [mailto:[EMAIL PROTECTED] Sent: Tue 8/26/2008 9:41 PM To: Velocity Users List Subject: Re: Serializing VelocityContext 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
