[ http://issues.apache.org/jira/browse/BEEHIVE-609?page=all ]
Carlin Rogers updated BEEHIVE-609:
----------------------------------
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
was:
When creating a tree (except runAtClient trees), the expansion and selection
actions are generated as anchor hrefs which include the parameter of
netui_treeid=tree. These generated URLs do not encode the & symbol into &
when the document type is set to html4-loose, causing the following error when
the html is run through an html validator: general entity "netui_treeid" not
defined and no default entity.
The generated XHTML when the document type is set to xhtml1-transitional is
correctly encoded as &
Example incorrect href:
<a href="/basicPFTree/select.do?netui_treenode=0&netui_treeid=tree1">
Example valid html href:
<a href="/basicPFTree/select.do?netui_treenode=0&netui_treeid=tree1">
Priority: Minor (was: Major)
Fix Version: TBD
(was: V1)
Please see JIRA Beehive-500 for more details.
http://issues.apache.org/jira/browse/BEEHIVE-500?page=all
> URLs in response from XmlHttpRequestServlet for XHTML doc contain '&' char
> --------------------------------------------------------------------------
>
> Key: BEEHIVE-609
> URL: http://issues.apache.org/jira/browse/BEEHIVE-609
> Project: Beehive
> Type: Bug
> Components: NetUI
> Versions: V1Beta
> Reporter: Carlin Rogers
> Assignee: Carlin Rogers
> Priority: Minor
> Fix For: TBD
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
