maven-doxia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: svn commit: r598803 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/sink/ doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/ doxia-modules/doxia-module-fo/src/main/java/org/apac...
Date Thu, 29 Nov 2007 18:11:21 GMT
Le jeudi 29 novembre 2007, Lukas Theussl a écrit :
> 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).
Latex tests failed. The reason was that there was text with spaces in it 
("Numbered list", "Item list", ...), and when the LineBreaker broke a long 
line on this space, removing the EOL led to "Numberedlist".

> 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.
why not. I didn't mean to change everything, just the simplest way to get 
things working. I think both approaches are right: between 
writeEndTagWithoutEOL() and writeEndTag(), every Sink chooses which method is 
right for on each call.

> If tests fail after that then it's probaby the tests that need to be
> adapted...
Yes, with LineBreaker in place, the test strategy is not perfect: it fails 
when tests need a long line with significant spaces.
But in the current case, current strategy was perfectly sufficient for 
functionnal needs IMHO



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

View raw message