On Fri, Mar 5, 2010 at 04:42, Sergiu Dumitriu <[email protected]> wrote: > On 03/04/2010 03:01 PM, Thomas Mortagne wrote: >> On Thu, Mar 4, 2010 at 13:56, Sergiu Dumitriu<[email protected]> wrote: >>> On 03/04/2010 10:54 AM, Thomas Mortagne wrote: >>>> On Wed, Mar 3, 2010 at 13:48, sdumitriu >>>> <[email protected]> wrote: >>>>> Author: sdumitriu >>>>> Date: 2010-03-03 13:48:22 +0100 (Wed, 03 Mar 2010) >>>>> New Revision: 27429 >>>>> >>>>> Modified: >>>>> >>>>> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java >>>>> Log: >>>>> XWIKI-4955: Page with empty content leads to "This template does not >>>>> exist" message when viewed in plain mode >>>>> Revert the trim() removal, which makes all the validation tests fail >>>> >>>> Then the wrong template should be fixed instead of putting a hack... >>> >>> It is not a hack, and there is not one wrong template. All the templates >> >> There is 16 wrong templates plus macro template itself is wrong and >> for most of them it's just one line that needs ##. >> >>> generate whitespaces. I still believe that there is absolutely no reason >> >> A template don't have to generate white spaces and the issue are not >> all templates that generated whites spaces, we just need to fix >> templates that generate white space before the actual xhtml content >> (i.e. before "<?xml..." in htmlheader.vm), >> >>> not to use the trim(), since nobody cares if the whitespace reaches the >> >> The problem is that you only think about full xhtml content, in that >> case yes we don't care about triming that content but that's not our >> only use case. You could write templates that return some content you >> want to get exactly like it was. An example: you need to write a >> service in a document to return the exact content of an object or the >> content of the document, with this you will be forced to inject >> directly your content in the response object and use >> $context.setFinished(true) which is a pain. > > Sending plain content is not the only option. You can (and should) put > it in a wrapper, either XML or JSON.
I call that a workaround for a limitation. My only point is that i can't find one good reason to trim content all the time and you did not gave any (sending several bytes less is not...). IMO we do something when it's needed not because "it's ok to do that nobody cares". > >> It's a hack because at Utils level we have no idea what is the >> content, safest is to let user decide how he want to use the content >> he produced, you can say you don't care as much as you want i still >> don't see how we could decide that noone is allowed to take white >> space as meaningful content... >> >> If the goal is to protect against UI templates badly written we should >> limit this trim() only to xhtml or html MIME types. > > And RDF, and SOAP, and all the other XML types. And CSV. It's irrelevant > for JSON. PDF/RTF/XAR/ZIP are unaffected, since they don't use the > parseTemplate logic. The only one that is affected is text/plain. I said "protect against UI templates" i know there is other content that don't care about white spaces but i expected theses ones to be coded properly... > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
