Re: [Zope3-dev] what is ZCML?

2006-03-16 Thread Martijn Faassen

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 feeling 
(I've been immunized by too much exposure? :) but because I'm grasping 
for ways, patterns, to make my code look better, briefer, shorter, less 
repetition, more reuability.


I would feel more comfortable if one of the following things were to 
happen:


1. The group acknowledges that repetition in ZCML is bad.


I definitely acknowledge his one.


2. Someone shows me how to avoid repetition in ZCML.


Grasping around here myself. We need to show more people than just Shane 
and Martijn too - we need to be able to reach a wider audience if this 
is going to work.



3. We decide that ZCML is a failed experiment.


On the one hand, I'm not willing to do that. On the other hand, if ZCML 
is to be a simple registration language, I am starting to idly wonder 
why a bunch of CSV tables wouldn't do (and might not be clearer and 
simpler).


If ZCML is to be a simple registration language, I'd also like there to 
be a 1 to 1 mapping of ZCML statement to Python code. Right now there is 
a mapping and while it may be reasonably straightforward, I personally 
am still lost in APIs (and it looks like Jeff Shell is too). This 
learning curve should be smaller.


Whatever we do, if ZCML is to be replaced we need to replace it with 
something. I think many of the notions of ZCML are dead on - this 
registration shouldn't be happening in normal Python code mixed with the 
rest but as a separate activity. It should allow overriding. It should 
be amenable to analysis.



4. We decide that ZCML should gain more qualities of a high level language.


I personally am quite interested in exploring this, but I'd like to see 
some examples of what this would actually look like, concretely.



5. We solve this some other way.


This would be satisfactory too. :)

I recognize that #3 and #4 are very risky, and we've already been over 
the risks, but I include them because they still feel better than the 
status quo.


We can mitigate some of the risks of both #3 and #4 as we could do them 
as separate, experimental, non-Zope projects.


I can't help but wonder if ZCML is largely a reaction to the horrible 
initialize(context) methods in CMF products. 


In non-CMF Silva we also got horrible initialize(context) methods, and 
we've got horrible and long install.py files. When looking at ZCML we 
should clearly keep in mind that what it replaces. Silva's install.py 
expressed in ZCML would be preferrable to what we have now in most ways.


Those beasts are horrible 
because they are based on workarounds of workarounds.  The workarounds 
came about because we were more willing to add code than fix code.  That 
attitude prevailed because we didn't have automated tests of Zope.


And because we weren't as good at designing good Pythonic APIs as we are 
now. At least I've definitely gotten better at that over the last years.


Now that we have automated tests, programmers are more likely to fix 
code rather than add code, so we can expect to see very few workarounds, 
so initialize(context) garbage won't happen.


I'm not convinced of this, myself. If Zope 3 becomes popular, lots of 
application developers won't be using automated tests in Zope 3 code 
either. In addition, you get unnecessary workarounds because people fail 
to see the right way to do it and are in a hurry. I feel that a 
declarative and domain specific language can help in such cases.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-16 Thread Jeff Shell
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 share these sentiments. Not that I have a particularly sick feeling
 (I've been immunized by too much exposure? :) but because I'm grasping
 for ways, patterns, to make my code look better, briefer, shorter, less
 repetition, more reuability.

Reuse is overrated. :)

Honestly, I think reuse best happens in Python. I've found it easy to
wrap and roll things up into more common APIs for personal use. This
has been one of the really positive things of Zope 3. But for that
sort of roll up to happen, the environment needs to support common
refactoring patterns (extract method/class/etc). I do not believe that
ZCML supports that.

  I would feel more comfortable if one of the following things were to
  happen:
 
  1. The group acknowledges that repetition in ZCML is bad.

 I definitely acknowledge his one.

  2. Someone shows me how to avoid repetition in ZCML.

Use less ZCML. Be creative. Have fun. This answer doesn't work for
everybody, and isn't as easily applicable as I would like.

  3. We decide that ZCML is a failed experiment.

 On the one hand, I'm not willing to do that. On the other hand, if ZCML
 is to be a simple registration language, I am starting to idly wonder
 why a bunch of CSV tables wouldn't do (and might not be clearer and
 simpler).

Because editing CSV tables sucks an even bigger electrical outlet.
(Honestly - I'm too stupid to understand Excel... But maybe I'm saying
that after spending a week writing an CSV inventory importer. Ugh).

 If ZCML is to be a simple registration language, I'd also like there to
 be a 1 to 1 mapping of ZCML statement to Python code. Right now there is
 a mapping and while it may be reasonably straightforward, I personally
 am still lost in APIs (and it looks like Jeff Shell is too). This
 learning curve should be smaller.

I agree. I think Jim said early on that ZCML should be theoretically
replaceable. Looking at many of the directive implementations, I do
not see this.

If the Zope 3 CA vision that I had is to have a good chance of
succeeding outside of this community, I'd hope that it doesn't ship
with or require ZCML.

 Whatever we do, if ZCML is to be replaced we need to replace it with
 something. I think many of the notions of ZCML are dead on - this
 registration shouldn't be happening in normal Python code mixed with the
 rest but as a separate activity. It should allow overriding. It should
 be amenable to analysis.

I'm mixed about whether this should happen in normal Python code. A
few months ago I laid out a vision for how I think it would work.
Basically, configuration would have to be a very locked-down module:
it couldn't really be imported by regular code, wouldn't really
execute when called from 'regular' code. It would, in short, try to
somehow enforce the importing a package should NOT automatically
register its components.

  4. We decide that ZCML should gain more qualities of a high level language.

 I personally am quite interested in exploring this, but I'd like to see
 some examples of what this would actually look like, concretely.

We have a high level language. It's Python. I think that people just
have gotten bad at thinking in objects and usable APIs and have
somehow developed a strange fear of the language. I don't get it.

class ArticleEditForm(form.EditForm):
form_fields = fields.FormFields(IArticle, ITaggable)
form_fields['tags'].custom_widget = ...

Wow. So much better than browser:editform. It's possible to design
other parts of the system like this. I just know it is.

like this? yes what is this? respects the Python developer.

Now I know forms are a special case, as Tres or Shane or both brought
up. I was just impressed by the amount of actually-helpful objects,
APIs, and base classes in formlib. That one package has made me more
productive and flexible than most of the rest of Zope 3's default
elements (zope.interface/component/schema/app.container excepted). I
think we can learn something from it. At least, I hope we can. Zope
can, at the end of the day, only provide some good core tools. I think
those tools, and the concepts behind them, should be simple. Then if
someone wants to build the giga-framework on top of it, they can. But
also, if I'm writing what should be a simple application like the
PyWebOff example, I don't have to waste time on countless elements
that don't apply. I don't have to waste time editing more XML than
Python. Etc.

Honestly: Rails is very appealing with its we use Ruby for
everything message. But Ruby's syntax and use of blocks seems to make
this more tenable than it is in Python. I'm not a big fan of their
convention over configuration design, but it's winning me over
slowly. The more I fight 

Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Martijn Faassen

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 skills.


So explicit is better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage 
collection). Garbage collection is both an abstraction, since 
programmers no longer manage memory directly, and an indirection, 
since programmers now use APIs that call malloc and free.  We all 
agree GC is good, so explicit is definitely not always better than 
implicit.


Thanks for explaining Explicit is better than implicit,
except when it's not.
 
Admittedly, I should have posted that in my blog, not here. :-)


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.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Jim Fulton

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 
building higher level skills.


So explicit is better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage 
collection). Garbage collection is both an abstraction, since 
programmers no longer manage memory directly, and an indirection, 
since programmers now use APIs that call malloc and free.  We all 
agree GC is good, so explicit is definitely not always better than 
implicit.



Thanks for explaining Explicit is better than implicit,
except when it's not.


 
Admittedly, I should have posted that in my blog, not here. :-)



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 it is incomplete and
obscures an important point.  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 the hiding.  One should always approach magic with skepticism.

This is an important design principle.  The explicit is better than
implicit is a guide, not a rule never to be broken.  It's something we
should start with.  Does that mean we never provide automation? Of
course not.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Martijn Faassen

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 it is incomplete and
obscures an important point.  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 the hiding.  One should always approach magic with skepticism.


Agreed. That's why magic in software has a bad reputation. But it's not 
bad if it works almost invisibly.



This is an important design principle.  The explicit is better than
implicit is a guide, not a rule never to be broken.  It's something we
should start with.  Does that mean we never provide automation? Of
course not.


I suspect we're in a state of violent agreement here. :)

What you say about this in part depends on who you're talking to. 
Repetition of code is generally bad. Many programmers don't abstract 
*enough* and copy  paste code all over the place. We don't want to make 
them more wary of automation.


To go to a related but slightly different topic:

One form of abstraction I'm still grasping for in Zope 3 is support for 
coarse-grained components. When I have a whole bunch of (local) 
utilities, content objects, views, permissions and the like that work 
together, tied together with quite a bit of ZCML, I'd like to be able to 
reuse that more easily in an application. Right now the only way to 
reuse code like that I can find is to copy it and modify it, but that's 
wrong - it'd like to be able to use all that code from my application 
without having to copy or modify it.


For instance, for an application I needed a user and group management 
system with a ZODB user interface. This uses the catalog, defines a 
number of content objects and adds a bunch of views. Extracting this 
functionality from the application turned out harder than I'd like it to 
be. And then I haven't figured out yet how to reuse it without having to 
copy and modify code...


Are there patterns to do this in current Zope 3? Part of the problem is 
a dependency on local utilities - I believe the new local utility 
registration API you're working on should help there. For the rest, I 
guess I could just copy and rewire the ZCML, but that is quite a bit of 
work and failure-prone. I could also invent a ZCML statement with a much 
higher level of abstraction that takes the place of dozens of lower 
level statements, but people argue against this rather a lot. What other 
strategies could I employ?


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Lennart Regebro
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 under 
 browser.
 Menus, pages, forms, that sort of thing.

 2. Switching on/overriding tools, utilities, adapters, etc. Call it
 component registration.

 3. Making non-component classes into component classes.

 Now, one thing we notice here is that the things in 3 is not anything
 that needs to be overriden. It therefore doesn't HAVE to be in ZCML.
 You can do this equally well by making small wrapper classes in
 Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This
 is one item that can be discussed.

 I also realised that what goes in my point 1 here, is what goes int
 Martijns #1, and what goes in my point to, fits into Martijns #2.

 So I would like to suggest that both view #1 and view #2 are equally
 valid, but for different things. One thing we notice is that for
 example the content directive doesn't fit vith view #2, of the leaner
 and meaner ZCML. And neither is it user interface configuration. My
 conclusion: It should go away.


 Thoughts on that?

None, evidently. So it was a bad brainwave then. :)

Ah well. Beware the Ideas of March, as my grandad never said.

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Jim Fulton

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
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Shane Hathaway

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 discussion medium that 
the words often come out sounding like an argument.


The statement explicit is better than implicit, except when it's not 
is void of any meaning.  I think I know what it means, but I can only 
guess what you think it means.  I attempted to elaborate so you can 
confirm or deny a common understanding.  I don't think I elaborated 
enough, though.  It seems to be a fundamental principle for building 
Zope 3, so we all need to understand it the same way.


Back on topic, the message I'm hearing about ZCML is confusing: 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 code to generate ZCML?  (That's a rhetorical question... I 
think.)


Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Jim Fulton

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 code to generate ZCML?  (That's a rhetorical question... I 
think.)


What I've said is that ZCML should be about configuration, especially
registration, and *not* about defining things.  I've said things should be
defined in Python and registered in ZCML.  I don't necessarily have a problem
with high-level configuration directives that configure several things at
once, although I'm wary that the benefit would be worth the obscurity.

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 they should be.

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.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Jean-Marc Orliaguet

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 they should be.



it depends a lot on the availability of softwares and of standards used 
to create such definitions.


Julien has done some work on using XML schemas in zope3 as you know:
http://blogs.nuxeo.com/sections/blogs/julien_anguenot/2005_08_19_xml-schema-support-on
http://svn.nuxeo.org/trac/pub/browser/z3lab/zope/xmlschema/trunk/demo/

XForms could be a good choice for defining forms too.

I'm using JSON for MVC definitions, because they can be used in 
Javacript without much fuss.

YAML seems to be easy to read  too, etc.
SVG can be investigated too for defining layouts, graphical objects etc.

this is really an area where one should look to see what already exists.

sorry if I'm off-topic.

/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Shane Hathaway

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-level configuration I'm thinking about is somewhere in 
between.  I don't know what to call it, so I won't call it anything.


Here's what has happened to me several times: I'm a Python developer, 
writing simple code for Zope 3, and I follow Stephan's examples on how 
to develop content types for Zope 3.  I write simple schema-based 
classes and simple directives.  I've been conditioned to not repeat 
myself in code; in fact, breaking that rule gives me a sick feeling.  So 
I proceed to follow Stephan's examples, which involves writing similar 
ZCML directives for multiple classes.  The repetitious classes don't 
bother me because I know how to refactor them.  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 would feel more comfortable if one of the following things were to happen:

1. The group acknowledges that repetition in ZCML is bad.

2. Someone shows me how to avoid repetition in ZCML.

3. We decide that ZCML is a failed experiment.

4. We decide that ZCML should gain more qualities of a high level language.

5. We solve this some other way.

I recognize that #3 and #4 are very risky, and we've already been over 
the risks, but I include them because they still feel better than the 
status quo.


I can't help but wonder if ZCML is largely a reaction to the horrible 
initialize(context) methods in CMF products.  Those beasts are horrible 
because they are based on workarounds of workarounds.  The workarounds 
came about because we were more willing to add code than fix code.  That 
attitude prevailed because we didn't have automated tests of Zope.


Now that we have automated tests, programmers are more likely to fix 
code rather than add code, so we can expect to see very few workarounds, 
so initialize(context) garbage won't happen.


Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Dieter Maurer
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 orientation is in Zope3 done in ZCML... So I
don't really know what you are trying to say here. :-)

I reject Sidnei's claim Zope3 were unique in this respect
(apart from using ZCML, of course) :-)

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Dieter Maurer
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 the hiding.  One should always approach magic with skepticism.

Neither costs nor benefits are objective but subjective.

  For me, when I repeat the same sequence for about half
  a dozen of times, I am crying out for an abstraction
  (if possible with a well chosen name) that gets rid
  of the repetition.

  I am rarely interested in details and am happy when
  lots of them are hidden -- that's no cost but benefit.

  Well chosen names give me enough feeling about the overall
  effect that I rarely need to dig into the details.

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Jim Fulton

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 this.



Ok.  The high-level configuration I'm thinking about is somewhere in 
between.  I don't know what to call it, so I won't call it anything.


Here's what has happened to me several times: I'm a Python developer, 
writing simple code for Zope 3, and I follow Stephan's examples on how 
to develop content types for Zope 3.  I write simple schema-based 
classes and simple directives.  I've been conditioned to not repeat 
myself in code; in fact, breaking that rule gives me a sick feeling.  So 
I proceed to follow Stephan's examples, which involves writing similar 
ZCML directives for multiple classes.  The repetitious classes don't 
bother me because I know how to refactor them.  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.


Could you give a more specific example?

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Shane Hathaway

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) should be used for this.




Ok.  The high-level configuration I'm thinking about is somewhere in 
between.  I don't know what to call it, so I won't call it anything.


Here's what has happened to me several times: I'm a Python developer, 
writing simple code for Zope 3, and I follow Stephan's examples on how 
to develop content types for Zope 3.  I write simple schema-based 
classes and simple directives.  I've been conditioned to not repeat 
myself in code; in fact, breaking that rule gives me a sick feeling.  
So I proceed to follow Stephan's examples, which involves writing 
similar ZCML directives for multiple classes.  The repetitious classes 
don't bother me because I know how to refactor them.  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.



Could you give a more specific example?


My attempt to solve the PyWebOff challenge, which I posted here:

http://mail.zope.org/pipermail/zope3-users/2006-March/002608.html

The ZCML I wrote in that message is quite representative of the ZCML I 
wrote for a Zope 3-based system that's now in production.  (The system 
is a management interface for a Beowulf-style microfilm scanning 
cluster.)  The repetition isn't a showstopper, obviously, but it makes 
me feel bad, so Zope 3 ends up being no fun.


Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Lennart Regebro
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 http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Lennart Regebro
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 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 a small wrapper class
instead?

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Lennart Regebro
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.

2. Switching on/overriding tools, utilities, adapters, etc. Call it
component registration.

3. Making non-component classes into component classes.

Now, one thing we notice here is that the things in 3 is not anything
that needs to be overriden. It therefore doesn't HAVE to be in ZCML.
You can do this equally well by making small wrapper classes in
Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This
is one item that can be discussed.

I also realised that what goes in my point 1 here, is what goes int
Martijns #1, and what goes in my point to, fits into Martijns #2.

So I would like to suggest that both view #1 and view #2 are equally
valid, but for different things. One thing we notice is that for
example the content directive doesn't fit vith view #2, of the leaner
and meaner ZCML. And neither is it user interface configuration. My
conclusion: It should go away.


Thoughts on that?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jim Fulton

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 definition,
not configuration.

The problem with some of the high-level ZCML directives is that
they performed *definition* in addition to configuration.
For example, browser:page creates new classes.

It's important that definition be done in Python. Configuration
should be done in ZCML.



Okay, since I'm wrong, I think it would be useful if you spelled out the 
difference between definition and configuration.


Admittedly, the distinction is not always crisp.  Similarly, the
difference between low-level configuration for programmers and
high-level configuration for adminstrators is not always crisp.

The philosophy is important though.  ZCML is configuration, not
definition.  Generally, Python is for definition, although, sometimes
other languages are used too. Obviously, template languages are used
for definition too.  Tres has argued that declarative languages might
be better for defining interfaces.

Also, XMI is an interesting case, as it, potentially, fills both roles. :)

 I have some intuitions
but it's obviously not fully clear to me, and I suspect others may also 
have difficulty. I'll phrase give examples of things that I could 
interpret as configuration or as definition.


Which of the following is definition and which is configuration (or 
something else entirely?):


* Specifying which pages can be viewed for an object providing a 
particular interface.


Low-level configuration


* Attaching annotations to objects of a particular interface.


Saying that we want to use a particular adapter is configuration.

Implementing that adapter is definition.



* Attaching menu entries to objects of a particular interface.


Low-level configuration. Defining the menu entries is definition.


* Setting the layer a view is in.


Low-level configuration.


* Specifying which page template is used to render a particular view.


Low-level configuration


* Setting the permissions needed to access the attributes of an object.


Low-level configuration


* Setting up the indexes in a catalog.


definition


* Setting up a catalog for a site.


Creating the catalog is definition, registering it is configuration

* Determine what is shown in which columns are shown in a table on a web 
page.


Definition


* The initial sorting order of these columns.


Grey :)


* The batch size of a particular batched view.


Grey

* Which resources should be included in a web page displaying a certain 
widget.


I don't know what this means.


* The relational database we've connected our application to.


High-level configuration


* The mailserver we've connected our application to.



High-level configuration



* The fields that show up in a form.


Definition


* Setting up which fields that show up in a form are required.


Definition

* Setting up which file extensions we want to allow to be uploaded into 
a file upload widget.


Grey.  I would expect that you might also want to define handlers
for these.  So you'd define the handlers and configure their use.

Perhaps these questions are too high level and should be split up into 
multiple questions.


What criteria do you use to determine whether something is definition or 
configuration?


It's hard to say without repeating the words or synonyms. :)

If it's


I also suspect that some of these are local or application specific 
configuration. It makes sense to store some configuration in the ZODB, 
and thus, at present, not express it in ZCML at all.


Yes.


 What is

configuration sometimes depends on the application in question.


Yup


Should there be high-level directives in ZCML?  I don't think they should
be disallowed, but you really have to ask yourself if the automation 
they provide is worth the extra burden of understanding what they do.



The other drawback of using ZCML for automation is that complicated 
automation is often quite cumbersome to express in ZCML.


Another drawback is that such automation often combines various bits of 
python code with ZCML and you have to look at multiple files instead of 
just one.


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 bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.


Anyway, the main thrust of the ZCML simplification is to use it just for
low-level configuration, not for definition.



So to make it clear, you're in favor of ZCML interpretation #2, with the 
modification that Python code should not be 

Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

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 bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.
[...]

Jim



yes, except that ZCML adds strictly no abstraction compared to what 
would have been written in python. It only paraphrases python by 
hiding lines of code. When I look at a zcml directive I often have to 
read that handler's code to see what it actually does and I have to find 
the objects, classes in files, .. that it handles.


that's 2 indirections, but no abstraction

Abstraction would in the case of ZCML mean that paths to python modules 
and classes would be hidden, that objects (adapters, pages, menus) could 
be given a shorter name that I could use inside ZCML for configuration 
purposes without registering these names in zope, it would mean that I 
could group directives together in a set and apply rules to it without 
always refering to the location of each individual object on the 
filesystem, that I wouln't have to do a grep on all zcml files when I 
move or rename files (I would register paths only once) ... It would 
mean that I could register all images inside a folder without listing 
them all one by one.


This would be the beginning of something called 'abstraction', but 
that's still far away from it :-).


best
/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jim Fulton

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 outweight
  their inherent bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.
[...]

Jim



yes, except that ZCML adds strictly no abstraction compared to what 
would have been written in python.  It only paraphrases python by

hiding lines of code.


I was refering to high-level ZCML, such browser:page, browser:menu, etc
vs low-level directives like adapter.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

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 provide benefits that outweight
  their inherent bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.
[...]

Jim



yes, except that ZCML adds strictly no abstraction compared to what 
would have been written in python.  It only paraphrases python by

hiding lines of code.



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 abstraction since 
a page is an alias for a multiadapter, a menu registers utilities, 
interfaces, .. . Anyway these are the ones that should be moved out of 
ZCML I guess since they are so site or application specific that it is 
difficult to be reuse them as components in other setups. But after 
rereading your mail it seems that this is what you said in it.


simply put, high-level ZCML would be for me being able to associate a 
collection of resources to a given skin in a global way, or saying that 
a given LDAP directory should be plugged into a given authentication 
service, but without specifying LDAP port, servers, when doing the 
connection (because I have an object in ZCML that stands for the LDAP 
directory and another one that refers to the authentication service)


/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jim Fulton

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 indirection and abstraction can provide benefits that outweight
  their inherent bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.
[...]

Jim



yes, except that ZCML adds strictly no abstraction compared to what 
would have been written in python.  It only paraphrases python by

hiding lines of code.




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 abstraction since 
a page is an alias for a multiadapter, a menu registers utilities, 
interfaces, ..


Wrong.  the page directive defines a class and combines multiple
configurations.  This is definately a higher level of abstraction.



 . Anyway these are the ones that should be moved out of
ZCML I guess since they are so site or application specific that it is 
difficult to be reuse them as components in other setups.


Well, no.  They are not application specific.  Rather, we feel,
after getting experience with them, that the benefits they provide
don't justify the hiding they do of what's really going on.
The same could have been true if they were written in Python.

In fact, we have a similar problem with some of our Python menu
APIs, which automate too much and actually obscure what is really
a simple pattern.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Dieter Maurer
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 like configuring a mail queue
(like we do right now) I'm sure we will get a big mess for
admins and developers understanding of what ZCML should be.

Why do we need ZCML for this?
It can be done with Python equally well...

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Dieter Maurer
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 there gives you this.

Aspect orientation does this:

  Use a given unprepared implementation and add all kinds
  of aspects to them: logging, tracing, persistence, additional
  checks


-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Dieter Maurer
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 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 -- almost all activities
would become drastically more difficult if they could only be
done explicitly: walking, driving, eating, ... I am very happy
that most things, in real life and in programming work implicitly
and on an appropriate abstract level).

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Dieter Maurer
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 'configuration time'.

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 a small wrapper class
instead?

And you can use Python, too, to mark them:

   You import the class and call an implements for it.

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Lennart Regebro
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 a small wrapper class
 instead?

 And you can use Python, too, to mark them:

You import the class and call an implements for it.

Right you are, you don't even need to subclass it.

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Lennart Regebro
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 really know what you are trying to say here. :-)
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

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 
abstraction since a page is an alias for a multiadapter, a menu 
registers utilities, interfaces, ..



Wrong.  the page directive defines a class and combines multiple
configurations.  This is definately a higher level of abstraction.




OK, but that's not violent abstraction. For a python programming, 
going to ZCML does feel like wow, I can do some high-level 
configuration of my application, we are still configuring fairly 
low-level components (pages, menus, views ...), they still need to be 
configured on a higher level for the application to start working. The 
effort is not necessarily justified compared with how views for instance 
are declared inline with the code. By looking at 
zope/app/publisher/browser/viewmeta.py it is clear that most of the code 
is there handle all the different page registration options (templates, 
attributes, security, ..).


the fact that the abstraction done in ZCML does not succeed in hiding 
information is an issue, IMO this is because the directives in ZCML 
correspond to low-level objects and the objects' internal way of 
functioning is getting too much exposed  (not enough encapsulation) as 
its the case with browser:page. 


/JM


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Shane Hathaway

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 -- almost all activities
would become drastically more difficult if they could only be
done explicitly: walking, driving, eating, ... I am very happy
that most things, in real life and in programming work implicitly
and on an appropriate abstract level).


+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 better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage collection). 
Garbage collection is both an abstraction, since programmers no longer 
manage memory directly, and an indirection, since programmers now use 
APIs that call malloc and free.  We all agree GC is good, so explicit is 
definitely not always better than implicit.


To say something is bad only because it's implicit or abstract is a poor 
argument, but to say something is bad because it's a leaky abstraction 
is an argument that can be explored further.  For example, it's not very 
sensible to say implicit acquisition is bad because it's implicit, but 
it is quite sensible to say it's bad because it leaks all attributes and 
forces a lot of code to be aware of wrappers.


Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jim Fulton

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 is better tham implicit -- almost all activities
would become drastically more difficult if they could only be
done explicitly: walking, driving, eating, ... I am very happy
that most things, in real life and in programming work implicitly
and on an appropriate abstract level).



+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 better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage collection). 
Garbage collection is both an abstraction, since programmers no longer 
manage memory directly, and an indirection, since programmers now use 
APIs that call malloc and free.  We all agree GC is good, so explicit is 
definitely not always better than implicit.


Thanks for explaining Explicit is better than implicit,
except when it's not.

To say something is bad only because it's implicit or abstract is a poor 
argument, but to say something is bad because it's a leaky abstraction 
is an argument that can be explored further. 


That's not what I was refering to.

 For example, it's not very
sensible to say implicit acquisition is bad because it's implicit, but 
it is quite sensible to say it's bad because it leaks all attributes and 
forces a lot of code to be aware of wrappers.


All abstractions have their dark side.  Things can have strengths and 
weaknesses.

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 have
an inherent cost and use them when the benefit doesn't outweigh the cost.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

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 better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage 
collection). Garbage collection is both an abstraction, since 
programmers no longer manage memory directly, and an indirection, 
since programmers now use APIs that call malloc and free.  We all 
agree GC is good, so explicit is definitely not always better than 
implicit.



Thanks for explaining Explicit is better than implicit,
except when it's not.



which is strictly equivalent to Implicit is better than explicit, 
except when it's not. :-) and when it's not ... explicit is better.


/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Stephan Richter
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
 have an inherent cost and use them when the benefit doesn't outweigh the
 cost.

He he. :-) Was this a Jim brain teaser? :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Shane Hathaway

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 better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage 
collection). Garbage collection is both an abstraction, since 
programmers no longer manage memory directly, and an indirection, 
since programmers now use APIs that call malloc and free.  We all 
agree GC is good, so explicit is definitely not always better than 
implicit.



Thanks for explaining Explicit is better than implicit,
except when it's not.


Admittedly, I should have posted that in my blog, not here. :-)

Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

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 maybe: a desire to argue pedantics is better than a desire to  
write code (and configuration wink).


Zac



yes, there is a lot of truth in what you wrote, and the opposite too.. 
maybe the zope philosophical findings should be published in a book :-)


/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Dieter Maurer
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 
else should be done in Python code, as configuration in Python code is 
more flexible and packages can form a more self-contained whole. ZCML 
should reflect the underlying universality of the component architecture.

If two directives work with, say, adapters underneath, they should 
really be one directive. ZCML should be simple and minimal so it is easy 
to grasp.

ZCML is not readable standalone. ZCML is simply used to turn on various 
adapters and such, hooking them into the system, but we do not get a 
clue what the adapters are doing by just looking at the ZCML - Python 
code needs to be consulted.


I believe that this interpretation is the up-and-coming interpretation 
of ZCML.

I hope not...

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).

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Lennart Regebro
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 tend to agree.

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Shane Hathaway

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 Python code, as configuration in Python code is 
more flexible and packages can form a more self-contained whole. ZCML 
should reflect the underlying universality of the component architecture.


If two directives work with, say, adapters underneath, they should 
really be one directive. ZCML should be simple and minimal so it is easy 
to grasp.


ZCML is not readable standalone. ZCML is simply used to turn on various 
adapters and such, hooking them into the system, but we do not get a 
clue what the adapters are doing by just looking at the ZCML - Python 
code needs to be consulted.




IOW, most of the directives we need have already been invented. [1]  We 
don't want to build high level directives; ZCML will follow the BASIC 
school of language design. :-)


[1] http://www.inventionmysteries.com/article4.html

While I was initially on board with the idea of reducing the number of 
directives, I've changed my mind.  I think we want high level directives 
and we want people to feel free to write new directive types.  We want 
tools that let us inspect and search the resulting low level directives. 
 If we have to use ZCML, then ZCML should be expressive.


Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Jeff Shell
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
  (but with reading of the component documentation).

 +1 The first time I saw:

 adapter factory=.MyFactory /

 I was a bit disturbed.  What's the point?  It tells you nothing unless you
 refer to the actual implementation.  Why not just put the registration in
 python alongside the implementation if that's where the configuration of
 provided and required interfaces is going to be?  I had considered one of
 zcml configuration's greatest benefits was that it could give a high level
 overview of how pieces of a package were interconnected.  Of course it's
 still possbile to do things the old way, but I get the impression that it's
 discouraged.  Brevity is not always a boon, though that cuts both ways here
 (adding a new magical seeming zcml declaration to save a copy/paste here
 and there may not be the best idea either).

I consider one of ZCML configurations greatest detriments is that it
does many things that cannot be easily replicated in Python (one day,
you'll probably come across having to set up just the right unit test
harness and you'll realize what I mean).

I consider one of it's greatest detriments is that it completely
destroys Don't-Repeat-Yourself. You can do:

adapter factory=.MyFrank
provides=.interfaces.IFrank
for=.interfaces.IBun .interfaces.IRelish
/

class MyFrank(object):
def __init__(self, context):
# ...

See? No declarations on MyFrank that says what it does. Or you can do:

class MyFrank(object):
implements(IFrank)
adapts(IBun, IRelish)

def __init__(self, context):
# ...

And do the full adapter line in ZCML. But then you've just said the
implements / adapts twice. Using different words, I should point out.
Or you can do the adapter line the short way and let the Python code
say what it does.

Three options. I know I'm not consistent with the ones that I choose.
I just know that I spend more time looking at Python code and I'd
rather understand what the Python code is doing by looking at the
Python code.

Three options. That sure kills the there should be one, and only one,
obvious way to do it theory too. Don't even get me started about when
I might want to use 'zope:view', 'browser:view', or just plain old
'adapter' (since a view is just a multi adapter, as are content
providers and viewlets and all sorts of other fun and useful
combinations).

Anyways - for me, the point of adapter factory=.MyFactory is that
I already said in MyFactory that it implements and adapts certain
interfaces already. I don't want to say that twice. 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?

And I also think it's important for code to be debuggable,
inspectable, so that when there's a bug from ... well, wherever it
came from, code can be traced. It's very hard to trace through ZCML
statements, and what they've produced. From dynamically made classes
to the weirdness of the metaconfigure.py code (handlers,
discriminators, etc) - all of those things get in the way of a
productive pdb or why is this thing blowing up? session real fast.
In my experience anyways. So I figure - the less ZCML I use, the
better it will be for me to maintain in the future.

--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Alec Mitchell
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, utilities, security requirements, and little else. Everything
 else should be done in Python code, as configuration in Python code is
 more flexible and packages can form a more self-contained whole. ZCML
 should reflect the underlying universality of the component architecture.
 
 If two directives work with, say, adapters underneath, they should
 really be one directive. ZCML should be simple and minimal so it is easy
 to grasp.
 
 ZCML is not readable standalone. ZCML is simply used to turn on various
 adapters and such, hooking them into the system, but we do not get a
 clue what the adapters are doing by just looking at the ZCML - Python
 code needs to be consulted.
 
 
 I believe that this interpretation is the up-and-coming interpretation
 of ZCML.

 I hope not...

 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).

+1 The first time I saw:

adapter factory=.MyFactory /

I was a bit disturbed.  What's the point?  It tells you nothing unless you 
refer to the actual implementation.  Why not just put the registration in 
python alongside the implementation if that's where the configuration of 
provided and required interfaces is going to be?  I had considered one of 
zcml configuration's greatest benefits was that it could give a high level 
overview of how pieces of a package were interconnected.  Of course it's 
still possbile to do things the old way, but I get the impression that it's 
discouraged.  Brevity is not always a boon, though that cuts both ways here 
(adding a new magical seeming zcml declaration to save a copy/paste here 
and there may not be the best idea either).

Alec
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Jeff Shell
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, utilities, security requirements, and little else. Everything
 else should be done in Python code, as configuration in Python code is
 more flexible and packages can form a more self-contained whole. ZCML
 should reflect the underlying universality of the component architecture.
 
 If two directives work with, say, adapters underneath, they should
 really be one directive. ZCML should be simple and minimal so it is easy
 to grasp.
 
 ZCML is not readable standalone. ZCML is simply used to turn on various
 adapters and such, hooking them into the system, but we do not get a
 clue what the adapters are doing by just looking at the ZCML - Python
 code needs to be consulted.
 
 
 I believe that this interpretation is the up-and-coming interpretation
 of ZCML.

 I hope not...

 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 think differently. ZCML is primarily for programmers. ZConfig style
configuration is what administrators deal with more, isn't it? Maybe
ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files.

I don't think of ZCML as administrative configuration.

I'd rather have Python files that I can read and understand what's
going on without having to consult ZCML files, directives,
documentation, and so on, just to understand why a certain class whose
code I'm looking at is getting its behavior when I can see no
superclass. I'd like to know that a class I'm looking at is an adapter
and what it provides and what it adapts without having to dig through
a large ZCML file.

An administrator is not likely to override my 'inplace_editor' view.
He may want to configure global services (if my application is written
that way) such as RDB connection parameters and mail services. But
beyond that, just loading it up in package-includes or in a specific
file is likely to be the bulk of 'administrative' effort.

Did administrators go into your ``initialize(context)`` functions in
your Zope 2 Product's __init__.py files and change things? That's what
I view ZCML as being - a better version of that. (Better in only that
configuration and initialization can be executed separately from
Python imports)

--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Jeff Shell
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 requirements, and little else. Everything
  else should be done in Python code, as configuration in Python code is
  more flexible and packages can form a more self-contained whole. ZCML
  should reflect the underlying universality of the component architecture.
 
  If two directives work with, say, adapters underneath, they should
  really be one directive. ZCML should be simple and minimal so it is easy
  to grasp.
 
  ZCML is not readable standalone. ZCML is simply used to turn on various
  adapters and such, hooking them into the system, but we do not get a
  clue what the adapters are doing by just looking at the ZCML - Python
  code needs to be consulted.
  

 IOW, most of the directives we need have already been invented. [1]  We
 don't want to build high level directives; ZCML will follow the BASIC
 school of language design. :-)

 [1] http://www.inventionmysteries.com/article4.html

 While I was initially on board with the idea of reducing the number of
 directives, I've changed my mind.  I think we want high level directives
 and we want people to feel free to write new directive types.  We want
 tools that let us inspect and search the resulting low level directives.
   If we have to use ZCML, then ZCML should be expressive.

Then why do we have Python? Is Zope going to be a write ZCML
directives to write your Zope app system? Or is it going to be write
Python code to write your Zope app system?

I don't know if it's possible to use a ZCML configuration-execution
outside of ZCML, which makes testing an awful hard beast sometimes.
There's functionality that's locked away inside the directives that
you then have to have not only the Zope environment set up to run, but
a ZCML environment too. Pain pain pain pain pain.

Unlock the magic. If it must exist, make it available and
understandable to me. Don't hide it under more layers and verbs and
nouns that conflict and change meaning depending on if you're using
ZCML and Python.

Make ZCML More Expressive - did we learn nothing from DTML
Expressions? It starts out simply enough, but how long until we have
more and more logic in ZCML? We already have this conditional that I
barely understand (but appreciate in theory).

Why design a language at all? I only want ZCML to allow me not to take
on a packages provided components when I import it. I don't want to
start thinking I can write an enterprise workflow and document
management system in it. Let Python be the language. Let ZCML exist to
do the final step of loading/registering registerable objects in a
predictable manner, and to provide the few things that we don't want
to pollute our (or others) Python code with, like security
declarations.

--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Sidnei da Silva
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 one of the points of
'Why ZCML' is that it allows you to 'do stuff' (configuration?) with
plain python code that wasn't written for, nor depends on, Zope 3
directly.

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 there gives you this.

-- 
Sidnei da Silva
Enfold Systems, Inc.
http://enfoldsystems.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Shane Hathaway

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 pass by unnoticed is that one of the points of
'Why ZCML' is that it allows you to 'do stuff' (configuration?) with
plain python code that wasn't written for, nor depends on, Zope 3
directly.

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 there gives you this.


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.


Shane
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Jim Fulton

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 be done in Python code,


Sort of.

 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.

The problem with some of the high-level ZCML directives is that
they performed *definition* in addition to configuration.
For example, browser:page creates new classes.

It's important that definition be done in Python. Configuration
should be done in ZCML.

Should there be high-level directives in ZCML?  I don't think they should
be disallowed, but you really have to ask yourself if the automation they 
provide
is worth the extra burden of understanding what they do.

Anyway, the main thrust of the ZCML simplification is to use it just for
low-level configuration, not for definition.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Jim Fulton

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 I mentioned in my recent proposal),
ZCML provides low-level configuration. It is aimed at developers,
not adminstrators.  Adminsitrators will use high-level configuration
languages like ZConfig or ConfigParser.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Paul Winkler
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
repetition is expressed. One thing I learned in my long-ago days as a
music student is that the least repetetive way to write a score is often
the most difficult to sight-read.  The stupidest, most repetitive
way to write the score is very easy to read; it's completely linear, so
the reader can't get lost.  You can notate repetition easily enough, and
make the score more compact, at the expense of requiring the reader to
mentally construct the linear model and maintain more mental state
while playing.

I have no idea whether any of that applies to ZCML, so I'll re-lurk now.

-- 

Paul Winkler
http://www.slinkp.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Jim Fulton

Alec Mitchell wrote:
...

adapter factory=.MyFactory /

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 implementation if that's where the configuration of 
provided and required interfaces is going to be? 


No, that's where the declaration is.  For smaller (non-Zope)
applications, you could configure them in Python.  For Zope,
we want people to override your configuration without modifying
your code.  ZCML lets them do that.


 I had considered one of
zcml configuration's greatest benefits was that it could give a high level 
overview of how pieces of a package were interconnected.  Of course it's 
still possbile to do things the old way, but I get the impression that it's 
discouraged.  Brevity is not always a boon, though that cuts both ways here 
(adding a new magical seeming zcml declaration to save a copy/paste here 
and there may not be the best idea either).


I understand how you feel here.  It *would* be nice to have the information
in both places *if* you didn't have to maintain it in both places.  There is
a tradeoff between avoiding duplication and making things cleared for the person
reading ZCML.  If I have to choose where to put the information, I far prefer
having it in Python.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] what is ZCML?

2006-03-13 Thread Sidnei da Silva
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 Systems, Inc.
http://enfoldsystems.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com