On 4/16/12 11:41 PM, Martin Aspeli wrote:
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.
I wouldn't worry about it too much. We should avoid hard dependencies on
things that some people aren't going to want, but managing a gazillion
packages is a pain.
David
----------
David Glick
Web Developer
[email protected]
206.286.1235x32
GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to
Groundwire
on this community-wide day of giving.
http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
