Tres Seaver wrote:
Note that the extension author's convenience was not highest in priority
in the design, which tries to make the integrators job easier.
Extension authors have to be extremely cautious, and may need to "clone"
steps (in the absence of dependencies).
[sorry if this may come out as OT but somehow I'm getting lost here]
Even for the integrator it might be advantageous if add-ons could
And it doesn't stop with Plone. Some things only start there ;-)
Let me illustrate this by way of example:
I provide an add-on for convenient handling of bibliographic data
in Plone (CMFBibliographAT; some of you may know it even).
It uses a specific field and widget (for handling the author lists)
that I provide via ATExtensions (because I think its generic enough
to be useful in its own right).
Now, when moving CMFBib to GS-based install I went for the "clone"
way (aka included ATExtensions' profile within CMFBib's profile - after
all I'm the author of both and I take it as my responsibility to take
care of the redundancy as things evolve further) so you could say
that's no big deal.
But, there are further add-ons by other people based on CMFBib,
e.g., ATBiblioStyles, ATBiblioList, ATBiblioTopic, ...
which all depend on CMFBib.
Previously it was no problem for any of these products to put
in their install something like (pseudocode of course; qi
is Plone's QuickInstaller):
for p in <dependencies>:
if not qi.isInstalled(p):
And now? What are those add-on authors (e.g. David Convent for
ATBiblioStyles or Mike Gabriel for ATBiblioTopic) supposed to do?
Include the ATExtensions and CMFBib profiles in their products
as well? Leave them out and explain in their README (which those
who should never read) that they have to load the other profiles
first? Is that making the integrators life easier?
I guess I just don't see what's wrong with supporting dependencies.
And to stress it as explicitly as I can: I sometimes get the impression
here that some don't realize what stacks get build up when it comes
to real-world applications/deployments. It's a matter of fact, that
many, many applications are not build on plain CMF (or Plone for
that matter) but often include a significant number of add-ons.
E.g., a 'simple' site for a university institute that wants to
have decent publication handling based on what I mentioned above
may be using:
CMF, Plone, Archetypes, ATExtensions, CMFBibliographyAT,
ATBiblioStyles, ATBiblioList, ATBiblioTopic and
maybe the AmazonTool and the PubMedClient
Now don't tell me its overkill to resort to 7(!) add-ons just
to handle bibliographic data on a website. All these packages
provide different yet useful features and it is on purpose that
they are kept apart (in fact I strongly believe I should
break down CMFBib into several packages as it became quite
overgrown by now) but without any decent support for handling
dependencies the *integrators* job won't become easier.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests