You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by James Maes <jm...@sportingnews.com> on 2001/12/07 05:17:45 UTC
1.3, status of
Geir,
We are thinking about going ahead with the 1.3 branch for the upcoming beta
rollout. Are there any other changes besides the plugable ResourceManager
that I should watch out for?
Thanks
-James
--
------------------------------------
|| James Maes
|| Senior Programmer
|| jmaes@sportingnews.com
|| The Sporting News
|| www.sportingnews.com
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of (Whitespace handling)
Posted by Christoph Reck <Ch...@dlr.de>.
"Geir Magnusson Jr." wrote:
>
> What happens with
>
> Hello there, my name is #parse("name.vm") and I am happy!
>
> And name.vm is >geir< (where >, < delimit the contents of the file)
>
> Output should be
>
> Hello there, my name is geir and I am happy!
>
> No whitespace slurping is wanted...
Yup, your expected output is what I propose.
The proposed rule is:
A) line{1,n} with schmoo only is emitted as is.
B) if a line contains non-whitespace schmoo and directive{1,n},
then the directive(s) will leave its whitespace around it
alone (either the parser does this or the directive emits it).
C) if a line contains only whitespaces and a directive, the
whitespace should become part of the directive and leave it
up to the directive on how to render it (normally it will
not emit it to the output, but I could think of an #indent
directive that will use its whitespace prefix to prepend
every line it outputs...)
:) Christoph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of (Whitespace handling)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/11/01 10:08 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> What happens with
>
>
> Hello there, my name is #parse("name.vm") and I am happy!
>
>
> And name.vm is >geir< (where >, < delimit the contents of the file)
>
> Output should be
>
> Hello there, my name is geir and I am happy!
>
>
> No whitespace slurping is wanted...
(Just to be clear, I mean with some of the proposals floating about...)
I will catch up to the discussion later today...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of (Whitespace handling)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
What happens with
Hello there, my name is #parse("name.vm") and I am happy!
And name.vm is >geir< (where >, < delimit the contents of the file)
Output should be
Hello there, my name is geir and I am happy!
No whitespace slurping is wanted...
On 12/11/01 8:38 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> Denis,
>
> one of your points does make sense:
>
>>> Currently in VTL the desinger must use the ## and #**# constructs
>>> to actively control output whitespaces in an ugly manner.
>>>
>>>> If we want the ability to escape space gobbling, why not to use a
>>>> new token? I thought of ### or #_
>>>> I would also like this token to do the opposite, i.e. escape space
>>>> rendering (and start gobbling). (we could use a pair of tokens for
>>>> this, e.g. #+ and #-)
>>>
>>> -1, keep it simple.
>>
>> Duh.
>>
>> I'm still not totally convinced that using the same token (##) for EOL
>> gobbling and for commenting 'make it simple'. When I use a light switch,
>> I expect it to turn the light on, not to open the blinds at the same
>> time. I'd say that the switch that also opens the blinds is bad design.
>> Similarly, a construct that allows commenting isn't expected to alter
>> the output at the same time.
>> I think that ## should therefore be documented as a 'EOL escaper', not
>> as a single-line comment. The commenting part is only a side-effect of
>> the construct (which would be mentioned in the doc, of course).
>
> It would be nice to have the ## comment not to gobble the EOL character,
> unless it is a standalone directive. This would match the whitespace
> handling I proposed for the other directives.
>
> The only reason for keeping the ## gobbling the EOL is that it has been
> used many times this way up to know. It would break code if it is
> changed.
>
> So the designer that wishes to post-comment existing templates will
> need to be *very* carefull with ##comments or continue using #*...*#
> in this case.
>
> Anyway, it is good practice in java and C et.al to add comments before
> blocks of statements instead of post-line -> why not in VTL?. This way
> post-inserting comments, each on in its own line, will not change an
> existing template. With my proposal this even applies if these are
> indented.
>
>> [snip]
>> In that case, it would be as well to un-increment it. IMHO, this version:
>>
>> #macro( csv $list )
>> #set( $sep = "" )
>> #foreach( $item in $list )
>> $sep$item## escape EOL
>> #set( $sep = ", " )
>> #end
>> #end
>>
>> Looks better than this one:
>>
>> #macro( csv $list )
>> #set( $sep = "" )
>> #foreach( $item in $list )
>> #noindent($sep$item)##
>> #set( $sep = ", " )
>> #end
>> #end
>
> No need for that ## after the #noindent() call, since I propose
> that standalone directives gobble all whitespaces around them
> including the EOL character.
>
> On the other hand, your non-indented version should be a tick
> more performant since it is once macro call less - for the users
> that need *real* velocity.
>
>> [snip]
>> +1 for your proposal.
>
> Thanks.
>
>> :)
>>
>> -- Denis.
>
>
> Anyone else sees my proposal as a clean whitespace handling solution?
> We need a quorum to get Geir and other comitters convinced.
>
> :) Christoph
>
> --
> 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
"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>
Re: 1.3, status of (Whitespace handling)
Posted by Christoph Reck <Ch...@dlr.de>.
Denis,
one of your points does make sense:
> > Currently in VTL the desinger must use the ## and #**# constructs
> > to actively control output whitespaces in an ugly manner.
> >
> >> If we want the ability to escape space gobbling, why not to use a
> >> new token? I thought of ### or #_
> >> I would also like this token to do the opposite, i.e. escape space
> >> rendering (and start gobbling). (we could use a pair of tokens for
> >> this, e.g. #+ and #-)
> >
> > -1, keep it simple.
>
> Duh.
>
> I'm still not totally convinced that using the same token (##) for EOL
> gobbling and for commenting 'make it simple'. When I use a light switch,
> I expect it to turn the light on, not to open the blinds at the same
> time. I'd say that the switch that also opens the blinds is bad design.
> Similarly, a construct that allows commenting isn't expected to alter
> the output at the same time.
> I think that ## should therefore be documented as a 'EOL escaper', not
> as a single-line comment. The commenting part is only a side-effect of
> the construct (which would be mentioned in the doc, of course).
It would be nice to have the ## comment not to gobble the EOL character,
unless it is a standalone directive. This would match the whitespace
handling I proposed for the other directives.
The only reason for keeping the ## gobbling the EOL is that it has been
used many times this way up to know. It would break code if it is
changed.
So the designer that wishes to post-comment existing templates will
need to be *very* carefull with ##comments or continue using #*...*#
in this case.
Anyway, it is good practice in java and C et.al to add comments before
blocks of statements instead of post-line -> why not in VTL?. This way
post-inserting comments, each on in its own line, will not change an
existing template. With my proposal this even applies if these are
indented.
>[snip]
> In that case, it would be as well to un-increment it. IMHO, this version:
>
> #macro( csv $list )
> #set( $sep = "" )
> #foreach( $item in $list )
> $sep$item## escape EOL
> #set( $sep = ", " )
> #end
> #end
>
> Looks better than this one:
>
> #macro( csv $list )
> #set( $sep = "" )
> #foreach( $item in $list )
> #noindent($sep$item)##
> #set( $sep = ", " )
> #end
> #end
No need for that ## after the #noindent() call, since I propose
that standalone directives gobble all whitespaces around them
including the EOL character.
On the other hand, your non-indented version should be a tick
more performant since it is once macro call less - for the users
that need *real* velocity.
>[snip]
> +1 for your proposal.
Thanks.
> :)
>
> -- Denis.
Anyone else sees my proposal as a clean whitespace handling solution?
We need a quorum to get Geir and other comitters convinced.
:) Christoph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of (Whitespace handling)
Posted by br...@euro.apple.com.
Hi
On Monday, December 10, 2001, at 03:25 PM, Christoph Reck wrote:
> Hi Denis,
>
> I think you misunderstood me in some points, explanation below...
Ok!
> Denis, please reply if you agree/disagree with my explanations.
>
>>
>> Don't like it. We should be able to use indentation for logic
>> structuring as well as for indented output.
>
> This is exactly what I propose. I'm just differentiating standalone
> directives from schmoo. Indented logic will remain logic and be
> transparent to the output. Indented text is just schmoo and passes
> unchanged.
Got it.
> Mixed text and #directives should disable whitespace
> gobbling to be backward compatible and to allow dynamic content
> within schmoo.
>
> Seeing some reasoning below, standalonw #macro calls should also
> gobble whitespaces. Use
> #**##macrocall(...)
> to keep it indented.
>
>>
>>>> a flag in the implementing
>>>> class could define if it gobbles whitespaces around it or not.
>>
>> Didn't think about that. Seems worth investigating...
>
> This note was intended for application defined directives, and also
> usable to make #parse and #include work differently.
>
> On a second thought, maybe #parse, #indent and #* *# should
> also gobble surrounding whitespaces when they are standalone,
Yes.
> one can always use
> #**##parse("template.vm")
> or
> #indent(" " #parse($template))
> to get nicely indented parsed input.
>
>>>>
>>>> If you place multiple directives on one line or mix directives,
>>>> references and schmoo in a line it should leave whitespaces
>>>> around it untouched.
>>
>> And what if you want to indent the whole mixed line in the code but
>> not in the output? #* *#?
>
> How can the parser know? #*
> *#The only way the designer can achieve this is by #*
> *#commenting out the EOLs.
> or by using a
> #macro(noindent $text)$text#end
> and call it
> #noindent( "#if($foo)$foo#else$bar#end" )
I see above that schmoo is indented as it is in the source, so my remark
is moot anyway.
>
> Vel says here "use a macro"! So maybe standalone macros should also
> gobble surrounding whitespaces. Then you can use #noindent and #indent
> macros for this purpose...
>
>> I read the proposal you offered back in May.
>> One thing that strikes me in it, as well as in current
>> implementation of Velocity parser (CVS), is that comments #**# are
>> used to 'escape' a EOL. IMHO adding a comment shouldn't alter in
>> any way the processed output. I put this axiom as point 1 of my own
>> proposal.
>
> If the template designer puts an #*
> *#spanning over an EOL, he means to skip the EOL in the
> output. This is what anyone wouold expect.
Right.
>
> What sometimes looks strange is that a ##comment gobbles the EOL in
> the output unexpectedly, but this is again what is expected, so
> the designer has to use #*comment*# at the end of a line to keep the
> EOL. Again this is standard practice.
So, if I want to add comments in a macro without altering its output, I
should use #*starred*# comments. On the other hand, if I want to eat the
trailing EOL in a line I can use ##. This has the additional effect that
anything following ## is ignored, so I can use it as comment.
>
> Currently in VTL the desinger must use the ## and #**# constructs
> to actively control output whitespaces in an ugly manner.
>
>> If we want the ability to escape space gobbling, why not to use a
>> new token? I thought of ### or #_
>> I would also like this token to do the opposite, i.e. escape space
>> rendering (and start gobbling). (we could use a pair of tokens for
>> this, e.g. #+ and #-)
>
> -1, keep it simple.
Duh.
I'm still not totally convinced that using the same token (##) for EOL
gobbling and for commenting 'make it simple'. When I use a light switch,
I expect it to turn the light on, not to open the blinds at the same
time. I'd say that the switch that also opens the blinds is bad design.
Similarly, a construct that allows commenting isn't expected to alter
the output at the same time.
I think that ## should therefore be documented as a 'EOL escaper', not
as a single-line comment. The commenting part is only a side-effect of
the construct (which would be mentioned in the doc, of course).
>>
>> And to finish, I would like to gobble space after #directives,
>> except #end. I would also like to gobble space before #else,
>> #elseif and #end. Some arrangements could be made, such as
>> rendering spaces inside one line with mixed commands and text. Or
>> putting a special flag on a class to tell if space is gobbled
>> around it or not.
>
> This is exactly my proposal (but with *very* straightforward
> and simple rules).
Ok.
>> Macro example:
>> ---
>> #macro( csv $list )
>> #set( $sep = "" )
>> #foreach( $item in $list )
>> $sep$item###
>> #set( $sep = ", " )
>> #end
>> #end
>>
>> #csv([1, 2, 3])
>> ---
>> The space after $sep$item has to be escaped, because of the #set
>> directive following it. All other spaces are gobbled. It will
>> render as:
>> ---1, 2, 3---
>
> With my proposal you will just need the current ## instead of ###
> to get you desired output (but you will need an extra call to
> #macro(noindent $text)$text#end
> to avoid the spaces before your references).
In that case, it would be as well to un-increment it. IMHO, this version:
#macro( csv $list )
#set( $sep = "" )
#foreach( $item in $list )
$sep$item## escape EOL
#set( $sep = ", " )
#end
#end
Looks better than this one:
#macro( csv $list )
#set( $sep = "" )
#foreach( $item in $list )
#noindent($sep$item)##
#set( $sep = ", " )
#end
#end
>
>> HTML table example:
>> ---
>> schmoo
>>
>> #if($!foo)
>> <table>
>> #for ($key in $foo)
>> <tr> ... display ...</tr>
>> #end
>> </table>
>> #end
>> ---
>> The space is gobbled after #if and #for, but it is gobbled before
>> #end. So the output is correctly indented:
>
> Again, look at it from my perspective: the lines with #if, #for, and
> twice the #end will not output anything. The rest produces literally
> what you wrote and thus the expected output.
Which is better than my solution, because if the #for encloses several
lines I would have an indentation issue. With your proposal they stay on
the same column.
> per (current) definiton:
> #* *# encloses whatever contents it has (including EOL)
> ## after anything will gobble up to and including the EOL
> I just want them to gobble leading whitespaces if they are indented
> and alone in one line.
>
> So, with my proposal:
> Adding#* *#comments on any line will not change the output (please
> note
> that spaces before and after the #*...*# will apear in the output
> in the current implementation, with my proposal these will dissapear
> if the comment is standalone).
> If you add your comments each on its own line you will not
> change the output. Current implentation does change if you comments
> are indented.
> If you append ##... comments to a line you will change the output
> (gobbles the EOL), as it does already in the current implementation.
>
+1 for your proposal.
:)
-- Denis.
>>
>> -- Denis.
>
> :) Christoph
>
> --
> To unsubscribe, e-mail: <mailto:velocity-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:velocity-user-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of (Whitespace handling)
Posted by Christoph Reck <Ch...@dlr.de>.
Hi Denis,
I think you misunderstood me in some points, explanation below...
Denis, please reply if you agree/disagree with my explanations.
Denis wrote:
>
> Hi Christoph
>
> >> Any chance on this in 1.3?
> >> Otherwise please make this into 1.4.
> >>
> >> The simple and straightforward proposal is to have stand alone
> >> directives transparent to the output. #parse, #include and #macro
> >> could be an exception on this, since they insert code at the
> >> specified location (if it is indented, the code it genereates
> >> should be indented - maybe it should event prefix each line it
> >> generates with its own indentation);
>
> Don't like it. We should be able to use indentation for logic
> structuring as well as for indented output.
This is exactly what I propose. I'm just differentiating standalone
directives from schmoo. Indented logic will remain logic and be
transparent to the output. Indented text is just schmoo and passes
unchanged. Mixed text and #directives should disable whitespace
gobbling to be backward compatible and to allow dynamic content
within schmoo.
Seeing some reasoning below, standalonw #macro calls should also
gobble whitespaces. Use
#**##macrocall(...)
to keep it indented.
>
> >> a flag in the implementing
> >> class could define if it gobbles whitespaces around it or not.
>
> Didn't think about that. Seems worth investigating...
This note was intended for application defined directives, and also
usable to make #parse and #include work differently.
On a second thought, maybe #parse, #indent and #* *# should
also gobble surrounding whitespaces when they are standalone,
one can always use
#**##parse("template.vm")
or
#indent(" " #parse($template))
to get nicely indented parsed input.
> >>
> >> If you place multiple directives on one line or mix directives,
> >> references and schmoo in a line it should leave whitespaces
> >> around it untouched.
>
> And what if you want to indent the whole mixed line in the code but
> not in the output? #* *#?
How can the parser know? #*
*#The only way the designer can achieve this is by #*
*#commenting out the EOLs.
or by using a
#macro(noindent $text)$text#end
and call it
#noindent( "#if($foo)$foo#else$bar#end" )
Vel says here "use a macro"! So maybe standalone macros should also
gobble surrounding whitespaces. Then you can use #noindent and #indent
macros for this purpose...
> I read the proposal you offered back in May.
> One thing that strikes me in it, as well as in current
> implementation of Velocity parser (CVS), is that comments #**# are
> used to 'escape' a EOL. IMHO adding a comment shouldn't alter in
> any way the processed output. I put this axiom as point 1 of my own
> proposal.
If the template designer puts an #*
*#spanning over an EOL, he means to skip the EOL in the
output. This is what anyone wouold expect.
What sometimes looks strange is that a ##comment gobbles the EOL in
the output unexpectedly, but this is again what is expected, so
the designer has to use #*comment*# at the end of a line to keep the
EOL. Again this is standard practice.
Currently in VTL the desinger must use the ## and #**# constructs
to actively control output whitespaces in an ugly manner.
> If we want the ability to escape space gobbling, why not to use a
> new token? I thought of ### or #_
> I would also like this token to do the opposite, i.e. escape space
> rendering (and start gobbling). (we could use a pair of tokens for
> this, e.g. #+ and #-)
-1, keep it simple.
>
> And to finish, I would like to gobble space after #directives,
> except #end. I would also like to gobble space before #else,
> #elseif and #end. Some arrangements could be made, such as
> rendering spaces inside one line with mixed commands and text. Or
> putting a special flag on a class to tell if space is gobbled
> around it or not.
This is exactly my proposal (but with *very* straightforward
and simple rules).
>
> Simple example:
> ---
> #if(...)
> ## a comment
> #set(...)
> schmoo
> #else
> #foo(...)
> bark
> #end
> ---
> The leading spaces before #if are rendered, as well as the EOL
> after #end.
I see this the other way around, and the result is the same. The
#if, ##comment, #set, #else, and #end make no output (even no
whitespaces and EOL); whereas, " schmoo$NL" and " bark$NL"
will go to the ouput literally and unchanged.
> The output is either:
> ---
> schmoo
> ---
> or
> ---
> bark
> ---
>
> Macro example:
> ---
> #macro( csv $list )
> #set( $sep = "" )
> #foreach( $item in $list )
> $sep$item###
> #set( $sep = ", " )
> #end
> #end
>
> #csv([1, 2, 3])
> ---
> The space after $sep$item has to be escaped, because of the #set
> directive following it. All other spaces are gobbled. It will
> render as:
> ---1, 2, 3---
With my proposal you will just need the current ## instead of ###
to get you desired output (but you will need an extra call to
#macro(noindent $text)$text#end
to avoid the spaces before your references).
>
> Example of rendering whitespaces:
> ---
> #foreach( $a in $vector )
> ###
> $a
> ###
> #end
> ---
> This time we want each element on its own line. So we escape space
> gobbling after #foreach and before #end. There is an extra EOL
> after #end. The output is like:
> ---
> a car
> a plane
> 1,000 balloons
>
> ---
With my proposal just leave avay the ###s and you get what you want.
>
> HTML table example:
> ---
> schmoo
>
> #if($!foo)
> <table>
> #for ($key in $foo)
> <tr> ... display ...</tr>
> #end
> </table>
> #end
> ---
> The space is gobbled after #if and #for, but it is gobbled before
> #end. So the output is correctly indented:
Again, look at it from my perspective: the lines with #if, #for, and
twice the #end will not output anything. The rest produces literally
what you wrote and thus the expected output.
> ---
> schmoo
>
> <table>
> <tr> ... display ...</tr>
> <tr> ... display ...</tr>
> <tr> ... display ...</tr>
> <tr> ... display ...</tr>
> </table>
> ---
>
> I am not very aware of the compatibility problems with this scheme,
> or if conversion is difficult. So it may not help much as a
> proposal. But I really think that comments should leave alone the
> generated text, and not to escape EOLs. I don't want to end up with
> an unusable macro template after I took it and added my own
> comments. What's your opinion?
per (current) definiton:
#* *# encloses whatever contents it has (including EOL)
## after anything will gobble up to and including the EOL
I just want them to gobble leading whitespaces if they are indented
and alone in one line.
So, with my proposal:
Adding#* *#comments on any line will not change the output (please note
that spaces before and after the #*...*# will apear in the output
in the current implementation, with my proposal these will dissapear
if the comment is standalone).
If you add your comments each on its own line you will not
change the output. Current implentation does change if you comments
are indented.
If you append ##... comments to a line you will change the output
(gobbles the EOL), as it does already in the current implementation.
>
> -- Denis.
:) Christoph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of (Whitespace handling)
Posted by Denis <ji...@respublica.fr>.
Hi Christoph
>> Any chance on this in 1.3?
>> Otherwise please make this into 1.4.
>>
>> The simple and straightforward proposal is to have stand alone
>> directives transparent to the output. #parse, #include and #macro
>> could be an exception on this, since they insert code at the
>> specified location (if it is indented, the code it genereates
>> should be indented - maybe it should event prefix each line it
>> generates with its own indentation);
Don't like it. We should be able to use indentation for logic
structuring as well as for indented output.
>> a flag in the implementing
>> class could define if it gobbles whitespaces around it or not.
Didn't think about that. Seems worth investigating...
>>
>> If you place multple directives on one line or mix directives,
>> references and schmoo in a line it should leave whitespaces
>> around it untouched.
And what if you want to indent the whole mixed line in the code but
not in the output? #* *#?
I read the proposal you offered back in May.
One thing that strikes me in it, as well as in current
implementation of Velocity parser (CVS), is that comments #**# are
used to 'escape' a EOL. IMHO adding a comment shouldn't alter in
any way the processed output. I put this axiom as point 1 of my own
proposal.
If we want the ability to escape space gobbling, why not to use a
new token? I thought of ### or #_
I would also like this token to do the opposite, i.e. escape space
rendering (and start gobbling). (we could use a pair of tokens for
this, e.g. #+ and #-)
And to finish, I would like to gobble space after #directives,
except #end. I would also like to gobble space before #else,
#elseif and #end. Some arrangements could be made, such as
rendering spaces inside one line with mixed commands and text. Or
putting a special flag on a class to tell if space is gobbled
around it or not.
Simple example:
---
#if(...)
## a comment
#set(...)
schmoo
#else
#foo(...)
bark
#end
---
The leading spaces before #if are rendered, as well as the EOL
after #end. The output is either:
---
schmoo
---
or
---
bark
---
Macro example:
---
#macro( csv $list )
#set( $sep = "" )
#foreach( $item in $list )
$sep$item###
#set( $sep = ", " )
#end
#end
#csv([1, 2, 3])
---
The space after $sep$item has to be escaped, because of the #set
directive following it. All other spaces are gobbled. It will
render as:
---1, 2, 3---
Example of rendering whitespaces:
---
#foreach( $a in $vector )
###
$a
###
#end
---
This time we want each element on its own line. So we escape space
gobbling after #foreach and before #end. There is an extra EOL
after #end. The output is like:
---
a car
a plane
1,000 balloons
---
HTML table example:
---
schmoo
#if($!foo)
<table>
#for ($key in $foo)
<tr> ... display ...</tr>
#end
</table>
#end
---
The space is gobbled after #if and #for, but it is gobbled before
#end. So the output is correctly indented:
---
schmoo
<table>
<tr> ... display ...</tr>
<tr> ... display ...</tr>
<tr> ... display ...</tr>
<tr> ... display ...</tr>
</table>
---
I am not very aware of the compatibility problems with this scheme,
or if conversion is difficult. So it may not help much as a
proposal. But I really think that comments should leave alone the
generated text, and not to escape EOLs. I don't want to end up with
an unusable macro template after I took it and added my own
comments. What's your opinion?
-- Denis.
>>
>> This would make pretty templates generate pretty output.
>>
>> Thanks for any time considering this and making it reality.
>> I could send a set of examples of what I mean and state the
>> issues that would affect any backward compatibility.
>> I could try the patch for this myself if you want.
>
> Actally, we are never going to do it. We just like to see you
> raise this
> issue every 3 months or so :)
>
> Seriously, the backwards compatibility is indeed worrysome...
> What is the
> biggest breakage that you can see?
>
> geir
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/10/01 3:52 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> I would love to see the whitespace handling issue cleared up in 1.3.
I'd actually like to start the 1.3 release cycle real-soon, as there are
things that people are using now, and we might as well get it locked down
for them.
I will get this done by 12/31 and get started asap unless someone howls. I
have some docs I want to do, but then I think all is well.
It means we all have to use It for this rapid a release cycle.
Anyone that I using the pluggable resource manager and/or cache, or the
application context, give a yell. It would be not fun to bake into a
release features that don¹t work right, or don't address the original
problem.
>
> Any chance on this in 1.3?
> Otherwise please make this into 1.4.
>
> The simple and straightforward proposal is to have stand alone
> directives transparent to the output. #parse, #include and #macro
> could be an exception on this, since they insert code at the
> specified location (if it is indented, the code it genereates
> should be indented - maybe it should event prefix each line it
> generates with its own indentation); a flag in the implementing
> class could define if it gobbles whitespaces around it or not.
>
> If you place multple directives on one line or mix directives,
> references and schmoo in a line it should leave whitespaces
> around it untouched.
>
> This would make pretty templates generate pretty output.
>
> Thanks for any time considering this and making it reality.
> I could send a set of examples of what I mean and state the
> issues that would affect any backward compatibility.
> I could try the patch for this myself if you want.
Actally, we are never going to do it. We just like to see you raise this
issue every 3 months or so :)
Seriously, the backwards compatibility is indeed worrysome... What is the
biggest breakage that you can see?
geir
> :) Christoph
>
>
> "Geir Magnusson Jr." wrote:
>>
>> On 12/6/01 11:17 PM, "James Maes" <jm...@sportingnews.com> wrote:
>>
>>>
>>> Geir,
>>> We are thinking about going ahead with the 1.3 branch for the upcoming beta
>>> rollout. Are there any other changes besides the plugable ResourceManager
>>> that I should watch out for?
>>>
>>
>> There are lots of little things that were fixed and changed. Tiny parser and
>> parser-support tweaks, logging changes (to auto-find log4j), some other
>> stuff. The pluggable resource/cache stuff is just the same code with the
>> options of plugging your own in, so that's no biggie.
>>
>> The only thing that was 'serious' were some fixes to the introspector. They
>> were tested pretty hard by cynics before they were added, and were resolving
>> a rare issue. I think it's ok.
>>
>> So no, not really anything to watch out for. Hang on to the existing
>> snapshot you have in the event we have to fix something in a controlled way
>> for you.
>>
>> 1.2 will roll this weekend, and then after a few more little things, we can
>> move right into a 1.3 release schedule to get all these goodies out there...
>>
>> geir
>
> --
> 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
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of
Posted by Christoph Reck <Ch...@dlr.de>.
I would love to see the whitespace handling issue cleared up in 1.3.
Any chance on this in 1.3?
Otherwise please make this into 1.4.
The simple and straightforward proposal is to have stand alone
directives transparent to the output. #parse, #include and #macro
could be an exception on this, since they insert code at the
specified location (if it is indented, the code it genereates
should be indented - maybe it should event prefix each line it
generates with its own indentation); a flag in the implementing
class could define if it gobbles whitespaces around it or not.
If you place multple directives on one line or mix directives,
references and schmoo in a line it should leave whitespaces
around it untouched.
This would make pretty templates generate pretty output.
Thanks for any time considering this and making it reality.
I could send a set of examples of what I mean and state the
issues that would affect any backward compatibility.
I could try the patch for this myself if you want.
:) Christoph
"Geir Magnusson Jr." wrote:
>
> On 12/6/01 11:17 PM, "James Maes" <jm...@sportingnews.com> wrote:
>
> >
> > Geir,
> > We are thinking about going ahead with the 1.3 branch for the upcoming beta
> > rollout. Are there any other changes besides the plugable ResourceManager
> > that I should watch out for?
> >
>
> There are lots of little things that were fixed and changed. Tiny parser and
> parser-support tweaks, logging changes (to auto-find log4j), some other
> stuff. The pluggable resource/cache stuff is just the same code with the
> options of plugging your own in, so that's no biggie.
>
> The only thing that was 'serious' were some fixes to the introspector. They
> were tested pretty hard by cynics before they were added, and were resolving
> a rare issue. I think it's ok.
>
> So no, not really anything to watch out for. Hang on to the existing
> snapshot you have in the event we have to fix something in a controlled way
> for you.
>
> 1.2 will roll this weekend, and then after a few more little things, we can
> move right into a 1.3 release schedule to get all these goodies out there...
>
> geir
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 1.3, status of
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/6/01 11:17 PM, "James Maes" <jm...@sportingnews.com> wrote:
>
> Geir,
> We are thinking about going ahead with the 1.3 branch for the upcoming beta
> rollout. Are there any other changes besides the plugable ResourceManager
> that I should watch out for?
>
There are lots of little things that were fixed and changed. Tiny parser and
parser-support tweaks, logging changes (to auto-find log4j), some other
stuff. The pluggable resource/cache stuff is just the same code with the
options of plugging your own in, so that's no biggie.
The only thing that was 'serious' were some fixes to the introspector. They
were tested pretty hard by cynics before they were added, and were resolving
a rare issue. I think it's ok.
So no, not really anything to watch out for. Hang on to the existing
snapshot you have in the event we have to fix something in a controlled way
for you.
1.2 will roll this weekend, and then after a few more little things, we can
move right into a 1.3 release schedule to get all these goodies out there...
geir
--
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>