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

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.

—
Sent from Mailbox for iPhone

On Fri, Nov 29, 2013 at 9:26 AM, Simone Orsi <[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 <[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
>> >
>>
>>
>> --
>> 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
>> _______________________________________________
>> 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