--On Thu, Mar 2, 2000 11:39 PM -0800 [EMAIL PROTECTED] wrote: >> Essentially the problem I see myself encountering is that I need to embed >> the <ForEach > functionality into the <Ant > task. The sub-task >> implementation I posted previously kept the DOM around to re-make the >> subtasks each iteration. I'm going to have to do the same thing, but >> without the guarantee that I'm capturing all the information. > > Please, don't ! > Keeping DOM around is wrong - it's redundant information, and it will put > too much weight on the framework.
I guess the problem is that the current <Ant /> task already has sub-tasks. It uses the createProperty() method to create a task in the sub-project it will run. If you want to have multiple sub-projects (even using the 'preferred' includes="" syntax) then you need to initialize multiple Property objects from each <property> tag; one for each of the sub-projects. I can see a few possible solutions: - remove the ability of the <ant /> task to have <property /> elements. - store the <property /> information in an object using the current interface, then initialize a new Property object from that storage object during each iteration. This has the disadvantage that it makes <property> tags in the <ant> task different from <property> tags elsewhere. Changes in one have to be propogated to the other manually. This solution is better if you rename the element in <Ant> so there is no expectation that it is the same as a standard property task. - Keep some generic form of the information around that could be used to initialize the property tags. This could be in DOM form or in any other form. You can then initialize the property objects from this information and be sure you haven't lost anything. > I can't understand what's wrong with reading the XML and creating Java > objects ??? Why do you need to keep the information after that in memory? Because, using the includes="" syntax, I do not know how many property objects to create until after the createProperty() method has been called. And even if I did, createProperty() can only return one of them for ProjectHelper to initialize. > DOM is a solution for a different problem - why keeping the XML document > in 2 different forms - the Java object tree and DOM ( or any equivalent )? > SAX is more than enough - and it's the logical solution. Because, if we keep the <property> subtask and try to implement looping, you need the information after ProjectHelper has finished. > Please don't say that this is the just to implement variables. This currently has nothing to do with variables. It has to do with the fact that the <Ant /> task has a sub-task, and I want to iterate over multiple folders. I can either drop out the sub-task (removing current functionality), or keep around the information to re-initialize it each iteration. > All current Ant tasks work fine with the constants ( or whatever > <property> is - it is set before project execution and doesn't change > after). If you need more - please don't change everything, maybe you can > use a scripting language that has a clear notion of variables, or your own > API that can get/set attributes. This has nothing to do with variables or constants. The element I'm talking about is called <property>, but any "deep-xml" element that needs to be re-initialized for each file in an includes="" list will have the same difficulty. later, \x/ill :-}
