On 17 April 2012 02:44, Érico Andrei <[email protected]> wrote: > Hello guys, > > I would like to present you collective.grok, a package bringing Grok and > Martian to Generic Setup and i18n registrations in Plone.
Cool ;) Could we please find a better name? This is hugely confusing when there is 'grok' and 'five.grok' already, and this covers only a very specific (but two unrelated?) use cases. We have been using plone.directives.* as a namespace before. Could that work? > Right now the package is in version 1.0a2 (released on Pypi) and the code > and issue tracker are available at GitHub > (https://github.com/collective/collective.grok) > > So, a tipical zcml file to handle profiles registration like this: > > <configure > xmlns="http://namespaces.zope.org/zope" > xmlns:genericsetup="http://namespaces.zope.org/genericsetup" > xmlns:i18n="http://namespaces.zope.org/i18n" > i18n_domain="collective.person"> > > <genericsetup:registerProfile > name="default" > title="collective.person: Install" > directory="profiles/default" > description="collective.person" > provides="Products.GenericSetup.interfaces.EXTENSION" > i18n:attributes="title; description" > /> > > <genericsetup:registerProfile > name="uninstall" > title="Uninstall collective.person" > directory="profiles/uninstall" > description="Uninstall collective.person" > provides="Products.GenericSetup.interfaces.EXTENSION" > i18n:attributes="title; description" > /> > > > <genericsetup:importStep > name="collective.person-upgrades" > title="collective.person: Upgrades" > description="Run available upgrades for this package." > handler="collective.person.setuphandlers.run_upgrades"> > </genericsetup:importStep> > > <include package=".upgrades" /> > > <genericsetup:importStep > name="collective.person" > title="Person Catalog Import Step" > description="" > handler="collective.person.exportimport.catalog.importPersonCatalog"> > <depends name="toolset"/> > </genericsetup:importStep> > > <genericsetup:exportStep > name="collective.person" > title="Person Catalog Export Step" > description="" > handler="collective.person.exportimport.catalog.exportPersonCatalog" > /> > > </configure> > > > Would be replaced by functions and decorators in Python files: > > from collective.grok import gs > > gs.profile(name=u'default', > title=u'collective.person: Install', > description=u'collective.person', > directory='profiles/default') > > # Uninstall Profile > gs.profile(name=u'uninstall', > title=u'Uninstall collective.person', > description=u'collective.person', > directory='profiles/uninstall') > > @gs.importstep(name=u'collective.person-upgrades', > title='collective.person: Upgrades', > description='Run available upgrades for this package.', > dependencies=[]) > def run_upgrades(context): > pass > > @gs.importstep(name=u'collective.person', > title='Person Catalog Import Step', > description='', > dependencies=['toolset', ]) > def importPersonCatalog(context): > pass > > > @gs.exportstep(name=u'collective.person', > title='Person Catalog Export Step', > description='',) > def exportPersonCatalog(context): > pass > > > In the near future, collective.grok is planned to support also: > > * Portlets registration > > * Transmogrifier > > * Dexterity Behaviors (I'm not sure about this one, should be somewhere > else...) I'm against trying to create these types of 'mega packages' that cover lots of functionality. What do we do if (when) we deprecate portlets, for instance? And is everyone going to want transmogrifier as a dependency? Better to have specific packages, like plone.directives.form and plone.directives.dexterity. Martin _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
