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

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]>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