Regarding Massimo's comment: because the last line sets 2 validators,
there is no automatic
dropbox.
As far as I'm aware IS_IN_DB can generate a drop-down, but
IS_NOT_IN_DB can't.
IMHO the combination of IS_IN_DB and IS_NOT_IN_DB should theoretically
be able to deliver a automatic drop-down. Basically the results list
of IS_IN_DB less IS_NOT_IN_DB entries. If I'm not wrong even complex
combinations like 2 IS_IN_DB and 3 IS_NOT_IN DB can be theoretically
resloved.
Thanks to Massimo I've got a workaround. The downsides are: its much
more complex code than it could be and due to that its more difficult
to maintain the code. See example below.
It would be great also for me if future wep2by versions do automatic
drop-down on combinations of IS_IN_DB and IS_NOT_IN_DB.
Hans
# vvvvvvvvvvvvvv the following construct replaces the broken dropdown
function of the 1st line of code following vvvvvvvvvvvvvvvvvvvvvv
#db.ipst.subsidary.requires=[IS_IN_DB(db,'subsidary.id','%(line)s %
(name)s'),IS_NOT_IN_DB(db
((db.ips.model_master==request.vars.model_master)&
(db.ips.month==request.vars.month)),db.ips.subsidary)]
class MY_ODD_VALIDATOR(IS_IN_DB):
def __init__(self,*a,**b): IS_IN_DB.__init__(self,*a,**b)
def __call__(self,value):
e=IS_IN_DB.__call__(self,value)
if e[1]: return e
e=IS_NOT_IN_DB(db
((db.ipst.model_master==request.vars.model_master)&
(db.ipst.year==request.vars.year)&(db.ipst.month==request.vars.month)&
(db.ipst.id!=request.vars.id)),db.ipst.subsidary)(value)
return e
db.ipst.subsidary.requires=MY_ODD_VALIDATOR(db
((db.usersubsidary.t2_person==t2.person_id)&
(db.usersubsidary.subsidary==db.subsidary.id)),'subsidary.id','%(name)
s')
# ^^^^^^^^^^^^ end of workaround construct
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Jun 22, 5:44 pm, DenesL <denes1...@yahoo.ca> wrote:
> In the current release form.accepts validates the input against a copy
> of the db field requires and that is OK most of the time but to cover
> for cases like this one it would also need to check against the db
> field requires, in case it was modified afterwards.
>
> But this method implies complexity in the controller and is not
> intuitive:
> 1) create widget for input and use the requires for things like drop-
> down generation and input validation.
> 2) modify requires for db side needs, which is the true use of
> requires.
>
> How would you modify the OptionsWidget to separate input-requires from
> db-requires, and at the same time keep it intuitive?.
>
> A convention? the first validator on the list is used for drop-downs
> an such? is this backward compatible?
> Or by perfecting the clone field trick?
>
> Denes.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
