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 < 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 < 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" (http://www.w3.org/TR/NOTE-datetime).
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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
