Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
V1Beta
-
None
-
None
Description
Here's a boundary case issue...
When the html-amp-entity element is set to false in the
beehive-netui-config.xml, the URLs in the response from
XmlHttpRequest contain '&' char rather than the "&"
entity, even when the original DocType is XHTML.
For example, an XHTML document type page with trees whose
properties included runAtClient=true and expandOnServer=true,
the XML document segments returned in the response from
the XmlHttpRequestServlet has URLS with the '&' character
as the parameter separator in the query.
The problem is that the request being handled by the
TreeCRI (our RequestInterceptor) calls directly into
the TreeRenderer. This response is just a document fragment
that does not have a <netui:html> element defining a
document type set on an Html tag. Usually in a JSP
page we add the Html tag object to the request so that
it can be pulled from the request to query the doc
type. In this case we have no doc type in the request
and can not tell the URL rewriting process that the
URL is for XML. Then the rewriting just falls back to
the default logic of checking for the html-amp-entity
setting in beehive-netui-config.xml.
We need to either have another mechanism for setting and
getting the doc type from the request that can be used
between the TreeCRI and the TreeRenderer or maybe just
mock up an Html tag instance to set on the request. There
are some other options that will fix this but may not be
very elegant.
I don't think this needs to be done for 1.0 but will
let the committers process this as appropriate.
To reproduce, add the following to the
<url-config>
<html-amp-entity>false</html-amp-entity>
</url-config>
Then run the TestRecorder recorder test for J519.
I.E.
cd netui/test/webapps/drt
ant start &
ant -Dplayback.list=J519 playback
Attachments
Issue Links
- is a clone of
-
-
- Closed
-