Hi,
We had a discussion about EOLs some time ago, I would like to know which
tests failed for you. The AbstractSinkTest (which all sink tests are
supposed to extend) filters out every EOL in the strings it compares (my
reasoning for that was that the case where EOLs are significant is
usually a special case and should be tested separately).
Apart from that, IMO AbstractXmlSink is an abstract base class that
shouldn't be concerned with formatting (btw, I just noticed that
writeStartTag also appends an EOL after simple tags, that should be
removed as well). The writeEndTagWithoutEOL() method is simply not
needed because implementing sinks should write the EOLs where they need
them. In the current case, it should be enough to move the EOLs into the
XhtmlBaseSink.
If tests fail after that then it's probaby the tests that need to be
adapted...
Cheers,
-Lukas
PS Are you saying you are using site-plugin beta-6 with doxia beta-1? I
haven't been able to make the two work together yet...
Hervé BOUTEMY wrote:
Le mercredi 28 novembre 2007, Lukas Theussl a écrit :
Herve,
Thanks for fixing this! Just two questions:
Why do we need a separate method in AbstractXmlSink, can't we just
remove the EOL from writeEndTag()?
I tried to do so in the first place: that's exactly what I wrote when mailing
to maven-dev.
But when doing so, I discovered 2 drawbacks:
- the whole generated HTML document was without any EOL, which is quite hard
to read. But no major problem here, I just thought that people who had
written these newlines prefer readable HTML, and wouldn't be happy if I
changed their "way of code" :)
- unit test were failing, since some sinks use LineBreaker class which adds a
newline when larger than 78 chars: the whole unit tests logic had to be
reworked...
Then I discovered where really these newlines were a problem, and where they
were not: see next paragraph...
And what's the reason for selecting only special tags to write no
newline? Just because they are inline elements? This doesn't solve the
issue of EOLs within <pre> tags, right?
Yes, because they're inline elements: HTML <a>, <i>, <b> and <code>. Within
<pre> tag, you don't use other tags, which are structural tags: you only use
inline elements for styling and links/anchors.
FYI, here is a page on which I discovered the problem when using 2.0-beta6
http://logdistiller.sourceforge.net/quickstart-4.html
Feel free to check and comment this logic, because I think it is good but I'm
not 100% sure I didn't miss a special case...
regards
Hervé
Cheers,
-Lukas
