On 3/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> Shane Hathaway wrote:
> [snip]
> > But the ZCML I've
> > written gives me a sick feeling, because I don't know how to refactor
> > ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then
> > I come here, hoping to find comfor
Shane Hathaway wrote:
[snip]
But the ZCML I've
written gives me a sick feeling, because I don't know how to refactor
ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then
I come here, hoping to find comfort.
I share these sentiments. Not that I have a particularly sick feel
On 3/15/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> I reject Sidnei's claim Zope3 were unique in this respect
> (apart from using ZCML, of course) :-)
I think that amongst web app frameworks we are. I don't know of any
other aspect oriented ones. I could be wrong.
--
Lennart Regebro, Nuxeo
Jim Fulton wrote:
Shane Hathaway wrote:
Jim Fulton wrote:
Finally, I'll note that I've used the term "high-level configuration" to
refer to the things we have sysadmins edit when they install Zope
systems. We currently use ZConfig for this. I don't think ZCML
(or any other XML-based system)
Shane Hathaway wrote:
Jim Fulton wrote:
Finally, I'll note that I've used the term "high-level configuration" to
refer to the things we have sysadmins edit when they install Zope
systems. We currently use ZConfig for this. I don't think ZCML
(or any other XML-based system) should be used for
Jim Fulton wrote at 2006-3-15 07:29 -0500:
> ...
>Magic always has the downside that it
>hides things. Often, as in the case of garbage collection, the benefit
>outweighs the cost. Too often though, people introduce magic
>(aka abstraction, indirection, automation) when the benefit doesn't
>justi
Lennart Regebro wrote at 2006-3-14 21:17 +0100:
>On 3/14/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
>> Aspect orientation does this:
>>
>> Use a given unprepared implementation and add all kinds
>> of aspects to them: logging, tracing, persistence, additional
>> checks
>
>Yeah. And that
Jim Fulton wrote:
Finally, I'll note that I've used the term "high-level configuration" to
refer to the things we have sysadmins edit when they install Zope
systems. We currently use ZConfig for this. I don't think ZCML
(or any other XML-based system) should be used for this.
Ok. The high-le
Jim Fulton wrote:
I'd also like to acknowledge Tres' point about high-level non-Python
definition mechanisms for things like forms and schemas. I agree
with him that such facilities could be a good thing. I may disagree
with him on whether these should be ZCML. I definately don't think
that t
Shane Hathaway wrote:
...
Back on topic, the message I'm hearing about ZCML is confusing:
That's because we don't all agree.
> high
level configuration is good, but ZCML isn't going to handle it because
we want to limit the number of directives. Does that mean we're going
to use Python cod
Jim Fulton wrote:
Martijn Faassen wrote:
...
I suspect we're in a state of violent agreement here. :)
Then why do people have to argue every single point ad nauseum?
Because we want to understand the current decisions and thinking. I
never intend to argue, but email is such a poor discus
Martijn Faassen wrote:
...
I suspect we're in a state of violent agreement here. :)
Then why do people have to argue every single point ad nauseum?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Z
On 3/14/06, Lennart Regebro <[EMAIL PROTECTED]> wrote:
> OK, I just think I had a sort of brainwave-thingy, so I'm going to lay
> it out here to see if it was a good brainwave or not:
>
>
> Currently I can see three useful uses of ZCML:
>
> 1. User interface configurations, that is, everything that
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
I appreciated you making it explicit, Shane, even though I already
knew and fully agree. :)
I sometimes express this principle as "magic is bad unless it's
perfect magic". Do post it on your blog.
Yes, it is a good thing to know, except that
Martijn Faassen wrote:
Shane Hathaway wrote:
Jim Fulton wrote:
Shane Hathaway wrote:
+1. When I learn a skill, it is at first completely explicit, and
as the skill becomes predictable and reliable, it gradually becomes
implicit. If I kept everything explicit, I would hinder myself from
Shane Hathaway wrote:
Jim Fulton wrote:
Shane Hathaway wrote:
+1. When I learn a skill, it is at first completely explicit, and as
the skill becomes predictable and reliable, it gradually becomes
implicit. If I kept everything explicit, I would hinder myself from
building higher level ski
Zachery Bir wrote:
On Mar 14, 2006, at 4:31 PM, Jean-Marc Orliaguet wrote:
which is strictly equivalent to "Implicit is better than explicit,
except when it's not." :-) and when it's not ... explicit is better.
Clearly arbitraritude is better than claritization, except when it
is. Or may
Jim Fulton wrote:
Shane Hathaway wrote:
+1. When I learn a skill, it is at first completely explicit, and as
the skill becomes predictable and reliable, it gradually becomes
implicit. If I kept everything explicit, I would hinder myself from
building higher level skills.
So explicit is bet
On Tuesday 14 March 2006 16:44, Jim Fulton wrote:
> I stand by my argument that indirection and abstraction are bad. Of
> course, they are often also good. They should be used when the good
> significantly outweighs the bad.
>
> Too often though, people don't realize that indirection and abstract
On Mar 14, 2006, at 4:31 PM, Jean-Marc Orliaguet wrote:
which is strictly equivalent to "Implicit is better than explicit,
except when it's not." :-) and when it's not ... explicit is better.
Clearly arbitraritude is better than claritization, except when it
is. Or maybe: a desire to argue
Jim Fulton wrote:
Shane Hathaway wrote:
+1. When I learn a skill, it is at first completely explicit, and as
the skill becomes predictable and reliable, it gradually becomes
implicit. If I kept everything explicit, I would hinder myself from
building higher level skills.
So explicit i
Shane Hathaway wrote:
Dieter Maurer wrote:
Jim Fulton wrote at 2006-3-14 07:23 -0500:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of "explicit is better than implicit".)
I do not agree with this (but I also do not agree with
"explici
Dieter Maurer wrote:
Jim Fulton wrote at 2006-3-14 07:23 -0500:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of "explicit is better than implicit".)
I do not agree with this (but I also do not agree with
"explicit is better tham implicit"
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
I was refering to high-level ZCML, such browser:page, browser:menu, etc
vs low-level directives like adapter.
Jim
I would say that they paraphrase more lines of code than the
low-level ones, but they fundamentally add no extremely valuable
On 3/14/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Aspect orientation does this:
>
> Use a given unprepared implementation and add all kinds
> of aspects to them: logging, tracing, persistence, additional
> checks
Yeah. And that aspect orientation is in Zope3 done in ZCML... So I
don
On 3/14/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> >Why is that important? In most cases you would have to write
> >interfaces for the non-z3 python objects. Assuming you don't actually
> >write them, but cheat and just mark them, you can get away with this,
> >sure. But is it really that hard
Lennart Regebro wrote at 2006-3-14 09:19 +0100:
>On 3/14/06, Sidnei da Silva <[EMAIL PROTECTED]> wrote:
>> That is, to me, a very important feature. To be able to write some
>> python module that does not depend on Zope 3 at import time, but is
>> 'hooked into' Zope 3 externally, with ZCML, at 'con
Jim Fulton wrote at 2006-3-14 07:23 -0500:
> ...
>> * Setting up the indexes in a catalog.
>
>definition
Really?
I would consider it configuration -- even "high level" configuration.
> ...
>BTW, a general thing to keep in mind:
>
>- Indirection and abstraction are inherently bad because they
>
Sidnei da Silva wrote at 2006-3-13 20:21 -0300:
> ...
>That is, to me, a very important feature. To be able to write some
>python module that does not depend on Zope 3 at import time, but is
>'hooked into' Zope 3 externally, with ZCML, at 'configuration time'.
>
>As I understand, no other framework
Roger Ineichen wrote at 2006-3-13 21:57 +0100:
> ...
>I think ZCML is defently not configuration in the clasic
>understanding of configuration. Defining directives in ZCML
>means we bind components together to a application.
>If developer share this configuration layer with admins and
>use it for t
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Yup.
BTW, a general thing to keep in mind:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of "explicit is better than implicit".)
- But indire
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Yup.
BTW, a general thing to keep in mind:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of "explicit is better than implicit".)
- But indirection and abstraction can pr
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Yup.
BTW, a general thing to keep in mind:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of "explicit is better than implicit".)
- But indirection and abstraction can provide benefits that o
Jim Fulton wrote:
Yup.
BTW, a general thing to keep in mind:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of "explicit is better than implicit".)
- But indirection and abstraction can provide benefits that outweight
their inherent ba
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
as configuration in Python code is more flexible and packages can
form a more self-contained whole.
Wrong!
This is an important point. No one in the know is proposing
using Python for configuration. Python is for d
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
as configuration in Python code is
more flexible and packages can form a more self-contained whole.
Wrong!
This is an important point. No one in the know is proposing
using Python for configuration. Python is for definition,
not configuration
OK, I just think I had a sort of brainwave-thingy, so I'm going to lay
it out here to see if it was a good brainwave or not:
Currently I can see three useful uses of ZCML:
1. User interface configurations, that is, everything that goes under "browser".
Menus, pages, forms, that sort of thing
On 3/14/06, Sidnei da Silva <[EMAIL PROTECTED]> wrote:
> That is, to me, a very important feature. To be able to write some
> python module that does not depend on Zope 3 at import time, but is
> 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'.
Why is that important? In most ca
On Mon, Mar 13, 2006 at 04:40:09PM -0700, Shane Hathaway wrote:
| I would suggest that is a component architecture feature, not a ZCML
| feature. If Zope were a hardware device, the CA would be the wiring and
| ZCML would be the schematic diagram.
Great point!
--
Sidnei da Silva
Enfold System
Paul Winkler wrote:
On Mon, Mar 13, 2006 at 04:14:08PM -0700, Shane Hathaway wrote:
You're aware of the DRY principle, right? ZCML is repetitive, and
repetitive is wrong.
We tend to think that repetition is *always* wrong, but in other fields
there are cases in which it depends who the read
Alec Mitchell wrote:
...
I was a bit disturbed. What's the point?
The point is that you are using the adapter.
> It tells you nothing unless you
refer to the actual implementation.
It tells you that the adapter is being used.
> Why not just put the registration in
python alongside the
On Mon, Mar 13, 2006 at 04:14:08PM -0700, Shane Hathaway wrote:
> You're aware of the DRY principle, right? ZCML is repetitive, and
> repetitive is wrong.
We tend to think that repetition is *always* wrong, but in other fields
there are cases in which it depends who the reader is, and how the
re
Dieter Maurer wrote:
...
Note, that configuration files should be understand and
adaptable by administrators. Therefore, they should be readable
and understandable -- without an understanding of the implementation
(but with reading of the component documentation).
As Jeffrey pointed out (and as
Martijn Faassen wrote:
...
A newer interpretation of ZCML is:
"""
ZCML is a configuration language that configures a number of basic
directives for configuring the component architecture and security:
adapters, utilities, security requirements, and little else.
Right.
Everything
else shoul
Sidnei da Silva wrote:
On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote:
| And I think it's
| very important for the Python code to say what it does, so when I come
| back to a module five months later I'm not staring at MyFactory going
| "yeah, but what is it?"
One thing that must not
On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote:
| And I think it's
| very important for the Python code to say what it does, so when I come
| back to a module five months later I'm not staring at MyFactory going
| "yeah, but what is it?"
One thing that must not pass by unnoticed is tha
Jeff Shell wrote:
Why design a language at all?
We already did, and it's a BASIC-like language, so now we reap the
consequences. Some of the consequences are:
1. If you stick to the established directives, you express repetitive,
low level information that really needs to be represented in
On 3/13/06, Alec Mitchell <[EMAIL PROTECTED]> wrote:
> +1 The first time I saw:
>
>
>
> I was a bit disturbed. What's the point? It tells you nothing unless you
> refer to the actual implementation.
Right, but it switches it on, which is important. :-)
--
Lennart Regebro, Nuxeo http://www.
On 3/13/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote:
> > A newer interpretation of ZCML is:
> >
> > """
> > ZCML is a configuration language that configures a number of basic
> > directives for configuring the component architecture and security:
> > adapters, utilities, s
On Monday 13 March 2006 10:59, Dieter Maurer wrote:
> Martijn Faassen wrote at 2006-3-13 17:15 +0100:
> > ...
> >A newer interpretation of ZCML is:
> >
> >"""
> >ZCML is a configuration language that configures a number of basic
> >directives for configuring the component architecture and security:
On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote at 2006-3-13 17:15 +0100:
> > ...
> >A newer interpretation of ZCML is:
> >
> >"""
> >ZCML is a configuration language that configures a number of basic
> >directives for configuring the component architecture and security
On 3/13/06, Alec Mitchell <[EMAIL PROTECTED]> wrote:
> On Monday 13 March 2006 10:59, Dieter Maurer wrote:
> > Note, that configuration files should be understand and
> > adaptable by administrators. Therefore, they should be readable
> > and understandable -- without an understanding of the implem
Martijn Faassen wrote:
A newer interpretation of ZCML is:
"""
ZCML is a configuration language that configures a number of basic
directives for configuring the component architecture and security:
adapters, utilities, security requirements, and little else. Everything
else should be done in P
On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Note, that configuration files should be understand and
> adaptable by administrators. Therefore, they should be readable
> and understandable -- without an understanding of the implementation
> (but with reading of the component documentation)
Martijn Faassen wrote at 2006-3-13 17:15 +0100:
> ...
>A newer interpretation of ZCML is:
>
>"""
>ZCML is a configuration language that configures a number of basic
>directives for configuring the component architecture and security:
>adapters, utilities, security requirements, and little else. E
55 matches
Mail list logo
