[Product-Developers] Introducing collective.grok

[David Glick]

On 4/16/12 11:41 PM, Martin Aspeli wrote:
> On 17 April 2012 02:44, Érico Andrei<erico at simplesconsultoria.com.br>  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
 davidglick at groundwire.org
 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