I also support zero=None, and it is not difficult for me to decide.
1. From the logical point of view, when saying IS_IN_DB(...) or
IS_IN_SET(...), it should generate a list that actually is in the set/
db, and nothing more. Besides, this is the way it worked before
zero=something is initially invented.
2. Actually I am the person who suggest to invent zero=''. That blank
displayed on the browser serves for one practical purpose, to remind
end user "hey, you have not finished this field yet". And that is
important when your form has 3 dozens of fields to input. Even so,
this zero='' or zero='Please choose' is an extra feature, it should be
the default behavior.
So, please:
IS_IN_DB(...,
zero=None, # Why None? See
http://groups.google.com/group/web2py/browse_frm/thread/d25d13cd3f5bd7b1
...)
On Feb5, 12:49am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> This is a difficult to decide. For me it is both ways. Since half of
> my forms require zero=None and the other half require zero='', either
> way it goes there will be no option that is more "convenient" for my
> development.
>
> I stand in support of zero=None. Web2py is a data/business logic
> oriented framework. Therefore it should default to what is most
> natural from the database point of view. It is also the original look
> and feel of these form elements, so it is also keeping things the same
> as they used to be.
>
> off-topic answer:
>
> SQLFORM(db.mytable, my_records_id)
> or
> crud.update(db.mytable, my_recofds_id)
>
> -Thadeus
>
>
>
> On Thu, Feb 4, 2010 at 9:59 AM, Jonathan Lundell <jlund...@pobox.com> wrote:
> > On Feb 4, 2010, at 7:34 AM, mdipierro wrote:
>
> >> Mind that currently zero='' should be interpreted as zero='(please
> >> choose a value)'. the value '' is not in the db and will not pass
> >> validation. It s just a place holder. Only if
> >> IS_NULL_OR(IS_IN_DB(...zero='')) then the value '' can pass
> >> validation.
>
> > Right, and it's a very useful mode. I think I see (vaguely) the source of
> > the tension.
>
> > zero='' is the most natural behavior for many (most?) forms, from a UI
> > logic point of view.
>
> > zero=None is the most natural logic from the POV of data access: it gives
> > us the list that actually is in the set/db, and nothing more.
>
> > I don't think that either flavor of naturalness is "most natural". Which is
> > why I don't care that much how it goes; I'll probably adopt a practice of
> > coding it explicitly regardless. So you can count me as neutral if you like.
>
> > BTW, an off-topic question: is there a straightforward way to prepopulate a
> > form with an existing database row? I know, I should RTFM....
>
> >> On Feb 4, 9:25 am, Jonathan Lundell <jlund...@pobox.com> wrote:
> >>> On Feb 4, 2010, at 7:08 AM, mdipierro wrote:
>
> >>>> I do not really have an opinion on this. I am only reluctant to
> >>>> changes in behavior.
> >>>> Anyway, I am prepared to make this change (zero=None by default). I
> >>>> would like to know that all major contributors are on board so that
> >>>> you can answer the emails when users complain instead of me. ;-)
>
> >>>> Anybody who has an opinion about this should post here or email me
> >>>> personally.
>
> >>> I prefer zero=None as the default, on the grounds that it seems more
> >>> logical for the default case to not include items that aren't actually in
> >>> the database. Least surprise.
>
> >>> OTOH, it's not a high priority for me, since it's easy enough to override
> >>> either way.
>
> >>>> Executive Summery:
>
> >>>> There is a proposal to default IS_IN_SET(zero=None) and
> >>>> IS_IN_DB(zero=None) so that dropdown select option NO LONGER will have
> >>>> a default black option. Currently, by default, when you create a new
> >>>> record the blank option is selected and, if you do not change it and
> >>>> if you do not allow IS_NULL, you get an error message. With the
> >>>> proposed change, when you create a new record all select/options will
> >>>> - by default - select the first alphabetical value unless you change
> >>>> it.
>
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
