Also, Denes could instead of
form.vars.field='value'
do
db.database.field.default='value'
before the form=SQLFROM, to "pre-populate" using controller values and
see it in the form filled
On Feb 11, 10:49 pm, vihang <vihan...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
