On Sun, 2002-12-08 at 04:21, Daniel Dekany wrote:
> Saturday, December 7, 2002, 10:34:51 PM, Jonathan Revusky wrote:
>
> > On Sat, 2002-12-07 at 00:29, Daniel Dekany wrote:
> [snip]
> >> And, unfortunately, we can't escape the common problem: is it
> >> transform visual or not?
> >
> >
> > Well, a transform has content, so there is no inherent ambiguity here.
> > It is treated symmetrically with <if..> and so on.
> >
> > <transform...>
> > blah blah
> > </transform>
> >
> > has the opening and ending tags on lines by themselves, and the current
> > algorithm considers the opening spaces and trailing newlines there to be
> > strippable.
> >
> > A way of looking at this is that the transform start and end tags do
> > not, in and of themselves produce output, so if they appear on their own
> > line (for formatting reasons) the initial spaces and trailing newlines
> > are not considered to be meaningful wrt output. (So, in the above case,
> > the four spaces prior to </transform> will not be passed through to the
> > transform.)
>
> Right... and now read the paragraph quoted bellow again and answer
> again... (don't copy-paste your answer from the pervious mail :))
>
> >> Consider macro-transform unification... and
> >> JSP taglib transforms, and then common transforms like compress.
> >> Transform is too flexible, so the parser can't say if it should gobble
> >> WS or not.
The parser itself does not actually gobble whitespace. It builds a tree
with all the whitespace and then there is a post-parse cleanup stage
where it walks the tree and makes certain adjustments.
As things stand, there is not much problem, since it's a recursive
algorithm that looks for terminal nodes. In the case of transform and
compress, it simply recurses into the nested nodes to figure out whether
to gobble whitespace or not. You can see the algorithm in
TextBlock.java, in the postParseCleanup() method.
If something is a terminal node, like an interpolation or an include or
macro directive -- i.e. contains no nested elements -- then the
heuristic judges whether to gobble whitespace or not.
<assign foo = "bar">
In the above, the opening whitespace is stripped because the assignment
is not a visual directive.
In this case:
${foo}
the opening whitespace is assumed to be relevant, since ${foo} does
produce output.
In the case of a directive with nested content, it recurses into the
nested content to figure out what to do. In:
<transform foo> blah blah blah </transform>
the opening whitespace is assumed to be relevant, since the nested
content in transform contains a terminal text node that occurs on the
same line. OTOH, in
<transform foo>
blah blah blah</transform>
the opening whitespace (and trailing newline) on the first line is
assumed to be ignorable, since the nested element, blah blah blah
contains no output (modulo whitespace) on the line in question.
Anyway, you can examine in the algorithm in TextBlock.java. It's pretty
distilled down now, but there is actually a *lot* of work in this. I
think it produces principle-of-least-surprise results pretty reliably..
> This problem becomes serious because of the macro-transform
> >> unification, since then you can't even tell on parsetime if you call a
> >> macro or a transform, and thus the policy for macros and transforms
> >> must be the same.
Well, it's just a question of 2 issues:
1. If something is a terminal node, you gobble or not based on whether
the terminal node contains output text on that line.
2. If something is not a terminal node, i.e. contains nested elements,
you recurse into the nested elements and apply point 1. above.
>I guess the least bad solution is to handle both as
> >> visual directives, so they don't gobble white-space. Thus, non-visual
> >> transfroms sadly will not gobble... well, this is just the pre-FM 2.2
> >> situation, and, "if", "foreach", "local", "global" and such common
> >> directives still gobble white-space, and it is a big win. After all,
> >> the above 4 directive causes almost all superfluous whitespace.
> [snip]
There may be some future refinements in store, but I have the basic
feeling that I've nailed this problem basically. :-)
Cheers,
Jonathan
>
> --
> Best regards,
> Daniel Dekany
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> FreeMarker-devel mailing list
> FreeMarker-devel@...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>
|