Hi Steve,
thank you for your positive feedback.
Do you think that the current syntax is ok as such, or would you like to
change something in it?
To summarize the syntax:
0. packages should have [meta|configure|overrides].py similarly to zcml
(I'm not changing how zope.configuration works, but just adding a new
syntax for it from what we've learned from Grok and Pyramid.)
1. configure.namespaceshortcut.somedirective(*args)
Any normal configuration call. (Namespaceshortcuts are simply
mapped into known namespace using a dict in c.venusianconfig.)
Classes, functions and methods (but not lambdas) can be passed
as arguments, but they are interpreted back to strings for
zope.configuration.
2. with configure(package='...') as subconfigure
subconfigure.namespaceshortcut.somedirective(*args)
Nested directives are implemented with contextmanagers.
3. @configure.namespaceshortcut.directive.[class_|handler|etc](*args)
Directive calls can be used as decorators by adding one more
part into configuration call (e.g. class_ for browser:page,
handler for subscriber, factory for adapter, etc.)
4. import submodule
scan(submodule)
Decorators from other that [meta|configure|overrides].py must be
read with scan (similarly to Pyramid)
Currently, scanning is not recursive and does even prohibit
scanning of subpackages in favor of configure.include(package="...")
I'm still think thinking mainly two things before adopting this to our
team for internal packages:
- scan() should probably be recursive and work for subpackages similarly
to Pyramid and Grok, but it would then compete with
<include package="" />
- should there be a set of predefined shortcuts like
page = configure.browser.page
adapter = configure.adapter
which could be used like directive
or
page_config = configure.browser.page.class_
adapter_config = configure.adapter.factory
which could be used as class/function decorator
Shortcuts would make the configuration to look simpler, but would also
add "magic" and more difficult to mentally "map" the configuration code
back to zcml.
Regards,
Asko
Steve McMahon wrote:
I like this a lot. It allows us to get configuration into Python without
being as magical as grok.
One thing I particularly like: knowledge of zcml would easily map to
this -- and back! That would make it great for teaching.
On Fri, Jan 3, 2014 at 12:17 AM, Asko Soukka <[email protected]
<mailto:[email protected]>> wrote:
Hi,
last year there was (again) a long discussion about pros and cons of
grok-based configuration:
http://plone.293351.n2.nabble.__com/GROK-RULES-I-WANT-IT-MORE-__Was-The-grokless-madness-and-__unable-to-create-a-simple-__form-tt7564217.html
<http://plone.293351.n2.nabble.com/GROK-RULES-I-WANT-IT-MORE-Was-The-grokless-madness-and-unable-to-create-a-simple-form-tt7564217.html>
TL;DR; It seems that Grok will never have feature parity with ZCML,
but it has use cases and we have nothing to replace it.
I've been experimenting with an alternative lately: a venusian-based
configuration library for zope.configuration; All python, minimal
dependencies, uses the same directive code as ZCML (= feature
parity), no conventions - just IDE-friendly Python-based configuration.
I'm not forcing this to anyone. An another way to configure may be
the last thing we need. Yet, I want to try this approach as a
grok-replacement for our (my employer) internal packages during this
spring (we'll have new developers and grok has always been easier to
teach than ZCML). Only for add-on-packages.
So, before spending too much time polishing the code, I'd like to
request for your comments about the configuration syntax, which I've
been tinkering:
https://github.com/datakurre/__collective.venusianconfig/__blob/master/demo/src/__venusianconfigdemo/configure.__py
<https://github.com/datakurre/collective.venusianconfig/blob/master/demo/src/venusianconfigdemo/configure.py>
https://github.com/datakurre/__collective.venusianconfig/__blob/master/demo/src/__venusianconfigdemo/views.py
<https://github.com/datakurre/collective.venusianconfig/blob/master/demo/src/venusianconfigdemo/views.py>
https://github.com/datakurre/__collective.venusianconfig/__blob/master/demo/src/__venusianconfigdemo/adapters.py
<https://github.com/datakurre/collective.venusianconfig/blob/master/demo/src/venusianconfigdemo/adapters.py>
https://github.com/datakurre/__collective.venusianconfig/__blob/master/demo/src/__venusianconfigdemo/portlets/__configure.py
<https://github.com/datakurre/collective.venusianconfig/blob/master/demo/src/venusianconfigdemo/portlets/configure.py>
So, it's not grok. It's a Python-syntax for zope.configuration with
optional support for limited set of decorators (directives with
class, factory or handler).
Venusian-library is used to make all configuration directives lazy:
venusian creates "registration callbacks" during module import, but
those callbacks are only executed when packages is imported by
zope.configuration.
The current catch is that this needs one line in zope.conf (for
monkeypatching zope.configuration) and custom site.zcml (for
z3c.autoinclude also Python-configured packages). These are required
to work around hardcoded zcml-expectations.
Waiting for your comments.
Regards,
Asko
_________________________________________________
Product-Developers mailing list
Product-Developers@lists.__plone.org
<mailto:[email protected]>
https://lists.plone.org/__mailman/listinfo/plone-__product-developers
<https://lists.plone.org/mailman/listinfo/plone-product-developers>
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
