beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers (JIRA)" <beehive-...@incubator.apache.org>
Subject [jira] Updated: (BEEHIVE-609) URLs in response from XmlHttpRequestServlet for XHTML doc contain '&' char
Date Fri, 06 May 2005 16:40:22 GMT
     [ 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 "&amp;"
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 &amp; 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 &amp;

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&amp;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 "&amp;"
> 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


Mime
View raw message