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

I very much like the way that what Asko's experimenting with maps to zcml.
I think that relationship would make this easier to understand, and a lot
easier to move back and forth between in-python configuration and zcml.

In my mind, the best part of grok is that it makes configuration in Python
easier. The most problematic part is its attempt to replace configuration
with convention, making its relationship to zcml sometimes mysterious.
Asko's configuration experiment is much more explicit.


On Fri, Nov 29, 2013 at 1:32 AM, Asko Soukka <[email protected]> wrote:

> Hi Jens,
>
> thanks for your comments.
>
> I've also experimented with Pyramid-style configuration so that you
> could use venusian-decorators in modules and then scan the modules in
> configure.py, or just declate everything configure.py just like in
> configure.zcml:
>
>
> https://github.com/datakurre/collective.venusianconfig/blob/master/demo/src/venusianconfigdemo/adapters.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/configure.py
>
> Again, I'm not forcing these ideas. We have used grok a lot internally,
> because it's been easier to get new developers started with it. Yet,
> grok has its issues, I'd be happy to replace it with something simpler
> (and more zcml-complient).
>
> Cheers,
> Asko
>
> Jens W. Klein 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
> >>
> >
> >
>
>
> ------------------------------------------------------------------------------
> 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

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers