Fred Drake wrote:
On 10/17/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:
Right - but you're building an application, and you're pretty
experienced with Zope. A lot of Plone users just want to install a
plug-in (a product), basically. Before, they just dropped it into a

It sounds like your concerns center around users of a
pluggable/extensible application (like Plone), rather than being
general Zope concerns.  It's certainly reasonable for an application
to want a plugin architecture that works that way.

I'd say it is a general concern of a framework to try to avoid how often you need to repeat yourself. Right now you to use a Zope 3 package you need to do the following things:

* list the egg in your dependencies

* load the ZCML required

* import it in your code

Investigating ways to reduce this sounds like a win from a framework perspective. Getting rid of the separate ZCML step would help as it'd make it more similar to just reusing an arbitrary Python package, making Zope less special in some ways.

> Perhaps the development teams for the applications would be interested
> in getting together and sharing a package that supports a plugin
> architecture that works that way.  That would be a good place to share
> effort without negatively impacting users who need bare-metal Zope or
> the developers of applications that don't have similar
> plugin-management requirements.

Sure, we should always avoid negatively impacting people who want to repeat themselves in many places as they need the control in some places. :) That's a given constraint with the bare Zope 3 libraries we'll need to keep in mind always. The ability to not use this should be present, and I'm fine if the default is not to use this. Systems like Plone and Grok can always turn this on.



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

Reply via email to