RE: [PROPOSAL] Whitespace handling

[Christoph Reck <Ch...@dlr.de>]

See the original "[PROPOSAL] Whitespace handling" in:
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg01310.html

"Geir Magnusson Jr." wrote in thread "Re: 1.3, status of":
> 
> On 12/10/01 3:52 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
>[snip]
> >
> > 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 :)

I'm patient :> and just waiting for improvements.

I plead others that are annoyed about the current whitespace handling
please speak up!

> 
> Seriously, the backwards compatibility is indeed worrysome...  What is the
> biggest breakage that you can see?
> 
> geir

The *only* breakage is that *less* stray whitespaces would be in
the output. This means that most of the testcase comparision data
will need to be cleaned up.

IMHO *very* few cases it will create problems on some output
that relied that a LF was gobbled, e.g. in the new world
  #if( $foo )  Hello World!#end
would emit the LF at the end. 
  #if( $foo )
    Hello World!
  #end
would print exactly the same (currently it leaves the two extra 
spaces before the #if statement).

I'm also concient that by doing changes in the parser it may break
something else. So we need to manually update the testcases comparision
files and check one-by-one any errors reported. I'm willing to do this!

In old and new world the following will continue being a problem:
  <javascript>
    // ## won't output anything at all
    alert("Will not show after velocity processing");
  </javascript>
The writer should have used an #*embedded comment*# to avoid this 
problem.

:) Christoph

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL] Whitespace handling

["Geir Magnusson Jr." <ge...@optonline.net>]

On 12/10/01 7:54 AM, "Christoph Reck" <Ch...@dlr.de> wrote:

> See the original "[PROPOSAL] Whitespace handling" in:
> http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg01310.html
> 
> "Geir Magnusson Jr." wrote in thread "Re: 1.3, status of":
>> 
>> On 12/10/01 3:52 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
>> [snip]
>>
>> Actally, we are never going to do it.  We just like to see you raise this
>> issue every 3 months or so :)
> 
> I'm patient :> and just waiting for improvements.
> 
> I plead others that are annoyed about the current whitespace handling
> please speak up!
> 
>> 
>> Seriously, the backwards compatibility is indeed worrysome...  What is the
>> biggest breakage that you can see?
>> 
>> geir
> 
> The *only* breakage is that *less* stray whitespaces would be in
> the output. This means that most of the testcase comparision data
> will need to be cleaned up.
> 
> IMHO *very* few cases it will create problems on some output
> that relied that a LF was gobbled, e.g. in the new world
> #if( $foo )  Hello World!#end
> would emit the LF at the end.
> #if( $foo )
>   Hello World!
> #end
> would print exactly the same (currently it leaves the two extra
> spaces before the #if statement).
> 
> I'm also concient that by doing changes in the parser it may break
> something else. So we need to manually update the testcases comparision
> files and check one-by-one any errors reported. I'm willing to do this!

If there really is demand for this, I am happy to do it - and would go
through the testbed as I did it - its going to be somewhat iterative.

However, I want to make sure that we aren't screwing some other, currently
non-vocal part of the user community by adding more magic behavior.

I have always thought of this as ( pretty templates | pretty output ).

I remember cooking up a few counter-examples. I'll see if I can find them.
 
> In old and new world the following will continue being a problem:
> <javascript>
>   // ## won't output anything at all
>   alert("Will not show after velocity processing");
> </javascript>
> The writer should have used an #*embedded comment*# to avoid this
> problem.
> 

Yep.  We can't tell you where to point the gun... :)

-- 
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>