Re: ".vars" names can't contain dashes?

Daniel, that was the perfect spot to start tracing, thanks!  :-)


Short story:   It's not a Freemarker issue.   Rather the Struts team chose
to hard-wire Freemarker to treat .vars names as OGNL expressions, and there
seems no way to tell OGNL to *not* parse them.  So under Struts, "-" and "+"
(and possibly other characters) cannot appear in .vars names.


Long story...

- freemarker.core.BuiltinVariable (line 192) is where Freemarker starts to
process .vars expressions

- freemarker.core.Environment (line 1088) hands control over to the
"rootDataModel" which the Struts team
   hard-wired to be an instance of
org.apache.struts2.views.freemarker.ScopesHashModel

- line 70 of that class (using version 2.1.8.1 of Struts) calls
"stack.findValue"; "stack" has been wired to be
  an instance of com.opensymphony.xwork2.ognl.OgnlValueStack

- at line 236 this class in turn asks an instance of OgnlUtil to find the
object, and that's where the name is
   assumed to be an OGNL expression and is parsed, turning "foo-bar" into (
foo - bar )

At no point along the way does there seem to be a choice to NOT treat the
.vars name as an expression (a comment in FreemarkerResult hints at the
possibility, but the code doesn't follow through).   In theory I could have
my implementation of FreemarkerManager create a variant of ScopesHashModel,
but that would take a lot of work to change all the associated classes with
it.

(Nor does there seem to be a way to escape "-" characters in OGNL
expressions.  Seems there was discussion 5-6 years ago to do this, but....
.vars( "foo\\-bar" ) fails on finding "-" after "\", so presumably "-" isn't
escapable?)

:-(

I'm not clear what the use-case is for treating .vars names as
expressions... but I don't think Struts is going to change, now.  Rather
than override a half dozen Struts classes, I instead changed the code that
loads our ResourceBundles into the value stack:  it now changes the names to
replace "-" and "_", and likewise my .vars names are changed the same way in
the template and... tada.  It works.  Woo.


rodney



On Fri, Jun 10, 2011 at 2:37 PM, Daniel Dekany <[email protected]> wrote:

> Friday, June 10, 2011, 7:00:10 PM, Rodney Gitzel wrote:
>
> > There's no Freemarker configuration to speak of.   Freemarker is
> > running inside a Struts 2 app, which has configuration for *finding*
> > templates but not for processing them.   Well, except maybe for
> > "struts.freemarker.wrapper.altMap" which didn't seem to matter (I
> > tried both false and true values).
> >
> > The template is dead simple: I emptied out an existing working
> > template and put in just the .vars expressions on their own, so
> > there shouldn't be any other macros or variables or such coming into
> play.
> >
> > The data structure isn't anything special:  we put plain old Java
> > ResourceBundles onto the value stack by name (e.g.
> > "resources_product" where "product" could be any product code).
> > .vars picks them out of there no problem normally.
> >
> > Later today I may try to reproduce it outside of Struts.   Also, I
> > could trace it with the debugger, but when trying to trace the
> > exceptions thrown yesterday, it wasn't clear at all what classes
> > were doing what.  Is there an obvious place to put a breakpoint for .vars
> processing?
>
> freemarker/core/BuiltinVariable.java line 192 where it's implemented.
> But it's just a env.getVariable(key) call, leads to
> freemarker/core/Environment.java line 1068. So I have no idea what
> could cause the problem. My only guess remains that the it's the root
> hash that returns those odd values.
>
> > Thanks!
> >
> > rodney
> >
> > On Thu, Jun 9, 2011 at 5:17 PM, Daniel Dekany <[email protected]>
> wrote:
> > Friday, June 10, 2011, 1:12:10 AM, Rodney Gitzel wrote:
> >
> >> We're using version 2.3.16, and I've just tracked down a weird bug
> >> in one of our apps.  It came down to there now being hyphens in some
> >> of our product code strings.  The codes are used to pull hashes of
> >> localized text from the global scope using ".vars".   Upgrading to
> >> 2.3.18 did not change the issue I found.
> >>
> >> Reducing the issue brought me to an example that anyone can try:
> >> ${.vars["foo-bar"]}  in a template outputs "0" (without the quotes).
> >> ${.vars["foo+bar"]} outputs "nullnull".   ${.vars["foobar"]}
> >> correctly triggers an InvalidReferenceException.   All three should
> fail, not just the last one.
> >>
> >>
> http://freemarker.sourceforge.net/docs/app_faq.html#faq_strange_variable_nameimplies
> >> this should work.   Instead, it appears the ".vars" parameter string is
> being evaluated!
> >
> >
> > It works correctly here. What are your configuration settings (not
> > like I have any idea now how to achieve this with settings...)? Or is
> > your data-model something special?
> >
> >> I saw mention of a similar issue a few weeks ago on this mailing
> >> list, and it was suggested to prefix the parameter string with "@".
> >> That might work with other hashes, but it does NOT work with
> >> ".vars".
> >
> > That has nothing to do with these. That was an XML thing, where the
> > name of the variable was indeed @something.
> >
> >> I just took a working example (.vars["resources_title"]) and that
> >> change made it throw an InvalidReferenceException
> >> (.vars["@resources_title"]).
> >>
> >> Thanks.
> >>
> >> rodney
> >>
> >>
> >
> > --
> > Best regards,
> >  Daniel Dekany
> >
>
> --
> Best regards,
>  Daniel Dekany
>
>

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user