Re: partial evaluation / removing directives

Hey, quick question re: modifying the resource loader .. I think I'm going
to go with this solution since  regexp replace seems to work well, hence if
I can intercept the vm files and fix them before velocity references them
I'll be in good shape.

The way I tried to do this so far is as follows:


StringResourceLoader.setRepository(StringResourceLoader.REPOSITORY_NAME_DEFAULT,new
StringResourceRepositoryImpl());
        instance = new Velocity();
Velocity.setProperty(Velocity.FILE_RESOURCE_LOADER_CACHE, false);

        Velocity.setProperty(Velocity.FILE_RESOURCE_LOADER_PATH,
TEMPLATE_LOCATION);

        Velocity.addProperty(Velocity.RESOURCE_LOADER, "classpath");
        Velocity.addProperty(Velocity.RUNTIME_REFERENCES_STRICT +
".escape","true");
        Velocity.setProperty("classpath." + Velocity.RESOURCE_LOADER +
".class",
            ClasspathResourceLoader.class.getName());
        Velocity.setProperty("classpath." + Velocity.RESOURCE_LOADER +
".cache", "false");
        Velocity.setProperty("classpath." + Velocity.RESOURCE_LOADER +
".modificationCheckInterval", "2");
        Velocity.setProperty("loader", "string");
        Velocity.setProperty("string.resource.loader.class",
"org.apache.velocity.runtime.resource.loader.StringResourceLoader");

Velocity.setProperty("string.resource.loader.repository.class","org.apache.velocity.runtime.resource.util.StringResourceRepositoryImpl");
Velocity.init();


Following this, I iterate over all my known velocity templates and try to
put them in the string resource loader repository, using something like
this
                repository.putStringResource((template path + name),
sanitizedAlert);
it was my understanding that putting these in, when I then call
mergeTemplate(), rather than using the files on the hard drive it would use
the copies in this resource loader repository.
However, it seems to still default to checking the classpath file loader,
and debugging in I didn't see any sort of conditonal check based on any of
the properties I set which wold make it use this resource loader repository
instead.

Am I doing this totally wrong? Is the String Resource Loader Repository not
what I want here?

thanks,
Pete

On Fri, Jul 13, 2012 at 11:25 AM, Nathan Bubna <[email protected]> wrote:

> 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]
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>