jspath at pangeamedia.com
Fri Sep 14 14:18:44 GMT 2007
Carl Franks wrote:
> On 13/09/2007, Jim Spath <jspath at pangeamedia.com> wrote:
>> Has there been any consideration of a standard Year element? The Date
>> element is extremely handy, and I think a year element would also be a
>> nice addition.
> Is this to be based on a Select element again?
> If so, then it'd be best to make it API-compatible with the Date
> element's year field, and make the Date element use it internally, so
> there's no code duplication.
> I would also suggest it's named "YearSelect".
I had planned on creating Year as a Select element for my application,
and it did feel strange that I was recreating something that the Date
element already provided itself.
> Note: I'm considering renaming the Date element to "DateSelect".
> If I do, I'll keep the old Date around while the code's still beta,
> but it'll spew "deprecated" warnings.
> Then for v1.0, the Date element would be removed.
> Feedback welcome - and if I do this, I'll top-post to the list about it.
YearSelect and DateSelect sound good to me, if for no other reason than
the clarity these names provide.
>> Similarly, I was wondering if some standardized date constraints might
>> also be a good idea. The most basic one would be to check to see if a
>> date is valid. More advanced ones could make sure the date is within an
>> allowable range.
> You can use the Date Inflator - which will return an error to the user
> if it's an invalid date, just like a constraint would.
> Or for a Select year field, you can just add an AutoSet constraint,
> and it'll ensure the value is one of the select menu's values.
I'll try the Date inflator... I'm new to FormFu and wasn't aware that an
error in the inflation stage would return an error to the user, but I
guess it makes sense.
I originally tried to use the AutoSet constraint on the Date element,
assuming that it would magically be applied to each individual select
More information about the HTML-FormFu