In view to maintain backward compatibility, can I propose that 2
behaviours:
Behaviour #1: form.vars.field=value be only effective for non-
visualized fields (current behaviour) - if the field is visualized,
then this has no effect, that is, the form takes precedence. This will
only require a change of the manual wordings as this is not exactly
"pre-populating" the form.
Behaviour #2: A new behaviour for pre-population in the form of
"form.vars.field.default = value" to have my mentioned pre-population
behaviour of:
1. If the form field is pre-populated with data A (value) 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.
Behaviour #2 is also in the spirit of
"db.tablename.fieldname.default=value"
What do you think?
maurice
On Feb 12, 3:05 am, vihang <vihan...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
