BTW, I don't think you would ever use list:string or list:integer without
IS_IN_SET or IS_IN_DB. From the book:
"While list:reference has a default validator and a default representation,
list:integer and list:string do not. So these two need an IS_IN_SET or an
IS_IN_DB validator if you want to use them in forms."
On Sunday, August 25, 2013 3:52:46 PM UTC-5, mr.freeze wrote:
>
> It still works fine for me after removing IS_IN_SET. What are you seeing?
>
> On Sunday, August 25, 2013 3:24:46 PM UTC-5, Niphlod wrote:
>>
>> try to remove the requires=IS_IN_SET...
>>
>> On Sunday, August 25, 2013 9:31:09 PM UTC+2, mr.freeze wrote:
>>>
>>> No grudge here. Just making my case for what I consider to be a useful
>>> patch. The overhead should be nominal since it only adds a null check and
>>> moves on (premature optimization is the root of all evil). Copy/paste is
>>> bad for code reuse. As the default widgets improve over time, the
>>> copied/pasted code would need to be maintained separately. list:integer
>>> and list:string work like a champ for me:
>>> def add_required(elm):
>>> elm['_required'] = ''
>>> form = SQLFORM.factory(Field('age','list:integer', required=True,
>>> requires=IS_IN_SET([12,23,34,45,56]),
>>> onrender=add_required ),
>>> Field('colors','list:string', required=True,
>>> requires=IS_IN_SET(['red','blue',
>>> 'green','orange','black']),
>>> onrender=add_required ))
>>>
>>>
>>>
>>> On Sunday, August 25, 2013 2:07:10 PM UTC-5, Niphlod wrote:
>>>>
>>>>
>>>>
>>>> On Sunday, August 25, 2013 6:45:21 PM UTC+2, mr.freeze wrote:
>>>>>
>>>>> "Ok, the thing is that there are no hooks in rendering cause all the
>>>>>> rendering is meant to be happen in your own widget." - I disagree. You
>>>>>> can
>>>>>> modify a SQLFORM after it renders. I am simply trying to achieve a
>>>>>> similar
>>>>>> effect at the Field level.
>>>>>>
>>>>> "Also, what you're trying to achieve works for input, but not for
>>>>> selects, list:string, etc etc. i.e." - It is working for me in inputs,
>>>>> selects, etc. Did you try it out?
>>>>>
>>>>
>>>> yes, and it doesn't work for list:string and list:integer fields
>>>>
>>>>
>>>>> "In any case, with your patch you just added the code you needed, it
>>>>> doesn't save you any typing if you import you own widgets overwriting the
>>>>> default ones with your own." - Recreating all of the default widgets is a
>>>>> lot of typing
>>>>>
>>>>
>>>> for mods like this, it's just copy/paste. For heavier mods, you'll have
>>>> to separate your "onrender" to be compatible with the different logics,
>>>> that will save no typing at all and will be much more error prone.
>>>>
>>>>
>>>>> "Again, I'm not seeing a big improvement vs the added complexity." -
>>>>> The patch is very simple. It just calls an onrender method if it exists
>>>>> after a default widget is rendered.
>>>>>
>>>>>
>>>> And it will hog down any Field with yet another "not-so-useful"
>>>> property from now on, plus a check if onrender exists for every serialized
>>>> widget out there (so, at least twice for any form submitted, for every
>>>> field in the form).
>>>>
>>>> Anyway, I'm starting to see a little bit of "grudge". I'll stop posting:
>>>> I'm just stating that in my POV this should belong either to a formstyle
>>>> or
>>>> in your own widgets, so it's not worth the inclusion in web2py.
>>>>
>>>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
