Well, you can make your own implementation of Context which is serializable-- that's easy enough. Then it's just a matter of making sure everything in the context is serializable.
It doesn't sound practical to make all your tools serializable. My suggestion would be to use chained contexts. Put all of the stuff with state-- database objcets, etc, in one context. Have that be a custom implementation which is serializable. (It's easy enough-- a context is basically just a map). Then chain that to a second context which contains the various tools. When you reload the page, just deserialize the first context and chain to a new version of the second. WILL On Tue, Aug 26, 2008 at 9:20 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Interesting. I have dabbled in serialization very little, but never > seriously or thoroughly. Does it really only require implementing > Serializable? Or would do doing so lead to problems down the road > with people assuming things are more serializable than they really > are? what about serialVersionUID? since seems like really more of a > development question, would you re-post/forward this to the > [EMAIL PROTECTED] or opening a JIRA issue requesting this > enhancment? and as a final question, if it really only requires > making classes Serializable, would you consider creating a patch for > this yourself and attaching it to a JIRA issue > (https://issues.apache.org/jira/browse/VELOCITY)? > > On Tue, Aug 26, 2008 at 7:11 PM, Jason Chodakowski <[EMAIL PROTECTED]> > wrote: > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
