cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
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
Date Wed, 23 Feb 2005 14:51:18 GMT
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

Mime
View raw message