You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2003/06/06 00:09:49 UTC

What hacks are going on in Cocoon? (was: DO NOT REPLY [Bug 20508] - [PATCH] Namespace cleanup in HTMLSerializer)

 > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20508

Hello Thorsten,

I applied your patch on my system and tested it. But it's even worse 
than without the patch :-( It's not your problem, it's because of 
extreme hacks I guess.

My test stylesheet:
<xsl:template match="/">
<html>
     <head>
         <title>Test</title>
     </head>
     <body xmlns:xhtml="http://www.w3.org/1999/xhtml" 
xmlns="http://www.w3.org/1999/xhtml" xmlns:i18n="i18nnamespace">
         <xsl:element name="test1" 
namespace="http://www.w3.org/1999/xhtml"/>
         <xsl:element name="test2" namespace="test2"/>
         <test3:test3 xmlns:test3="test3"/>
         <xhtml:div>test</xhtml:div>
     </body>
</html>
</xsl:template>

result using Xalan transformer:
exception on test2 and test3 as expected
output:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Test</title>
</head>
<body>
<test1></test1>
<xhtml:div>test</div>
</body>
</html>

Logging of element sax events:

startElement[
uri: '', localName:'xhtml:div', raw:'xhtml:div']
endElement[
uri:'http://www.w3.org/1999/xhtml', localName:'div', raw:'xhtml:div']

And using XSLTC:
no exception.
output:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Test</title>
</head>
<body>
<xhtml:test1></xhtml:test1>
<ns0:test2></ns0:test2>
<test3:test3></test3:test3>
<xhtml:div>test</xhtml:div>
</body>
</html>

element sax events:

startElement[uri: '', localName: 'xhtml:test1', raw: 'xhtml:test1']
endElement  [uri: '', localName: 'xhtml:test1', raw: 'xhtml:test1']
startElement[uri: '', localName: 'ns0:test2',   raw: 'ns0:test2']
endElement  [uri: '', localName: 'ns0:test2',   raw: 'ns0:test2']
startElement[uri: '', localName: 'test3:test3', raw: 'test3:test3']
endElement  [uri: '', localName: 'test3:test3', raw: 'test3:test3']
startElement[uri: '', localName: 'xhtml:div',   raw: 'xhtml:div']
endElement  [uri: '', localName: 'xhtml:div',   raw: 'xhtml:div']

I guess this means everything is handled via prefix mapping. Hmm, we can 
add a test for ':' in the localName, but this is not the thing I call 
good programming. But I guess it's ok from SAX' point of view. The 
xhtml:div with Xalan seems to be a real bug.

Why SAX is so sloppy and careless?

Joerg

Re: Forms Forms Everywhere

Posted by Steven Noels <st...@outerthought.org>.
On 6/06/2003 14:01 Mark Miller wrote:

> I used XMLforms for my last one and was reasonably happy. But what about 
> Woody? or Precept? or JXForms?
> 
> Help Need advice. Are these new (Woody, JXForms) worth the extra 
> headache of alpha software?
> Do not want to start a war.

Just a quick note on Woody before heading off for the weekend:

Woody came into existence upon my persistent nagging of Bruno to come up 
with something less programmatic as XMLForms (take this as a neutral 
note and largely IMHO), also with regards to the messy Transformer code 
at that time. Woody does forms, and nothing more than that ATM. We hope 
it does a good job at that, and will be adding widgets when the need arises:

We are currently implementing Woody for a customer of ours, which has a 
huge EJB backend app to which we are going to talk through XML/HTTP, 
according more or less the same integration principles existing in 
xReporter (ReST style): back-end is a Phoenix-based query server and 
front-end is Cocoon. No sessions, no fancy presentation tier state 
management, all explicit bookmarkable URIs and all good stuff Roy 
Fielding noted down & Paul Prescod advocated.

The binding framework for that customer project will map between the 
Woody form instance model and XML, and it is noted in our contract that 
we can contribute any part of that framework back to Cocoon (as noted on 
our website, we give price reductions for customers willing to adopt 
this scheme). It will be upon our own judgement whether parts are 
sufficiently generic enough to do so.

Woody is largely orthogonal to the flow approach, and given sufficient 
time, energy, fun and funding, we might be contributing glue between 
both, and work on other binding frameworks (think: databases).

Woody is also our lunchtime sandwich caterer, but that's largely 
off-topic, I guess. The guy doesn't even know his shop name is used in 
org.apache... package names. ;-D

Hope this helps,

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Forms Forms Everywhere

Posted by Mark Miller <mm...@moondance.com>.
Hey,

Happy longtime user of Cocoon (dev versions) is wondering what Form 
framework to use for his next app.

I used XMLforms for my last one and was reasonably happy. But what 
about Woody? or Precept? or JXForms?

Help Need advice. Are these new (Woody, JXForms) worth the extra 
headache of alpha software?
Do not want to start a war.

Mark Miller

Re: What hacks are going on in Cocoon?

Posted by Joerg Heinicke <jo...@gmx.de>.
The SAX events startElement, endElement, startPrefixMapping, 
endPrefixMapping in Xalan:

startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'html', raw: 'html'

startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'head', raw: 'head'

startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'title', raw: 'title'
endElement  [uri: '', localName: 'title', raw: 'title'

endElement  [uri: '', localName: 'head', raw: 'head'

startPrefix [prefix: '', uri: 'http://www.w3.org/1999/xhtml'
startPrefix [prefix: 'i18n', uri: 'i18nnamespace'
startPrefix [prefix: '', uri: 'http://www.w3.org/1999/xhtml'
startPrefix [prefix: 'xhtml', uri: 'http://www.w3.org/1999/xhtml'
startElement[uri: '', localName: 'body', raw: 'body'

startPrefix [prefix: 'i18n', uri: 'i18nnamespace'
startPrefix [prefix: 'xhtml', uri: 'http://www.w3.org/1999/xhtml'
startPrefix [prefix: '', uri: 'http://www.w3.org/1999/xhtml'
startElement[uri: '', localName: 'test1', raw: 'test1'
endElement  [uri: 'http://www.w3.org/1999/xhtml', localName: 'test1', 
raw: 'test1'

startPrefix [prefix: 'xhtml', uri: 'http://www.w3.org/1999/xhtml'
startPrefix [prefix: 'i18n', uri: 'i18nnamespace'
startPrefix [prefix: '', uri: 'http://www.w3.org/1999/xhtml'
startPrefix [prefix: 'xhtml', uri: 'http://www.w3.org/1999/xhtml'
startElement[uri: '', localName: 'xhtml:div', raw: 'xhtml:div'
endElement  [uri: 'http://www.w3.org/1999/xhtml', localName: 'div', raw: 
'xhtml:div'

endElement  [uri: 'http://www.w3.org/1999/xhtml', localName: 'body', 
raw: 'body'

endElement  [uri: '', localName: 'html', raw: 'html'


result: heavy use of prefix mapping, no endPrefixMapping

Can this be improved in Cocoon or is it Xalan core?

Joerg

Re: What hacks are going on in Cocoon?

Posted by Joerg Heinicke <jo...@gmx.de>.
Bruno Dumon wrote:
 > If you have some time, could you compare the current behaviour with
 > that of xalan 2.5 and 2.4.1, to see if this got worse recently?

Hello Bruno,

back to these bugs - we stumbled over them in our company, where we use 
Cocoon 2.0.4 and updated Xalan to 2.4.1.

The pipe:

<map:match pattern="*.xbl">
   <map:generate src="{1}.xbl"/>
   <map:serialize type="xml"/>
</map:match>

The file:

<bindings xmlns="xbl-namespace-uri" xmlns:xbl="xbl-namespace-uri" 
xmlns:xul="xul-namespace-uri">
   <binding>
     <content>
       <xul:textbox xbl:inherits="class"/>
     </content>
   </binding>
</bindings>

The result (with Xalan 2.4.1):

<xbl:bindings xmlns="xbl-namespace-uri" xmlns:xbl="xbl-namespace-uri" 
xmlns:xul="xul-namespace-uri">
   <xbl:binding>
     <xbl:content>
       <xul:textbox xbl:inherits="class"/>
     </xbl:content>
   </binding>
</bindings>

While with old Xalan 2.2.D11 from JDK on every element the xbl 
namespace-prefix was added correctly (also on endElement). This can be 
seen still at http://conweb.virbus.de/conweb/binding/textbox.xml (using 
Mozilla; only if http://conweb.virbus.de/conweb/ shows still version 
2.1.12, the page will be updated probably tomorrow).

The solution here was simple: replacing generator + serializer by a 
reader. But I guess this is not always possible. Xalan 2.4.1 and up 
seems to have problems when the default namespace and a namespace-prefix 
are set to one namespace-uri.

Joerg

Re: What hacks are going on in Cocoon?

Posted by Bruno Dumon <br...@outerthought.org>.
On Sun, 2003-06-08 at 10:38, Joerg Heinicke wrote:
[...]
> 
> Not remembering the LogTransformer I did the logging in the 
> HTMLSerializer, but I get the same output using LogTransformer.
> And I saw XSLTC does not use any prefix mapping, but as you can see it 
> does neither use URIs. How is it propagating namespaces? Through 
> xmlns:xyz="anyUri" attributes? That's the only possibility I can imagine.
> But why does XSLTC use SAX in such a bad way? They completely ignore the 
> /SAX contract/. And why does SAX allow this?
> 

SAX doesn't prevent to generate malicious events.

I think the problems you highlighted here are also the cause of bug
20084.

If you have some time, could you compare the current behaviour with that
of xalan 2.5 and 2.4.1, to see if this got worse recently?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: What hacks are going on in Cocoon?

Posted by Joerg Heinicke <jo...@gmx.de>.
Hello Bruno,

Bruno Dumon wrote:
>>startElement[
>>uri: '', localName:'xhtml:div', raw:'xhtml:div']
>>endElement[
>>uri:'http://www.w3.org/1999/xhtml', localName:'div', raw:'xhtml:div']
> 
> if these are corresponding start and end element events, then this is
> obviously wrong.

Yes, these are :-(

>>And using XSLTC:
>>startElement[uri: '', localName: 'xhtml:test1', raw: 'xhtml:test1']
>>endElement  [uri: '', localName: 'xhtml:test1', raw: 'xhtml:test1']
>>startElement[uri: '', localName: 'ns0:test2',   raw: 'ns0:test2']
>>endElement  [uri: '', localName: 'ns0:test2',   raw: 'ns0:test2']
>>startElement[uri: '', localName: 'test3:test3', raw: 'test3:test3']
>>endElement  [uri: '', localName: 'test3:test3', raw: 'test3:test3']
>>startElement[uri: '', localName: 'xhtml:div',   raw: 'xhtml:div']
>>endElement  [uri: '', localName: 'xhtml:div',   raw: 'xhtml:div']
> 
> In a namespace-aware environment, this certainly isn't allowed either.
> For more background see also
> http://www.saxproject.org/?selected=namespaces

Thanks for the link, I will read it today.

> If you put the loggingtransformer right behind the xslt transformer,
> then these are problems with xalan.

Not remembering the LogTransformer I did the logging in the 
HTMLSerializer, but I get the same output using LogTransformer.
And I saw XSLTC does not use any prefix mapping, but as you can see it 
does neither use URIs. How is it propagating namespaces? Through 
xmlns:xyz="anyUri" attributes? That's the only possibility I can imagine.
But why does XSLTC use SAX in such a bad way? They completely ignore the 
/SAX contract/. And why does SAX allow this?

Joerg

Re: What hacks are going on in Cocoon? (was: DO NOT REPLY [Bug 20508] - [PATCH] Namespace cleanup in HTMLSerializer)

Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-06-06 at 00:09, Joerg Heinicke wrote:
[...]
> Logging of element sax events:
> 
> startElement[
> uri: '', localName:'xhtml:div', raw:'xhtml:div']
> endElement[
> uri:'http://www.w3.org/1999/xhtml', localName:'div', raw:'xhtml:div']
> 

if these are corresponding start and end element events, then this is
obviously wrong.

> And using XSLTC:
> no exception.
> output:
[...]
> element sax events:
> 
> startElement[uri: '', localName: 'xhtml:test1', raw: 'xhtml:test1']
> endElement  [uri: '', localName: 'xhtml:test1', raw: 'xhtml:test1']
> startElement[uri: '', localName: 'ns0:test2',   raw: 'ns0:test2']
> endElement  [uri: '', localName: 'ns0:test2',   raw: 'ns0:test2']
> startElement[uri: '', localName: 'test3:test3', raw: 'test3:test3']
> endElement  [uri: '', localName: 'test3:test3', raw: 'test3:test3']
> startElement[uri: '', localName: 'xhtml:div',   raw: 'xhtml:div']
> endElement  [uri: '', localName: 'xhtml:div',   raw: 'xhtml:div']
> 

In a namespace-aware environment, this certainly isn't allowed either.
For more background see also
http://www.saxproject.org/?selected=namespaces

If you put the loggingtransformer right behind the xslt transformer,
then these are problems with xalan.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org