Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: [Chris] >> That said, I can live with most of the crap, but these dynamically >> generated classes... wtf? why? why did that? why are they still breathing?! > > *sigh* I don't know who came up with the idea, and I don't really care > as I don't want to point fingers at anyone. The reasons are probably > historical...
Philipp, note that we're dynamically generating some classes in Grok: 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'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. Of course there were good reasons to do this - I wanted to avoid mixing formlib level forms with grok-level forms, as too many method names were the same and making that horrible tangle work would've been a lot more pain indeed, I think. Regards, Martijn _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com