This package provides base classes of basic component types for the
Zope Component Architecture, as well as means for configuring and
registering them directly in Python (without ZCML).
.. contents::
How to set up ``grokcore.component``
====================================
In the following we assume you're writing or extending an application
that does bootstrap configuration using ZCML. There's always a single
ZCML file that is executed when the application is started, which then
includes everything else. Let's assume this file is called
``site.zcml`` (that's what it's called in Zope), so that file is what
we'll be editing.
In order to register the components that you wrote using the base
classes and directives available from ``grokcore.component``, we'll
use the ``<grok:grok />`` ZCML directive. But before we can use it,
we need to make sure it's available to the ZCML machinery. We do this
by including the meta configuration from ``grokcore.component``::
<include package="grokcore.component" file="meta.zcml" />
Put this line somewhere to the top of ``site.zcml``, next to other
meta configuration includes. Now, further down the line, we can tell
the machinery in ``grokcore.component`` to register all components in
your package (let's say it's called ``helloworld``)::
<grok:grok package="helloworld" />
To sum up, your ``site.zcml`` file should look like something like this::
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:grok="http://namespaces.zope.org/grok">
<!-- do the meta configuration to make the ZCML directives available -->
<include package="zope.foobar" file="meta.zcml" />
<include package="zope.frobnaz" file="meta.zcml" />
<include package="grokcore.component" file="meta.zcml" />
<!-- now load the configuration of packages that we depend on -->
<include package="zope.barfoo" />
<include package="zope.somethingorother" />
<!-- finally load my components which are based on grokcore.component -->
<grok:grok package="helloworld" />
</configure>
There is an optional ``exclude`` on the `grok` directive. It allows to specify
names of packages or modules that if encountered won't be grokked. These
names might contain unix shell-style wildcards.
`implementer()` versus `implements()`
=====================================
Note how the Python 3 compatibility brings a change in how the
`grokcore.component.implements()` *directive* works. When using this directive
you now have to make sure the component is grokkked, to have the underlying
mechanism to take effect.
Alternatively you could start to use the `grokcore.component.implementer()`
*class decorator* instead. This will do the same thing, but does not require
your component to be grokkked and still have your component declare it
implements the given interface.
Examples
========
Adapter
-------
Here's a simple adapter that may be useful in Zope. It extracts the
languages that a user prefers from the request::
import grokcore.component
from zope.publisher.interfaces.browser import IBrowserRequest
from zope.i18n.interfaces import IUserPreferredLanguages
class CookieLanguage(grokcore.component.Adapter):
"""Extract the preferred language from a cookie"""
grokcore.component.context(IBrowserRequest)
grokcore.component.implements(IUserPreferredLanguages)
# No need to implement __init__, it's already provided by the base class.
def getPreferredLanguages(self):
# This an adapter for the request, so self.context is the request.
request = self.context
# Extract the preferred language from a cookie:
lang = request.cookies.get('language', 'en')
# According to IUserPreferredLanguages, we must return a list.
return [lang]
Multi-adapter
-------------
Here's a multi-adapter that functions as a content provider as known
from the ``zope.contentprovider`` library. Content providers are
components that return snippets of HTML. They're multi-adapters for
the content object (model), the request and the view that they're
supposed to be a part of::
import grokcore.component
from zope.publisher.interfaces.browser import IBrowserRequest
from zope.publisher.interfaces.browser import IBrowserPage
from zope.contentprovider.interfaces import IContentProvider
class HelloWorldProvider(grokcore.component.MultiAdapter):
"""Display Hello World!"""
grokcore.component.adapts(Interface, IBrowserRequest, IBrowserPage)
grokcore.component.implements(IContentProvider)
def __init__(self, context, request, view):
pass
def update(self):
pass
def render(self):
return u'<p>Hello World!</p>'
Global utility
--------------
Here's a simple named utility, again from the Zope world. It's a
translation domain. In other words, it contains translations of user
messages and is invoked when the i18n machinery needs to translate
something::
import grokcore.component
from zope.i18n.interfaces import ITranslationDomain
class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
grokcore.component.implements(ITranslationDomain)
grokcore.component.name('helloworld')
domain = u'helloworld'
def translate(self, msgid, mapping=None, context=None,
target_language=None, default=None):
if target_language is None:
preferred = IUserPreferredLanguages(context)
target_language = preferred.getPreferredLanguages()[0]
translations = {'de': u'Hallo Welt',
'nl': u'Hallo Wereld'}
return translations.get(target_language, u'Hello World')
Of course, it's silly to implement your own translation domain utility
if there are already implementations available in ``zope.i18n`` (one
that reads translations from a GNU gettext message catalog and a
simple implementation for tests). Let's try to reuse that
implementation and register an instance::
import grokcore.component
from zope.i18n.interfaces import ITranslationDomain
from zope.i18n.simpletranslationdomain import SimpleTranslationDomain
messages = {('de', u'Hello World'): u'Hallo Welt',
('nl', u'Hello World'): u'Hallo Wereld'}
helloworld_domain = SimpleTranslationDomain(u'helloworld', messages)
grokcore.component.global_utility(helloworld_domain,
provides=ITranslationDomain,
name='helloworld',
direct=True)
Global adapter
--------------
Sometimes, you may have an object that should be registered as an adapter
factory. It may have come from some other framework that configured that
adapter for you, say, or you may have a class that you instantiate many
times to get different variations on a particular adapter factory. In these
cases, subclassing grokcore.component.Adapter or MultiAdapter is not
possible. Instead, you can use the global_adapter() directive. Here is an
example drawing on the ``z3c.form`` library, which provides an adapter factory
factory for named widget attributes::
import zope.interface
import zope.schema
import grokcore.component
import z3c.form.widget import ComputedWidgetAttribute
class ISchema(Interface):
"""This schema will be used to power a z3c.form form"""
field = zope.schema.TextLine(title=u"Sample field")
...
label_override = z3c.form.widget.StaticWidgetAttribute(
u"Override label", field=ISchema['field'])
grokcore.component.global_adapter(label_override, name=u"label")
In the example above, the provided and adapted interfaces are deduced from the
object returned by the ``StaticWidgetAttribute`` factory. The full syntax
for global_adapter is::
global_adapter(factory, (IAdapted1, IAdapted2,), IProvided, name=u"name")
The factory must be a callable (the adapter factory). Adapted interfaces are
given as a tuple. You may use a single interface instead of a one-element
tuple for single adapters. The provided interface is given as shown. The name
defaults to u"" (an unnamed adapter).
Handling events
---------------
Here we see an event handler much like it occurs within Zope itself. It
subscribes to the modified event for all annotatable objects (in other words,
objects that can have metadata associated with them). When invoked, it updates
the Dublin Core 'Modified' property accordingly::
import datetime
import grokcore.component
from zope.annotation.interfaces import IAnnotatable
from zope.lifecycleevent.interfaces import IObjectModifiedEvent
from zope.dublincore.interfaces import IZopeDublinCore
@grokcore.component.subscribe(IAnnotatable, IObjectModifiedEvent)
def updateDublinCoreAfterModification(obj, event):
"""Updated the Dublin Core 'Modified' property when a modified
event is sent for an object."""
IZopeDublinCore(obj).modified = datetime.datetime.utcnow()
Subscriptions
-------------
Subscriptions look similar to Adapter, however, unlike regular adapters,
subscription adapters are used when we want all of the adapters that adapt an
object to a particular adapter.
Analogous to MultiAdapter, there is a MultiSubscription component that "adapts"
multiple objects.
Changes
=======
4.1 (2023-03-21)
----------------
- Upgrade to support ``zope.interface >= 6.0`` by no longer importing removed
functions:
+ ``classProvides``
+ ``implementsOnly``
4.0 (2023-02-17)
----------------
- Add support for Python 3.10, 3.11.
- Drop support for Python 2.7, 3.5, 3.6.
3.2.0 (2021-03-22)
------------------
- Add support for Python 3.7 up to 3.9.
- Update to ``zope.component >= 5``.
- Drop support for Python 3.4.
3.1 (2018-05-09)
----------------
- Expose ``martian.ignore`` through our API.
3.0.2 (2018-01-17)
------------------
- Replace the use of `grok.implements()` with the `@grok.implementer()`
directive throughout.
3.0.1 (2018-01-12)
------------------
- Rearrange tests such that Travis CI can pick up all functional tests too.
3.0 (2017-10-19)
----------------
- Add support for Python 3.5, 3.6, PyPy2 and PyPy3.
- Drop support for Python 2.6 and 3.3.
2.7 (2016-02-16)
----------------
- Add ability to exclude more than one module or package using
``<grok:grok exclude="<names>" />`` and allow to use unix shell-style
wildcards within.
2.6.1 (2016-01-29)
------------------
- Make grokcore.component.implementer compatible with
zope.interface.implementer by allowing doing the adapter magic when
used on functions.
2.6 (2015-05-12)
----------------
- Compatibility for python 3l
- Python 3 doesn't support the directive ``zope.interface.implements``
any more and is required to use the ``@implementer`` class decorator instead.
This version of grokcore.components provides its own
``grokcore.component.implements`` directive for both Python 2 and 3.
So this directive can still be used with the help of a grokker.
If you use grokcore.components >= 2.6 the new implementation will be used
while earlier versions used zope.interface.implements.
2.5 (2012-05-01)
----------------
- Introduce provideUtility, providerAdapter, provideSubscriptionAdapter,
provideHandler and provideInterface in grokcore.component. These by default
delegate the registration of components to the global site manager like
was done before, but provide the possibility for custom registries for the
grokked components.
- Fix the `global_adapter` to properly use information annotated by
``grok.adapter``, and using the IContext object if it was not
specified. (Fix Launchpad issue #960097).
- Add a ``key`` option to ``sort_components`` that behave like ``key``
options available on standard Python sort methods.
2.4 (2011-04-27)
----------------
- Fix the `global_adapter` directive implementation to accept an explicit
"empty" name for nameless adapter registrations (as it used to be that
providing an empty name in the registration would actually result in
registering a named adapter in case the factory has a `grok.name`).
2.3 (2011-02-14)
----------------
- Implement the generic (Multi)Subscriptions components.
2.2 (2010-11-03)
----------------
- The default values computation for the context directive and the provides
directive is now defined in the directives themselves. This means that where
the values for these directives is being retrieved, the "default_context"
function does not need to be passed along anymore for general cases.
Analogous to this, when getting values for the provides directive the
"default_provides" function does not need to be passed along in the general
case.
2.1 (2010-11-01)
----------------
* Made package comply to zope.org repository policy.
* Moved directives 'order' from grokcore.viewlet and 'path' from
grokcore.view to this very package.
* Tiny dependency adjustment: moved zope.event to test dependencies.
* Port from 1.x branch exclude parameter to the Grok ZCML directive.
* Port from 1.x branch the ignore of testing.py modules.
2.0 (2009-09-16)
----------------
* Use a newer version of Martian that has better support for
inheritance. This is demonstrated in ``tests/inherit``.
* The ``ContextGrokker`` and the ``scan.py`` module have gone away
thanks the newer Martian.
* Directive implementations (in their factory method) should *not*
bind directives. Directive binding cannot take place at import time,
but only at grok time. Binding directives during import time (when
directives are executed) can lead to change problems. (we noticed
this during our refactoring to use the new Martian).
* Use 1.0b1 versions.cfg in Grok's release info instead of a local
copy; a local copy for all grokcore packages is just too hard to
maintain.
1.7 (2009-06-01)
----------------
* Add missing provider, global_adapter, implementsOnly, classProvides() to
the module interface so that they are included in __all__
1.6 (2009-04-10)
----------------
* Add convenience imports for implementsOnly() and classProvides() class
declarations form zope.interface.
* Add support for registering global adapters at module level::
grok.global_adapter(factory, (IAdapted1, IAdapted2,), IProvided, name=u"name")
Only 'factory' is required. If only a single interface is adapted, the
second argument may be a single interface instead of a tuple. If the
component has declared adapted/provided interfaces, the second and third
arguments may be omitted.
* Add support for an @provider decorator to let a function directly provide
an interface::
@grok.provider(IFoo, IBar)
def some_function():
...
This is equivalent to doing alsoProvides(some_function, IFoo, IBar).
* Add support for named adapters with the @adapter decorator::
@grok.adapter(IAdaptedOne, IAdaptedTwo, name=u"foo")
def some_function(one, two):
...
1.5.1 (2008-07-28)
------------------
* The ``IGrokcoreComponentAPI`` interface was missing declarations for
the ``title`` and ``description`` directives.
1.5 (2008-07-22)
----------------
* Fix https://bugs.launchpad.net/grok/+bug/242353: grokcore.component
contains old-style test setup. There is no `register_all_tests`
method in grokcore.component.testing anymore. Use z3c.testsetup
instead.
* Allow functions that have been marked with @grok.subscribe also be
registered with ``zope.component.provideHandler()`` manually. This
is useful for unit tests where you may not want to grok a whole
module.
* Document grokcore.component's public API in an interface,
``IGrokcoreComponentAPI``. When you now do::
from grokcore.component import *
only the items documented in that interface will be imported into
your local namespace.
1.4 (2008-06-11)
----------------
* Ported class grokkers to make use of further improvements in Martian.
This requires Martian 0.10.
1.3 (2008-05-14)
----------------
* Ported class grokkers to make use of the new declarative way of
retrieving directive information from a class. This requires
Martian 0.9.6.
1.2.1 (2008-05-04)
------------------
* Upgrade to Martian 0.9.5, which has a slight change in the signature of
``scan_for_classes``.
* Remove an unnecessary import ``methods_from_class`` from
``grokcore.component.scan``.
1.2 (2008-05-04)
----------------
* Ported directives to Martian's new directive implementation. As a
result, nearly all helper functions that were available from
``grokcore.component.util`` have been removed. The functionality is
mostly available from the directives themselves now.
* The ``baseclass`` directive has been moved to Martian.
* The ``order`` directive and its helper functions have been moved
back to Grok, as it was of no general use, but very specific to
viewlets.
1.1 (2008-05-03)
----------------
* ``determine_module_component`` now looks for classes that implement
a certain interface (such as ``IContext``), instead of taking a list
of classes. If looking for ``IContext``, it still will find
``Context`` subclasses, as these were also made to implement
``IContext``.
* Move the ``public_methods_from_class`` helper function back to Grok,
it isn't used at all in ``grokcore.component``.
1.0.1 (2008-05-02)
------------------
* The grokkers for adapters and global utilities did not use the
correct value for the *provided* interface in the configuration
action discriminator. Because of this, uninformative and
potentially wrong conflict errors would occur, as well as no
conflict where a conflict should have occurred.
* The grokker for the ``global_utility()`` directive did immediate
registrations instead of generating configuration actions.
Therefore it did not provoke ``ConflictErrors`` for conflicting
registrations.
* Improved documentation
1.0 (2008-05-01)
----------------
* Created ``grokcore.component`` in March 2008 by factoring basic
component base classes and their directives and grokkers out of
Grok.
Raw data
{
"_id": null,
"home_page": "https://github.com/zopefoundation/grokcore.component",
"name": "grokcore.component",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": "",
"keywords": "",
"author": "Grok Team",
"author_email": "zope-dev@zope.dev",
"download_url": "https://files.pythonhosted.org/packages/ae/4e/997c1b295e92c4946f43dd625e1752645fa6b7a17b2e1090c119ea4e6ed6/grokcore.component-4.1.tar.gz",
"platform": null,
"description": "This package provides base classes of basic component types for the\nZope Component Architecture, as well as means for configuring and\nregistering them directly in Python (without ZCML).\n\n.. contents::\n\nHow to set up ``grokcore.component``\n====================================\n\nIn the following we assume you're writing or extending an application\nthat does bootstrap configuration using ZCML. There's always a single\nZCML file that is executed when the application is started, which then\nincludes everything else. Let's assume this file is called\n``site.zcml`` (that's what it's called in Zope), so that file is what\nwe'll be editing.\n\nIn order to register the components that you wrote using the base\nclasses and directives available from ``grokcore.component``, we'll\nuse the ``<grok:grok />`` ZCML directive. But before we can use it,\nwe need to make sure it's available to the ZCML machinery. We do this\nby including the meta configuration from ``grokcore.component``::\n\n <include package=\"grokcore.component\" file=\"meta.zcml\" />\n\nPut this line somewhere to the top of ``site.zcml``, next to other\nmeta configuration includes. Now, further down the line, we can tell\nthe machinery in ``grokcore.component`` to register all components in\nyour package (let's say it's called ``helloworld``)::\n\n <grok:grok package=\"helloworld\" />\n\nTo sum up, your ``site.zcml`` file should look like something like this::\n\n <configure\n xmlns=\"http://namespaces.zope.org/zope\"\n xmlns:grok=\"http://namespaces.zope.org/grok\">\n\n <!-- do the meta configuration to make the ZCML directives available -->\n <include package=\"zope.foobar\" file=\"meta.zcml\" />\n <include package=\"zope.frobnaz\" file=\"meta.zcml\" />\n <include package=\"grokcore.component\" file=\"meta.zcml\" />\n\n <!-- now load the configuration of packages that we depend on -->\n <include package=\"zope.barfoo\" />\n <include package=\"zope.somethingorother\" />\n\n <!-- finally load my components which are based on grokcore.component -->\n <grok:grok package=\"helloworld\" />\n\n </configure>\n\nThere is an optional ``exclude`` on the `grok` directive. It allows to specify\nnames of packages or modules that if encountered won't be grokked. These\nnames might contain unix shell-style wildcards.\n\n`implementer()` versus `implements()`\n=====================================\n\nNote how the Python 3 compatibility brings a change in how the\n`grokcore.component.implements()` *directive* works. When using this directive\nyou now have to make sure the component is grokkked, to have the underlying\nmechanism to take effect.\n\nAlternatively you could start to use the `grokcore.component.implementer()`\n*class decorator* instead. This will do the same thing, but does not require\nyour component to be grokkked and still have your component declare it\nimplements the given interface.\n\nExamples\n========\n\nAdapter\n-------\n\nHere's a simple adapter that may be useful in Zope. It extracts the\nlanguages that a user prefers from the request::\n\n import grokcore.component\n from zope.publisher.interfaces.browser import IBrowserRequest\n from zope.i18n.interfaces import IUserPreferredLanguages\n\n class CookieLanguage(grokcore.component.Adapter):\n \"\"\"Extract the preferred language from a cookie\"\"\"\n grokcore.component.context(IBrowserRequest)\n grokcore.component.implements(IUserPreferredLanguages)\n\n # No need to implement __init__, it's already provided by the base class.\n\n def getPreferredLanguages(self):\n # This an adapter for the request, so self.context is the request.\n request = self.context\n\n # Extract the preferred language from a cookie:\n lang = request.cookies.get('language', 'en')\n\n # According to IUserPreferredLanguages, we must return a list.\n return [lang]\n\nMulti-adapter\n-------------\n\nHere's a multi-adapter that functions as a content provider as known\nfrom the ``zope.contentprovider`` library. Content providers are\ncomponents that return snippets of HTML. They're multi-adapters for\nthe content object (model), the request and the view that they're\nsupposed to be a part of::\n\n import grokcore.component\n from zope.publisher.interfaces.browser import IBrowserRequest\n from zope.publisher.interfaces.browser import IBrowserPage\n from zope.contentprovider.interfaces import IContentProvider\n\n class HelloWorldProvider(grokcore.component.MultiAdapter):\n \"\"\"Display Hello World!\"\"\"\n grokcore.component.adapts(Interface, IBrowserRequest, IBrowserPage)\n grokcore.component.implements(IContentProvider)\n\n def __init__(self, context, request, view):\n pass\n\n def update(self):\n pass\n\n def render(self):\n return u'<p>Hello World!</p>'\n\n\nGlobal utility\n--------------\n\nHere's a simple named utility, again from the Zope world. It's a\ntranslation domain. In other words, it contains translations of user\nmessages and is invoked when the i18n machinery needs to translate\nsomething::\n\n import grokcore.component\n from zope.i18n.interfaces import ITranslationDomain\n\n class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):\n grokcore.component.implements(ITranslationDomain)\n grokcore.component.name('helloworld')\n\n domain = u'helloworld'\n\n def translate(self, msgid, mapping=None, context=None,\n target_language=None, default=None):\n if target_language is None:\n preferred = IUserPreferredLanguages(context)\n target_language = preferred.getPreferredLanguages()[0]\n\n translations = {'de': u'Hallo Welt',\n 'nl': u'Hallo Wereld'}\n return translations.get(target_language, u'Hello World')\n\nOf course, it's silly to implement your own translation domain utility\nif there are already implementations available in ``zope.i18n`` (one\nthat reads translations from a GNU gettext message catalog and a\nsimple implementation for tests). Let's try to reuse that\nimplementation and register an instance::\n\n import grokcore.component\n from zope.i18n.interfaces import ITranslationDomain\n from zope.i18n.simpletranslationdomain import SimpleTranslationDomain\n\n messages = {('de', u'Hello World'): u'Hallo Welt',\n ('nl', u'Hello World'): u'Hallo Wereld'}\n helloworld_domain = SimpleTranslationDomain(u'helloworld', messages)\n\n grokcore.component.global_utility(helloworld_domain,\n provides=ITranslationDomain,\n name='helloworld',\n direct=True)\n\nGlobal adapter\n--------------\n\nSometimes, you may have an object that should be registered as an adapter\nfactory. It may have come from some other framework that configured that\nadapter for you, say, or you may have a class that you instantiate many\ntimes to get different variations on a particular adapter factory. In these\ncases, subclassing grokcore.component.Adapter or MultiAdapter is not\npossible. Instead, you can use the global_adapter() directive. Here is an\nexample drawing on the ``z3c.form`` library, which provides an adapter factory\nfactory for named widget attributes::\n\n import zope.interface\n import zope.schema\n import grokcore.component\n import z3c.form.widget import ComputedWidgetAttribute\n\n class ISchema(Interface):\n \"\"\"This schema will be used to power a z3c.form form\"\"\"\n\n field = zope.schema.TextLine(title=u\"Sample field\")\n\n ...\n\n label_override = z3c.form.widget.StaticWidgetAttribute(\n u\"Override label\", field=ISchema['field'])\n\n grokcore.component.global_adapter(label_override, name=u\"label\")\n\nIn the example above, the provided and adapted interfaces are deduced from the\nobject returned by the ``StaticWidgetAttribute`` factory. The full syntax\nfor global_adapter is::\n\n global_adapter(factory, (IAdapted1, IAdapted2,), IProvided, name=u\"name\")\n\nThe factory must be a callable (the adapter factory). Adapted interfaces are\ngiven as a tuple. You may use a single interface instead of a one-element\ntuple for single adapters. The provided interface is given as shown. The name\ndefaults to u\"\" (an unnamed adapter).\n\nHandling events\n---------------\n\nHere we see an event handler much like it occurs within Zope itself. It\nsubscribes to the modified event for all annotatable objects (in other words,\nobjects that can have metadata associated with them). When invoked, it updates\nthe Dublin Core 'Modified' property accordingly::\n\n import datetime\n import grokcore.component\n from zope.annotation.interfaces import IAnnotatable\n from zope.lifecycleevent.interfaces import IObjectModifiedEvent\n from zope.dublincore.interfaces import IZopeDublinCore\n\n @grokcore.component.subscribe(IAnnotatable, IObjectModifiedEvent)\n def updateDublinCoreAfterModification(obj, event):\n \"\"\"Updated the Dublin Core 'Modified' property when a modified\n event is sent for an object.\"\"\"\n IZopeDublinCore(obj).modified = datetime.datetime.utcnow()\n\nSubscriptions\n-------------\n\nSubscriptions look similar to Adapter, however, unlike regular adapters,\nsubscription adapters are used when we want all of the adapters that adapt an\nobject to a particular adapter.\n\nAnalogous to MultiAdapter, there is a MultiSubscription component that \"adapts\"\nmultiple objects.\n\nChanges\n=======\n\n4.1 (2023-03-21)\n----------------\n\n- Upgrade to support ``zope.interface >= 6.0`` by no longer importing removed\n functions:\n\n + ``classProvides``\n + ``implementsOnly``\n\n\n4.0 (2023-02-17)\n----------------\n\n- Add support for Python 3.10, 3.11.\n\n- Drop support for Python 2.7, 3.5, 3.6.\n\n\n3.2.0 (2021-03-22)\n------------------\n\n- Add support for Python 3.7 up to 3.9.\n\n- Update to ``zope.component >= 5``.\n\n- Drop support for Python 3.4.\n\n\n3.1 (2018-05-09)\n----------------\n\n- Expose ``martian.ignore`` through our API.\n\n3.0.2 (2018-01-17)\n------------------\n\n- Replace the use of `grok.implements()` with the `@grok.implementer()`\n directive throughout.\n\n3.0.1 (2018-01-12)\n------------------\n\n- Rearrange tests such that Travis CI can pick up all functional tests too.\n\n3.0 (2017-10-19)\n----------------\n\n- Add support for Python 3.5, 3.6, PyPy2 and PyPy3.\n\n- Drop support for Python 2.6 and 3.3.\n\n2.7 (2016-02-16)\n----------------\n\n- Add ability to exclude more than one module or package using\n ``<grok:grok exclude=\"<names>\" />`` and allow to use unix shell-style\n wildcards within.\n\n2.6.1 (2016-01-29)\n------------------\n\n- Make grokcore.component.implementer compatible with\n zope.interface.implementer by allowing doing the adapter magic when\n used on functions.\n\n2.6 (2015-05-12)\n----------------\n\n- Compatibility for python 3l\n\n- Python 3 doesn't support the directive ``zope.interface.implements``\n any more and is required to use the ``@implementer`` class decorator instead.\n This version of grokcore.components provides its own\n ``grokcore.component.implements`` directive for both Python 2 and 3.\n So this directive can still be used with the help of a grokker.\n If you use grokcore.components >= 2.6 the new implementation will be used\n while earlier versions used zope.interface.implements.\n\n2.5 (2012-05-01)\n----------------\n\n- Introduce provideUtility, providerAdapter, provideSubscriptionAdapter,\n provideHandler and provideInterface in grokcore.component. These by default\n delegate the registration of components to the global site manager like\n was done before, but provide the possibility for custom registries for the\n grokked components.\n\n- Fix the `global_adapter` to properly use information annotated by\n ``grok.adapter``, and using the IContext object if it was not\n specified. (Fix Launchpad issue #960097).\n\n- Add a ``key`` option to ``sort_components`` that behave like ``key``\n options available on standard Python sort methods.\n\n2.4 (2011-04-27)\n----------------\n\n- Fix the `global_adapter` directive implementation to accept an explicit\n \"empty\" name for nameless adapter registrations (as it used to be that\n providing an empty name in the registration would actually result in\n registering a named adapter in case the factory has a `grok.name`).\n\n2.3 (2011-02-14)\n----------------\n\n- Implement the generic (Multi)Subscriptions components.\n\n2.2 (2010-11-03)\n----------------\n\n- The default values computation for the context directive and the provides\n directive is now defined in the directives themselves. This means that where\n the values for these directives is being retrieved, the \"default_context\"\n function does not need to be passed along anymore for general cases.\n\n Analogous to this, when getting values for the provides directive the\n \"default_provides\" function does not need to be passed along in the general\n case.\n\n2.1 (2010-11-01)\n----------------\n\n* Made package comply to zope.org repository policy.\n\n* Moved directives 'order' from grokcore.viewlet and 'path' from\n grokcore.view to this very package.\n\n* Tiny dependency adjustment: moved zope.event to test dependencies.\n\n* Port from 1.x branch exclude parameter to the Grok ZCML directive.\n\n* Port from 1.x branch the ignore of testing.py modules.\n\n2.0 (2009-09-16)\n----------------\n\n* Use a newer version of Martian that has better support for\n inheritance. This is demonstrated in ``tests/inherit``.\n\n* The ``ContextGrokker`` and the ``scan.py`` module have gone away\n thanks the newer Martian.\n\n* Directive implementations (in their factory method) should *not*\n bind directives. Directive binding cannot take place at import time,\n but only at grok time. Binding directives during import time (when\n directives are executed) can lead to change problems. (we noticed\n this during our refactoring to use the new Martian).\n\n* Use 1.0b1 versions.cfg in Grok's release info instead of a local\n copy; a local copy for all grokcore packages is just too hard to\n maintain.\n\n1.7 (2009-06-01)\n----------------\n\n* Add missing provider, global_adapter, implementsOnly, classProvides() to\n the module interface so that they are included in __all__\n\n1.6 (2009-04-10)\n----------------\n\n* Add convenience imports for implementsOnly() and classProvides() class\n declarations form zope.interface.\n\n* Add support for registering global adapters at module level::\n\n grok.global_adapter(factory, (IAdapted1, IAdapted2,), IProvided, name=u\"name\")\n\n Only 'factory' is required. If only a single interface is adapted, the\n second argument may be a single interface instead of a tuple. If the\n component has declared adapted/provided interfaces, the second and third\n arguments may be omitted.\n\n* Add support for an @provider decorator to let a function directly provide\n an interface::\n\n @grok.provider(IFoo, IBar)\n def some_function():\n ...\n\n This is equivalent to doing alsoProvides(some_function, IFoo, IBar).\n\n* Add support for named adapters with the @adapter decorator::\n\n @grok.adapter(IAdaptedOne, IAdaptedTwo, name=u\"foo\")\n def some_function(one, two):\n ...\n\n1.5.1 (2008-07-28)\n------------------\n\n* The ``IGrokcoreComponentAPI`` interface was missing declarations for\n the ``title`` and ``description`` directives.\n\n1.5 (2008-07-22)\n----------------\n\n* Fix https://bugs.launchpad.net/grok/+bug/242353: grokcore.component\n contains old-style test setup. There is no `register_all_tests`\n method in grokcore.component.testing anymore. Use z3c.testsetup\n instead.\n\n* Allow functions that have been marked with @grok.subscribe also be\n registered with ``zope.component.provideHandler()`` manually. This\n is useful for unit tests where you may not want to grok a whole\n module.\n\n* Document grokcore.component's public API in an interface,\n ``IGrokcoreComponentAPI``. When you now do::\n\n from grokcore.component import *\n\n only the items documented in that interface will be imported into\n your local namespace.\n\n1.4 (2008-06-11)\n----------------\n\n* Ported class grokkers to make use of further improvements in Martian.\n This requires Martian 0.10.\n\n1.3 (2008-05-14)\n----------------\n\n* Ported class grokkers to make use of the new declarative way of\n retrieving directive information from a class. This requires\n Martian 0.9.6.\n\n1.2.1 (2008-05-04)\n------------------\n\n* Upgrade to Martian 0.9.5, which has a slight change in the signature of\n ``scan_for_classes``.\n\n* Remove an unnecessary import ``methods_from_class`` from\n ``grokcore.component.scan``.\n\n1.2 (2008-05-04)\n----------------\n\n* Ported directives to Martian's new directive implementation. As a\n result, nearly all helper functions that were available from\n ``grokcore.component.util`` have been removed. The functionality is\n mostly available from the directives themselves now.\n\n* The ``baseclass`` directive has been moved to Martian.\n\n* The ``order`` directive and its helper functions have been moved\n back to Grok, as it was of no general use, but very specific to\n viewlets.\n\n1.1 (2008-05-03)\n----------------\n\n* ``determine_module_component`` now looks for classes that implement\n a certain interface (such as ``IContext``), instead of taking a list\n of classes. If looking for ``IContext``, it still will find\n ``Context`` subclasses, as these were also made to implement\n ``IContext``.\n\n* Move the ``public_methods_from_class`` helper function back to Grok,\n it isn't used at all in ``grokcore.component``.\n\n1.0.1 (2008-05-02)\n------------------\n\n* The grokkers for adapters and global utilities did not use the\n correct value for the *provided* interface in the configuration\n action discriminator. Because of this, uninformative and\n potentially wrong conflict errors would occur, as well as no\n conflict where a conflict should have occurred.\n\n* The grokker for the ``global_utility()`` directive did immediate\n registrations instead of generating configuration actions.\n Therefore it did not provoke ``ConflictErrors`` for conflicting\n registrations.\n\n* Improved documentation\n\n1.0 (2008-05-01)\n----------------\n\n* Created ``grokcore.component`` in March 2008 by factoring basic\n component base classes and their directives and grokkers out of\n Grok.\n",
"bugtrack_url": null,
"license": "ZPL",
"summary": "Grok-like configuration for basic components (adapters, utilities, subscribers)",
"version": "4.1",
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "c07a7f6d7d3090213afb2ec16470cdf2c83a391989cbc3b4aa297e2fb50d2631",
"md5": "a702b12f08680ef4bdeb0f9eb09346cd",
"sha256": "ece8ad0d364a23809a4124ddf3c2a405fb92c4a3ebb7a85e9fe189b047678c0d"
},
"downloads": -1,
"filename": "grokcore.component-4.1-py3-none-any.whl",
"has_sig": false,
"md5_digest": "a702b12f08680ef4bdeb0f9eb09346cd",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7",
"size": 77553,
"upload_time": "2023-03-21T16:30:46",
"upload_time_iso_8601": "2023-03-21T16:30:46.167834Z",
"url": "https://files.pythonhosted.org/packages/c0/7a/7f6d7d3090213afb2ec16470cdf2c83a391989cbc3b4aa297e2fb50d2631/grokcore.component-4.1-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "ae4e997c1b295e92c4946f43dd625e1752645fa6b7a17b2e1090c119ea4e6ed6",
"md5": "0129738dc522928fdddfaf2aad9ad0e4",
"sha256": "e4b19b1460b5aac0f2ab44e1cecb50cb3330e995e39e595189e16d60024ea53a"
},
"downloads": -1,
"filename": "grokcore.component-4.1.tar.gz",
"has_sig": false,
"md5_digest": "0129738dc522928fdddfaf2aad9ad0e4",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 49935,
"upload_time": "2023-03-21T16:30:48",
"upload_time_iso_8601": "2023-03-21T16:30:48.244374Z",
"url": "https://files.pythonhosted.org/packages/ae/4e/997c1b295e92c4946f43dd625e1752645fa6b7a17b2e1090c119ea4e6ed6/grokcore.component-4.1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-03-21 16:30:48",
"github": true,
"gitlab": false,
"bitbucket": false,
"github_user": "zopefoundation",
"github_project": "grokcore.component",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"tox": true,
"lcname": "grokcore.component"
}
JSON
