ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: Selectors documentation and a Reference bug fix
Date Tue, 07 May 2002 19:07:08 GMT
Ok, a quick summary of the feedback I've received so far and the changes I 
will submit today or tomorrow barring arguments to the contrary.

First, <selector> seems to be preferred and I like it better as well, so 
I'll change to that.

Second, I haven't heard complaints about changing the names to drop the 
"select" suffix, so they are gone.

Third, I've fixed both the errors in the HTML. Thanks for the catches, 
Diane and Stefan. Stefan, I wasn't sure exactly what you were referring to 
since I think the HTML for the example of <containsselect> has &lt; 
everywhere. On reflection, however, I realized you must be talking about 
the contents of the contains attribute which render as "<script". I decided 
to drop the &lt; from that string as it muddied what was supposed to be a 
clear example.

Then we have Rob's "tirade". Please, keep the tirades coming. The more 
feedback, the better the selectors will be.

At 05:02 PM 5/7/2002 +0100, Rob Oxspring wrote:
>Static Selectors:
>This term rubs a little as a Java developer since the classes have nothing
>to do with the "static" keyword.

Fair enough. Changed to "Core" in the documentation.

>Date Selector:
>Not wanting to start any pro/anti american battles but I hate the
>"MM/DD/YYYY HH:MM AM_or_PM" on so many levels (its a pet of mine).  I think
>the best option it probably to allow pattern= and locale= attributes ala
><tstamp/> and will happily send in a patch to do so (probably tomorrow
>night) unless someone else beats me to it.

I'm going to leave this one to you. If you do this, you should also take a 
look at the Touch task since I got the format from there. Sounds like a new 
feature, though.

>   However I'd also suggest that
>the default format changes - standards are there for a reason and although I
>can't lay my hands on a copy of ISO8601, the format seems to be
>"YYYY-MM-DDThh:mm:ss.sTZD" (

Hmm. This would be something to get right from the beginning, but I favour 
consistency with existing tasks for a default rather than an awkward (from 
the user's typing point of view) standard. Just my HO, though, I'm ready to 
be shouted down.

What would be really nice eventually is a date parser that handled any 
format you threw at it, much like the one many C projects have with the 
getdate.y yacc file. It can handle "yesterday", "5 days ago", "a fortnight 
ago", and "last february". It can also handle "2001-12-17", "12/17/2001", 
and even "17-12-2001". Of course, it can't disambiguate "01-02-03" 
automatically, but you could use locale or pattern attributes only if you 
needed them. Someday.

>Extend Selector:
>Like "static selectors" the term doesn't gell well for me. I think its
>because "extend" is a verb which doesn't match with the others, alternatives
>might be "extendedselector" or "customselector".

Assuming no one complains, I'll make this <custom>.

>When fields:
>And now we reach the bottom of the pile.  When faced with <date
>datetime="06/18/1979 00:00 AM"/> I would assume that it is going to select
>files with exactly that date rather than anything before it.  I guess
>"equal" is going to be the least used of the "when" possibilities but I
>still feel its the logical default.  The argument makes sense to me with
><size size="1" units"Mi"/> too - seeing this for the first time I would
>assume that we are talking exact matches rather than maximum. So how about
>changing these defaults to equal when faced the less/equal/more question?

I could make this change, but I'm not partial to it. I hear what you are 
saying about expectations (and I've argued that Ant should act as a user 
expects as much as possible myself) but I'm not thrilled with making an 
unusual usecase the default. My inclination is to save the user from having 
to type things as much as possible, even if it means forcing them to read 
the documentation.

Counterpoints and further feedback welcome.

Thanks everyone.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message