Good questions, and to be honest, this stuff is just getting off the
ground - ie, I've only been thinking about it for a week and only just
started typing code last night. I'd love to give some type of smart-
ass answer like, "It's proprietary" but to be honest, we're just not
sure how this will end up. What we do know is that we have more than
one web designer that is stumped by our templates... a DreamWeaver
plugin (and not one that understands VTL - that already exists) that
could put this all together would be a god-send for these web guys who
we need as proponents, not opponents.
What we have imagined - and that's a long way from reality - is
perhaps multiple windows, one for each template, and a final one for
the rendered version. Templates would be tweaked individually, but
part of the plugin would be the page context, which I've already tried
to cover, and the "knowledge" that a final rendering is composed of
template X, Y, Z, and Q.
Put another way, we're still bouncing ideas around... what we do know
is that one of the things we would like is this concept of a serialzed
context object... an all-inclusive snapshot of what it takes to render
a page. Because we were able to implement this in a central way, we
were just trying to see 1) if it could be done and 2) who threw the
NotSerializeableException first. As I mentioned in another email,
we've also iterated through the context and put those objects into a
HashMap, which is Serializeable. That brings us to what Will has
suggested with the chained contexts because none of the tools are
serialized.
We'll see where it goes. Thanks for the good questions.
Cheers,
J --
On Aug 27, 2008, at 6:26 AM, Claude Brisson wrote:
Jason, there is something I don't understand in the template edition
process that you are trying to build. Let's suppose you can serialize
and deserialize the context, and that your small Java app can present
merged views to the user. Let's say your merged views are edited in a
wysiwyg javascript editor. What's next? Do you make a diff of old and
new versions to back up changes upwards or what? I don't see how you
can
easily achieve that. Just curious...
Claude
Le mardi 26 août 2008 à 22:05 -0700, Will Glass-Husain a écrit :
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]
---------------------------------------------------------------------
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]
