Re: partial evaluation / removing directives

On Fri, Jul 13, 2012 at 8:12 AM, Pete <[email protected]> wrote:
> Thanks for the info guys. To answer that one question
>> Why would evaluate cause problems for #parse??  If the engine is
>> configured the same, the #parse should work the same whether you enter
>> via file or string.
> The problem would be even if the #parse directives get picked up OK in my
> in-memory, preprocessed string version of the file (since I set template
> location path), Velocity would just go and consume those additional
> template files on its own, not giving me a chance to preprocess them first.
>  Maybe I could avoid this if there was way to extend /replacevelocity's
> template file loader, I haven't looked at the code enough to know if this
> is possible

oh yeah, duh.  and yes, you can definitely make your own resource
loaders.  those are pluggable. :)

> That's an interesting suggestion re: the other templating Engine... I
> considered trying to home-brew my own (just looking for those two
> directives), but it seemed like a waste since there's already such powerful
> and robust ones out there. Also, there'sa bit of subtley there since it can
> be recursive ($resourceBundles can themselves include references to #parse,
> which can include references to resource bundles, etc).  If there was a
> really simple, customizable template engine one that would let me choose
> exactly what was parsed, that would probably be best.

Hmm.  i'm not aware of one, but i'm much less active in this space
than i used to be.

> My only issue using
> another one similar in size to velocity is that there might be some "side
> effects", eg statements which are ignored by velocity but which get
> interpreted somehow through this other engine due to its own particular
> syntax.

yeah, that's a concern.

> As for the AST rewrite idea, if it was possible to "Burn down" nodes to
> their corresponding text something like that would work, However, wouldnt'
> that then possibly miss additional child elements in that AST tree? For
> instance a clause in an if statement which had a resourceBundle reference?
>  I'm not too familiar with ASTs (been years since I dealt with those at
> school), maybe I can look at it a bit more today.

worth a look.  it sounded like a reasonable approach to me.
definitely easier than trying to remove baked-in directives.

>
> thanks,
> Pete
>
> On Fri, Jul 13, 2012 at 9:57 AM, Alex Fedotov <[email protected]> wrote:
>
>> Another option may be rewriting the AST tree after the template is parsed
>> and replacing some nodes with text or something else.
>> I tried that on the side as an experiment to inject some security checks
>> and collect profiling info for macros and templates.
>>
>> Alex
>>
>>
>>
>> On Fri, Jul 13, 2012 at 9:50 AM, Nathan Bubna <[email protected]> wrote:
>>
>> > On Thu, Jul 12, 2012 at 2:27 PM, Pete <[email protected]> wrote:
>> > > Hi all,
>> > > I'm working with some velocity files where I want to partially evaluate
>> > > them, such that the only things actually evaluated are #parse (includes
>> > of
>> > > other velocity templates in the same directory) and  $references to a
>> > > resourceBundle variable passed in the context map.  In essence, all
>> this
>> > is
>> > > doing is combining a number of velocity files into one master velocity
>> > > file, and localizing any resource bundle references to a given locale.
>> > All
>> > > the main velocity directives in the velocity file(s) should be left
>> > > unevaluated-   #set, #ifelse, #foreach etc. This way, the result could
>> be
>> > > redistributed and modified specific to a particular locale, with just
>> one
>> > > file instead of n based on the #parse structure.
>> >
>> > interesting challenge!  glad i don't have to do it though. :)
>> >
>> > > Up till now, I've been doing this in a somewhat roundabout way:
>> > > 1. setting strict escape property to true
>> > > 2. pre-processing the velocity templates by regexp replacing all
>> > instances
>> > > of #if / #else/ #elseif/ #end / #foreach / #define / #break / #stop
>> >  #set /
>> > > #evaluate with  \\#{$1}
>> > > This adds a an escape character before each of these directives, and I
>> > can
>> > > then call mergeTemplate on the result.  It works OK, sometimes, but I
>> > still
>> > > run into some parsing issues now and again (eg not a robust solution).
>> It
>> > > also seems kind of heavy handed to have to preprocess these files
>> using a
>> > > regular expression and saving them before velocity gets a handle on
>> them.
>> > > It would even be a bit better if I could do this by reading them in and
>> > > doing the rgexp in-memory rather than on the saved files, then using
>> > > evaluate instead of mergeTemplate. But I assume that would cause
>> problems
>> > > for the #parse directives.
>> >
>> > Why would evaluate cause problems for #parse??  If the engine is
>> > configured the same, the #parse should work the same whether you enter
>> > via file or string.
>> >
>> > > I know velocity added a removeDirective() method in 1.6.2 which seems
>> > like
>> > > it should be perfect for me - I could simply rip out all the directives
>> > but
>> > > #parse.  However, I tried the and it seems that it only works for
>> certain
>> > > directives, eg  #foreach, #include, etc.  More basic directives like
>> #if
>> > > and #elseif are not in the list of runtimedirectives, or even
>> represented
>> > > as Directive objects, so removing them doesn't work.
>> >
>> > Yeah, they are deep in the parser.  Their structure doesn't work as a
>> > normal directive.
>> >
>> > > Any suggestions on the best way to proceed with this? Would it be easy
>> to
>> > > change a few velocity files locally, recompile and get this behavior?
>> Or
>> > is
>> > > it sufficiently complex removing all these more basic directives that
>> I'm
>> > > better off continuing to try some kind of  preprocessing/ escaping?
>> >
>> > You would have to redesign Velocity's parsing deeply.  A major
>> > overhaul.  You're best off preprocessing.   Have you considered using
>> > a different template engine to do the first part (the parse and
>> > resourceBundle resolution)?  Might be overkill, but might be easier,
>> > so long as the syntax has no overlap with VTL.
>> >
>> > > thanks,
>> > > Pete
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [email protected]
>> > For additional commands, e-mail: [email protected]
>> >
>> >
>>