@action decorator overrides actions of superclasses

[Guilherme Salgado]

That seems to be because the @action decorator uses sys._getframe() to get the caller's .actions attribute and append the new Action instance to it. When it does that for any class whose superclass uses the @action decorator, it doesn't find an .actions attribute defined and thus assigns an empty Actions object to it. From there you know what happens: the superclass' @action methods will not be present in my class' .actions attribute and thus they won't be rendered/processed.

In the following example, I'd like instances of MyForm2 to have both the 'Save' and 'Edit' actions, but it doesn't.

from zope.formlib import form
from zope import interface, schema

class IOrder(interface.Interface):
    identifier = schema.Int(title=u"Identifier", readonly=True)

class MyForm(form.Form):
    form_fields = form.Fields(IOrder, render_context=True)

    @form.action("Edit")
    def edit_action(self, action, data):
        pass

class MyForm2(MyForm):
    @form.action("Save")
    def save_action(self, action, data):
        pass

print [action.label for action in MyForm2(None, None).actions]
['Save']

[James Henstridge (jamesh)]

formlib already depends on zope.interface, so there is no dependency related reason not to use zope.interface.advice instead of sys._getframe(). That'd allow merging of actions from base class(es).

[Fred Drake (fdrake)]

On 10/22/07, James Henstridge <email address hidden> wrote:
> related reason not to use zope.interface.advice instead of
> sys._getframe(). That'd allow merging of actions from base class(es).

The reason not to merge actions is that that would be a silent change
in semantics, which would be bad for existing systems, making it
difficult to work with versions of zope.formlib before and after the
change.

Using an alternate action constructor would make it easier to deal
with this change; only users of the new constructor (decorator) would
get the new behavior. That doesn't seem like a particularly clean way
to do it, however, since it only affects the first use of the
constructor in a class.

The current approach, of copying the actions explicitly if you want
them, is simple and clean. I'd be hard pressed to call this a bug
even if zope.formlib weren't already in production.

[Colin Watson (cjwatson)]

The zope.formlib project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope.formlib.