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]
