Leszek Gawron wrote:
Daniel Fagerstrom wrote:
The functionality seem useful, but I don't think that it should be
implemented as an attribute. An attribute template language would be
cool, but, for JXTG, I think that all instructions should be
elements. Mixing element and attribute instructions makes the
template language confusing IMO.
we already have <root jx:cache-key=""/>
Didn't exactly like it there either ;)
Thing is jx:strip-whitespace is not really an instruction. It's more
like a processing directive. With <jx:strip-whitespace/> being a tag
the syntax is awful:
<xyz jx:strip-whitespace="true">
${abc.name}
<nested-tag jx:strip-whitespace="false"> ${abc.description}
</nested-tag>
</xyz>
vs.
<xyz>
<jx:strip-whitespace>
${abc.name}
<nested-tag><jx:preserve-whitespace> ${abc.description}
</jx:preserve-whitespace></nested-tag>
</jx:strip-whitespace>
</xyz>
Might be that it is awful, but that goes for the rest of JXTG as well
(or any XML language), it is still not a reason to complicate life for
users by mixing attribute and element syntax. Furthermore, I doubt that
what you do above is a common use case.
Recursive space stripping is also very useful when do you not generate
html output but use jxtg to generate views for a self made client (not
web browser).
From architectural stand point I would prefer letting the strip
whitespace element just work on its immediate children. Striping
whitespace recursively means that we need to make the Template
architecture more complicated and less reusable, I'm not convinced
that it would be worthwhile.
The architectural issues are to be discussed further but I do not
think that this functionality will impact jxtg core much.
We did a huge and not always fun work in refactoring JXTG so that it
should be understandable and maintainable for the rest of the community,
we should be really careful so that we not destroy this by adding
features that makes it more complicated.
There are lots of comments from users (mainly using jx-macros for
cforms) that whitespace is problematic. So I think it's worthwhile.
Maybe the whitespace handling for macros need an overlook then, what
exactly is the whitespace problem with jx-macros?
/Daniel
