You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Jon Stevens <jo...@latchkey.com> on 2000/08/27 04:04:57 UTC
Re: Compiled templates
on 8/26/2000 7:05 PM, "dave" <da...@miceda-data.com> wrote:
> Is the goal for Velocity to compile templates ( similiar to Tea ) ?
Yes.
I was thinking that they would not be "compiled" but simply a serialized
byte[] of the pre-parsed template object stored to disk.
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
Re: Compiled templates
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
dave wrote:
> [ snip agreement ;) ]
> Here's the configurable stuff I was thinking of:
>
> o Cache - true/false
> o check-lastmodified - true/false
>
> Now here's the one I'm still up in the air about-
> Stale out the cache.
> What real benefit is it to stale the cache out ( in
> our situation ) every x minutes. Is this so you can tell page authors
> that your new changes will be available in T-2.5 minutes :-).
> ( i'm in a stupid humor mood )
Hehe. I can't think of any positives in staling-out the cache (if it
file hasn't been modified). How about this for configuration:
o template.cache - true | false
o template.modificationCheckInterval - 0..N
If template.modificationCheckInterval is zero (thanks to my fiance Laila
for the word "interval"), the last modified timestamp is never checked.
Otherwise, N is the number of either minutes or seconds (*not*
milliseconds) to wait in between checking for a stale (i.e. modified)
template.
The fact that the template.cache property overrides
template.modificationCheckInterval should be clearly documented in two
or more places. ;P
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Compiled templates
Posted by dave <da...@miceda-data.com>.
On Mon, 28 Aug 2000, you wrote:
> I would prefer to check a the template last modified
> date before expiring the template so that it doesn't have to be
> re-parsed if it hasn't been changed.
I agree.
> The last modification check could
> occur periodically or not at all, and would be specified in a properties
> file.
I agree again.
> This will provide better performance (less disk I/O and less
> parsing), especially in the situation where templates should never
> expire (such as on a pristine production machine).
And again i agree.
Here's the configurable stuff I was thinking of:
o Cache - true/false
o check-lastmodified - true/false
Now here's the one I'm still up in the air about-
Stale out the cache.
What real benefit is it to stale the cache out ( in
our situation ) every x minutes. Is this so you can tell page authors
that your new changes will be available in T-2.5 minutes :-).
( i'm in a stupid humor mood )
--
dave
daveb@miceda-data.com
----------------------
Re: Compiled templates
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
dave wrote:
> [snip good stuff]
> We need to also add some way to periodically check to see if the file has
> changed on disk. Maybe make the cached template stale after a set
> period of time so it'll be reloaded.
Dave, I liked all your thoughts on template compilation (sorry, away
this weekend). I would prefer to check a the template last modified
date before expiring the template so that it doesn't have to be
re-parsed if it hasn't been changed. The last modification check could
occur periodically or not at all, and would be specified in a properties
file. This will provide better performance (less disk I/O and less
parsing), especially in the situation where templates should never
expire (such as on a pristine production machine).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: A point (or two)
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
>
> On Sun, 27 Aug 2000, bob wrote:
>
> >
> > Howdy guys--
> >
> > Was browsing your implementation, and I see that y'll
> > work with a typed object as the context, instead of accepting
> > just any ol' Object as the context.
>
> But did the objects implement an interface of some sort?
>
> I think the context needs to adhere to an interface. Daniel
> had the idea of using the Map interface (or something like it).
> I liked this idea from the stand point of scoping nested blocks.
>
> I haven't implemented it yet, but was planning on using a stack
> of contexts. Using the Map interface a whole set of items could
> be added to a context ... When entering a new block push all
> the items in the current context into the new context. Then you
> effectively get local variables. When you leave the block pop
> the context away. This might be expensive though and might be
> a bit of overkill.
>
> Anyway I'm not really sure how the context worked in IntroSpock,
> but I'll look at it and we can certainly bat some ideas around :)
> I'm not saying that using an Object for a context is bad, I just
> am not clear how it would work. I'll take a peek at your code.
Using just any old instance of Object would be very flexible. One of
the reasons that I like Java so much is its support of strict typing and
extensive use of interfaces. Though I like the idea of using any Object
as a Context conceptually, I'm not certain how well it will work out
with non-technical template developers (often more artist than
programmer).
> > Additionally, it seems the context gets bound to the template,
> > which could be problematic, possibly, when using the same cached
> > Template by multiple threads at the same time, with different
> > contexts.
>
> Yes, this defintely needs to be fixed. I concentrated on
> the parser and visitors and just popped the context off
> to get it to output, it needs work.
Cool. +1
--
Daniel Rall <dl...@finemaltcoding.com>
suppression of error messages
Posted by bob <bo...@accurev.com>.
btw--
WebMacro has a habit of being verbose in it's error messages,
which can get annoying.
If you attempt $variable.that.results.in.null, it'll spew forth
<!-- Unable to locate $variable.that.results.in.null -->
Which is useful sometimes, but gets in your way sometimes
also, when you do something like this:
<input type="text" value="$possiblyNull"/>
iSpock allows $!possiblyNull, and the addition of the !
suppresses output of warnings.
(Additionally, iSpock allows customization of the comment
characters around/in-front-of warnings/errors that are
printed.)
I think the per-variable suppression of warnings is absolutely
needed. Comment-customization is just plain nice to have.
-bob
Re: A point (or two)
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 28 Aug 2000, bob wrote:
> > That looks strange to me ... I don't see why
> > you couldn't do that as long as getMethods()
> > returned an object that could proffer up an
> > Iterator or an Enumeration. Maybe I'm missing
> > something.
>
> Oh, I'm just confused, probably. When you were using a
> hashmap, I assumed that meant you always did context.get("Foo")
> as opposed to even looking for a context.getFoo().
>
> I should really go read the code some more. I think we're
> all agreeing, at this point, and Velocity does indeed
> Do The Right Thing.
>
> -bob
> (sorry to confuse)
Absolutely no problem! This is how we get things worked
out! It's always hard at first with a new whack of code.
I will also take a look at iSpock, or at least your
parser grammar and code. I can't really look at any
off the WM stuff yet. Hopefully Justin will APL the
code soon so that I can look at it.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: A point (or two)
Posted by bob <bo...@accurev.com>.
> That looks strange to me ... I don't see why
> you couldn't do that as long as getMethods()
> returned an object that could proffer up an
> Iterator or an Enumeration. Maybe I'm missing
> something.
Oh, I'm just confused, probably. When you were using a
hashmap, I assumed that meant you always did context.get("Foo")
as opposed to even looking for a context.getFoo().
I should really go read the code some more. I think we're
all agreeing, at this point, and Velocity does indeed
Do The Right Thing.
-bob
(sorry to confuse)
Re: A point (or two)
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 28 Aug 2000, bob wrote:
> > Yes, we do the same thing! We just have different names for
> > it. The context is what I call the holder for all the objects,
> > and they can be anything. We do the same thing.
>
> Okay, then basically, allow
>
> $foo
>
> #set $foo = "bar"
>
> to work *just* like
>
> $foo.goober
>
> #set $foo.goober = "bar"
>
> Do normal introspection to set/get top-level things
> from the context.
Yes.
> In a code-generator I did, I had an object that matched
> a java Class that I used as my Context. I ended up
> with code like:
>
> #foreach $_method in $Methods
>
> Which used for $Methods
>
> myClass.getMethods()
>
> and to set the $_method, it called:
>
> myClass.put("_method", each);
>
> Yes, that indeed *could* fail if myClass didn't provide
> a put/set() type of thing.
That looks strange to me ... I don't see why
you couldn't do that as long as getMethods()
returned an object that could proffer up an
Iterator or an Enumeration. Maybe I'm missing
something.
> Dunno if that's too dangerous. Maybe a HashMap as a Context
> is indeed a Good Thing. (And probably, in the context of
> Turbine, it will always be a HashMap.)
Right now a Hashtable holds all the objects in what
Velocity calls a context. I think there are some variations
in what Velocity and iSpock do but we will eventually
understand one another :)
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: A point (or two)
Posted by bob <bo...@accurev.com>.
> Yes, we do the same thing! We just have different names for
> it. The context is what I call the holder for all the objects,
> and they can be anything. We do the same thing.
Okay, then basically, allow
$foo
#set $foo = "bar"
to work *just* like
$foo.goober
#set $foo.goober = "bar"
Do normal introspection to set/get top-level things
from the context.
In a code-generator I did, I had an object that matched
a java Class that I used as my Context. I ended up
with code like:
#foreach $_method in $Methods
Which used for $Methods
myClass.getMethods()
and to set the $_method, it called:
myClass.put("_method", each);
Yes, that indeed *could* fail if myClass didn't provide
a put/set() type of thing.
Dunno if that's too dangerous. Maybe a HashMap as a Context
is indeed a Good Thing. (And probably, in the context of
Turbine, it will always be a HashMap.)
-bob
Re: A point (or two)
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 28 Aug 2000, bob wrote:
> > So the actual context object itself could be any object, yes?
>
> Ayup.
>
> > So what did you do exactly to get values out of the context
> > in that case? I just want to make sure I fully understand
> > the reason :)
>
> To be honest, I borrowed Justin's reflection back-end from WebMacro.
>
> My main goal was to have a better front-end, not delve into the
> wonders of reflection.
>
> java.lang.reflect.* is what you need to manipulate the context
> Object.
Yes, we do the same thing! We just have different names for
it. The context is what I call the holder for all the objects,
and they can be anything. We do the same thing.
> ** Jon: Would it be safe for me to describe how the reflection
> stuff works, since I'm familiar with the WM code, or would that
> be walking a fine copyright line?
>
> > I check to make sure that something called $element
> > doesn't already live in the context. If it does, then
> > I store it. Then the new value of $element is scoped
> > to the #foreach block. When the block is done I remove
> > $element from the context, and put the old one back
> > in if there was one. This seemed more correctly to
> > me in terms of scoping.
>
> Ahh. We're on slight different wavelengths, then
> about the reflective aspects of this all. In iSpock,
> the context is the 'currently active object'. In the
> template, it starts out as the object passed into the
> process() method. But, an accessors like
>
> $user.FirstName
>
> and
>
> #set $User.FirstName = "Bob"
>
> might cause statements to be directed to a radically
> different object, possibly of non-HashMap variety.
> That call might result in reflectin something equiv to
>
> context.get("User").getFirstName();
>
> and
>
> context.get("User").setFirstName("Bob");
>
> Yes, I personally argue that you shouldn't be directly
> mutating 'business objects' from the template. It's
> just wrong and evil. But, bet your last dollar that
> there are people out there with code that does.
We do the same things :)
> > I am trying to explain the internals of what's
> > been done in a design document so I can just
> > throw it on the table. That way we can fix any
> > of the design flaws that I've initially made.
> > This document will explain how the parser currently
> > works, how the visitors work, and can be done
> > easily what is hard, what the limitations are
> > and anything else I can think of...
>
> Okay, good. Your explanation of #include rests my
> fears there. I look forward to the design doc. Is
> it online yet?
No, I've just started it!
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: A point (or two)
Posted by bob <bo...@accurev.com>.
> So the actual context object itself could be any object, yes?
Ayup.
> So what did you do exactly to get values out of the context
> in that case? I just want to make sure I fully understand
> the reason :)
To be honest, I borrowed Justin's reflection back-end from WebMacro.
My main goal was to have a better front-end, not delve into the
wonders of reflection.
java.lang.reflect.* is what you need to manipulate the context
Object.
** Jon: Would it be safe for me to describe how the reflection
stuff works, since I'm familiar with the WM code, or would that
be walking a fine copyright line?
> I check to make sure that something called $element
> doesn't already live in the context. If it does, then
> I store it. Then the new value of $element is scoped
> to the #foreach block. When the block is done I remove
> $element from the context, and put the old one back
> in if there was one. This seemed more correctly to
> me in terms of scoping.
Ahh. We're on slight different wavelengths, then
about the reflective aspects of this all. In iSpock,
the context is the 'currently active object'. In the
template, it starts out as the object passed into the
process() method. But, an accessors like
$user.FirstName
and
#set $User.FirstName = "Bob"
might cause statements to be directed to a radically
different object, possibly of non-HashMap variety.
That call might result in reflectin something equiv to
context.get("User").getFirstName();
and
context.get("User").setFirstName("Bob");
Yes, I personally argue that you shouldn't be directly
mutating 'business objects' from the template. It's
just wrong and evil. But, bet your last dollar that
there are people out there with code that does.
> I am trying to explain the internals of what's
> been done in a design document so I can just
> throw it on the table. That way we can fix any
> of the design flaws that I've initially made.
> This document will explain how the parser currently
> works, how the visitors work, and can be done
> easily what is hard, what the limitations are
> and anything else I can think of...
Okay, good. Your explanation of #include rests my
fears there. I look forward to the design doc. Is
it online yet?
-bob
Re: A point (or two)
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 28 Aug 2000, bob wrote:
> > But did the objects implement an interface of some sort?
>
> Nope. Just java.lang.Object. Introspcection/Reflection
> took care of the rest. The context should be pretty
> opaque to the most of Velocity, with the exception of
> the reflect code.
So the actual context object itself could be any object, yes?
So what did you do exactly to get values out of the context
in that case? I just want to make sure I fully understand
the reason :)
> > I haven't implemented it yet, but was planning on using a stack
> > of contexts. Using the Map interface a whole set of items could
> > be added to a context ... When entering a new block push all
> > the items in the current context into the new context. Then you
> > effectively get local variables. When you leave the block pop
> > the context away. This might be expensive though and might be
> > a bit of overkill.
>
> Ahh, at least WebMacro and iSpock both dealt with a single
> instance of the context object for the entire walk of the
> tree. No 'local' variables, per se. I know of some code
> that takes advantage of the fact the named iterator
> variable is still valid after a #foreach block is done.
Right now in velocity in for something like this:
#foreach $element in $list
{
$element
}
I check to make sure that something called $element
doesn't already live in the context. If it does, then
I store it. Then the new value of $element is scoped
to the #foreach block. When the block is done I remove
$element from the context, and put the old one back
in if there was one. This seemed more correctly to
me in terms of scoping.
> And some code will #include a template to mere set
> variables contained within. If those got popped after
> the #include statement, all would be lost. ;)
Actually something like
#set $this = "that"
#include "whatever.inc"
where whatever.inc is:
#set $that = "this"
$that and $this are in the same context. In
the parser when there is an #include or #parse
I save the current steam, open the file to be
#included or #parsed reset the lexer and start
pulling in the new file.
The upshot of that a template with abitrarily
nest #includes and #parses end as a single
AST. It's like one document, and scope only
changes when you enter a block. #includes
and #parses don't push or pop wouldn't cause
any pushing or popping of contexts, but blocks
inside them would.
I am trying to explain the internals of what's
been done in a design document so I can just
throw it on the table. That way we can fix any
of the design flaws that I've initially made.
This document will explain how the parser currently
works, how the visitors work, and can be done
easily what is hard, what the limitations are
and anything else I can think of...
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: A point (or two)
Posted by bob <bo...@accurev.com>.
> But did the objects implement an interface of some sort?
Nope. Just java.lang.Object. Introspcection/Reflection
took care of the rest. The context should be pretty
opaque to the most of Velocity, with the exception of
the reflect code.
> I haven't implemented it yet, but was planning on using a stack
> of contexts. Using the Map interface a whole set of items could
> be added to a context ... When entering a new block push all
> the items in the current context into the new context. Then you
> effectively get local variables. When you leave the block pop
> the context away. This might be expensive though and might be
> a bit of overkill.
Ahh, at least WebMacro and iSpock both dealt with a single
instance of the context object for the entire walk of the
tree. No 'local' variables, per se. I know of some code
that takes advantage of the fact the named iterator
variable is still valid after a #foreach block is done.
And some code will #include a template to mere set
variables contained within. If those got popped after
the #include statement, all would be lost. ;)
-bob
Re: A point (or two)
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 27 Aug 2000, bob wrote:
>
> Howdy guys--
>
> Was browsing your implementation, and I see that y'll
> work with a typed object as the context, instead of accepting
> just any ol' Object as the context.
But did the objects implement an interface of some sort?
I think the context needs to adhere to an interface. Daniel
had the idea of using the Map interface (or something like it).
I liked this idea from the stand point of scoping nested blocks.
I haven't implemented it yet, but was planning on using a stack
of contexts. Using the Map interface a whole set of items could
be added to a context ... When entering a new block push all
the items in the current context into the new context. Then you
effectively get local variables. When you leave the block pop
the context away. This might be expensive though and might be
a bit of overkill.
Anyway I'm not really sure how the context worked in IntroSpock,
but I'll look at it and we can certainly bat some ideas around :)
I'm not saying that using an Object for a context is bad, I just
am not clear how it would work. I'll take a peek at your code.
jvz.
> Additionally, it seems the context gets bound to the template,
> which could be problematic, possibly, when using the same cached
> Template by multiple threads at the same time, with different
> contexts.
Yes, this defintely needs to be fixed. I concentrated on
the parser and visitors and just popped the context off
to get it to output, it needs work.
> fwiw, I have some WebMacro/IntroSpock code laying around
> that assumes the context can be any ol' Object. Mostly
> this is for code-generation, where I throw some weird
> read-only tree of objects as my context at a template.
>
> I'd hate to have to go back and wrap it in a hashmap (as the
> only entry) and then edit my templates to account for the
> extra level of objects.
We'll see what we can do :)
> I've mentioned to Jon, but I'll also post here, Introspock,
> my rewrite of WebMacro, is BSD licensed for the parser front-end
> though, it uses WebMacro's introspection back-end still.
>
> iSpock handles the Object context, and also keeps the context
> from being a stateful member of the Template. iSpock's templates
> are fully parallizeable/re-entrant.
>
> Y'all are welcome to any/all of it that you like. It's
> based on an antlr (www.antlr.org) parser, instead of javacc.
Much appreciated! Thank a lot Bob!
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
A point (or two)
Posted by bob <bo...@accurev.com>.
Howdy guys--
Was browsing your implementation, and I see that y'll
work with a typed object as the context, instead of accepting
just any ol' Object as the context.
Additionally, it seems the context gets bound to the template,
which could be problematic, possibly, when using the same cached
Template by multiple threads at the same time, with different
contexts.
fwiw, I have some WebMacro/IntroSpock code laying around
that assumes the context can be any ol' Object. Mostly
this is for code-generation, where I throw some weird
read-only tree of objects as my context at a template.
I'd hate to have to go back and wrap it in a hashmap (as the
only entry) and then edit my templates to account for the
extra level of objects.
I've mentioned to Jon, but I'll also post here, Introspock,
my rewrite of WebMacro, is BSD licensed for the parser front-end
though, it uses WebMacro's introspection back-end still.
iSpock handles the Object context, and also keeps the context
from being a stateful member of the Template. iSpock's templates
are fully parallizeable/re-entrant.
Y'all are welcome to any/all of it that you like. It's
based on an antlr (www.antlr.org) parser, instead of javacc.
Anyhoo, you can find it at <http://code.werken.com/introspock/>.
-bob
Re: How best to move forward?
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 27 Aug 2000, Jon Stevens wrote:
> on 8/27/2000 1:58 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
>
> > Hi,
> >
> > I was thinking that it might be best for me to
> > stop coding for a while and write an extensive
> > description of how Velocity works so that people
> > who are interested in helping don't have to muddle
> > about looking through the source to get an
> > overview.
>
> Jason, if you do that from a code documentation perspective. +1. I'm taking
> care of documenting the directives. I'm nearly done.
Yes from a code perspective. You've got the directives :)
> Also, we need javadoc at least on all of the classes badly. The methods can
> come later.
I will start now.
>
> > I'd also like to fully document the ideas of
> > the injectors. Which I've described a couple
> > of times, but I don't think I did a very good
> > job because I didn't get much feed back. I'm
> > not sure if I explained it very well.
>
> Yea, I'm pretty lost, but that is just because of my lack of understanding
> how parsers work. It would be nice if you added some documentation to some
> of the directives that state stuff like:
>
> input: #if
> output: we are in an #if directive
>
> That way, I can walk through the code without adding a bunch of println
> statements to see what is going on.
Not a problem.
> > I would just like to make the code as accessible
> > as possible. It needs further documentation, that
> > I will do today. And any ideas about creating
> > some clean interfaces would be great!
> >
> > Is it completely cool to look at the WM code
> > now?
Ok.
Anyway, tonights project will be code docs and a
design doc with a little javacc material, how
the visitors work and how the injectors are
to work.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: How best to move forward?
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/2000 1:58 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
> Hi,
>
> I was thinking that it might be best for me to
> stop coding for a while and write an extensive
> description of how Velocity works so that people
> who are interested in helping don't have to muddle
> about looking through the source to get an
> overview.
Jason, if you do that from a code documentation perspective. +1. I'm taking
care of documenting the directives. I'm nearly done.
Also, we need javadoc at least on all of the classes badly. The methods can
come later.
> I'd also like to fully document the ideas of
> the injectors. Which I've described a couple
> of times, but I don't think I did a very good
> job because I didn't get much feed back. I'm
> not sure if I explained it very well.
Yea, I'm pretty lost, but that is just because of my lack of understanding
how parsers work. It would be nice if you added some documentation to some
of the directives that state stuff like:
input: #if
output: we are in an #if directive
That way, I can walk through the code without adding a bunch of println
statements to see what is going on.
> I would just like to make the code as accessible
> as possible. It needs further documentation, that
> I will do today. And any ideas about creating
> some clean interfaces would be great!
>
> Is it completely cool to look at the WM code
> now?
Not yet. I need to get the ASF's approval. I also need to discuss with them
the issues surrounding use of bits of code that are copyright to someone
else as well as the dual license.
Generally the ASF makes you give up the copyright to the ASF, so I'm not
sure if we can take a method or two (or more) out of WM and include that in
Velocity without having issues with copyright holder. I understand the point
of saying "This code uses code from WM." but I'm not sure I understand the
copyright issues yet.
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
How best to move forward?
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
I was thinking that it might be best for me to
stop coding for a while and write an extensive
description of how Velocity works so that people
who are interested in helping don't have to muddle
about looking through the source to get an
overview.
I'd also like to fully document the ideas of
the injectors. Which I've described a couple
of times, but I don't think I did a very good
job because I didn't get much feed back. I'm
not sure if I explained it very well.
I would just like to make the code as accessible
as possible. It needs further documentation, that
I will do today. And any ideas about creating
some clean interfaces would be great!
Is it completely cool to look at the WM code
now?
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Compiled templates
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/2000 1:37 PM, "dave" <da...@miceda-data.com> wrote:
> I'm working on this stuff now. Besides the loader
> I looking at how we want to do the overall configuration.
> I'm thinking of Avalon, but I need to get a little smarter on it first.
>
> I want to steal some of the things out of Turbine, more specifically
> * configuration stuff ( TurbineResources )
> * Logging
>
> At the same time I don't want to directIy bind Turbine to Velocity,
> So I'll probably just copy and paste.
Yea...it is strange...we could check a copy of turbine.jar into velocity/lib
and we could check a copy of velocity.jar into turbine/lib. Talk about
eating your own dog food.
> Also I plan on making an interface
> to Logging so you can configure and use the Logger of your choice. I'll
> provide a default logger.
I believe Alex Reina London <Al...@reuters.com> on the Turbine list
picked up the task of doing logging...Alex, how are you doing?
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
Re: Compiled templates
Posted by dave <da...@miceda-data.com>.
On Sun, 27 Aug 2000, you wrote:
> If know how you want this to work in terms of configurability
> just let me know ... I'm just finishing off some torque
> docs then I'll be back at Velocity this afternoon. I'm
> going to try and write the design doc before I do anything
> and then try to finish the injectors.
I'm working on this stuff now. Besides the loader
I looking at how we want to do the overall configuration.
I'm thinking of Avalon, but I need to get a little smarter on it first.
I want to steal some of the things out of Turbine, more specifically
* configuration stuff ( TurbineResources )
* Logging
At the same time I don't want to directIy bind Turbine to Velocity,
So I'll probably just copy and paste. Also I plan on making an interface
to Logging so you can configure and use the Logger of your choice. I'll
provide a default logger.
--
dave
daveb@miceda-data.com
----------------------
Re: UltraDev
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Gary Kerbaugh wrote:
>
> Hi Guys,
Hi Gary.
> The issue is viewing a frontend page that is populated with data as it's
> being developed. Supposedly, UltraDev is designed to do this. I took the
> liberty of telling people in a Macromedia online forum about you. I suspect
> that an object or inspector to edit Velocity tag elements will be
> forthcoming. I would like to know anything that would help get UltraDev to
> display the parsing results real time.
This should be incrediably easy. You just call the parser directly, and
pipe its output to UltraDev's HTML buffer.
> Is the parser a standard servlet? (or called by a standard servlet?)
Dave recently added VelocityServlet, an abstract class that you can
extend if you are doing servlet development. The Velocity engine itself
is not tied to any particular means of deployment (like the web, for
instance), and can be run stand-alone. There are code examples in the
repository of doing just this.
> Are there any plans (or even any hope) of
> having the parser parse remote templates? Finally, I'm pretty much out of my
> league here, so if you have any thoughts on how to link a program like
> UltraDev to the data, I'd love to hear them. (Naturally, I know there's no
> reason you should have any knowledge of UltraDev or it's ilk. I just thought
> I'd ask)
Parsing remote templates doesn't sound like a very good idea for web
deployment, but would be easy enough to add. Download the latest code
from CVS and take a look at the tests and examples. It should be pretty
clear from the code how to call the parser directly, but let us know if
you have any specific questions (especially if there is stuff that we
can do to make it more clear).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: UltraDev
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/2000 1:35 PM, "Gary Kerbaugh" <GK...@nc.rr.com> wrote:
> Hi Guys,
>
> I'm just a lurker eager to learn about this exciting new development. As
> you post webpages with more detailed information, I may have some worthy
> questions but right now I'll try to stay out of your hair, excepting of
> course for this one question. I need to make a recommendation to a client,
> so it's pressing.
No problem.
> The issue is viewing a frontend page that is populated with data as it's
> being developed. Supposedly, UltraDev is designed to do this. I took the
> liberty of telling people in a Macromedia online forum about you. I suspect
> that an object or inspector to edit Velocity tag elements will be
> forthcoming. I would like to know anything that would help get UltraDev to
> display the parsing results real time. Is the parser a standard servlet? (or
> called by a standard servlet?) Are there any plans (or even any hope) of
> having the parser parse remote templates?
The parser is standalone currently. It will be definitely integrated with
Turbine which is a standard servlet and we will also provide a simpler
standard servlet to execute the template engine (we will probably just use
the WMServlet code).
> Finally, I'm pretty much out of my
> league here, so if you have any thoughts on how to link a program like
> UltraDev to the data, I'd love to hear them. (Naturally, I know there's no
> reason you should have any knowledge of UltraDev or it's ilk. I just thought
> I'd ask)
My only response is that this is a volunteer project and if this is an itch
for you, then you are welcome to join and scratch it or try to recruit
others who have the same itch. :-) We appreciate all contributions greatly.
> I learned about you through Jason Hunter. (Don't flame him because of my
> intrusion!) He was long ago sold on WebMacro as the best implementation of
> MVC architecture and he was very excited about your project. I'm sure that
> you'll be featured on his servlet website soon! I'm also sure you'll get
> featured in the second edition of his O'Reilly book as well. I think you've
> got an exciting project going, best of luck, and I'll be following it
> closely! (I only wish I had the expertise to contribute)
No worries. I work with Jason. We know each other well. :-)
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
UltraDev
Posted by Gary Kerbaugh <GK...@nc.rr.com>.
Hi Guys,
I'm just a lurker eager to learn about this exciting new development. As
you post webpages with more detailed information, I may have some worthy
questions but right now I'll try to stay out of your hair, excepting of
course for this one question. I need to make a recommendation to a client,
so it's pressing.
The issue is viewing a frontend page that is populated with data as it's
being developed. Supposedly, UltraDev is designed to do this. I took the
liberty of telling people in a Macromedia online forum about you. I suspect
that an object or inspector to edit Velocity tag elements will be
forthcoming. I would like to know anything that would help get UltraDev to
display the parsing results real time. Is the parser a standard servlet? (or
called by a standard servlet?) Are there any plans (or even any hope) of
having the parser parse remote templates? Finally, I'm pretty much out of my
league here, so if you have any thoughts on how to link a program like
UltraDev to the data, I'd love to hear them. (Naturally, I know there's no
reason you should have any knowledge of UltraDev or it's ilk. I just thought
I'd ask)
I learned about you through Jason Hunter. (Don't flame him because of my
intrusion!) He was long ago sold on WebMacro as the best implementation of
MVC architecture and he was very excited about your project. I'm sure that
you'll be featured on his servlet website soon! I'm also sure you'll get
featured in the second edition of his O'Reilly book as well. I think you've
got an exciting project going, best of luck, and I'll be following it
closely! (I only wish I had the expertise to contribute)
--
Gary Kerbaugh
gkerbaugh@earthlink.net
A computer scientist is someone who, when told to "Go to Hell", sees the
"go to", rather than the destination, as harmful.
Re: Compiled templates
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 27 Aug 2000, dave wrote:
> On Sat, 26 Aug 2000, you wrote:
> > I was thinking that they would not be "compiled" but simply a serialized
> > byte[] of the pre-parsed template object stored to disk.
That's what I was thinking.
> After doing a little more thinking on this, I don't think it's really
> necessary that we serialize the pre-parse templates to disk. I don't
> see how it's beneficial.
>
> Here's my thoughts:
> Lazy load the templates into the cache on demand. Pre-parse them before
> cached ( see below ).
>
> We need to also add some way to periodically check to see if the file has
> changed on disk. Maybe make the cached template stale after a set
> period of time so it'll be reloaded.
>
> Of course, all this should be configurable -
> * Cache
> * lastmodified
> * preparse.
If know how you want this to work in terms of configurability
just let me know ... I'm just finishing off some torque
docs then I'll be back at Velocity this afternoon. I'm
going to try and write the design doc before I do anything
and then try to finish the injectors.
> // This is from FileTemplateLoader
>
> File file = new File( templatepath, name );
> if ( file.canRead() )
> {
> Template template = new Template( name );
> -> template.preParse()
> if ( useCache )
> {
> synchronized(lock)
> {
> cache.put( name, template );
> }
> }
> return template;
> }
>
>
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Compiled templates
Posted by dave <da...@miceda-data.com>.
On Sat, 26 Aug 2000, you wrote:
> I was thinking that they would not be "compiled" but simply a serialized
> byte[] of the pre-parsed template object stored to disk.
After doing a little more thinking on this, I don't think it's really
necessary that we serialize the pre-parse templates to disk. I don't
see how it's beneficial.
Here's my thoughts:
Lazy load the templates into the cache on demand. Pre-parse them before
cached ( see below ).
We need to also add some way to periodically check to see if the file has
changed on disk. Maybe make the cached template stale after a set
period of time so it'll be reloaded.
Of course, all this should be configurable -
* Cache
* lastmodified
* preparse.
// This is from FileTemplateLoader
File file = new File( templatepath, name );
if ( file.canRead() )
{
Template template = new Template( name );
-> template.preParse()
if ( useCache )
{
synchronized(lock)
{
cache.put( name, template );
}
}
return template;
}
--
dave
daveb@miceda-data.com
----------------------