format zero IS_IN_DB

[DenesL]

Back in Jan.2/10 the default for zero was changed to ''
http://groups.google.com/group/web2py/msg/684a2374e7379861

Consider:
db.define_table('person',Field('name',unique=True), format='%(name)s')
db.define_table('dog',Field('name',unique=True),Field
('owner',db.person), format='%(name)s')

will generate a db.dog.owner dropdown with an empty option that IMO
should not be there since it is not part of the associated IS_IN_DB
requires.

Could you please explain to me why was zero='' made the default?

Denes.

PS: this also applies to IS_IN_SET but not in relation to
table._format e.g.

>>> r=IS_IN_SET((1,2,3))
>>> r.options()
[('', ''), ('1', '1'), ('2', '2'), ('3', '3')]

counter-intuitive.

[Thadeus Burgess]

http://groups.google.com/group/web2py/browse_thread/thread/e0ed90f8e72960f6

Please follow the above thread.

Massimo said he was thinking about how to procede with the matter.

-Thadeus

> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
>
>

[DenesL]

Thanks, I've seen it.

The problem with format and IS_IN_DB can be easily fixed in sql.py but
I would be against setting the default of zero to '' in IS_IN_DB and
IS_IN_SET if it creates an empty option in the dropdown.

zero seems to have been introduced to display a "choose a value" kind
of message as the first option in the dropdown, and it should be
explicitly set when required, not explicity removed when not required,
i.e. having to set zero=None if you do not want the empty option,
which should not have been there to begin with.

Denes.

On Jan 28, 12:25 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> http://groups.google.com/group/web2py/browse_thread/thread/e0ed90f8e7...

[Thadeus Burgess]

My thoughts exactly :)

-Thadeus

[DenesL]

<bump>

[mdipierro]

There is no way to please everybody here. some people ask for
zero=None, some for zero='', some for zero='Please choose a value'.
There is no right or wrong. I think we should leave the default as is
('', we changed it twice already) and you configure it as needed.

Massimo

On Jan 29, 9:00 am, DenesL <denes1...@yahoo.ca> wrote:
> <bump>

[DenesL]

I must insist.
The point is that IS_IN_DB and IS_IN_SET now show a spurious empty
option by default.
The keyword here is default.

If you want to introduce a 'choose a value" option you should do it
explicitly and 'at your own risk', the risk being that it creates an
option that when selected will cause an error.

An empty option is plainly wrong, it is not part of the IS_IN_DB or
IS_IN_SET options. It is completely artificial.

How many times the option has been changed should not matter, getting
it right should.
Denes.

[mdipierro]

Let's hear a few more opinions. I don't just want to say no. The
problem is that we had this discussion already and people insisted
such option should be there.

Massimo

[Jonathan Lundell]

Yes, the option is important. But the case for a default of None is
pretty convincing.

[Thadeus Burgess]

+1 supporting DenesL argument. (but we already know this)

note.

default.

breaks app.

we like the feature

but it shouldn't break an app

no reason to have to specifically DISABLE something that hasn't
existed in web2py before ( you know, the empty select or "please
choose a value" breaks my app which is why I'm still running pre-1.70
codebase )

The only reason that it defaults to zero='' is because the person who
originally requested it needed that.

Their only argument was THEY needed it so it should default to it just
for THEIR convenience while everyone else is subjugated to having to
DISABLE a NEW feature.

-Thadeus

[mdipierro]

I think the point is: is it better to generate a validation error
message when a choice is not selected or, by default, select always
the first choice? Are you sure that the problem is with the presence
of a blank option and not with the wrong error associated to it?

On Jan 29, 9:55 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> +1 supporting DenesL argument. (but we already know this)
>
> note.
>
> default.
>
> breaks app.
>
> we like the feature
>
> but it shouldn't break an app
>
> no reason to have to specifically DISABLE something that hasn't
> existed in web2py before ( you know, the empty select or "please
> choose a value" breaks my app which is why I'm still running pre-1.70
> codebase )
>
> The only reason that it defaults to zero='' is because the person who
> originally requested it needed that.
>
> Their only argument was THEY needed it so it should default to it just
> for THEIR convenience while everyone else is subjugated to having to
> DISABLE a NEW feature.
>
> -Thadeus
>

[Iceberg]

When saying "some people ask for zero=None, some for zero='', some for
zero='Please choose a value'", ok, I am the one who once suggest the
recent zero='' change, in this thread:
https://groups.google.com/group/web2py/browse_frm/thread/7a5154c377c9eec3

But hey, I think I made myself clear in that post, that:
zero='blah blah' is UNACCEPTABLE, because it is not friendly for non-
english users.
zero='' is better than above
zero=None is preferable. The reason is explained so well by Denes
and Thadeus, and I can't agree more.

And one more suggestion. If after this discussion, the default zero is
back to None again (I hope so), so please please add one line of
comment as a warning sign, to avoid it being change in the future. It
was changed back and forth in the past, only because we fail to mark
all these valuable, wise discussion in document. For example:

IS_IN_DB(...,
zero=None, # Why? See https://groups.google.com/group/web2py/browse_frm/thread/d25d13cd3f5bd7b1
...)

Regards,
Iceberg

[Thadeus Burgess]

Excellent suggestion on adding the comments with a link to the
discussion thread Iceberg

-Thadeus

[DenesL]

^bump^

[DenesL]

Any more pros/cons on this?
Now is the time to weigh in your opinion.

[mdipierro]

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.

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.

[Jonathan Lundell]

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.

[mdipierro]

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.

[Jonathan Lundell]

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.
>>
>>
>

[Thadeus Burgess]

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

[Iceberg]

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
...)

[villas]

If I've understood the arguments correctly, I think there are 3 good
reasons to keep as-is:

1. We should assume the average user to be as lazy as possible and
make as few clicks as they can. This means that with default=None the
first option will often be passively selected. i.e. many of your
users will appear to come from 'Afghanistan'. Who wants that!

2. IMO form designers should adopt the doctor's mantra: "First, do no
harm to the data". Passively accepting spurious choices does harm.

3. Changing the default will break some of my previously intended
default behaviour when I upgrade. The case for change in this
instance is not greater than the need for backwards-compatibility.

Just my 3 cents.
--D