Am 14.05.2009 um 15:02 schrieb Martijn Faassen:
Michael Howitz wrote:
Am 14.05.2009 um 12:05 schrieb Martijn Faassen: [snip]
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 function 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 weekend.
The guaranteed compatible step forward to reduce dependencies would be to extract the namedtemplate mechanism from zope.formlib and place that somewhere else. zope.formlib can then have an import for backwards compatibility.
Maybe, but is this namedtemplate mechanism used outside zope.formlib? If so we should extract it.
See also the proposal http://mail.zope.org/pipermail/zope-dev/2009-April/035833.html
I missed this discussion then, my apologies. I still stand by my opinion 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 just do it to lift a dependency.
Right. I will not merge my branch, but look into breaking the zope.app.publisher dependency.
(see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort)
This (move the ISystemErrorView) seems to be the right solution to get 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?
Yours sincerely, -- Michael Howitz · mh@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