Daniel Fagerstrom wrote:
Jason Johnston skrev:
Daniel Fagerstrom wrote:
...
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?
http://issues.apache.org/jira/browse/COCOON-1381
I'm aware of that bug, I was asking for more details, which maybe wasn't
that clear. Where does the unwanted whitespace show up, and why is that
happen?
Sorry, didn't realize what you were asking. :-) Here's a simple example:
Definition:
<fd:output id="theOutput">...</fd:output>
(assume that this widget has the value "myValue")
Template:
<pre>The value of theOutput is <ft:widget id="theOutput" /></pre>
Right now you end up with something akin to:
<pre>The value of theOutput is
myValue
</pre>
The cause of this is that in the JX macro for ft:widget there is
whitespace between each of the jx:parameter, jx:if, jx:set etc.
elements, all of which gets written to the output. It seems there is no
way to strip this unwanted whitespace, besides removing all of it from
the JX macro, which would of course make it entirely unreadable.
HTH
Anyway, IIRC, the jx:import basically includes the whole document with
macro definitions, whitespace between macros, and XML elements, that are
between the macro definitions. While such a construction certainly can
be useful, it is not the most natural for importing macros, and it would
have been better to name it jx:include.
What we need IMO, is a "jx:importMacros" instruction that just imports
the macros in a macro definition file, without doing any document
inclusion. That would solve the macro problem in a clean way.
I think you're talking here about whitespace *between* the macro
definitions, whereas the problem really lies with whitespace *within*
the macro definitions. The former may also be an issue that deserves
attention but I think not as critical as the latter.
Now, we still might want a skip whitespace instruction. But we shouldn't
introduce it as a workaround for fixing problems macros, better fix the
macros directly.
/Daniel