Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Yes, or maybe have a vote about it. The current construction is rather bad, so we should decide if we want to have it fully declarative or have the construction above.
But whats most important is to start actually using the refactored JXTG. Have you tried as a replacement for the original one in some larger examples? As soon as we have done some basic testing e.g. the JXTG use
After fixing the jxtg testcases I have upgraded an application we use internally in our company for project tracking. Next few days will show.
Great!
in the samples in Cocoon, we should start a vote about removing the original JXTG and replace it with the refactored. There are certainly things letf to do in the internal refactoring of interfaces. But that doesn't affect the use of JXTG, so we don't have to wait for that to be finished.
I'd like to start breaking depencidencied between tags and jxtg engine itself. I'll try to create some outline how it might look but still I have hard time figuring it out to the very detail.
I think that what we discussed in the threads about this earlier should work.
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).
/Daniel
