Precisely why I am pushing for a generic onrender method. Adding an
attributes property to either the field or the widget only couples it to
the presentation layer further. Also, attributes are only one aspect of
the usage. Others would be value based modification, wrapping the element
or appending child elements. What about db.table.widget.onrender = ....?
The crux is that default widgets aren't applied until a form is rendered.
This might need to be changed.
On Sunday, August 25, 2013 8:59:31 PM UTC-5, Massimo Di Pierro wrote:
>
> I like this better than the original proposal but I am still unhappy. I
> think Field(...widget=...) is already too much coupling between the
> database layer and the presentation (form) layer. I do not think this
> coupling should be increased. Can we do something like:
>
> db.table.field.widget.attributes = ...
>
> On Sunday, 25 August 2013 17:05:37 UTC-5, Alan Etkin 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.
>>>>>>>>>
>>>>>>>>
>>
>> How about a Field(..., attributes={"class": "required"}) argument so
>> widgets can override their attributes with those on creation. This would
>> avoid the need of adding custom widget code for that simple task. OTOH I
>> think the best would be not to provide the shortcut because it sort of
>> mixes the database configuration and the client user interface. I'd instead
>> subclass the widgets so they add the class to the html if the field is
>> required.
>>
>>
--
---
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.
