Martijn Faassen wrote:
dynamically generated class for templates that don't have classes of
themselves. I know you were there when we created this one. :)
class TemplateView(grok.View):
template = unassociated
module_info = module_info_
of course the instances of this class do nothing the developer has to
interact with. As soon as the developer provides a view class of their
own, there's no dynamically generated class anymore. I think that this
is an acceptable use of the pattern.
I'm not sure. Debugging becomes a nightmare with generated classes,
which is how I ran into these problems in the first place.
Can you explain what the what the above code snippet actually does?
I've done it too recently in the form support. The *real* formlib-level
form class is dynamically created for each grok-level form:
class RealEditForm(form.EditForm):
form_fields = get_form_fields(factory, context)
actions = actions_
This one is a bit more scary, as the end-user interacts with an
*instance* of this class; the form attribute on grok-level forms is one.
There must be a nicer way :-S
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
