velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: #parse() directive
Date Thu, 17 Apr 2003 09:49:17 GMT
Thanx Christoph for your inputs. I agree with you that an #eval(...)
directive sounds better than using a "tool".

However I have some issues supporting the same through a directive as
against a ResourceLoader.

Uptil now Velocity has not supported using Strings as templates, the way
it supports using Files/Jars etc. For that purpose, an evaluate method
exists in the Velocity class. However the usage of the evaluate method
is limited as can be seen by my problem. Another aspect is that using a
StringResourceLoader these problems could be overcome in a generic
manner across the entire Velocity engine. At the same time all features
available to a file-based template would be available to a string-based
template. Even today a File need not contain any markup and it would be
processed on a "as-is" basis. The same would happen to a String of that
format. But ability to create a template out of a String I feel is very

However if the Velocity team yet feels otherwise, I would be willing to
contribute my change as a directive as well.

Please let me know what is the general consensus.

-----Original Message-----
From: Christoph.Reck []
Sent: Thursday, April 17, 2003 2:36 PM
To: velocity-user
Cc: Christoph.Reck
Subject: Re: #parse() directive

I believe that the outcome of adding a StringResourceLoader would be
just as misleading as what you beleieved #parse should do. OK, you
could look into the string to see if it contains eitehr # or $, but
someone else might try to pass in an arbitrary "resource" string
that does not contain markup, then it would try it as a file and just
break the same.

The general approach of velocity is to "keep it simple" and "use a
tool". Keeping it simple means not to overload directives.

With the second "use a tool" religous war, I do  have some problems.
Here I believe that velocity should support a bit wider scope of
basic directives. I your case it should be #eval("..."), and another
one I'd like to see in the core is #local($foo $bar)...#end as in
the contrib section (I've not yet had a chance to test it... browsing
the source makes me think it's OK, but I originally thought of
something more like the #foreach approach - disclaimer: I'm commenting
out of memory...).

Could you change your approach and propose and send a patch as an #eval
directive? Maybe it could support a caching flag as a second parameter?

Christoph wrote:
> As I mentioned earlier, how about using a StringResourceLoader. I have
> created one and it seems to be working fine. I was wondering whether
> something of this kind would be useful in standard Velocity.
> This requirement would be present to a large extent in cases where hte
> templates are being generated dynamically.
> -----Original Message-----
> From: nathan []
> Sent: Wednesday, April 16, 2003 7:30 PM
> To: velocity-user
> Cc: nathan
> Subject: Re: #parse() directive
> dhaval.h.udani said:
>>I have some doubts about the #parse() directive. I believe that apart
>>from a filename even a Velocity variable can be given here. However it
>>seems that the variable must refer to a template file which can be
> found
>>via the ResourceManager mechanism. However in my case, the variable
>>actally refers to a string containing VTL. I need this VTL to be
> parsed
>>sign the context I supplied. i.e. instead of using the ResourceManager
>>to lcoate a template file, I am giving the contents of the template
>>which need to be parsed.
> you are mistaking the purpose of the #parse directive.  what you need
> a
> tool such as Simon suggests.  try:
> /vel
> s-ma
> rkup
> or if you are using Velocity-Tools, use
> /vel
> .vie
> wcvs-markup
> for greater convenience.
> Nathan Bubna
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

:) Christoph Reck

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message