Re: Could it be possible to support configuring with *.cfg instead of *.zcml?

Martin Aspeli wrote:
> For what it's worth the pyramid "scan" approach is inspired by and 
> quite similar to the Martian/grokcore approach. The main difference is 
> that pyramid kicks it all off in Python as you create a config state 
> machine imperatively.

In detail:

1. during each module import, Pyramid's venusian-decorators add 
configuration callbacks into special module-level variable (and 
therefore, just importing modules does anything)

2. finally, during app-configuration, venusian-scan looks up those 
callbacks, and in Pyramid those callbacks execute the actual 
configuration code

My approach with venusian-decorators is to execute venusican-scan for 
each package within zope.configuration so that those callbacks do normal 
zope.configuration-calls similarly to xmlconfig does. So, it's up to 
zope.configuration to figure out the actual directives, configuration 
conflicts, missing parameters, etc.

Regards
Asko

> On Fri, Nov 29, 2013 at 9:26 AM, Simone Orsi <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Hi,
>
>     personally I feel ok with ZCML since is useful
>     for knowing what has been configured from a single file
>     without having to dig around in .py files.
>     I think people started hating ZCML only because it's "zope thing" :)
>
>     Also, as Jens said, people are used to XML conf...
>     It's just a matter of different extensions and namespaces.
>
>     Nevertheless I understand that for some people is an entry barrier.
>     I don't think grok is the alternative. I never liked it :)
>
>     I think that the Pyramid approach would be really good.
>     Using decorators to register routes, views, etc,
>     is really common in python web framework nowadays.
>
>     My $0.02 :)
>
>     S.
>
>
>     On Fri, Nov 29, 2013 at 10:09 AM, Jens W. Klein
>     <jens-/[email protected] <mailto:jens-/[email protected]>> wrote:
>
>         The current zcml approach is not that bad. People coming from
>         outside
>         python projects are used to xml based configuration. So it is
>         not that
>         exotic too.
>
>         I'am not sure if ini-style configuration solves the problem.
>         From my
>         observations theres are two mindsets out in the wild:
>         1) do all configuration in python,
>         2) do it using a configuration file.
>
>         For (1) I think zcml is fine. Adding another configuration
>         language for
>         the same problem does not make it better. It just add
>         confusion and
>         incompatibility.
>
>         For (2) we have grok. But even if I like to use python for
>         configuration
>         I never adopted grok. Theres too much implicit magic in it. I
>         like the
>         way Pyramid solved the problem using python: Explicit, easy to
>         understand and pluggable.
>
>         So in my opinion we should better improve the way for (2) and
>         keep (1)
>         as is - maybe we could document it better (theres always room
>         to improve
>         docs ;) )?
>
>         regards
>         Jensens
>
>         On 2013-11-23 22:42, Asko Soukka wrote:
>         > Ahem, just continuing after accidental send:
>         >
>         > Asko Soukka wrote:
>         >> The benefit would be that add-on developer could write
>         configure.cfg:
>         >>
>         >> [browser:page:uniquepostfix]
>         >> name = hello-world
>         >> for = *
>         >> class = .view.FooBar
>         >> permission = zope2.View
>         >>
>         >> instead of configure.zcml
>         >
>         > <configure
>         >       xmlns="http://namespaces.zope.org/zope"
>         >       xmlns:browser="http://namespaces.zope.org/browser">
>         >
>         > <browser:page
>         >           name="hello-world"
>         >           for="*"
>         >           class=".view.FooBar"
>         >           permission="zope2.View"
>         >           />
>         >
>         > </configure>
>         >
>         > Cfg may not be significantly better than zcml, just not xml.
>         >
>         > What all issues would there be left to be solved?
>         >
>         > At least, cfg would be flatter. I have no idea, where
>         directives inside
>         > directives are really needed, so I don't know can everything be
>         > implemented in cfgs.
>         >
>         > It should not difficult to support zcml:condition, so
>         conditional
>         > sections could be solved into conditional include-directives.
>         >
>         > Cfg-sections would need to be unique, which would require
>         something
>         > dummy after the directive name.
>         >
>         > Do we have any colliding namespaces, which would prevent
>         fixing e.g.
>         > that browser to always mean http://namespaces.zope.org/browser
>         >
>         > Directives ZCMLs are executed in order. Forcing order with
>         cfg would
>         > need something like "require = section:name" (like in puppet).
>         >
>         >> I made a very naive experiment:
>         >>
>         >> https://github.com/datakurre/collective.cfgconfig
>         >
>         > Cheers,
>         > Asko
>         >
>         >
>         ------------------------------------------------------------------------------
>         > Shape the Mobile Experience: Free Subscription
>         > Software experts and developers: Be at the forefront of tech
>         innovation.
>         > Intel(R) Software Adrenaline delivers strategic insight and
>         game-changing
>         > conversations that shape the rapidly evolving mobile
>         landscape. Sign up now.
>         >
>         http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>         <http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk>
>         >
>
>
>         --
>         Klein & Partner KG, member of BlueDynamics Alliance
>
>
>         ------------------------------------------------------------------------------
>         Rapidly troubleshoot problems before they affect your
>         business. Most IT
>         organizations don't have a clear picture of how application
>         performance
>         affects their revenue. With AppDynamics, you get 100%
>         visibility into your
>         Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>         AppDynamics Pro!
>         http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>         <http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk>
>         _______________________________________________
>         Plone-developers mailing list
>         Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>         <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>         https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET,&  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk