On Wed, Dec 30, 2009 at 4:10 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Are you talking about forms you made or forms in appadmin? forms in
> appadmin ignore writable and readable by design. Your own forms should
> not ignore them.
My forms are not behaving as I expected (although that might be the
intended behavior :-)
I did forget about appadmin ignoring redable/writable settings, so I
re-did the example with user (my own) forms.
The general use case is editing a record without allowing the end user
to reset its parent.
In models:
db.define_table('account', Field('name'))
db.define_table('oppty_main',
Field('name'),
Field('origin_account_id', db.account))
db.oppty_main.origin_account_id.requires=IS_IN_DB(db, 'account.id', '%(name)s')
In the default controller:
def index():
account=db.account[1] # Just the first record
frmAccount=SQLFORM(db.account, record=account)
oppty_main=db(db.oppty_main.origin_account_id==1).select()[0] #
An oppty_main related to the first account
frmOpptyMain1=SQLFORM(db.oppty_main, record=oppty_main)
db.oppty_main.origin_account_id.writable=False
frmOpptyMain2=SQLFORM(db.oppty_main, record=oppty_main)
# No form processing code!! There are two accounts in the db & one
oppty_main related to the first account
return dict(frmOpptyMain1=frmOpptyMain1,
frmOpptyMain2=frmOpptyMain2, frmAccount=frmAccount)
I the corresponding view:
{{extend 'layout.html'}}
<h1>All forms are update forms</h1>
<h2>Account</h2>
{{=frmAccount}}
<h2>Oppty Main - writable = True</h2>
{{=frmOpptyMain1}}
<h2>Oppty Main - writable = False</h2>
{{=frmOpptyMain2}}
Note: the db already holds two accounts: "account 1" & "account 2" and
one oppty_main: "Oppty main related to account 1"
>From this I would expected that frmOpptyMain2 rendered the string
representation of origin_account_id (either as a span or as a disabled
select element), but it renders the actual digit! I think this is
wrong because I have the opinion that the form should honor the field
representation requirement set at the field definition level.
I can get around this using custom forms:
{{=form.custom.widget.origin_account_id.name}}
but this defeats the purpose of both SQLFORM and the field requirement
mechanism, leading to much code that could otherwise be avoided.
BTW: Happy New Year Everyone!
Miguel
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
