+1, sounds like a sensible approach On Sat, Apr 23, 2011 at 7:35 PM, Juergen Donnerstag <[email protected]> wrote: > I had another look at Page.configureResponse(). I agree that the > current behavior is a bit strange. > > If the page markup contains the xml prolog, than a xml prolog is > written to the response, with the encoding provided by > application.getRequestCycleSettings().getResponseRequestEncoding(). > If page markup contain no xml prolog, than no xml prolog is written > into the response. > > I think we should remove get/setStripXmlDeclarationFromOutput() and > replace it with is/setInsertXmlProlog. An no matter whether the page > markup contains a prolog or not, only if the application setting is > true, a prolog is written or not. If RCS encoding is null, the prolog > will still be written, but without encoding attribute. > > - it more clearly separates markup reading from response writing > - allow to enable/disable xml prolog for all pages of the application, > irrespective whether the markup has the prolog > - the response prolog can no longer be controlled via the page markup. > E.g. all pages with style or variation "IE" containing IE specific > markup, have slightly different markup (don't know if anybody is using > it like that). We could still allow that by introducing > WebApplication.isInsertXmlProlog with Page parameter, which can be > overriden by user on demand. By default it return > markupSettings.isInsert... > > Any thoughts? > > -Juergen > > On Fri, Apr 22, 2011 at 11:12 AM, Martin Grigorov <[email protected]> > wrote: >> Hi Juergen, >> >> Thanks for the explanation. It is more clear now. >> I meant using IResponseFilter to add the XML prolog if the user >> application really wants to. >> Now Page#configureResponse() sets it only for the pages which have it >> in their markup. If a MyPage.html don't have it and all panels used in >> that page use non-ascii characters and have the prolog then it is not >> set in the produced final page markup. >> >> I'm not saying we need to change it. If I want the prolog then I'd use >> my own IResponseFilter to add it to all pages - mine and re-used from >> libraries (like Wicket internals). >> >> The problem reported by Petr is fixed in 1.5. All pages have the prolog. >> >> On Fri, Apr 22, 2011 at 10:10 AM, Juergen Donnerstag >> <[email protected]> wrote: >>> the setting/exception is to make sure that all markup files have >>> proper encoding. Think about moving markup files from your local latop >>> onto a production server. Who guarantees that in your markup are only >>> ascii chars? Who guarantees the prod server has the same default >>> encoding than your devs laptops (and your dev might be working >>> somewhere on the globe). And though the response needs to be browser >>> aware, because especially historically every browser version behaved >>> different depending on the presence of the xml prolog in response, it >>> doesn't (and shouldn't) matter for Wicket's markup. Use whatever web >>> editor you want, with whatever encoding you want, just make sure the >>> xml prolog is present. >>> >>> Wicket always removes the xml prolog from the markup upon reading, >>> only the encoding (of Pages) get remembered and used as default for >>> configuring the Page response. It is Page.configureResponse which >>> writes a new xml prolog to the response. You can omit that by simply >>> setting getMarkupSettings().setStripXmlDeclarationFromOutput(false). >>> No need for response filter or whatever. >>> >>> IMO every Wicket markup, especially of what we deliver, should have >>> the xml prolog. >>> >>> -Juergen >>> >>> On Thu, Apr 21, 2011 at 9:04 PM, Martin Grigorov <[email protected]> >>> wrote: >>>> I don't know the history of this recommendation. The log message says >>>> "The markup file does not have a XML declaration prolog: " + >>>> markupResourceData.getResource() + ". It is more save to use it." >>>> >>>> I'm not sure how it is more safe this way (if we keep this message we >>>> need to fix the typo at least :-) ) >>>> I'd vote to remove this prolog all together. If the user app needs it >>>> then it is quite easy to use IResponseFilter to add it for each and >>>> every page. >>>> >>>> >>>> On Thu, Apr 21, 2011 at 7:51 PM, Pedro Santos <[email protected]> wrote: >>>>> >>>>> He Petr, by add the prolog in the html files those pages are not correctly >>>>> rendered in IE8, IMO opinion the best option we have now is to move the >>>>> Apache header in those files to inside the html tag plus restore the >>>>> prolog >>>>> [1]. >>>>> >>>>> Devs, I don't know if we can freely move the Apache header to outside the >>>>> top of our files. Also reading the header politic site [2], I don't get if >>>>> we can simple remove it. Does the exception page fits the "without any >>>>> degree of creativity" requirement since it has no programming code? It is >>>>> just static markup... >>>>> >>>>> 1 - https://issues.apache.org/jira/browse/WICKET-3566 >>>>> 2 - http://www.apache.org/legal/src-headers.html >>>>> >>>>> <https://issues.apache.org/jira/browse/WICKET-3566> >>>>> On Thu, Apr 21, 2011 at 2:26 AM, Petr Gladkikh <[email protected]> wrote: >>>>> >>>>> > I am trying to upgrage from wicket 1.4.1 to 1.4.17 and have following >>>>> > problem. >>>>> > In our application we configure >>>>> > getMarkupSettings().setThrowExceptionOnMissingXmlDeclaration(true); >>>>> > >>>>> > This prevents all Wicket's default pages from rendering since none of >>>>> > them contain XML prolog anymore. E.g. none of HTML files in >>>>> > >>>>> > apache-wicket-1.4.17/src/wicket/src/main/java/org/apache/wicket/markup/html/pages >>>>> > contain XML declaration prolog. When wicket tries to show error page >>>>> > exception is thrown. Top of stack trace is: >>>>> > at org.apache.wicket.markup.MarkupParser.parse(MarkupParser.java:280) >>>>> > at >>>>> > org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:52) >>>>> > at >>>>> > org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:62) >>>>> > at >>>>> > org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:55) >>>>> > at org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:465) >>>>> > at >>>>> > org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:561) >>>>> > at org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:325) >>>>> > at >>>>> > org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java:216) >>>>> > at >>>>> > org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContainer.java:351) >>>>> > at org.apache.wicket.Page.onRender(Page.java:1587) >>>>> > at org.apache.wicket.Component.render(Component.java:2521) >>>>> > at org.apache.wicket.Page.renderPage(Page.java:932) >>>>> > >>>>> > I can work around by switching these exceptions off. But I think that >>>>> > the problem should be fixed otherwise since even when these exceptions >>>>> > are switched off following message is written to log: >>>>> > log.debug("The markup file does not have a XML declaration prolog: " + >>>>> > markupResourceData.getResource() + ". It is more save to use it. E.g. >>>>> > <?xml version=\"1.0\" encoding=\"UTF-8\" ?>"); >>>>> > >>>>> > -- >>>>> > Petr Gladkikh >>>>> > >>>>> > --------------------------------------------------------------------- >>>>> > To unsubscribe, e-mail: [email protected] >>>>> > For additional commands, e-mail: [email protected] >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> Pedro Henrique Oliveira dos Santos >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>>> >>> >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> >
-- Become a Wicket expert, learn from the best: http://wicketinaction.com
