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.
