+1 On Sun, Apr 24, 2011 at 2:20 PM, Martijn Dashorst <[email protected]> wrote: > +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 >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
