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
