Ruby on Rails

On 1 February 2012 09:58, Peter Vandenabeele <peter@vandenabeele.com> wrote:
> On Wed, Feb 1, 2012 at 10:35 AM, Colin Law <clanlaw@googlemail.com> wrote:
>>
>> On 1 February 2012 09:24, sandip ransing <sandip@funonrails.com> wrote:
>> > Hi Peter,
>> >
>> > validating date against Date.strptime('DATE STRING') will surely work.
>> > At controller level, i can able to do validation on date but at model
>> > level
>> > it goes for toss bcz value gets nil before validation(at assignment
>> > level)
>>
>> The best thing is not to let the user enter a simple string for the
>> date, but give him different fields for day, month and year and then
>> combine them into a date.  Allowing him to enter it as a string will
>> cause problems as different users will expect different ordering of
>> the date.  I generally use date_select for dates as Rails will
>> automatically combine the form fields for you.
>
>
> I had experience that the typical administrative user, is _very_ fast at
> typing
> dates on her numeric keypad. It is really a lot easier for her to type a
> requested
> delivery_date as 300412 (that is delivery on 30 April 2012) even if we as
> developers frown upon it. Maybe a series of 3 boxes as you suggest
> may also be a good compromise.

I agree that for what one might call an 'internal' app where users
know what is expected that a single box may be ok. In the case of
three boxes then provided tab can be used between them this can still
be quick to type.

>
> The protection against the problem of misinterpretation, is then to show the
> fully expanded date (preferably with a local fast javascript), to verify
> that the
> computer interpreted the data correctly. And use localisation, where users
> in
> EU get dd/mm/yyyy as default setting and users in US get mm/dd/yyyy as
> default input setting.

The most safe way is possibly to provide a drop down select box for
the month then there is no confusion, but it is slower to enter. I
think date_select will provide this.
Of course there is no "correct" answer to this, different applications
require different solutions.

Colin

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.