RE: Strange ouput with pretty print on
Jacob Kjome <[email protected]> Fri, 28 Nov 2003 17:12:52 -0600
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
At 10:42 AM 11/28/2003 -0500, you wrote: > > >For development I use pretty printed output in the > > DefaultDOMWriter (will > > >it be renamed to XMLCDOMWriter as Jake stated in the Barracuda Mailing > > >list on 19-11-2003?). > > > > Probably not. I wanted to do this a while ago, but it wasn't approved by > > all committers. Too many people directly reference it as well to change > > the name now. Unless we have an outcry for it to be renamed, it probably > > won't be. Just know that the DefaultDOMWriter really provides XMLC-based > > dom writing (and JTidy pretty printing, currently). Other DOMWriter > > implementations should be named for the library they back such as the > > JivanDOMWriter that Arno Schatz wrote (which isn't in CVS yet). Anyway, > > enough about that. This isn't the Barracuda list, after all. > >As a suggestion, maybe we should rename to XMLCDOMWriter, and then create a >DefaultDONWriter that just extends from this. This would clear up the naming >issues, while still providing backwards compatibility for existing code. > >Thoughts? > >Christian Maybe, although I'm not sure it would make things any more clear. People might then ask "Why is there an 'XMLCDOMWriter' and a 'DefaultDOMWriter' that both do the same thing"? Hmmm... I'll have to mull that over a bit. We could always ask the Barracuda users what they think. Anyway, any more conversation on this should take place on the BarracudaMVC list (which seems down at the moment, BTW). Jake >---------------------------------------------- >Christian Cryder >Internet Architect, ATMReports.com >Project Chair, BarracudaMVC - http://barracudamvc.org >---------------------------------------------- >"Coffee? I could quit anytime, just not today" > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On Behalf Of > > Jacob Kjome > > Sent: Friday, November 28, 2003 8:35 AM > > To: [email protected] > > Subject: Re: Xmlc: Strange ouput with pretty print on > > > > > > Hi Mark, > > > > At 10:56 AM 11/28/2003 +0100, you wrote: > > >Hello, > > > > > >For development I use pretty printed output in the > > DefaultDOMWriter (will > > >it be renamed to XMLCDOMWriter as Jake stated in the Barracuda Mailing > > >list on 19-11-2003?). > > > > Probably not. I wanted to do this a while ago, but it wasn't approved by > > all committers. Too many people directly reference it as well to change > > the name now. Unless we have an outcry for it to be renamed, it probably > > won't be. Just know that the DefaultDOMWriter really provides XMLC-based > > dom writing (and JTidy pretty printing, currently). Other DOMWriter > > implementations should be named for the library they back such as the > > JivanDOMWriter that Arno Schatz wrote (which isn't in CVS yet). Anyway, > > enough about that. This isn't the Barracuda list, after all. > > > > >But the output gets wrong in case of a text area with default value: > > >If my mockup contains: > > > > > ><textarea>Default value</textarea> > > > > > >it got outputed as: > > > > > ><textarea> > > > Default value > > ></textarea> > > > > > >Nice for html source readability, but it definitely changes something in > > >the browser, as I now have a lot of spaces before the "Default > > value" text > > >inside the text area. Could this be considered a bug, as pretty printing > > >should in my opnion not change the user visible output? (Guess the same > > >applies with </td> on the next line, but haven't tested it. > > > > It is possible that <textarea> (and <pre>?) should be treated as > > a special > > case in pretty printing. However, since Barracuda uses JTidy to > > implement > > pretty printing, the bug (?) is in JTidy, not XMLC or Barracuda. Of > > course, I don't think XMLC's pretty printing output would be any > > different > > anyway since it doesn't treat any tags as special cases, but > > you'd have to > > test it out. To do that, just set the pretty printing OutputOptions > > (DefaultDOMWriter takes an OutputOptions object in its constructor) and > > turn off pretty printing in DefaultDOMWriter. > > > > That said, pretty printing is strictly for source readability and > > shouldn't > > be used in production as it will decrease performance and will > > fetter out a > > few unexpected bugs like this. You might do well to asking on > > the Mozilla > > lists as to what proper browser behavior is. Should <textarea> be paying > > attention to white space like this? That is problematic since it forces > > the developer to pay attention to the HTML code structure which, > > normally, > > shouldn't be an issue. I suppose it is for elements treating white space > > as "pre" (is CSS terms). If you can report back as to your findings, it > > would be helpful. > > > > Jake > > > > _______________________________________________ > > XMLC mailing list > > [email protected] > > http://www.enhydra.org/mailman/listinfo.cgi/xmlc > >_______________________________________________ >XMLC mailing list >[email protected] >http://www.enhydra.org/mailman/listinfo.cgi/xmlc