done with setuptools
entrypoints and then accessed later by using pkg_resources. Initially
we could just assume cmfish eggs are unzippable.
-w
--
-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org -
- m: 415-710-8975 -
If you don't know where
plone's egg story looks non-existent until next release.
-w
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
howdy lennart!
Right, any tool that now exists must directly map unto a local
utility, and that local utility must also have the same API.
If we in CMF 2.0 feel that most tools should be made into utilities,
we could register the utilities with a name, and use the old tool
name. getToolByName
I remember some discussion of this in the past.
Transitionally, it would be helpful to be able to register local
utilities to a tool name, and then have getToolByName spit out a
deprecation warning and return an appropriate object.
thoughts? comments? does this exist somewhere already?
-w
yuppie wrote:
Hi!
The skin scripts for complex forms in CMF like folder_contents are
currently big monolithic blocks of code. All the values needed in the
template are computed in a predefined order that makes sure expensive
tasks like querying the catalog or listing folder contents are
So, I think 1 and 2 aren't that far apart sometimes.
I agree with this...and I think biggest wins are somewhere in between.
I don't necessarily want a compatibility layer, I just want the
declarative quality of AT to spit out something I could play with more
sensibly using the z3 paradigm.
thanks for starting up this conversation Rocky!
I think these assertions are more or less deadon. The next step is
charting a path for transition. for CMF, zope3 / five provides
lighterweight analogs of AT features. What is currently lacking is a
mapping layer to allow AT users to use the
Namespaces represent communities and their products. Using the CMF
namespace means to create a feature that is only supported in CMF (and
products built on top of the CMF).
without doubt, but these things are not written in stone. Being able to
smoothly transfer appropriate behavior into
Yes, there certainly is a terrible tool proliferation, probably more
painfully in Plone than in the CMF. IMHO it wouldn't be so bad if those
were optional components that provide optional functionality, but most
of them must be there or the site breaks.
exactly. almost every addon has it's
doh...
registerIndexer
for=.interfaces.IMyContent
provides=.interfaces.ISomeCalledInterface
factory=.SomeCallabelAdapter
permission=zope2.Public
/
could be simpler (no need for factory or permission), just:
registerIndexAdapter
for=.interfaces.IMyContent
or even::
adapter
for=.interfaces.IMyContent
provides=Products.CMFCore.CatalogValues
name=some name
/
and then have the catalog look for all such adapters when indexing content.
that seems to make the most sense and requires no extra lingo in the zcml.
-w
11 matches
Mail list logo
