You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Thomas Åhlen <th...@obidobi.net> on 2001/11/25 08:33:04 UTC
macros powerfull but dangerous
Since a macro function works in the same way as a directive there might be
namespace problems in the future when Velocity expands with new directives.
Is there a list with reserved namespace of possible future directives?
The last thing I would like to do is build an application framework with
lots of predefined layout templates and macros, later finding out that one
of my macros has the same name a new directive. Then having to rename my
macro, changing all templates that uses this macro. This would destroy
backward compability for my application framework. Lets say lots of people
us my open source servlet framework and have used my predefined macros in
their templates. They will not be happy if I have to rename one of the macro
calls when upgrading to latest Velocity package.
Is my fear valid or have I missunderstod something?
Thomas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macros powerfull but dangerous
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/25/01 3:07 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
>>> Since a macro function works in the same way as a directive there might
> be
>>> namespace problems in the future when Velocity expands with new
> directives.
>>>
>>
>> Valid. :)
>>
>> Maybe prefix your VMs with 'vm'?
>
> Yes I will use a prefix to be sure.
> Thou #image, #table is very tempting :)
To be honest, I think it's fairly certain we wouldn't add those directives.
Nothing is 100% sure of course, but still - those are pretty application
domain specific. (We ain't just web...)
Not that I think we would ever do it either, but #while() is more risky....
:)
>
> Guess a little varning and prefix suggestion on the Developer Guide would be
> nice. Not everyone thinks about that possibility I guess.
>
> What about
>
> #macro ( range $a $b )
> $a to $b
> #end
>
> #macro.range( $value.low $value.high )
>
> You could also extend the functionallity of #parse and #include
>
> #parse.jar( "myfile" )
> #parse.db( "myfile" )
>
> [velocity.properties]
> file.resource.loader.jar.description = ...
> file.resource.loader.jar.class = ...
> file.resource.loader.jar.path = ...
>
> file.resource.loader.db.description = ...
> file.resource.loader.db.class = ...
> file.resource.loader.db.path = ...
>
> Hope you like suggestions. I can keep sending them :)
>
> Thomas
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macros powerfull but dangerous
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/25/01 3:46 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
>>> #parse.jar( "myfile" )
>>> #parse.db( "myfile" )
>>>
>>> [velocity.properties]
>>> file.resource.loader.jar.description = ...
>>> file.resource.loader.jar.class = ...
>>> file.resource.loader.jar.path = ...
>>>
>>> file.resource.loader.db.description = ...
>>> file.resource.loader.db.class = ...
>>> file.resource.loader.db.path = ...
>
>> This means that your template is tightly tied to your configuration...
>
> Yes I see your point. But I can't see why someone would like to run their
> application with someone elses configuration :).
What I do is use files when developing, so I can edit them in place, and
then jar them up for deployment...
> The advantage I see in the
> above notation is that it makes it possible to categorise your templates.
By source? Then you are stuck...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macros powerfull but dangerous
Posted by Thomas Åhlen <th...@obidobi.net>.
>> #parse.jar( "myfile" )
>> #parse.db( "myfile" )
>>
>> [velocity.properties]
>> file.resource.loader.jar.description = ...
>> file.resource.loader.jar.class = ...
>> file.resource.loader.jar.path = ...
>>
>> file.resource.loader.db.description = ...
>> file.resource.loader.db.class = ...
>> file.resource.loader.db.path = ...
>This means that your template is tightly tied to your configuration...
Yes I see your point. But I can't see why someone would like to run their
application with someone elses configuration :). The advantage I see in the
above notation is that it makes it possible to categorise your templates.
Thomas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macros powerfull but dangerous
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/25/01 3:07 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
>>> Since a macro function works in the same way as a directive there might
> be
>>> namespace problems in the future when Velocity expands with new
> directives.
>>>
>>
>> Valid. :)
>>
>> Maybe prefix your VMs with 'vm'?
>
> Yes I will use a prefix to be sure.
> Thou #image, #table is very tempting :)
>
> Guess a little varning and prefix suggestion on the Developer Guide would be
> nice. Not everyone thinks about that possibility I guess.
>
> What about
>
> #macro ( range $a $b )
> $a to $b
> #end
>
> #macro.range( $value.low $value.high )
Not bad :)
>
> You could also extend the functionallity of #parse and #include
>
> #parse.jar( "myfile" )
> #parse.db( "myfile" )
>
> [velocity.properties]
> file.resource.loader.jar.description = ...
> file.resource.loader.jar.class = ...
> file.resource.loader.jar.path = ...
>
> file.resource.loader.db.description = ...
> file.resource.loader.db.class = ...
> file.resource.loader.db.path = ...
This means that your template is tightly tied to your configuration...
> Hope you like suggestions. I can keep sending them :)
>
> Thomas
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macros powerfull but dangerous
Posted by Thomas Åhlen <th...@obidobi.net>.
>> Since a macro function works in the same way as a directive there might
be
>> namespace problems in the future when Velocity expands with new
directives.
>>
>
>Valid. :)
>
>Maybe prefix your VMs with 'vm'?
Yes I will use a prefix to be sure.
Thou #image, #table is very tempting :)
Guess a little varning and prefix suggestion on the Developer Guide would be
nice. Not everyone thinks about that possibility I guess.
What about
#macro ( range $a $b )
$a to $b
#end
#macro.range( $value.low $value.high )
You could also extend the functionallity of #parse and #include
#parse.jar( "myfile" )
#parse.db( "myfile" )
[velocity.properties]
file.resource.loader.jar.description = ...
file.resource.loader.jar.class = ...
file.resource.loader.jar.path = ...
file.resource.loader.db.description = ...
file.resource.loader.db.class = ...
file.resource.loader.db.path = ...
Hope you like suggestions. I can keep sending them :)
Thomas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macros powerfull but dangerous
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/25/01 2:33 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
> Since a macro function works in the same way as a directive there might be
> namespace problems in the future when Velocity expands with new directives.
>
> Is there a list with reserved namespace of possible future directives?
>
> The last thing I would like to do is build an application framework with
> lots of predefined layout templates and macros, later finding out that one
> of my macros has the same name a new directive. Then having to rename my
> macro, changing all templates that uses this macro. This would destroy
> backward compability for my application framework. Lets say lots of people
> us my open source servlet framework and have used my predefined macros in
> their templates. They will not be happy if I have to rename one of the macro
> calls when upgrading to latest Velocity package.
>
> Is my fear valid or have I missunderstod something?
>
Valid. :)
Maybe prefix your VMs with 'vm'?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>