Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <421C9866.5080704@mobilebox.pl>
Date: Wed, 23 Feb 2005 15:51:18 +0100
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: svn commit: r154841 - in cocoon/trunk/src:
 blocks/template/java/org/apache/cocoon/components/expression/jexl/JexlExpression.java
 blocks/template/test/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.java
 java/org/apache/cocoon/environment/TemplateObjectModelHelper.java
References: <20050222130110.561.qmail@minotaur.apache.org>
 <421B2F6D.7060108@apache.org> <421B34DE.80804@nada.kth.se>
 <421B3AF5.5000306@mobilebox.pl> <421B4182.7070506@nada.kth.se>
 <421B4598.7010501@mobilebox.pl> <421B6E37.3010109@nada.kth.se>
 <421C7F01.9000703@mobilebox.pl> <421C8864.8050708@nada.kth.se>
 <421C8AAE.1000106@mobilebox.pl> <421C8D06.7080302@nada.kth.se>
 <421C8E0C.2020706@mobilebox.pl> <421C90A8.7040307@nada.kth.se>
In-Reply-To: <421C90A8.7040307@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>>> Leszek Gawron wrote:
>>>>>
>>>>>> Daniel Fagerstrom wrote:
>>>>>>
>>>>>>> The main thing left to do in the invoker is to get rid of the 
>>>>>>> code for handling macros in the StartElement part of execute. My 
>>>>>>> idea there is to create a class that implements StartInstruction 
>>>>>>> and contains all the macro creation and execution code. So it is 
>>>>>>> such classes that is stored in the definition map, if a element 
>>>>>>> name is found in the definition map one need just call the 
>>>>>>> execution method on it. By doing like this we get rid of all the 
>>>>>>> refernces to tags from the invoker. Concerning the parser I think 
>>>>>>> we allready have discussed how it can work, check the archive 
>>>>>>> (marc.theaimsgroup.com seem to be down so I can't give anty 
>>>>>>> detailed refernces right now).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> For starters: what do you say if every Event had an execute method 
>>>>>> and we got rid of
>>>>>>
>>>>>> } else if (ev instanceof EndCDATA) {
>>>>>>     consumer.endCDATA();
>>>>>> } else if (ev instanceof EndDTD) {
>>>>>>     consumer.endDTD();
>>>>>> } else if (ev instanceof EndEntity) {
>>>>>>     consumer.endEntity(((EndEntity) ev).getName());
>>>>>> } else if (ev instanceof StartCDATA) {
>>>>>>     consumer.startCDATA();
>>>>>> } else if (ev instanceof StartDTD) {
>>>>>>     StartDTD startDTD = (StartDTD) ev;
>>>>>>     consumer.startDTD(startDTD.getName(), startDTD.getPublicId(),
>>>>>>                       startDTD.getSystemId());
>>>>>> } else if (ev instanceof StartEntity) {
>>>>>>     consumer.startEntity(((StartEntity) ev).getName());
>>>>>>
>>>>>>     // Instructions
>>>>>> }
>>>>>>
>>>>>> ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sure, what interface do you have in mind?
>>>>
>>>>
>>>>
>>>>
>>>> I mean just add:
>>>>     public Event execute(final XMLConsumer consumer,
>>>>                          ExpressionContext expressionContext,
>>>>                          ExecutionContext executionContext,
>>>>                          StartElement macroCall, Event startEvent, 
>>>> Event endEvent)
>>>>         throws SAXException {
>>>>         return getNext();
>>>>     }
>>>
>>>
>>>
>>>
>>> Ok, I would prefer having just:
>>>
>>>    public Event execute(final XMLConsumer consumer,
>>>                         ExpressionContext expressionContext)
>>>        throws SAXException {
>>>        return getNext();
>>>    }
>>>
>>> or maybe even:
>>>    public void execute(final XMLConsumer consumer,
>>>                         ExpressionContext expressionContext)
>>>        throws SAXException {
>>>    }
>>>
>>> To make the Event handling independent of the instruction handling as 
>>> I propsed in 
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110132582421156&w=2. 
>>> But that might require some further refactoring so if you don't feel 
>>> like it you can go ahead with the fatter interface.
>>
>>
>> I'll go in small steps. Keeping fatter interface won't break a thing. 
>> After I finish we'll go for making it simpler.
>>
Done and commited.
next things:

1. IgnorableWhitespace.execute uses TextEvent.characters method. This is 
almost identical to Characters.execute. Differs in one thing:

Characters.execute uses:
Object val = expr.getNode(expressionContext);
Invoker.executeNode(consumer, val);

while for IgnorableWhitespace:
Object val = expr.getValue(expressionContext);
chars = val != null ? val.toString().toCharArray()
                             : ArrayUtils.EMPTY_CHAR_ARRAY;

Looks like IgnorableWhitespace could also use the first construct 
without side effects. Still I'm not 100% sure.

2. To move macro calling code from Invoker we need to introduce 
StartCall event. Now I have a little problem with that as we will need 2 
versions of this class:
a) "compiled" - when macro is invoked via a jx:call macro="something"
b) "final" when macro is invoked via <something param1="foo"/>

a) needs to hold expressions while b) needs to hold ready to use values. 
I'll see if there is a way to construct a "compiled" version on the fly.

What do you say if we deprecate <something param1="foo"/> and make users 
call macros only via jx:call? This is much cleaner and does not 
introduce accidental mistakes. Several times I had stack overflows 
because I accidentally created an element that had the same name as one 
of the imported macros.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65