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 [EMAIL PROTECTED] 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
