Firstly: please accept my apologies because I haven't helped code wise on the selectors and on reading of this mail it looks like I'm wading in with criticisms left, right and centre. The work Bruce has done is great and selectors will provide an extremely flexble mechanism with offering intuitive clarity to first time users (IMHO). I just want to try and get it as close to right as possible before release so that we don't tie ourselves to terms and defaults that may have better alternatives.
Static Selectors: This term rubs a little as a Java developer since the classes have nothing to do with the "static" keyword. I realise this is meant to be as opposed to dynamic selectors but maybe a term such as "Standard", "Core" or "Built in" would be just as good without the meaning clash. This is just a doc thing that I'll happily submit a patch for when CVS has something to patch against. 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. 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). I haven't tried handling this exact varient in Java yet but at least "YYYY-MM-DD[Thh:mm:ss]" could be handled with ease. If nothing else the year being first causes the average joe to at least consider which slots the month and day should go in rather than make a mistaken assumption. 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". From the code it looks as if this name is taken from the class name alone (need to get to know the dynamic configuration better) so this might be best changed before any commits are made. 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? Okay, tirade over - comments & knock backs are welcome as ever! Rob ----- Original Message ----- From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 07, 2002 3:09 PM Subject: Re: Selectors documentation and a Reference bug fix > On Mon, 06 May 2002, Bruce Atherton <[EMAIL PROTECTED]> wrote: > > >> - For consistency, wouldn't <selectset> be better than <select>? > > > > I'm happy to call it whatever people want. > > I'm with Rob - <selector> may be better and <selectset> is misleading. > > > You are right, it would be cleaner to drop the "select" part > > +1 > > > Is it too late for that kind of a change, though? > > The whole selector stuff hasn't been documented at all in 1.5beta1, > has it? I don't think we must stick to the names we have right now, > but should stick to them as soon as we release documentation. > > Others? > > > It's fixed in my copy now. > > You may also want to make sure the example for <contains(select)> > doesn't have a literal < in the contains attribute but a < 8-). > > > Should I resubmit the whole tarball or just the one file? > > If we want to rename stuff, a new tarball may be the better option. > > Stefan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
