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.
--
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
