Rails core - Sep 2008 - datetime_select :include_blank clobbers :default option

Currently with datetime_select, if you set :include_blank => true, it
overrides any :default you may have specified. I thought this was a
bug until I looked into the tests and found:

test_include_blank_overrides_default_option

Does anyone know why this is the expected and desirable behavior? I
think if a user specifies a default, this should be respected
-- :include_blank doesn''t imply that it would override a default.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> Currently with datetime_select, if you set :include_blank => true, it
> overrides any :default you may have specified. I thought this was a
> bug until I looked into the tests and found:
>
> test_include_blank_overrides_default_option
>
> Does anyone know why this is the expected and desirable behavior? I
> think if a user specifies a default, this should be respected
> -- :include_blank doesn''t imply that it would override a default.
This has been here since the beginning, so I''m not sure of the
rationale there.  However every time I''ve wanted :include_blank
it''s
been to prevent it from unintentionally defautling to today''s date.
If there''s a :default then this isn''t an issue.

I''ve pinged nik, but I believe he subscribes here too.



-- 
Cheers

Koz

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

Hey Guys,

I believe it is for what Koz suggested - when you use :include_blank
that''s usually because you want the select boxes to appear blank at
first (so your user has to select a date).

To be honest the actual rationale is probably lost to the mists of
time - correct me if I''m wrong, but I think that was added over a year
ago :)

It''s a weird combination, might I ask why you want the opposite
behaviour?

Cheers,

Nik

On Tue, Sep 16, 2008 at 9:08 PM, Michael Koziarski
<michael@koziarski.com> wrote:
>
>> Currently with datetime_select, if you set :include_blank => true,
it
>> overrides any :default you may have specified. I thought this was a
>> bug until I looked into the tests and found:
>>
>> test_include_blank_overrides_default_option
>>
>> Does anyone know why this is the expected and desirable behavior? I
>> think if a user specifies a default, this should be respected
>> -- :include_blank doesn''t imply that it would override a
default.
>
> This has been here since the beginning, so I''m not sure of the
> rationale there.  However every time I''ve wanted :include_blank
it''s
> been to prevent it from unintentionally defautling to today''s
date.
> If there''s a :default then this isn''t an issue.
>
> I''ve pinged nik, but I believe he subscribes here too.
>
>
>
> --
> Cheers
>
> Koz
>
> >
>


-- 

Nik Wakelin
+64 27 424 5433

* Blog: http://codetocustomer.com/blog
* WWR: http://workingwithrails.com/person/7401-nicholas-wakelin
* Company: http://codetocustomer.com

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

Opposite is useful for when someone wants the option to unselect an already
selected date and return the value to nil.  Or, you want today to be the
default, but give the user the choice to select nil.  i.e. When are you
going to do this low priority task?

Tim.

On Tue, Sep 16, 2008 at 9:58 PM, Nik Wakelin <munkywrench@gmail.com>
wrote:
>
> Hey Guys,
>
> I believe it is for what Koz suggested - when you use :include_blank
> that''s usually because you want the select boxes to appear blank
at
> first (so your user has to select a date).
>
> To be honest the actual rationale is probably lost to the mists of
> time - correct me if I''m wrong, but I think that was added over a
year
> ago :)
>
> It''s a weird combination, might I ask why you want the opposite
behaviour?
>
> Cheers,
>
> Nik
>
> On Tue, Sep 16, 2008 at 9:08 PM, Michael Koziarski
> <michael@koziarski.com> wrote:
> >
> >> Currently with datetime_select, if you set :include_blank =>
true, it
> >> overrides any :default you may have specified. I thought this was
a
> >> bug until I looked into the tests and found:
> >>
> >> test_include_blank_overrides_default_option
> >>
> >> Does anyone know why this is the expected and desirable behavior?
I
> >> think if a user specifies a default, this should be respected
> >> -- :include_blank doesn''t imply that it would override a
default.
> >
> > This has been here since the beginning, so I''m not sure of
the
> > rationale there.  However every time I''ve wanted
:include_blank it''s
> > been to prevent it from unintentionally defautling to today''s
date.
> > If there''s a :default then this isn''t an issue.
> >
> > I''ve pinged nik, but I believe he subscribes here too.
> >
> >
> >
> > --
> > Cheers
> >
> > Koz
> >
> > >
> >
>
>
>
> --
>
> Nik Wakelin
> +64 27 424 5433
>
> * Blog: http://codetocustomer.com/blog
> * WWR: http://workingwithrails.com/person/7401-nicholas-wakelin
> * Company: http://codetocustomer.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 16, 5:14 am, "Tim Haines" <tmhai...@gmail.com>
wrote:
> Opposite is useful for when someone wants the option to unselect an already
> selected date and return the value to nil.  Or, you want today to be the
> default, but give the user the choice to select nil.  i.e. When are you
> going to do this low priority task?
Right, good examples.

I can''t think of any reason we shouldn''t change this -- I
can''t think
of any reason a developer would want to explicitly specify a default
and have it be ignored.

The fix is pretty simple -- here''s my monkeypatch:
http://pastie.org/273313
-- I''m just adding a check for the absence of the :default option to
the return statement at the top of the default_datetime method.
Shouldn''t break any existing behavior.


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

On Sep 16, 9:05 am, Geoff B <gbues...@gmail.com>
wrote:
> Shouldn''t break any existing behavior.
...other than, the test I mentioned at the top of this thread, which
we''d need to change or get rid of.

Shouldn''t break any real-world use, I meant to say.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Geoff B wrote:
> On Sep 16, 9:05 am, Geoff B <gbues...@gmail.com> wrote:
>> Shouldn''t break any existing behavior.
> 
> ...other than, the test I mentioned at the top of this thread, which
> we''d need to change or get rid of.
> 
> Shouldn''t break any real-world use, I meant to say.
This sounds good to me.  Feel free to clobber that test while you fix it up.

-- 
Cheers,

Koz

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