What do you think about the following:
We have three concept in Zope 3 which are the real base for
Zope 3 as application server.
This are:
- python
- Zope components
- ZMCL
Each of them are well separated. Python is well documented,
Zope 3 is also good documented for a devleoper in it's
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
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 comfort.
I
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
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
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
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 goes
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
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
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
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
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
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 aspect
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
justify
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:
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)
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
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 cases
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.
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
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
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
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
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 tasks
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 out
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
hide
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
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 to write
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't
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
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 --
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
explicit
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
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 abstraction
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
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
Hi there,
In this mail I'd like to make explicit some competing design influences
on ZCML.
The first interpretation of what ZCML is:
ZCML is a configuration language that provides abstract directives for
configuring Zope applications. If we're setting up a page, we use the
page directive.
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. Everything
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).
I
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
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 implementation
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:
adapters,
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:
adapters,
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, security
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 that
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
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 should
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
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
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
50 matches
Mail list logo
