I really do not like to touch this stuff because historically, every
time I changed form processing, something broke.
Anyway, I think I have implemented what you suggest and it is
available in trunk.
Please test it careful for a few forms (with string, textarea and
checkboxes, default and no default) and let me know if it works as you
expect.
Massimo
On Feb 11, 8:43 pm, Maurice Ling <mauricel...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
