Re: [tools] Using java.text.MessageFormat in templates

Yes, the conflict was intentional. The idea was that people using
VelocityStruts would default to using Struts' message support, so we should
default $text to use that. Whether that is still valid reasoning, i don't
know. I haven't used Struts in a very, very long time.


On Fri, Feb 21, 2014 at 10:17 AM, Christopher Schultz <
[email protected]> wrote:

> All,
>
> On 2/21/14, 12:48 PM, Christopher Schultz wrote:
> > All,
> >
> > I have a template where I'd like to take some text in a variable and do
> > parametric-replacement like new
> > MessageFormat("format").format(replacements) might do.
> >
> > I'm already using Velocity Tools/Struts to great effect with pre-defined
> > messages in properties files, but this data needs to come from a
> > database and I'd rather not pre-process the data in Java code unless
> > absolutely necessary.
> >
> > I've browsed through the tools available from Velocity Tools and I don't
> > really see anything that would meet my needs. I even looked at ClassTool
> > to see if I could instantiate an object through brute-force and it looks
> > like that is not possible.
> >
> > Is there a stock tool I can use, or will I have to write my own?
>
> Of course, as soon as I post, I find ResourceTool.render, which appears
> to do exactly what I want.
>
> I can see that while the Javadoc says the method signature is
> render(Object resource, Object[] args), Velocity treats it as a varargs
> call and so you need to do:
>
>    $text.render("format", arg, arg, arg)
>
>  instead of
>
>    $text.render("format", [arg, arg, arg])
>
> Use of the latter yields unfortunate results ;)
>
> Also, it looks like the default key for ResourceTool is "text", as I can
> see this during startup:
>
> INFO:  Velocity  [debug] Configuring factory with:
> FactoryConfiguration from 8 sources including 4 data with 3 toolboxes:
>  Toolbox 'application' with 1 properties [scope -auto-> application; ]
> and 17 tools:
>   Tool 'alternator' => org.apache.velocity.tools.generic.AlternatorTool
>   Tool 'class' => org.apache.velocity.tools.generic.ClassTool
> [...]
>   Tool 'text' => org.apache.velocity.tools.generic.ResourceTool
>
> ...but it conflicts with Velocity Struts, which re-defined the key:
>
>  Toolbox 'request' with 2 properties [scope -auto-> request; xhtml
> -auto-> true;
>  ] and 16 tools:
>   Tool 'context' => org.apache.velocity.tools.view.ViewContextTool
>   [...]
>   Tool 'text' => org.apache.velocity.tools.struts.MessageTool
>
> Since the "Struts" key is at a closer scope (request instead of
> application), it masks the definition at the application level. I can
> clearly re-name the ResourceTool's key, but I was wondering if it was
> intentional to have a tool key naming conflict there?
>
> Thanks,
> -chris
>
>