>
> "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?
"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
"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. 

On Sunday, August 25, 2013 10:53:16 AM UTC-5, Niphlod 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.
> Also, what you're trying to achieve works for input, but not for selects, 
> list:string, etc etc. i.e. the method is only applicable if you know what 
> widget is being used beforehand...more on the matter, it saves typing just 
> the "required" attribute, that is somewhat "universal", that can really be 
> addressed with the same for loop on a dict full of your own widgets.
>
> 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.
> Again, I'm not seeing a big improvement vs the added complexity. 
>
>
> On Sunday, August 25, 2013 5:37:15 PM UTC+2, mr.freeze wrote:
>>
>> Creating custom widgets is exactly what I'm trying to get around. I have 
>> a bunch of fields that just need a css class added.  The default SQLFORM 
>> widgets work perfectly otherwise.  So instead of creating a bunch of custom 
>> widgets I can just tweak the default widgets output for ALL fields like 
>> this:
>> def add_required(elm):
>>     elm['_class'] += ' required'
>> for t in db.tables:
>>     for f in db[t].fields:
>>         if db[t][f].required:
>>             db[t][f].onrender = add_required
>> There is currently no hook into the rendering of default widgets 
>> otherwise. I hope that makes sense.
>>
>>
>> On Sunday, August 25, 2013 9:51:30 AM UTC-5, Niphlod wrote:
>>>
>>> -1 on the patch.
>>>
>>> I don't really get it. Why do you (and all of us) need yet another 
>>> attribute (too many already) of the Field when we have widget= for it ?
>>> Is it really that hard to do
>>>
>>> def my_string_widget(field, value): 
>>>     return INPUT(_name=field.name, _id="%s_%s" % (field._tablename, 
>>> field.name), 
>>>     _class="whatever", 
>>>     _value=value,
>>>     _required=""
>>>     requires=field.requires) 
>>>
>>> Field('comment', 'string', widget=my_string_widget)
>>>
>>> that enables you to do all sorts of crazy things with your own widget ?!
>>>
>>>
>>>
>>>
>>>
>>> On Sunday, August 25, 2013 4:36:45 PM UTC+2, mr.freeze wrote:
>>>>
>>>> Thanks Anthony.  This is good for a specific use case but my patch 
>>>> would allow for arbitrary modification of a field's default widget output. 
>>>>  
>>>> I think this could be generally useful.  
>>>>
>>>> On Sunday, August 25, 2013 9:04:20 AM UTC-5, Anthony wrote:
>>>>>
>>>>> Check out http://dev.s-cubism.com/plugin_notemptymarker.
>>>>>
>>>>> Anthony
>>>>>
>>>>

-- 

--- 
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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to