I agree with Denes that the "pre-populate" is kindof misleading. I was
stuck with this for a while too. On the first go I would have expected
the behavior as explained by Maurice, and preferred that. But backward
compatibility is important. So the ball is in Massimo's court.
On Feb 11, 9:15 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> This is how it is now
>
> 1)
>
> db.define_table('person',db.Field('person'),db.Field
> ('gender',default='male'))
> form=SQLFORM(db.person)
> form.vars.gender='female'
> form.accepts(....)
>
> shows 'male' by default. and form.vars.gender gets ignored
>
> 2)
>
> db.define_table('person',db.Field('person'),db.Field
> ('gender',default='male'))
> form=SQLFORM(db.person,fields=['name'])
> form.vars.gender='female'
> form.accepts(....)
>
> does not show gender in the form and form.vars.gender is used instead.
>
> 3) Since 1.56
>
> db.define_table('person',db.Field('person'),db.Field
> ('gender',default='male'))
> form=SQLFORM(db.person,fields=['name'])
> db.person.gender.default='female'
> db.person.gender.update='female'
> form.accepts(....)
>
> works the same as 2, but default sets the field only for CREATE forms,
> and update only for UPDATE forms.
>
> The rule is that what is in the form overwrites what is set manually.
> form.vars is not there to prepopulate forms but to set values for
> those fields that are not displayed.
>
> Changing this behavior would break backward compatibility.
>
> I will double check the manual. Perhaps Denes is right that this is
> not explained properly.
>
> Massimo
>
> On Feb 11, 9:34 am, Maurice Ling <mauricel...@gmail.com> wrote:
>
> > I will expect the behaviour to be this:
>
> > 1. If the form field is pre-populated with data A AND visualized, the
> > visualized field should be populated with the data A, then data A
> > should be accepted with the rest of the form data. Unless data A is
> > amended by the user, then the amended data is accepted.
>
> > 2. If the form field is pre-populated with data A AND NOT visualized,
> > data A should be accepted with the rest of the form data.
>
> > Am I getting this right?
>
> > maurice
>
> > On Feb 11, 4:15 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > I will look into changing its behavior. This can be seen as a bug fix
> > > but also as a backward compatibility issue. Anybody opposes?
>
> > > Massimo
>
> > > On Feb 10, 1:20 pm, DenesL <denes1...@yahoo.ca> wrote:
>
> > > > Fixing the manual is easier but what does form.vars.field=value really
> > > > do then?.
>
> > > > A fixed form.vars.field would have multiple personalities.
> > > > It would act as db.tablename.fieldname.default if the field is shown
> > > > in the form and as request.vars.field if it is not returned by the
> > > > form.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@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
-~----------~----~----~----~------~----~------~--~---
