[stringtemplate-interest] How to use variables inside format modifiers

[Mohamed Mansour]

Hmm, that would be unfortunate. I can't use this kind of approach then. I am
trying to create a generic "Report" where every user can do whatever they
want with it. If they wanted to add 10 to the result to any variable, they
could. But we can't do that with StringTemplate.
I guess that is the limitation of StringTemplate.

Isn't there any way I can make it work, like a hack? A user can modify a
variable by appending(adding) a number to it. (simply scenario)

Thanks,

-- Mohamed Mansour


On Fri, Jul 31, 2009 at 2:16 PM, Jim Idle <jimi at temporal-wave.com> wrote:

>  Mohamed Mansour wrote:
>
> Hello,
>  I have been using StringTemplate to produce stylized report files. Some
> variables need to be formatted someway, for example if I want to uppercase a
> variable I do, therefore I setup an attribute renderer:
> $foo;format="uppercase"$
>
>  In my specific case I would need to apply more than one formatter (more
> than one attribute renderer for a variable), so I created many attribute
> renders and I can process them like:
> $foo;format="uppercase|fixedlength:10:x:R|lowercase"$ If you notice a
> modifer could have parameters ( with colons as seen with fixedlength)
>
>  So if $foo is "123aBc" it will return "XXXX123abc", the above works
> perfectly fine
>
>  My main problem is that, some parameters in my format modifiers need to
> be ST variables, for example, I would need to add a number:
> $numA;format="calculate:+:$numB$"$
>
>  If numA = 10, and numB = 5, the formatter will return15. But my problem
> is that, it treats the variables as a string doesn't actually give me the
> exact value of the variable.
>
>  How can I pass variables in the "format" area?
>
> Calculations need to be performed before setting the values in the
> templates otherwise you are breaking the model/view separation that
> StringTemplate is as strict about as it can be. In other words you should
> not be trying to do this.
>
> The attribute renderer while powerful, has to be used carefully so that you
> do not break this  separation as it is kind of a back door (the only way to
> close it would be to implement a generic formatting engine and get rid of
> attribute renderers, but that is a lot of code bloat of course.
>
> Jim
>
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20090731/58967d02/attachment.html