> Again I'm not sure if you are talking about server or client. From
> the server perspective, if you have
> def myFunc(self):
> return u"alert('the fields in this form are %s');" % [w.id for w in
> function so it is not dynamic from the client perspective.
i'm talking about the server-side. the example that you wrote doesnt work,
because when the function is rendered, the following happens:
args = inspect.getargspec(self.function)
if args is 'self':
return self.function(*[x for x in ['self'] + self.arguments])
the value of the parameter self is not longer the form, its only a string
with the content 'self'. but even if it was not that way, a self doesnt
exist because the jsfunctions are added in the class description. the thing
one would have to do is register those functions in the update-method for
example and additionaly change the render-method of the jsfunction. this
works but this is what i meant when i wrote hacky.
> include style sheets and other resources: either by placing said
> objects and the viewlet manager pattern.
i think with global variables its the same. i want those global variables
have values coming from my form. so i cant use an external js-script file
and register it.
another you wrote:
> If it were a widget for List fields, it would be a great addition to,
> um, z3c.widget? z3c.listwidget? I think.
i first wanted to make a widget, but then i came to the conclusion, that
widgets should be atomic. if a widget is composed of more than one element,
then its a form. otherwise there would be no difference between those.
imagine the widget-switch from formjs for a widget that is composed of more
than one element. that wouldnt make any sense. so there will be a subform.
View this message in context:
Sent from the Zope3 - users mailing list archive at Nabble.com.
Zope3-users mailing list