Am 14.05.2009 um 15:02 schrieb Martijn Faassen:
> Michael Howitz wrote:
>> Am 14.05.2009 um 12:05 schrieb Martijn Faassen:
>>> Could you talk a bit about what your branch is trying to accomplish?
>> zope.app.exception depends on zope.formlib's namedtemplate mechanism.
>> zope.formlib has many many dependencies but only this special
>> of it is used by zope.app.exception. It's needed to render
>> customizable the unauthorized views.
>> So I replaced zope.formlib by the much more lightweight z3c.template.
> Is this replacement compatible with zope.formlib's namedtemplate
> mechanism? Will anything break?
No it is not compatible. So I think it's a bad idea. Breaking the
dependency between zope.app.publication and zope.app.exception by
moving the ISystemErrorView interface and maybe the class which
implements it to zope.browser would be better. I'll look into it at
> The guaranteed compatible step forward to reduce dependencies would be
> to extract the namedtemplate mechanism from zope.formlib and place
> somewhere else. zope.formlib can then have an import for backwards
Maybe, but is this namedtemplate mechanism used outside zope.formlib?
If so we should extract it.
>> See also the proposal
> I missed this discussion then, my apologies. I still stand by my
> that this would suddenly pull in *new* libraries in with a significant
> chunk of new code, and we need to be very careful with that and not
> do it to lift a dependency.
Right. I will not merge my branch, but look into breaking the
>>> (see elsewhere on the thread for a way to cut the dependency of
>>> zope.app.publication to zope.app.exception completely with little
>> This (move the ISystemErrorView) seems to be the right solution to
>> rid of the zope.app.publication dependency on zope.app.exception.
>> In a project of mine I need zope.app.exception independently of this
>> dependency but I do not want to depend on zope.formlib for a little
>> feature of it which can be done by another smaller package.
I looked into it, its not a project of mine it's z3c.layer.pagelet but
it can be refactored to use only the ISystemErrorView interface. It
uses some classes from zope.app.exception but does not need their
features. So I'll refactor it.
> I understand. Why not move the namedtemplate mechanism somewhere else
> entirely, though? This way we'd not introduce new code. The
> namedtemplate code itself only seems to depend on zope.traversing, but
> that doesn't sound like a good home. The tests depend on
> zope.app.pagetemplate, so perhaps it should move there? This is
> still a
> dependency of zope.app.exception anyway, and it itself doesn't
> appear to
> depend on zope.formlib.
Nice idea. I'll look into it.
> zope.app.exception's UI bits are a curious case in that they're not
> really part of the ZMI, though they integrate with the ZMI and assume
> the existence of some macros. It's also a zope.app.* package and we'd
> like to get rid of those in the toolkit. What to do with it?
Michael Howitz · m...@gocept.com · software developer
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -