You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andrew Madu <an...@gmail.com> on 2007/03/15 15:14:16 UTC

XHTML Serializer block/Ajax: Bug

Hi,
I would like to bring this to the attention of the cocoon membership.
Utilising the serializer block as seralizer of choice in an ajax-request
block breaks the ajax process:

<map:serializer name="xhtml" src="
org.apache.cocoon.components.serializers.XHTMLSerializer"
mime-type="text/html">

                <map:select type="ajax-request">
                  <map:when test="true">
                    <map:serialize type="xml"/>
                  </map:when>
                  <map:otherwise>
                    <map:serialize type="xhtml"/>
                  </map:otherwise>
                </map:select>

Output from browser view:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns
="http://www.w3.org/1999/xhtml"><head><script
 type="text/javascript" src="resources/dojo/dojo.js"></script
><script type="text/javascript" src=
"resources/ajax/cocoon.js"></script><script type="text/javascript"
src="resources/forms/js/forms-lib.js"></script><script
 type="text/javascript">
        dojo.addOnLoad(forms_onload);
        dojo.require(&quot;cocoon.forms.*&quot;);
    </script
><link href="resources/forms/css/forms.css" type=
"text/css" rel="stylesheet" /><
script type="text/javascript"
src="resources/forms/mattkruse-lib/AnchorPosition.js"
></script><script type="text/javascript"
src="resources/forms/mattkruse-lib/PopupWindow.js"></script><script
 type="text/javascript" src="resources/forms/mattkruse-lib/OptionTransfer.js"></
script><script type="text/javascript" src
="resources/forms/mattkruse-lib/selectbox.js"></script><script type
="text/javascript" src="resources/forms/mattkruse-lib/CalendarPopup.js"></
script><script type="text/javascript" src=
"resources/forms/mattkruse-lib/date.js"></script><script type="text/javascript"
>
      // Setup calendar
      var forms_calendar = CalendarPopup();
      forms_calendar.setWeekStartDay(1);
      forms_calendar.showYearNavigation();
      forms_calendar.showYearNavigationInput();

      forms_calendar.setCssPrefix(&quot;forms_&quot;);
    </script><link href=
"resources/forms/css/forms-calendar.css" type="text/css" rel=
"stylesheet" /><script type="text/javascript"
>
      _editor_url = &quot;resources/forms/htmlarea/&quot;;
      _editor_lang = &quot;en&quot;;
    </script><script src="resources/forms/htmlarea/htmlarea.js"
type="text/javascript"
></script>


Alert message generated on each ajax page:

'WARNING:_editor_url is not set! You should set this variable to the editor
files path; it should preferably be an absolute path, like in '/htmlarea',
but it can be relative if you prefer. Further we will try to load the editor
files correctly but we'll probably fail.'

Form action:

Submitting an ajaxed page will cause a whole page reload when none of the
required fields are filled in.

System:

WinXP/SP2 - Java 1.6, Jboss 4.0.3 AS

--
Regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
Pier Fumagalli <pier <at> betaversion.org> writes:

> > But why not staying with HTML then??? Why is the XHTMLSerializer be used
> > in those cases? IMO we should NOT implement any special case handling in
> > XHTMLSerializer but tell the people to use the HTMLSerializer.
> 
> As the original author of the code, if you don't want to implement
> quirks, then, what's the difference between the "XHTML" serializer and
> the "XML" serializer?

That's exactly what Grek put into question [1]. But I think it's ok to do some
of the specific stuff [2].

> If you don't need quirks, you don't need to support browsers, then
> simply use the XMLSerializer and forget about it, the XHTML and HTML
> do exactly this job of supporting as many browsers as possible, no?

I gave my reasoning at [3]: You address quirks in the XHTMLSerializer which
you'd not need if you were not using it. Furthermore you introduce further
problems by forcing the browser into the quirks mode as it can't understand
XHTML anyway. Delivering standard conform HTML is much more appropriate for
those browsers.

Joerg

[1] http://marc.info/?l=xml-cocoon-dev&m=117407836212241&w=4
[2] http://marc.info/?l=xml-cocoon-dev&m=117408459418886&w=4
[3] http://marc.info/?l=xml-cocoon-dev&m=117422523711377&w=4


Re: XHTML Serializer block/Ajax: Bug

Posted by Pier Fumagalli <pi...@betaversion.org>.
On 3/16/07, Joerg Heinicke <jo...@gmx.de> wrote:
> (moving to dev list)
>
> [...]
> But why not staying with HTML then??? Why is the XHTMLSerializer be used
> in those cases? IMO we should NOT implement any special case handling in
> XHTMLSerializer but tell the people to use the HTMLSerializer.

As the original author of the code, if you don't want to implement
quirks, then, what's the difference between the "XHTML" serializer and
the "XML" serializer?

If you don't need quirks, you don't need to support browsers, then
simply use the XMLSerializer and forget about it, the XHTML and HTML
do exactly this job of supporting as many browsers as possible, no?

    Pier

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.03.2007 16:43, Jason Johnston wrote:

> If by "the lazy guys" you also mean Cocoon itself.  For instance, the 
> CForms forms-field-styling.xsl creates all its output in the null 
> namespace, which is fine for regular HTML delivery but if for some 
> reaason you do want to deliver as XHTML you have to set the proper 
> namespace somehow.

A most trivial XSLT can do this.

> To interject a counter-opinion, there is a well-established precendent 
> on the Web today for delivering XHTML in ways that are consumable by 
> current-day user agents but without sacrificing the well-formedness or 
> validity of the XML.  True, you have to control certain aspects of the 
> serialization to avoid tripping up certain browsers, which can be a bit 
> of a pain.

This can be easily reached by using BrowserSelector.

> I think there's a lot of value in having the tool handle these things
> transparently rather than making users figure out workarounds themselves.

That's the point where I don't agree. By delivering XHTML while the 
browser can't understand it you force it into the quirks mode - and 
that's more or less unpredictable. If you deliver standard conform HTML 
instead the browser will behave (probably also more or less) standard 
conform.

Just an example, probably everybody who has been working with CSS knows 
the box model bug in IE. Since IE6 this one is fixed and you will get 
expected behaviour IF you are in standard compliance mode [1]. 
Otherwise, with the one fits all solution, you have to cope with that 
bug [2].

Despite this being just an example which I generalize IMO there is not 
lot of value doing such things transparently. Once again problems should 
get fixed where they arise. This means using HTMLSerializer here when 
necessary and not create one workaround (additional stuff in 
XHTMLSerializer) which leads to the next one (e.g. fixing IE box model) 
both bloating the code. That's just paradoxical. Documenting it is much 
more appropriate.

Regards
Jörg

[1] 
http://msdn2.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic3
[2] 
http://www.456bereastreet.com/archive/200612/internet_explorer_and_the_css_box_model/

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.03.2007 16:43, Jason Johnston wrote:

> If by "the lazy guys" you also mean Cocoon itself.  For instance, the 
> CForms forms-field-styling.xsl creates all its output in the null 
> namespace, which is fine for regular HTML delivery but if for some 
> reaason you do want to deliver as XHTML you have to set the proper 
> namespace somehow.

A most trivial XSLT can do this.

> To interject a counter-opinion, there is a well-established precendent 
> on the Web today for delivering XHTML in ways that are consumable by 
> current-day user agents but without sacrificing the well-formedness or 
> validity of the XML.  True, you have to control certain aspects of the 
> serialization to avoid tripping up certain browsers, which can be a bit 
> of a pain.

This can be easily reached by using BrowserSelector.

> I think there's a lot of value in having the tool handle these things
> transparently rather than making users figure out workarounds themselves.

That's the point where I don't agree. By delivering XHTML while the 
browser can't understand it you force it into the quirks mode - and 
that's more or less unpredictable. If you deliver standard conform HTML 
instead the browser will behave (probably also more or less) standard 
conform.

Just an example, probably everybody who has been working with CSS knows 
the box model bug in IE. Since IE6 this one is fixed and you will get 
expected behaviour IF you are in standard compliance mode [1]. 
Otherwise, with the one fits all solution, you have to cope with that 
bug [2].

Despite this being just an example which I generalize IMO there is not 
lot of value doing such things transparently. Once again problems should 
get fixed where they arise. This means using HTMLSerializer here when 
necessary and not create one workaround (additional stuff in 
XHTMLSerializer) which leads to the next one (e.g. fixing IE box model) 
both bloating the code. That's just paradoxical. Documenting it is much 
more appropriate.

Regards
Jörg

[1] 
http://msdn2.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic3
[2] 
http://www.456bereastreet.com/archive/200612/internet_explorer_and_the_css_box_model/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Jason Johnston <co...@lojjic.net>.
Joerg Heinicke wrote:
> On 16.03.2007 21:52, Grzegorz Kossakowski wrote:
> 
>> Moreover, I wonder why we need special XHTMLSerializer? As XHTML is 
>> only XML with special namespace and tag set why we don't use just 
>> normal xml serializer and configure proper mime type? Do I miss 
>> something important?
> 
> If you have a look into the source code [1] you can see that it handles 
> (besides the stuff fixing the tag soup) doc type, mime type and has same 
> special XHTMLEncoder [2], which adds the HTML 4 entities. So far 
> absolutely ok.
> 
> It puts every element in no namespace into the XHTML namespace. Still 
> acceptable, but abdicable - it's for the lazy guys.

If by "the lazy guys" you also mean Cocoon itself.  For instance, the 
CForms forms-field-styling.xsl creates all its output in the null 
namespace, which is fine for regular HTML delivery but if for some 
reaason you do want to deliver as XHTML you have to set the proper 
namespace somehow.

> Also the meta tag 
> for content type it adds should be abdicable. AFAIR it's also only for 
> IE as it stumbles on the XML declaration.
> 
> But at the end it should not do more than this.

To interject a counter-opinion, there is a well-established precendent 
on the Web today for delivering XHTML in ways that are consumable by 
current-day user agents but without sacrificing the well-formedness or 
validity of the XML.  True, you have to control certain aspects of the 
serialization to avoid tripping up certain browsers, which can be a bit 
of a pain.  But I think the end result is a good one: more documents get 
published as true XML but can still be consumed by non-XML user agents. 
  In fact this compatibility was an important consideration when XHTML 
1.0 was created, and there is an entire appendix in the W3C 
Recommendation dedicated to the subject [1].

Now, XHTMLSerializer is a tool for publishing XHTML.  Adopting a 
hard-line attitude and deliberately ignoring those things that can be 
(fairly easily) done to make the XHTML consumable by current-day user 
agents greatly decreases the usefulness of that tool.  I think there's a 
lot of value in having the tool handle these things transparently rather 
than making users figure out workarounds themselves.

--Jason

[1] http://www.w3.org/TR/xhtml1/#guidelines

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.03.2007 21:52, Grzegorz Kossakowski wrote:

> Moreover, I wonder why we need special XHTMLSerializer? As XHTML is only 
> XML with special namespace and tag set why we don't use just normal xml 
> serializer and configure proper mime type? Do I miss something important?

If you have a look into the source code [1] you can see that it handles 
(besides the stuff fixing the tag soup) doc type, mime type and has same 
special XHTMLEncoder [2], which adds the HTML 4 entities. So far 
absolutely ok.

It puts every element in no namespace into the XHTML namespace. Still 
acceptable, but abdicable - it's for the lazy guys. Also the meta tag 
for content type it adds should be abdicable. AFAIR it's also only for 
IE as it stumbles on the XML declaration.

But at the end it should not do more than this.

Joerg

[1] 
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java?revision=433543&view=markup
[2] 
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/encoding/XHTMLEncoder.java?revision=433543&view=markup

Re: XHTML Serializer block/Ajax: Bug

Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke napisał(a):
> (moving to dev list)
>
> To be honest I'm quite intolerant in this regard: I would even remove 
> this code. It's an all or nothing decision - where you probably can't 
> reach all.
>
> What's actually happening? People want to use XHTML because it's cool, 
> in or state of the art, but they have to support browsers that don't 
> handle XHTML correctly or they break it themselves by not providing 
> the XHTML correctly and forcing the browsers into the quirks mode.
>
> Then we get 20 bug reports for 10 issues in special cases because not 
> all quirks have been addressed yet. And we complicate our code base 
> more and more. Just have a look at XHTMLSerializer commits [1]: 
> special tags handling, omit-xml-declaration and now the 
> not-to-be-escaped characters. And what for at the end? That something 
> formerly known as XHTML can be understood by the browsers in quirks 
> mode and gets parsed as tag soup again.
>
> But why not staying with HTML then??? Why is the XHTMLSerializer be 
> used in those cases? IMO we should NOT implement any special case 
> handling in XHTMLSerializer but tell the people to use the 
> HTMLSerializer.
I agree with you, Joerg, on all you said.
Moreover, I wonder why we need special XHTMLSerializer? As XHTML is only 
XML with special namespace and tag set why we don't use just normal xml 
serializer and configure proper mime type? Do I miss something important?

-- 
Grzegorz Kossakowski

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
(moving to dev list)

On 16.03.2007 14:58, Jason Johnston wrote:

>>> Another option might be to wrap the contents of <script> elements 
>>> within a CDATA section so the JS could remain unencoded but it would 
>>> still result in well-formed XML.  I'm not sure how some browsers 
>>> would handle the CDATA delimiters so they might have to be commented 
>>> out so they're not mistaken for script code:
>>>
>>> <script type="text/javascript">/*<![CDATA[*/
>>> while(0 < 1 && true) alert("oops");
>>> /*]]>*/</script>
>>
>> Actually I don't like it. From an XML POV the above and the current 
>> solution are
>> absolutely equal. What we are going to do with such a fix is to fix 
>> awkward
>> browser behaviour or even wrong document contents.
> 
> I understand what you're saying; it definitely creates uglier content. 
> But in terms of fixing browser behavior, we actually already have logic 
> in place that does just that by preventing collapsing of <script /> 
> tags.  From an XML point of view <script/> and <script></script> are 
> also equal, but we force the latter simply because browsers handle it 
> better.  I don't see this situation as any different.

To be honest I'm quite intolerant in this regard: I would even remove 
this code. It's an all or nothing decision - where you probably can't 
reach all.

What's actually happening? People want to use XHTML because it's cool, 
in or state of the art, but they have to support browsers that don't 
handle XHTML correctly or they break it themselves by not providing the 
XHTML correctly and forcing the browsers into the quirks mode.

Then we get 20 bug reports for 10 issues in special cases because not 
all quirks have been addressed yet. And we complicate our code base more 
and more. Just have a look at XHTMLSerializer commits [1]: special tags 
handling, omit-xml-declaration and now the not-to-be-escaped characters. 
And what for at the end? That something formerly known as XHTML can be 
understood by the browsers in quirks mode and gets parsed as tag soup again.

But why not staying with HTML then??? Why is the XHTMLSerializer be used 
in those cases? IMO we should NOT implement any special case handling in 
XHTMLSerializer but tell the people to use the HTMLSerializer.

Jörg

[1] 
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
(moving to dev list)

On 16.03.2007 14:58, Jason Johnston wrote:

>>> Another option might be to wrap the contents of <script> elements 
>>> within a CDATA section so the JS could remain unencoded but it would 
>>> still result in well-formed XML.  I'm not sure how some browsers 
>>> would handle the CDATA delimiters so they might have to be commented 
>>> out so they're not mistaken for script code:
>>>
>>> <script type="text/javascript">/*<![CDATA[*/
>>> while(0 < 1 && true) alert("oops");
>>> /*]]>*/</script>
>>
>> Actually I don't like it. From an XML POV the above and the current 
>> solution are
>> absolutely equal. What we are going to do with such a fix is to fix 
>> awkward
>> browser behaviour or even wrong document contents.
> 
> I understand what you're saying; it definitely creates uglier content. 
> But in terms of fixing browser behavior, we actually already have logic 
> in place that does just that by preventing collapsing of <script /> 
> tags.  From an XML point of view <script/> and <script></script> are 
> also equal, but we force the latter simply because browsers handle it 
> better.  I don't see this situation as any different.

To be honest I'm quite intolerant in this regard: I would even remove 
this code. It's an all or nothing decision - where you probably can't 
reach all.

What's actually happening? People want to use XHTML because it's cool, 
in or state of the art, but they have to support browsers that don't 
handle XHTML correctly or they break it themselves by not providing the 
XHTML correctly and forcing the browsers into the quirks mode.

Then we get 20 bug reports for 10 issues in special cases because not 
all quirks have been addressed yet. And we complicate our code base more 
and more. Just have a look at XHTMLSerializer commits [1]: special tags 
handling, omit-xml-declaration and now the not-to-be-escaped characters. 
And what for at the end? That something formerly known as XHTML can be 
understood by the browsers in quirks mode and gets parsed as tag soup again.

But why not staying with HTML then??? Why is the XHTMLSerializer be used 
in those cases? IMO we should NOT implement any special case handling in 
XHTMLSerializer but tell the people to use the HTMLSerializer.

Jörg

[1] 
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java

Re: XHTML Serializer block/Ajax: Bug

Posted by Jason Johnston <co...@lojjic.net>.
Joerg Heinicke wrote:
> Jason Johnston <cocoon <at> lojjic.net> writes:
> 
>> The first issue is that XHTMLSerializer encodes all double-quotes in 
>> text content as &quot;, which is of course absolutely valid XML/XHTML. 
>> Unfortunately, when an XHTML document is served up with a text/html 
>> mime-type, as you're doing, Firefox doesn't actually parse the document 
>> with an XML parser; it instead uses the "quirky" HTML parser which 
>> doesn't handle &quot; entities in script.  I suspect MSIE behaves similarly.
> 
> At least for Firefox it is not as simple as you write. IIRC you can serve XHTML
> document with text/html and they are parsed as XHTML using an XML parser. But
> the document itself must also match some criteria (Doctype, XML declaration?).
> There are documents available about this topic on the internet, but I have no
> time to search for them at the moment.
> 
>> The bad news is that apparently Dojo uses 
>> document.write(), which is not allowed in XHTML, so a different error is 
>> thrown.  Dojo would have to be fixed to be able to use this mime-type.
> 
> So, Dojo is not XHTML compatible at all?

Apparently not, though I haven't researched it in depth.  I just know 
that document.write() is not allowed in XHTML.

> 
>> Another option might be to wrap the contents of <script> elements within 
>> a CDATA section so the JS could remain unencoded but it would still 
>> result in well-formed XML.  I'm not sure how some browsers would handle 
>> the CDATA delimiters so they might have to be commented out so they're 
>> not mistaken for script code:
>>
>> <script type="text/javascript">/*<![CDATA[*/
>> while(0 < 1 && true) alert("oops");
>> /*]]>*/</script>
> 
> Actually I don't like it. From an XML POV the above and the current solution are
> absolutely equal. What we are going to do with such a fix is to fix awkward
> browser behaviour or even wrong document contents.

I understand what you're saying; it definitely creates uglier content. 
But in terms of fixing browser behavior, we actually already have logic 
in place that does just that by preventing collapsing of <script /> 
tags.  From an XML point of view <script/> and <script></script> are 
also equal, but we force the latter simply because browsers handle it 
better.  I don't see this situation as any different.

> 
> If Dojo is not XHTML compatible at all, it is also clear that you shouldn't use
> XHTMLSerializer at all - and we shouldn't fix the XHTMLSerializer to make the
> output readable as tag soup what quirks mode actually means.

I also sort of agree that using XHTMLSerializer, or XHTML in general, in 
this situation probably isn't the best choice.  In addition to the 
browser incompatibilities, there are other known issues like CForms 
adding arbitrary attributes like <form dojoType=""> which will make the 
document not validate anyway.






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
Jason Johnston <cocoon <at> lojjic.net> writes:

> The first issue is that XHTMLSerializer encodes all double-quotes in 
> text content as &quot;, which is of course absolutely valid XML/XHTML. 
> Unfortunately, when an XHTML document is served up with a text/html 
> mime-type, as you're doing, Firefox doesn't actually parse the document 
> with an XML parser; it instead uses the "quirky" HTML parser which 
> doesn't handle &quot; entities in script.  I suspect MSIE behaves similarly.

At least for Firefox it is not as simple as you write. IIRC you can serve XHTML
document with text/html and they are parsed as XHTML using an XML parser. But
the document itself must also match some criteria (Doctype, XML declaration?).
There are documents available about this topic on the internet, but I have no
time to search for them at the moment.

> The bad news is that apparently Dojo uses 
> document.write(), which is not allowed in XHTML, so a different error is 
> thrown.  Dojo would have to be fixed to be able to use this mime-type.

So, Dojo is not XHTML compatible at all?

> Another option might be to wrap the contents of <script> elements within 
> a CDATA section so the JS could remain unencoded but it would still 
> result in well-formed XML.  I'm not sure how some browsers would handle 
> the CDATA delimiters so they might have to be commented out so they're 
> not mistaken for script code:
> 
> <script type="text/javascript">/*<![CDATA[*/
> while(0 < 1 && true) alert("oops");
> /*]]>*/</script>

Actually I don't like it. From an XML POV the above and the current solution are
absolutely equal. What we are going to do with such a fix is to fix awkward
browser behaviour or even wrong document contents.

If Dojo is not XHTML compatible at all, it is also clear that you shouldn't use
XHTMLSerializer at all - and we shouldn't fix the XHTMLSerializer to make the
output readable as tag soup what quirks mode actually means.

My 2c.

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Jason Johnston <co...@lojjic.net>.
I've done some investigation.

The first issue is that XHTMLSerializer encodes all double-quotes in 
text content as &quot;, which is of course absolutely valid XML/XHTML. 
Unfortunately, when an XHTML document is served up with a text/html 
mime-type, as you're doing, Firefox doesn't actually parse the document 
with an XML parser; it instead uses the "quirky" HTML parser which 
doesn't handle &quot; entities in script.  I suspect MSIE behaves similarly.

So I tried changing the mime-type to application/xhtml+xml.  The good 
news is that the &quot; entities get parsed correctly by Firefox, so 
those errors go away.  The bad news is that apparently Dojo uses 
document.write(), which is not allowed in XHTML, so a different error is 
thrown.  Dojo would have to be fixed to be able to use this mime-type.

Then I looked into Carsten's HTMLSerializer change to see if it could be 
adopted in XHTMLSerializer as well.  Unfortunately I don't think this is 
possible as-is, because his change prevents *all* XML special character 
encoding in text content, which is fine for HTML but would create a 
non-well-formed XHTML document if the script contained a '<' or '&'.

Another option might be to wrap the contents of <script> elements within 
a CDATA section so the JS could remain unencoded but it would still 
result in well-formed XML.  I'm not sure how some browsers would handle 
the CDATA delimiters so they might have to be commented out so they're 
not mistaken for script code:

<script type="text/javascript">/*<![CDATA[*/
while(0 < 1 && true) alert("oops");
/*]]>*/</script>

Thoughts?  I think I'll try implementing this locally and see if it helps.



Andrew Madu wrote:
> Hi Jörg,
> 
> 
>     Carsten fixed something in the HTMLSerializer, but changed nothing in
>     the XHTMLSerialzer:
> 
> 
> 
> Yes, I have seen the changes made by Carsten in HTMLSerializer:
> 
> @version CVS $Id: HTMLSerializer.java 515096 2007-03-06 12:11:29Z cziegeler
> 
> Changes to the XHTMLSerializer were made last by Crossley:
> 
> @version CVS $Id: XHTMLSerializer.java 433543 2006-08-22 06:22:54Z crossley
> 
> 
>     I have no idea (and no time to investigate) if the XHTMLSerializer needs
>     to be updated as well.
> 
> 
> 
> Ok. Could someone direct me to the where bugs are flagged?
> 
> --
> Regards
> 
> Andrew
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Andrew Madu <an...@gmail.com>.
Hi Carsten,

I definitly think that we should fix this in the serializer by adding a
> "/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
> script tag closes. Additionally no encoding inside the script tag (as
> with the html serializer).
>
> Does this make sense?


Sounds good to me. I am of the opinion that ajax-request should be robust
enough to handle both html and xhtml serialization types.

--
Regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Andrew Madu <an...@gmail.com>.
Hi Joerg,

 Didn't you say in another thread it works as expected in Firefox - a
> browser
> supporting XHTML?


Yes, but that was only in reference to the in-built xhtml serializer, which
as we know doesn't really xhtml serialize, and not the one from blocks which
doesn't quite like javascript!

--
Regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.03.2007 17:37, Jason Johnston wrote:

> Well... sort of.  When Firefox uses the XML parser the document gets
> parsed just fine, but then another problem arises when the Dojo
> libraries used by CForms AJAX tries to call document.write(), which
> is not allowed in the XHTML DOM.  So you trade a problem with the
> XHTML serialization for a problem with Dojo.

Sorry, can't follow. From what I understand this is one more reason not 
to use the XHTMLSerializer but to deliver HTML. Actually this one is 
even a knock out criterion.
Anything else would mean to break the XHTML output to force the browser 
into the quirks mode. Then it does not use the XHTML DOM and Dojo works 
again. Hmm ... Or do I miss something?

Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Jason Johnston <co...@lojjic.net>.
On Mon, 19 Mar 2007 15:28:10 +0000 (UTC), Joerg Heinicke <jo...@gmx.de> wrote:
> Andrew Madu <andrewmadu <at> gmail.com> writes:
> 
>> Wouldn't xhtml serializer need to be fixed anyway, as anyone using it as
>> serializer will still encounter the problems with javascript
> irrespective of
>> whether they are using ajax forms or not?!!
> 
> Didn't you say in another thread it works as expected in Firefox - a
> browser
> supporting XHTML? For browsers not handling XHTML I suggested to switch to
> conform HTML to avoid other issues. The problem arises only when browsers
> are
> not using the XML parser but their tag soup parser.

Well... sort of.  When Firefox uses the XML parser the document gets parsed just fine, but then another problem arises when the Dojo libraries used by CForms AJAX tries to call document.write(), which is not allowed in the XHTML DOM.  So you trade a problem with the XHTML serialization for a problem with Dojo.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
Andrew Madu <andrewmadu <at> gmail.com> writes:

> Wouldn't xhtml serializer need to be fixed anyway, as anyone using it as
> serializer will still encounter the problems with javascript irrespective of
> whether they are using ajax forms or not?!!

Didn't you say in another thread it works as expected in Firefox - a browser
supporting XHTML? For browsers not handling XHTML I suggested to switch to
conform HTML to avoid other issues. The problem arises only when browsers are
not using the XML parser but their tag soup parser.

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Andrew Madu <an...@gmail.com>.
Hi Jason,

>
> Well since Jörg is so strongly against it, and I don't feel like
> swimming upstream against his opinion, I'm not going to bother.  If you
> still feel like taking that on (both the code and the argument) feel free.


Wouldn't xhtml serializer need to be fixed anyway, as anyone using it as
serializer will still encounter the problems with javascript irrespective of
whether they are using ajax forms or not?!!

--
regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.03.2007 14:41, Jason Johnston wrote:

>>>> Yes, I only fixed the html serializer and that fix is not appropriate
>>>> for the xhtml. In html, the contents of the script tag is defined as a
>>>> cdata section, therefore there should be no encoding inside the script.
>>>> And that's what I fixed.
>>>> With xhtml the contents of script is defined as pcdata, so the solution
>>>> would be to create a block like this:
>>>> <script type="text/javascript">
>>>> /* <![CDATA[ */
>>>>     THE REAL JAVA SCRIPT
>>>> /* ]]> */
>>>> </script>
>>>> I definitly think that we should fix this in the serializer by adding a
>>>> "/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
>>>> script tag closes. Additionally no encoding inside the script tag (as
>>>> with the html serializer).
> 
> Well since Jörg is so strongly against it, and I don't feel like 
> swimming upstream against his opinion, I'm not going to bother.  If you 
> still feel like taking that on (both the code and the argument) feel free.

I don't want to block this feature if people think it's useful. I only 
wanted to convince that using XHTMLSerializer where it is not 
appropriate does not buy the user anything, forces us to handle quirks 
though actually not necessary and might force the user to handle 
additional problems he would not have when not using XHTMLSerializer.

Jörg

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.03.2007 14:41, Jason Johnston wrote:

>>>> Yes, I only fixed the html serializer and that fix is not appropriate
>>>> for the xhtml. In html, the contents of the script tag is defined as a
>>>> cdata section, therefore there should be no encoding inside the script.
>>>> And that's what I fixed.
>>>> With xhtml the contents of script is defined as pcdata, so the solution
>>>> would be to create a block like this:
>>>> <script type="text/javascript">
>>>> /* <![CDATA[ */
>>>>     THE REAL JAVA SCRIPT
>>>> /* ]]> */
>>>> </script>
>>>> I definitly think that we should fix this in the serializer by adding a
>>>> "/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
>>>> script tag closes. Additionally no encoding inside the script tag (as
>>>> with the html serializer).
> 
> Well since Jörg is so strongly against it, and I don't feel like 
> swimming upstream against his opinion, I'm not going to bother.  If you 
> still feel like taking that on (both the code and the argument) feel free.

I don't want to block this feature if people think it's useful. I only 
wanted to convince that using XHTMLSerializer where it is not 
appropriate does not buy the user anything, forces us to handle quirks 
though actually not necessary and might force the user to handle 
additional problems he would not have when not using XHTMLSerializer.

Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Jason Johnston <co...@lojjic.net>.
Carsten Ziegeler wrote:
> Jason Johnston wrote:
>> Carsten Ziegeler wrote:
>>> Actually I was too fast in answering :(
>>>
>>> Yes, I only fixed the html serializer and that fix is not appropriate
>>> for the xhtml. In html, the contents of the script tag is defined as a
>>> cdata section, therefore there should be no encoding inside the script.
>>> And that's what I fixed.
>>> With xhtml the contents of script is defined as pcdata, so the solution
>>> would be to create a block like this:
>>> <script type="text/javascript">
>>> /* <![CDATA[ */
>>>     THE REAL JAVA SCRIPT
>>> /* ]]> */
>>> </script>
>>> I definitly think that we should fix this in the serializer by adding a
>>> "/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
>>> script tag closes. Additionally no encoding inside the script tag (as
>>> with the html serializer).
>> Carsten are you working on implementing this?  I was going to give it a 
>> shot but if you're doing it I won't bother. :-)
>>
> No, I'm not working on it yet - I would do it by the end of next week.
> So if you want, just do it :)

Well since Jörg is so strongly against it, and I don't feel like 
swimming upstream against his opinion, I'm not going to bother.  If you 
still feel like taking that on (both the code and the argument) feel free.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Carsten Ziegeler <cz...@apache.org>.
Jason Johnston wrote:
> Carsten Ziegeler wrote:
>> Actually I was too fast in answering :(
>>
>> Yes, I only fixed the html serializer and that fix is not appropriate
>> for the xhtml. In html, the contents of the script tag is defined as a
>> cdata section, therefore there should be no encoding inside the script.
>> And that's what I fixed.
>> With xhtml the contents of script is defined as pcdata, so the solution
>> would be to create a block like this:
>> <script type="text/javascript">
>> /* <![CDATA[ */
>>     THE REAL JAVA SCRIPT
>> /* ]]> */
>> </script>
>> I definitly think that we should fix this in the serializer by adding a
>> "/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
>> script tag closes. Additionally no encoding inside the script tag (as
>> with the html serializer).
> 
> Carsten are you working on implementing this?  I was going to give it a 
> shot but if you're doing it I won't bother. :-)
> 
No, I'm not working on it yet - I would do it by the end of next week.
So if you want, just do it :)

Carsten

-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Jason Johnston <co...@lojjic.net>.
Carsten Ziegeler wrote:
> Actually I was too fast in answering :(
> 
> Yes, I only fixed the html serializer and that fix is not appropriate
> for the xhtml. In html, the contents of the script tag is defined as a
> cdata section, therefore there should be no encoding inside the script.
> And that's what I fixed.
> With xhtml the contents of script is defined as pcdata, so the solution
> would be to create a block like this:
> <script type="text/javascript">
> /* <![CDATA[ */
>     THE REAL JAVA SCRIPT
> /* ]]> */
> </script>
> I definitly think that we should fix this in the serializer by adding a
> "/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
> script tag closes. Additionally no encoding inside the script tag (as
> with the html serializer).

Carsten are you working on implementing this?  I was going to give it a 
shot but if you're doing it I won't bother. :-)


> 
> Does this make sense?
> 
> Carsten
> 
> 
> 
> Andrew Madu wrote:
>> Hi Jörg,
>>
>>
>> Carsten fixed something in the HTMLSerializer, but changed nothing in
>>> the XHTMLSerialzer:
>>
>>
>> Yes, I have seen the changes made by Carsten in HTMLSerializer:
>>
>> @version CVS $Id: HTMLSerializer.java 515096 2007-03-06 12:11:29Z cziegeler
>>
>> Changes to the XHTMLSerializer were made last by Crossley:
>>
>> @version CVS $Id: XHTMLSerializer.java 433543 2006-08-22 06:22:54Z crossley
>>
>>
>> I have no idea (and no time to investigate) if the XHTMLSerializer needs
>>> to be updated as well.
>>
>>
>> Ok. Could someone direct me to the where bugs are flagged?
>>
>> --
>> Regards
>>
>> Andrew
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Carsten Ziegeler <cz...@apache.org>.
Actually I was too fast in answering :(

Yes, I only fixed the html serializer and that fix is not appropriate
for the xhtml. In html, the contents of the script tag is defined as a
cdata section, therefore there should be no encoding inside the script.
And that's what I fixed.
With xhtml the contents of script is defined as pcdata, so the solution
would be to create a block like this:
<script type="text/javascript">
/* <![CDATA[ */
    THE REAL JAVA SCRIPT
/* ]]> */
</script>
I definitly think that we should fix this in the serializer by adding a
"/* <![CDATA[ */" when a script tag opens and a "/* ]]> */" before the
script tag closes. Additionally no encoding inside the script tag (as
with the html serializer).

Does this make sense?

Carsten



Andrew Madu wrote:
> Hi Jörg,
> 
> 
> Carsten fixed something in the HTMLSerializer, but changed nothing in
>> the XHTMLSerialzer:
> 
> 
> 
> Yes, I have seen the changes made by Carsten in HTMLSerializer:
> 
> @version CVS $Id: HTMLSerializer.java 515096 2007-03-06 12:11:29Z cziegeler
> 
> Changes to the XHTMLSerializer were made last by Crossley:
> 
> @version CVS $Id: XHTMLSerializer.java 433543 2006-08-22 06:22:54Z crossley
> 
> 
> I have no idea (and no time to investigate) if the XHTMLSerializer needs
>> to be updated as well.
> 
> 
> 
> Ok. Could someone direct me to the where bugs are flagged?
> 
> --
> Regards
> 
> Andrew
> 


-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Andrew Madu <an...@gmail.com>.
Hi Jörg,


Carsten fixed something in the HTMLSerializer, but changed nothing in
> the XHTMLSerialzer:



Yes, I have seen the changes made by Carsten in HTMLSerializer:

@version CVS $Id: HTMLSerializer.java 515096 2007-03-06 12:11:29Z cziegeler

Changes to the XHTMLSerializer were made last by Crossley:

@version CVS $Id: XHTMLSerializer.java 433543 2006-08-22 06:22:54Z crossley


I have no idea (and no time to investigate) if the XHTMLSerializer needs
> to be updated as well.



Ok. Could someone direct me to the where bugs are flagged?

--
Regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Joerg Heinicke <jo...@gmx.de>.
On 15.03.2007 18:43, Andrew Madu wrote:

> thanks for the link. I checked out the latest files from the address given,
> rebuilt cocoon, but the problem still remains. Carsten could you confirm
> with me where exactly your changed files are or even better could you send
> me the serializer.jar file?

Carsten fixed something in the HTMLSerializer, but changed nothing in 
the XHTMLSerialzer:

http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/

I have no idea (and no time to investigate) if the XHTMLSerializer needs 
to be updated as well.

Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Andrew Madu <an...@gmail.com>.
Hi Bertrand,


https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/


thanks for the link. I checked out the latest files from the address given,
rebuilt cocoon, but the problem still remains. Carsten could you confirm
with me where exactly your changed files are or even better could you send
me the serializer.jar file?

--
Regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Bertrand Delacretaz <bd...@apache.org>.
On 3/15/07, Andrew Madu <an...@gmail.com> wrote:

> ...I have checked out the latest files from svn:
>
> https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.1/RELEASE_2_1_10/..

the latest 2.1.x code is available at

https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XHTML Serializer block/Ajax: Bug

Posted by Andrew Madu <an...@gmail.com>.
Hi Carsten,

Yes, this is a bug in 2.1.10 - I have fixed it last week. You could
> either use the current xhtml serializer from svn or wait for the next
> release :)



For a second there I was almost convinced that you had sent your reply even
before I had sent my bug report! ;-)

I have checked out the latest files from svn:

https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.1/RELEASE_2_1_10/

but am still having the same problem. What am I overlooking here?

--
Regards

Andrew

Re: XHTML Serializer block/Ajax: Bug

Posted by Carsten Ziegeler <cz...@apache.org>.
Yes, this is a bug in 2.1.10 - I have fixed it last week. You could
either use the current xhtml serializer from svn or wait for the next
release :)

Carsten

Andrew Madu wrote:
> Hi,
> I would like to bring this to the attention of the cocoon membership.
> Utilising the serializer block as seralizer of choice in an ajax-request
> block breaks the ajax process:
> 
> <map:serializer name="xhtml" src="
> org.apache.cocoon.components.serializers.XHTMLSerializer"
> mime-type="text/html">
> 
>                 <map:select type="ajax-request">
>                   <map:when test="true">
>                     <map:serialize type="xml"/>
>                   </map:when>
>                   <map:otherwise>
>                     <map:serialize type="xhtml"/>
>                   </map:otherwise>
>                 </map:select>
> 
> Output from browser view:
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns
> ="http://www.w3.org/1999/xhtml"><head><script
>  type="text/javascript" src="resources/dojo/dojo.js"></script
>> <script type="text/javascript" src=
> "resources/ajax/cocoon.js"></script><script type="text/javascript"
> src="resources/forms/js/forms-lib.js"></script><script
>  type="text/javascript">
>         dojo.addOnLoad(forms_onload);
>         dojo.require(&quot;cocoon.forms.*&quot;);
>     </script
>> <link href="resources/forms/css/forms.css" type=
> "text/css" rel="stylesheet" /><
> script type="text/javascript"
> src="resources/forms/mattkruse-lib/AnchorPosition.js"
>> </script><script type="text/javascript"
> src="resources/forms/mattkruse-lib/PopupWindow.js"></script><script
>  type="text/javascript" src="resources/forms/mattkruse-lib/OptionTransfer.js"></
> script><script type="text/javascript" src
> ="resources/forms/mattkruse-lib/selectbox.js"></script><script type
> ="text/javascript" src="resources/forms/mattkruse-lib/CalendarPopup.js"></
> script><script type="text/javascript" src=
> "resources/forms/mattkruse-lib/date.js"></script><script type="text/javascript"
>       // Setup calendar
>       var forms_calendar = CalendarPopup();
>       forms_calendar.setWeekStartDay(1);
>       forms_calendar.showYearNavigation();
>       forms_calendar.showYearNavigationInput();
> 
>       forms_calendar.setCssPrefix(&quot;forms_&quot;);
>     </script><link href=
> "resources/forms/css/forms-calendar.css" type="text/css" rel=
> "stylesheet" /><script type="text/javascript"
>       _editor_url = &quot;resources/forms/htmlarea/&quot;;
>       _editor_lang = &quot;en&quot;;
>     </script><script src="resources/forms/htmlarea/htmlarea.js"
> type="text/javascript"
>> </script>
> 
> 
> Alert message generated on each ajax page:
> 
> 'WARNING:_editor_url is not set! You should set this variable to the editor
> files path; it should preferably be an absolute path, like in '/htmlarea',
> but it can be relative if you prefer. Further we will try to load the editor
> files correctly but we'll probably fail.'
> 
> Form action:
> 
> Submitting an ajaxed page will cause a whole page reload when none of the
> required fields are filled in.
> 
> System:
> 
> WinXP/SP2 - Java 1.6, Jboss 4.0.3 AS
> 
> --
> Regards
> 
> Andrew
> 


-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org