Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4856B857.3040607@mobilebox.pl>
Date: Mon, 16 Jun 2008 21:00:39 +0200
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: jx:element patch
References: <4853B69C.1040401@tt.com.au> <48568FEA.9070307@tuffmail.com>
In-Reply-To: <48568FEA.9070307@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Grzegorz Kossakowski wrote:
> 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?

It should be totally ok to declare a namespace without a prefix[1]:

<?xml version="1.0"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
       xmlns:isbn='urn:ISBN:0-395-36341-6'>
     <title>Cheaper by the Dozen</title>
     <isbn:number>1568491379</isbn:number>
     <notes>
       <!-- make HTML the default namespace for some commentary -->
       <p xmlns='http://www.w3.org/1999/xhtml'>
           This is a <i>funny</i> book!
       </p>
     </notes>
</book>

[1] http://www.w3.org/TR/REC-xml-names/#defaulting

-- 
Leszek Gawron                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.