El 6 Aug 2008, a las 17:17 , Roger Ineichen escribió:
I'm +1 on zc.configuration.
z3c.unconfigure, however, will contain zope.component
specific code to "unconfigure" subscribers (which currently
have no useful discriminator). So it's a hack to make it work
with existing Zope code out there. If zope.component.zcml
were changed to emit useful actions for <subscriber /> (and
<interface />, too!), we could solely rely on shooting down
actions and the code could find its way into
zope.configuration. That will only help us with future Zope
code, not with existing code out there (which this is for).
Feel free to undertake this :)
That's a good argument but valid for any development or improvment
on existing code/packages.
It's about being pragmatic. We need to this to work on existing code
(Zope 3.3 to be exact). We can't just upgrade zope.configuration.
The bad thing is that we now have 3 packages for one thing
doing right.
It's unfortunate, but things could be worse.
I'm +1 too for a simple zope.configuration package which offers
the API for doing configuration how it should.
What do you think about to release z3c.unconfigure and merge it
to zope.configuration after the release. So we have both options
and a simple setup for the future.
Not forgetting to give <subscriber /> and <interface /> decent
discriminators.
But yes, that sounds like a great idea. Feel free to do it ;). I
probably won't have time to worry about this any time soon. I'm just
trying to fix an issue at hand.
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
