quick question. your test,jspx start like this:
<?xml version="1.0" encoding="UTF-8" ?> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"; version="2.0" xmlns:f="http://java.sun.com/jsf/core"; xmlns:h="http://java.sun.com/jsf/html"; xmlns:tr="http://myfaces.apache.org/trinidad";> <jsp:text><![CDATA[<?xml version="1.0" encoding="UTF-8" ?>]]></jsp:text> isn't that already one PI too much ? -M On Fri, Jul 4, 2008 at 5:39 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke > <[EMAIL PROTECTED]> wrote: >> I found the following solution in the dev.mailing list: >> >> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200709.mbox/[EMAIL >> PROTECTED] >> >> when I remove the >> >> <jsp:text><![CDATA[<?xml version="1.0" encoding="UTF-8" ?>]]></jsp:text> >> >> at my jsp the PPR response does contain only one XML-PI and no parse error >> occure. > > yes, that workaround I found as well. > But, looks not like a desired step. > >> >> It seems that the jsp servlet pushes its <jsp:text>-content (in this case >> the XML-PI) into the response before the PPR engine filters the rendered >> page. >> to give it a chance I put the <jsp:text> element into the <f:view>. So it is >> rendered at the beginning of the document but is filtered out during PPR. >> >> May be that there is a better way? > > not sure yet. Was busy. Not looked into this in detail, at all > > -Matthias > >> >> >> Am 04.07.2008 um 09:22 schrieb Matthias Wessendorf: >> >>> Hi, >>> >>> On Fri, Jul 4, 2008 at 9:11 AM, Burghard Britzke >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> I catched the response from the server and it contains a double >>>> xml-header >>>> <?xml version="1.0" encoding="UTF-8" ?><?xml version="1.0" ?> >>>> <?Tr-XHR-Response-Type ?> >>>> <content action="/test/faces/test.jspx"> <fragment><![CDATA[<div >>>> id="j_id_id6"><table cellpadding="0"... >>>> ... >>> >>> <?xml version="1.0" ?> >>> <?Tr-XHR-Response-Type ?> >>> >>> this comes from Trinidad directly. >>> >>> the "extra" PI is from your page, I guess. >>> >>>> is there a configuration option to prevent this double header in the ppr >>>> response? >>> >>> not that I am aware of. >>> I need to run some tests on our library. >>> >>>> >>>> Am 03.07.2008 um 20:12 schrieb Matthias Wessendorf: >>>> >>>> On Thu, Jul 3, 2008 at 7:03 PM, Burghard Britzke >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>> first of all, this is NOT the issue I filed with (1139) there are only >>>> >>>> similar symptoms. >>>> >>>> yes, it was bad from me to hijack this email thread >>>> >>>> but there is a significant difference: (1139) does not send a request >>>> while >>>> >>>> on this issue a browser is not capable of parsing the response because it >>>> >>>> has two xml headers. >>>> >>>> is there a way to switch of ppr? >>>> >>>> for table paging? no >>>> >>>> for your statement: it does not depend on wether facelets or jsp. it is a >>>> >>>> pure client side problem. it depends on html or xhtml/xml (imo) >>>> >>>> yes, but faclets sends down xhtml as well. >>>> I noticed that in the XML case, in your demo, document.forms is >>>> undefined. >>>> I haven't had much time to check it deeper (yes, the 1139 issue) >>>> >>>> -M >>>> >>>> Am 03.07.2008 um 11:03 schrieb Matthias Wessendorf: >>>> >>>> I did a quick look at the issue, you filed (1139). >>>> >>>> It is strange that xhtml is causing these kinda problems. >>>> >>>> works fine with facelets. >>>> >>>> give me some time to verify the root issues, instead >>>> >>>> of doing a simple "getElementById". I think there are >>>> >>>> more similar issue to your problem. >>>> >>>> -M >>>> >>>> On Thu, Jul 3, 2008 at 8:33 AM, Burghard Britzke >>>> >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>> with the following environment: >>>> >>>> Mac OS X 10.5.4 >>>> >>>> Sun AS 9.0.2 (Glassfish) >>>> >>>> Java 1.5 >>>> >>>> Safari 3.1.2 and Firefox 3.0 >>>> >>>> <tr:table>'s page navigation does not work as expected for my >>>> >>>> configuration. >>>> >>>> A klick on one of the navigation buttons sends a request (or two) to the >>>> >>>> server. But the response is routed into an empty case of a chained if >>>> >>>> statement in the js-function _handlePprResponse() in file >>>> >>>> DebugCommon1_2_8.js. >>>> >>>> 20723 else >>>> >>>> 20723 { >>>> >>>> 20724 // FIXME: log an error >>>> >>>> 20725 } >>>> >>>> 20726} >>>> >>>> This is because the rootNodeName is "parseerror". I checked the >>>> >>>> documentElement which is passed to that function as a parameter. I found >>>> >>>> the >>>> >>>> following: >>>> >>>> <parseerror> >>>> >>>> XML-Verarbeitungsfehler: XML- oder Text-Deklaration nicht am Beginn der >>>> >>>> Entität Adresse: >>>> >>>> http://localhost:8080/test/faces/test.jspx Zeile Nr. 1, Spalte 40: >>>> >>>> <sourcetext> >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?><?xml version="1.0" ?> >>>> >>>> ---------------------------------------^ >>>> >>>> </sourcetext> >>>> >>>> </parsererror> >>>> >>>> For the endusers it looks like they ran into TRINIDAD-1139. The only >>>> >>>> difference is that the page is rendered as html 4.01 (not xhtml). and >>>> >>>> with a >>>> >>>> server side logging the presence of successfull requests can be >>>> >>>> monitored. >>>> >>>> Is it possible to prevent double <?XML?> elements in the ppr response by >>>> >>>> configuration? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Matthias Wessendorf >>>> >>>> further stuff: >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> >>>> sessions: http://www.slideshare.net/mwessendorf >>>> >>>> mail: matzew-at-apache-dot-org >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> further stuff: >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> mail: matzew-at-apache-dot-org >>>> >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> further stuff: >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> mail: matzew-at-apache-dot-org >> >> > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
