[jira] Updated: (COCOON-2249) XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors
[ https://issues.apache.org/jira/browse/COCOON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Hartmann updated COCOON-2249: - Attachment: cocoon-serializers.txt The patch I committed in the 2.1.x branch. Has to be applied to the 2.2 branch as well. XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors Key: COCOON-2249 URL: https://issues.apache.org/jira/browse/COCOON-2249 Project: Cocoon Issue Type: Improvement Components: Blocks: Serializers Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andreas Hartmann Attachments: COCOON-2249-2009-01-21-1601.txt, cocoon-serializers.txt, MinimalXMLEncoder.java The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the serializers block in Cocoon 2.1.x escapes all characters with a corresponding HTML 4.0 character entity reference into this entity reference. This causes issues with inline JavaScript, since e.g. the double quotes are transformed to quot; which causes a JavaScript parsing error. Another minor negative effect is the increased document size. If I understand the W3C correctly, see e.g. [2], the recommended approach is to use the character set of the encoding as far as possible, and use escapes only in exceptional circumstances. I didn't find a reason why the XHTMLSerializer uses escapes, but I suspect that it is related to browser compatibility issues. Maybe we could make this behaviour configurable, e.g. use-entity-referencestrue|false/use-entity-references [1] http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360 [2] http://www.w3.org/International/tutorials/tutorial-char-enc/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2249) XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors
[ https://issues.apache.org/jira/browse/COCOON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666471#action_12666471 ] Andreas Hartmann commented on COCOON-2249: -- As Antonio suggested, I pulled up the behaviour of the HTMLSerializer to the XHTMLSerializer. Should be fixed in the 2.1.x branch in revision 736988. XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors Key: COCOON-2249 URL: https://issues.apache.org/jira/browse/COCOON-2249 Project: Cocoon Issue Type: Improvement Components: Blocks: Serializers Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andreas Hartmann Attachments: COCOON-2249-2009-01-21-1601.txt, cocoon-serializers.txt, MinimalXMLEncoder.java The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the serializers block in Cocoon 2.1.x escapes all characters with a corresponding HTML 4.0 character entity reference into this entity reference. This causes issues with inline JavaScript, since e.g. the double quotes are transformed to quot; which causes a JavaScript parsing error. Another minor negative effect is the increased document size. If I understand the W3C correctly, see e.g. [2], the recommended approach is to use the character set of the encoding as far as possible, and use escapes only in exceptional circumstances. I didn't find a reason why the XHTMLSerializer uses escapes, but I suspect that it is related to browser compatibility issues. Maybe we could make this behaviour configurable, e.g. use-entity-referencestrue|false/use-entity-references [1] http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360 [2] http://www.w3.org/International/tutorials/tutorial-char-enc/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON3-14) Use generics for pipeline assembly
Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-14: Attachment: generics.patch Patch Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2249) XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors
[ https://issues.apache.org/jira/browse/COCOON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666483#action_12666483 ] Andreas Hartmann commented on COCOON-2249: -- I applied the patch to the 2.2 branch as well. XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors Key: COCOON-2249 URL: https://issues.apache.org/jira/browse/COCOON-2249 Project: Cocoon Issue Type: Improvement Components: Blocks: Serializers Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andreas Hartmann Attachments: COCOON-2249-2009-01-21-1601.txt, cocoon-serializers.txt, MinimalXMLEncoder.java The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the serializers block in Cocoon 2.1.x escapes all characters with a corresponding HTML 4.0 character entity reference into this entity reference. This causes issues with inline JavaScript, since e.g. the double quotes are transformed to quot; which causes a JavaScript parsing error. Another minor negative effect is the increased document size. If I understand the W3C correctly, see e.g. [2], the recommended approach is to use the character set of the encoding as far as possible, and use escapes only in exceptional circumstances. I didn't find a reason why the XHTMLSerializer uses escapes, but I suspect that it is related to browser compatibility issues. Maybe we could make this behaviour configurable, e.g. use-entity-referencestrue|false/use-entity-references [1] http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360 [2] http://www.w3.org/International/tutorials/tutorial-char-enc/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Avoid escaping chars in script/style only in HTMLSerializer? (Re: svn commit: r515096)
Antonio Gallardo schrieb: Andreas Hartmann escribió: Hi Carsten, cziege...@apache.org schrieb: Author: cziegeler Date: Tue Mar 6 04:11:29 2007 New Revision: 515096 URL: http://svn.apache.org/viewvc?view=revrev=515096 Log: Correctly handle content of script and style tag as cdata for html. is there a particular reason why this change hasn't been applied to the XHTMLSerializer as well? IIUC, the script/style CDATA handling is also defined for XHTML [1]. I think this is a better solution. Please implement it in this way. Move the code from HTMLSerializer to XHTML Serializer. Thanks for taking care of this long standing issue. Thanks for your comment! I have pulled up the special handling for script/style from the HTMLSerializer to the XHTMLSerializer in both the 2.1 and 2.2 branch. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: AW: Avoid escaping chars in script/style only in HTMLSerializer? (Re: svn commit: r515096)
Merico Raffaele schrieb: Dear Devs One of my current tasks is making some cocoon 2.1.9 apps xhtml compliant. And I have noticed as posted here that there is a problem with inline java script code that we need in connection with the calendar/date picker of Matt Kruse. Now that you have found a way how to fix it I have the following questions: - When do you aspect to release the corrected XHTML serializer in terms of time? I have committed the patch. It should be available in the next releases of the 2.1 and 2.2 branches. - Can I patch my running cocoon 2.1.9 applications? I think so – I'm not sure if 2.1.9 already contained the serializers block, but since it seems to be quite self-contained, it should be no problem to add it. - If yes, how do I know when the corrected serializer is available and how I have to proceed to patch my running 2.1.9 apps? You could try to apply the patch [1] to your Cocoon codebase. If it doesn't match, you could check-out the current 2.1 branch from SVN and copy the Java classes from the serializers block to your Cocoon codebase. [1] https://issues.apache.org/jira/secure/attachment/12398543/cocoon-serializers.txt HTH, -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666523#action_12666523 ] Andreas Pieber commented on COCOON3-14: --- I'm still the opinion that this would not work at pipeline level. The problem is that components themself decide which consumer/producer they accept (depends on the component type). The first time you come into the situation where components have to be mixed (eg. xml and picture components) the pipeline-compile-check would fail. Think about the following situation: A *.xhtml is inserted in the pipe with some pictures in it. According to the description in it the pictures could be transformed, saved to some place and the urls in the xhtml replaced. In this case the pipeline would look like: X-X-X-XP-P-P-P-PX-X-X Where X stands for XML-Components and P for picture-Component and XP,PX for the Translators (Starter and Finisher are not relevant for the example). This situation will work at the moment, but will fail with generic pipes. Taking the wrong components would fail the first time you create the pipeline with a SetupException so that IMO its not a real life problem at all, and more an academic problem. If there really have to be a compile-check it may have to be happen at component-level. Does the type of the Producer matches my Consumer (or the other way round). At least there's still the option to create a plugin for the different IDEs checking this at compile time. Best Regards, Andreas Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666527#action_12666527 ] Carsten Ziegeler commented on COCOON3-14: - Why does your example from above not work with generics? Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666534#action_12666534 ] Andreas Pieber commented on COCOON3-14: --- Of course it would work using a general Pipeline. But it wont work using a PipelineStAX|SAX|Dom (whatever). I simply wanted to point out that its possible with this generic construction to forbid completely valid constructions... Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666541#action_12666541 ] Carsten Ziegeler commented on COCOON3-14: - Hmm I still don't so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666541#action_12666541 ] cziegeler edited comment on COCOON3-14 at 1/23/09 5:46 AM: -- Hmm I still don't think so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). was (Author: cziegeler): Hmm I still don't so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2249) XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors
[ https://issues.apache.org/jira/browse/COCOON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666537#action_12666537 ] Andreas Hartmann commented on COCOON-2249: -- Does this problem also occur in Cocoon 3? Are further actions required? XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors Key: COCOON-2249 URL: https://issues.apache.org/jira/browse/COCOON-2249 Project: Cocoon Issue Type: Improvement Components: Blocks: Serializers Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andreas Hartmann Attachments: COCOON-2249-2009-01-21-1601.txt, cocoon-serializers.txt, MinimalXMLEncoder.java The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the serializers block in Cocoon 2.1.x escapes all characters with a corresponding HTML 4.0 character entity reference into this entity reference. This causes issues with inline JavaScript, since e.g. the double quotes are transformed to quot; which causes a JavaScript parsing error. Another minor negative effect is the increased document size. If I understand the W3C correctly, see e.g. [2], the recommended approach is to use the character set of the encoding as far as possible, and use escapes only in exceptional circumstances. I didn't find a reason why the XHTMLSerializer uses escapes, but I suspect that it is related to browser compatibility issues. Maybe we could make this behaviour configurable, e.g. use-entity-referencestrue|false/use-entity-references [1] http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360 [2] http://www.w3.org/International/tutorials/tutorial-char-enc/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666545#action_12666545 ] Steven Dolg commented on COCOON3-14: Although we cannot prevent every misconfiguration of a pipeline with this patch, I think it still makes a lot of sense. If a user knows which type of components (s)he will use, the pipeline can be narrowed down to accept only those type of components. If the exact type is not known or a mixture of different components is to be used, using PipelinePipelineComponent pipeline = ... will yield exactly the same behavior we have now. IMO that is the most important aspect of this patch: we do not limit the possibilities, while still providing the option to have compile-time checks. The only drawback I can think of is that we will need a marker interface for every content type that is to be used. While we certainly won't need more than one (maybe two) per module, this adds another interface to the hierarchy. Now there were some objections that the number of interfaces already is high (or at least higher than expected), but IMO this is absolutely worth it. Usually I don't bother with the Pipeline module when working on a content type specific module. And declaring my own marker interface for my components (instead of using PipelineComponent) is actually a sound approach. This might also be used to clearly indicate which components are compatible - although this would rather be something to be encouraged and probably cannot be enforced, since it is only a marker interface. Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1210#action_1210 ] Carsten Ziegeler commented on COCOON3-14: - Yes, even with this patch it's still possible to mix different component types and yes, we have to introduce new marker interfaces :) (and yes it was me how mentioned that there are too many interfaces already...), but if you're just interested in one component type, e.g. sax, then it's just one additional interface. So if noone objects I'll apply the patch in the next days. Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RT] Using the xml subproject in C3
Hi, I think we should use the new xml subproject (containing sax and dom utility classes) in C3. If noone objects, I could do the changes in the next days. Carsten -- Carsten Ziegeler cziege...@apache.org
[Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
Original Message Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open Date: Fri, 23 Jan 2009 13:28:19 + From: Tony Stevenson pct...@apache.org Reply-To: commun...@apache.org To: travel-assista...@apache.org The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee
