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

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