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?
>> depends on zope.formlib's namedtemplate mechanism.
>> zope.formlib has many many dependencies but only this special  
>> function
>> of it is used by 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 and 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  
> 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 
> 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 dependency.

>>> (see elsewhere on the thread for a way to cut the dependency of
>>> to completely with little
>>> effort)
>> This (move the ISystemErrorView) seems to be the right solution to  
>> get
>> rid of the dependency on
>> In a project of mine I need 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 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
>, so perhaps it should move there? This is  
> still a
> dependency of anyway, and it itself doesn't  
> appear to
> depend on zope.formlib.

Nice idea. I'll look into it.

>'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* package and we'd
> like to get rid of those in the toolkit. What to do with it?

Yours sincerely,
Michael Howitz · · software developer
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to