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). > > 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... I forgot: no, I didn't test the full stack Doxia + maven-site-plugin I just found in Doxia unit tests the cause of the problem
> > 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
