cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: jx:element patch
Date Mon, 16 Jun 2008 16:08:10 GMT
Kamal pisze:
> Hi,
> I am responsible for JIRA issue 2211, including the associated patch. I 
> will be honest, I didn't really understand what I did. 

If your patch is a result of random typing then I'm truly impressed. ;-)

> I knew enough to 
> test it and make sure it worked, but there are some points I would like 
> to clarify:
> 
> Firstly, I was looking at the code for jx:attribute, in particular this:
> 
> final Attributes EMPTY_ATTRS = new AttributesImpl();
> String elementName = "attribute";
> 
> TextSerializer serializer = new TextSerializer();
> StringWriter writer = new StringWriter();
> serializer.setOutputCharStream(writer);
> 
> ContentHandlerWrapper contentHandler = new 
> ContentHandlerWrapper(serializer, serializer);
> contentHandler.startDocument();
> 
> contentHandler.startElement(JXTemplateGenerator.NS, elementName, 
> elementName, EMPTY_ATTRS);
> Invoker.execute(contentHandler, objectModel, executionContext, 
> macroContext, namespaces, this.getNext(), this.getEndInstruction());
> contentHandler.endElement(JXTemplateGenerator.NS, elementName, elementName);
> contentHandler.endDocument();
> valueStr = writer.toString(); 
> 
> Am I right in saying that the text serializer is what ensures that XML 
> ouput is not serialized in the attributes? I looked at the javadoc for 
> TextSerializer and found little useful information.

Yep, I guess that TextSerializer implements text output method described for XSLT, see[2].
It means
that <jx:attribute> will evaluate it's content (descendant elements) and will pull only
text result
of this evaluation. This enables one to use for example macros to generate the value of attribute.

> I noticed that there is very little validation for jx:attribute. You can 
> put in any old value for an attribute name, including invalid values 
> such as values with spaces and colons (':') in them. I took a very 
> different approach for jx:element and tested that the prefix and name 
> are valid. 

Obviously, your approach is much, much better. I appreciate your attention to details.

> Is there are reason why jx:attribute does not check that the 
> name is a correct name? 

I think the only reason is that original authors forgot about implementing these checks. Are
you a
volunteer to fix that? :)

> Also, in xsp:element, apparently[1], you could 
> not specify a namespace without a prefix and visa versa. I chose to 
> relax this to just not allowing a prefix without a namespace. Is this right?

To be honest, I don't remember why such a rule has been established. Could anyone comment?

> This is probably a very stupid question, but I know that 
> |SitemapComponentTestCase.generate()produced org.w3c.dom.Document object 
> and I was wondering how do I convert this into a string? If I needed to 
> debug a test, I would need to install the block then produce output that 
> way.
> |

Take a look at o.a.c.xml.XMLUtils class[3].

BTW. I think this class should be moved to cocoon-xml-utils module.

> Also, I am happy to update the documentation. Do I update the Daisy site 
> or is there some other procedure I need to follow? Should I also update 
> the samples?

Updating samples and documentation is more than welcome! I guess the first place to look at
should 
be following page:
http://cocoon.apache.org/2.2/blocks/template/1.0/1391_1_1.html

> There are a lot more questions I would like answers to, but I think that 
> I would be better off investigating on my own.
> 
> Finally, I would like to thank the dev team. In the past I don't think I 
> would have considered contributing code to Cocoon, not even something 
> this simple. Not because I didn't want to but because the development 
> environment for Cocoon was a mess. I may not agree with all  the 
> decisions made regarding cocoon 2.2, but even I (someone who loathes 
> using Maven) have to accept the move to Maven was a necessary change and 
> has made the prospect of developing for Cocoon a little less daunting.

Thanks Kamal for your kind words. I'm glad that you some positives on Maven transition. :-)

I've looked carefully at your patch and it looks ok. I'll commit it tomorrow with minor corrections

like methods/file renaming.

Thank you again for your effort!

[2] http://www.w3.org/TR/xslt#section-Text-Output-Method
[3] 
http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/xml/XMLUtils.java?view=markup


-- 
Grzegorz Kossakowski

Mime
View raw message