Community
Participate
Working Groups
I have tried to adapt my XML project plan to the namespace'd version as per bug 243303, but it just renders an empty page: http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm My plan validates correctly according to the plan xsd as well as the strict xhtml xsd. My plan does look a bit different than the Dash example from the Wiki, since I chose to use a "p:" namespace for all plan elements, and the default namespace for all xhtml. Because I had way more html than plan tags, this seemed less work to get right. I think that this should not matter, and in fact the plan renders correctly in a local firefox, using a local clone of the project-plan-render.xsl. I've been in contact with Dave Carver through AIM and we don't know how to proceed from here. No xml markup bugs, and good local rendering, but still fails on the server? Could you check some server logs, or what else could I do to debug and fix this?
Dave, this one is for you...
(In reply to comment #0) > I have tried to adapt my XML project plan to the namespace'd version as per bug > 243303, but it just renders an empty page: > > http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm > When I click on that link and view the RAW xml: http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm&raw=1 It doesn't look like that is a valid file. Bjorn is the XML file being cached. Martin double check that the XML that renders correctly locally is the same as the XML that is being served by the above page.
(In reply to comment #0) > I have tried to adapt my XML project plan to the namespace'd version as per bug > 243303, but it just renders an empty page: > > http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm > > The XML that is produced by the RAW method isn't valid. So the version you have locally and the version that is on the web site aren't in synch. Once you get the version that is working locally synchronized with what the web site has, you should be good to go.
They are identical, and do render correctly locally. Try Shift+Refresh if you are using Firefox to sync your client cache.
(In reply to comment #4) > They are identical, and do render correctly locally. Try Shift+Refresh if you > are using Firefox to sync your client cache. > Okay, that seemed to work, refreshing the XML does bring up a valid and correct XML. Bjorn, I've verified that this isn't an XSL stylesheet problem, so we need to check the server logs to see if PHP is tossing anything out into the log files. I'll review the source generated by the transformation on the server to see if I can see anything out of the ordinary there.
The logs aren't really useful because there are five front end machines and no good way to get to the logs/aggregate the logs. However, I added an error checking routine to the page and you can now see big red error boxes of all the errors.
There seems to be an XSL issue reported when trying to render the GMF plan: http://www.eclipse.org/projects/project-plan.php?projectid=modeling.gmf
Then again, it seems that using a target milestone of '---' in the bugzilla query strings isn't such a good idea. The XSL comment errors I was seeing appear to be caused by this.
(In reply to comment #8) > Then again, it seems that using a target milestone of '---' in the bugzilla > query strings isn't such a good idea. The XSL comment errors I was seeing > appear to be caused by this. > Yeah, for some reason the --- is getting converted to - - -. I haven't been able to figure out exactly why it is happening when it is going through the url-encode process to clean up the url string. I also noticed one other stylseheet error in the deferred items, they are getting an extra bullet point added. I'll see if I can fix that section up.
(In reply to comment #6) > The logs aren't really useful because there are five front end machines and no > good way to get to the logs/aggregate the logs. However, I added an error > checking routine to the page and you can now see big red error boxes of all the > errors. > Those errors help. I can address the comment issue, with an update. I'll try and get something later today as well as fix the one other issue with the Deferred items.
Created attachment 111307 [details] Fixes issues with comments and libXSLT as well as Deferred items This patch fixes an issue with LibXSLT's handling of xsl:comments and the allowed text it handles. I have removed the xsl:comment statement as it was primarly there for debugging purposes. Also fixed an issue with the deferred items rendering an extra ul / li combination when it was unnecessary.
Patch applied.
(In reply to comment #4) > They are identical, and do render correctly locally. Try Shift+Refresh if you > are using Firefox to sync your client cache. > Martin, it looks like the libXSLT is having some problems with the encoding in your bugzilla queries. If you can try to get it so that there isn't as much be escaped I think that will help solve some of the issues. Basically try and get the queries down to the minimum possible.
Those pink error markers are awsome! They helped me find the issue immediately. My bugzilla query was using a regex: * unencoded field-0-0-0=\[(tcf|wince) * my XML: field-0-0-0=%5C%5B%28tcf%7Cwince%29 * what bugzilla saw: field-0-0-0=%265C[%2628tcf%267Cwince%2629 Apparently, the %5B was translated back into [ but for the other encoded characters, the % char was encoded into %26. Lookslike the ampersand is the only char I need to encode into & while all the rest can go in verbatim, correct? Putting the Regex into the XML unencoded fixed this issue.
The only issues which I see now are these: (1) My <a name="foo"></a> tags render as boldface and look likey they are clickable. Probably an issue in the style sheet? <a name> Anchors should have a class other than <a href> references. Ideally I wouldn't need any <a name> anchors myself anyways when bug 241822 is resolved. (2) Looking at the source of my plan I see that there is a <meta author> tag listing Bjorn as the Author. That's not correct IMHO since the document is the XML so either no author or the XML's author should be listed. (3) Proposed theme items' heading reads "Propose" but should be "Proposed" (4) When there are no items in a bugzilla query, the "No items" text renders with newline before and after (because inside a <p>No items</p> tag). These should be inside a <div>No items</div> tag instead to look similar as the queries which do produce items. http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm
(In reply to comment #15) > The only issues which I see now are these: > > (3) Proposed theme items' heading reads "Propose" but should be "Proposed" Yeah, this is a typo in the Stylesheet. I'll get it corrected. > > (4) When there are no items in a bugzilla query, the "No items" text renders > with newline before and after (because inside a <p>No items</p> tag). > These should be inside a <div>No items</div> tag instead to look similar > as the queries which do produce items. > > http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm I'll make the <div> corrections as well.
Created attachment 111351 [details] Fixes Proposed and No items bugs. This adds fixes for the Proposed and No Items bugs that were mentioned in Comment #15.
Created attachment 111352 [details] Removes XML Declaration, fixes Proposed, and No Items This fixes in addition to the No Items, and Proposed, the XML declaration was being outputed into the middle of the HTML document. This is technically incorrect, so added the omit-xml-declaration attribute to the xsl:output element of the stylesheet. This should keep the xsl file from outputting the <?xml ?> declaration in the middle of the file.
Dave, this seems like something the XSLT could do.
(Argh, comment on wrong bug)
Patch applied, I think we're going to mark this bug as fixed.
Released or closed for STAGING_264 (yesterday). Please see final comments for actual resolution status. This message does not imply that any action was taken that was not already stated.
