> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > But we already have all this in our ANT conditions. So why > do we want > > to redefine them again with a new syntax? How do you add new > > conditions? Because the need for new conditions to check > does not end > > today. > > Along this line of thought, XSLT would not have used XPath > expressions, but a bunch of nested XML tags to specify what a > simple string can express. I've just read that last night > from Michael Kay's XSLT book (very good so far by the way). > Thank god the hyper verbose pure XML syntax was ditched and > XPath parses a string to know what it should do. > > This is exactly why I prefer 100 times inline conditional > attributes, and why I'd like to have my current custom > conditional attributes on all Ant types/tasks. I'd actually > love to be able to have an XPath boolean predicate that could > have access to the Ant Object Model (hierarchy of task/types) > and Context (to access properties and references). >
That is fine, but then we should either adopt an existing language or define one properly. Nor just amalgamate whatever the next contributor came up with (n offence intended). Whatever we add to ANT will stay there for a long time, so we need to be careful in what we add and how we added. > These mini-languages are just plain easier to read and write, > and a long terser than the equivalent XML you can invent. > This is why XSLT has XPath, and why Relax-NG has the compact syntax. > Give me a well define evaluation language with a way to plug new functionality, and then we are talking. But let me just say just providing a bunch of different attrubutes all having different meanings and with an unknown capacity to combine, that does not fit as well define in my book. So lets see a proposal. > I actually like having to deal with XML for Ant build file, > but for condition XPath or any other simpler is tons better > is a lot of cases, even though I want to retain <condition> > for the rare cases I need so heavy duty logic. > > The properties I test are only static properties, set in > properties file, not dynamically computed, so I don't have > any spaghetti code. --DD Well, lucky you. In my case they need to be dynamically computed. So, you see, your special case where everything is static does not cover for more complex situations. The point is to get the right balance. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
