Hi Massimo, have you had a chance to look at this? I am just wondering if I
need to create a workaround outside of the framework or if this will be
incorporated. No worries either way.
On Sunday, August 25, 2013 9:23:39 PM UTC-5, Massimo Di Pierro wrote:
>
> Please open a ticket with your patch
Great idea, the onrender callback.
On Wed, Aug 28, 2013 at 12:33 AM, mr.freeze wrote:
> Thanks Manuele. I am hoping that a generic onrender callback for default
> widgets will simplify this.
>
> On Tuesday, August 27, 2013 5:38:37 AM UTC-5, Manuele wrote:
>>
>> Il 25/08/13 00:37, mr.freeze ha sc
Thanks Manuele. I am hoping that a generic onrender callback for default
widgets will simplify this.
On Tuesday, August 27, 2013 5:38:37 AM UTC-5, Manuele wrote:
>
> Il 25/08/13 00:37, mr.freeze ha scritto:
>
> I want to take advantage of bootstrap's form validation classes so I need
> to
Il 25/08/13 00:37, mr.freeze ha scritto:
> I want to take advantage of bootstrap's form validation classes so I
> need to add a class to the field.
if could be of any help that's the ugly way how I solved it locally :)
def dressMandatory(grid, table):
""" Special representation for mandatory f
Can you please open an issue and add an example. this may be a bug.
On Sunday, 25 August 2013 15:34:40 UTC-5, Joe Barnhart wrote:
>
> I just discovered that dictform and smartdictform override my "requires"
> and add their own, based on the type of the Field. It somewhat defeats the
> purpose o
Here you go: http://code.google.com/p/web2py/issues/detail?id=1648
On Sunday, August 25, 2013 9:23:39 PM UTC-5, Massimo Di Pierro wrote:
>
> Please open a ticket with your patch so I do not forget. I will look at it
> carefully tomorrow. I welcome more discussion on the topic.
>
> On Sunday, 25 A
Please open a ticket with your patch so I do not forget. I will look at it
carefully tomorrow. I welcome more discussion on the topic.
On Sunday, 25 August 2013 21:15:04 UTC-5, mr.freeze wrote:
>
> Precisely why I am pushing for a generic onrender method. Adding an
> attributes property to eithe
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 appe
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.attribu
> "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.
>>>
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
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
I just discovered that dictform and smartdictform override my "requires"
and add their own, based on the type of the Field. It somewhat defeats the
purpose of having a custom widget.
-- Joe
On Sunday, August 25, 2013 7:51:30 AM UTC-7, Niphlod wrote:
>
> -1 on the patch.
>
> I don't really get
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
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/pa
After using this, I am convinced it is generally useful. Otherwise, I have
to create custom widgets for each field. I cleaned up the patch and
submitted it here: http://code.google.com/p/web2py/issues/detail?id=1648
On Sunday, August 25, 2013 2:07:10 PM UTC-5, Niphlod wrote:
>
>
>
> On Sunday
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
>>
>
> "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
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 beforeh
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
t
-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
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_notemp
Here's the patch. I adds an onrender property to Field which is called from
the widget method of all default widgets.
On Saturday, August 24, 2013 6:42:49 PM UTC-5, mr.freeze wrote:
>
> Ideally, I wouldn't set the class via a script, that was just a hack. I
> would like to alter the field after
Ideally, I wouldn't set the class via a script, that was just a hack. I
would like to alter the field after its default widget is rendered. I have
a patch that allows you to do this. Thoughts?:
def add_required(elm):
elm['_required'] += ' required'
db.mytable.myfield.onrender = add_required
Nice idea. But why put it in a comment?
script = ''
for table in db:
for field in table:
if field.required:
script += 'jQuery("#%s_%s").attr("required","")' % (
field._tablename,field.name)
You can then cache the script and place in the layout.
Massimo
On Saturday, 24
I want to take advantage of bootstrap's form validation classes so I need
to add a class to the field. Too bad there's not a hook into when a Field's
widget is rendered so you can manipulate it. Would you take a patch for
that? I can work around it with your method in the meantime:
for t in db.
You could use something like:
db.table.field.comment = 'required'
or
for field in db.table:
if field.required:
field.comment='required'
On Saturday, 24 August 2013 09:36:16 UTC-5, mr.freeze wrote:
>
> I want to show users which fields are required *before* they submit a
> form.
27 matches
Mail list logo
