Fred Drake wrote:
On 1/21/06, Jim Fulton [EMAIL PROTECTED] wrote:
are really attributes of foo. In ZCML, this might have been:
foo
x=1
y=2
/
Except this breaks down in the case of ZConfig multikey elements,
which allow configuration like this:
foo
x = 1
x = 2
Jim Fulton wrote:
Martijn Faassen wrote:
Shane Hathaway wrote:
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
I like this proposal. It is likely to reduce the total amount of code.
However, I want to be sure that
Martijn Faassen wrote at 2006-1-23 18:27 +0100:
...
For one, ZConfig is a
syntax not very well known, even granting its similarity to the Apache
configuration language, while XML is very well known.
Come on:
The only syntactic part of ZConfig is: there are
keys with values and sections
Fred Drake wrote at 2006-1-23 09:56 -0500:
On 1/23/06, Chris Withers [EMAIL PROTECTED] wrote:
As I said earlier, I think XML is wrong for configuration for exactly
this kind of reason... element-based is right for this type of config,
it's why Apache uses, it's why Zope 2 uses it, and it's why
Jim Fulton wrote:
What is the fundamental difference between ZConfig and ZCML apart from
the esthetic appearance that everyone seems to be so concerned with?
ZConfig is also generally simpler. For example, it doesn't use XML
namespaces and is thus less extensible.
I'm sure ZConfig could be
On 1/23/06, Chris Withers [EMAIL PROTECTED] wrote:
As I said earlier, I think XML is wrong for configuration for exactly
this kind of reason... element-based is right for this type of config,
it's why Apache uses, it's why Zope 2 uses it, and it's why Zope 3 uses
it for the .conf file...
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
The use case of experimenting with different formats could also be
approached using a pre-processor approach for ZCML. That ZCML is an XML
dialect makes such a thing easier,
Shane Hathaway wrote:
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
I like this proposal. It is likely to reduce the total amount of code.
However, I want to be sure that consolidating engines is the real focus
of the
Martijn Faassen wrote:
Shane Hathaway wrote:
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
I like this proposal. It is likely to reduce the total amount of code.
However, I want to be sure that consolidating engines
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
After thinking about it for a little bit, -1.
Firstly, I'm interested in experimenting with alternative syntaxes for
ZCML. I'm however not convinced that the proposal is a
Jim Fulton wrote:
[snip]
Huh? Geez, my proposal must have been really unclear. I'm not proposing
replacing ZCML files with ZConfig files. I'm proposing leveraging the ZCML
engine and especially the system for extensibility for handling ZConfig
files
Yeah, I read some of the thread, which
Fred Drake wrote:
On 1/21/06, Jim Fulton [EMAIL PROTECTED] wrote:
are really attributes of foo. In ZCML, this might have been:
foo
x=1
y=2
/
Except this breaks down in the case of ZConfig multikey elements,
which allow configuration like this:
foo
x = 1
x = 2
On 1/21/06, Jim Fulton [EMAIL PROTECTED] wrote:
are really attributes of foo. In ZCML, this might have been:
foo
x=1
y=2
/
Except this breaks down in the case of ZConfig multikey elements,
which allow configuration like this:
foo
x = 1
x = 2
y = 3
/foo
Paul Winkler wrote:
Does this mean we could potentially change zconfig options at
runtime? i.e. no server restart? That might be useful.
...or dangerous and unpredictable, depending on your point of view...
Chris
--
Simplistix - Content Management, Zope Python Consulting
-
Stephan Richter wrote:
On Friday 20 January 2006 07:36, Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
I am +1.
However, there is another risk. If we support multiple formats then that means
that a developer will have to
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
I like this proposal. It is likely to reduce the total amount of code.
However, I want to be sure that consolidating engines is the real focus
of the proposal. Converting XML
Paul Winkler wrote:
On Fri, Jan 20, 2006 at 07:36:19AM -0500, Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
...We'll register the options object as a utility.
To the extent that we want to keep using an object like that,
option handlers would save their
Paul Winkler wrote at 2006-1-20 10:26 -0500:
...
Does this mean we could potentially change zconfig options at
runtime?
What do you mean by that?
You can already now change zconfig options at runtime
(you can modify the object returned by getConfiguration()).
But usually, it will have little
On Fri, Jan 20, 2006 at 07:58:52PM +0100, Dieter Maurer wrote:
Paul Winkler wrote at 2006-1-20 10:26 -0500:
...
Does this mean we could potentially change zconfig options at
runtime?
What do you mean by that?
You can already now change zconfig options at runtime
(you can modify the
19 matches
Mail list logo
