[tools] Using java.text.MessageFormat in templates
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?
Thanks,
-chris
signature.asc
Description: OpenPGP digital signature
Re: [tools] Using java.text.MessageFormat in templates
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
signature.asc
Description: OpenPGP digital signature
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 <
ch...@christopherschultz.net> 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
>
>
Re: [tools] Using java.text.MessageFormat in templates
Nathan, On 2/21/14, 1:42 PM, Nathan Bubna wrote: > 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. That sounds reasonable, yet MessageTool does not extend from ResourceTool, so a bunch of capability is lost with that conflict. Would it be reasonable for MessageResourcesTool to extend ResourceTool? (I just realized that ResourceTool is "locale-ized" and therefore should probably not be in my application scope. Either that, or MessageTool.render should have another method that accepts a Locale argument). -chris signature.asc Description: OpenPGP digital signature
Re: [tools] Using java.text.MessageFormat in templates
I'll be honest: toward the end of my active VelocityTools use and work, i was not using VelocityStruts and it did not get the attention it could have. If you can make MessageResourcesTool extend ResourceTool, that sounds reasonable to me. ResourceTool does extend SafeConfig (via LocaleConfig) so you can use it in any scope: http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/SafeConfig.html On Fri, Feb 21, 2014 at 10:58 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Nathan, > > On 2/21/14, 1:42 PM, Nathan Bubna wrote: > > 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. > > That sounds reasonable, yet MessageTool does not extend from > ResourceTool, so a bunch of capability is lost with that conflict. Would > it be reasonable for MessageResourcesTool to extend ResourceTool? > > (I just realized that ResourceTool is "locale-ized" and therefore should > probably not be in my application scope. Either that, or > MessageTool.render should have another method that accepts a Locale > argument). > > -chris > >
