Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

2006-03-13 Thread Chris Withers

Jim Fulton wrote:

I don't want to try to make paste deploy or setuptools,
use ZConfig.  There are other tools out there that use
ConfigParser,


Yay! Lowest common denominator programming :-(


I'd like to be able to use configuration files for the
test runner, but I really don't want ZConfig to be a
dependency of the test runner.  I also don't want to
go through all of the gymnasics required to develop a ZConfig
schema just for the test runner.


What are these gymnastics you speak of?

This isn't all that common. 


Hmmm, the number of DeprecationWarnings I seem to see with Zope 
3-related stuff would appear to disagree with that...


...but maybe that's another thread.


Note that in my proposal, I proposed supporting the ZConfig
format, at least for a while.


Isn't there some way we could make this switchable so we don't have to 
make either/or choices?

(I'd still be verymuch in favour of seeing ZConfig as the default.)


I assume this was done because it's too much of a PITA to write ZConfig
schemas.


I think you assume wrong there...


Paste Deploy provides a framework for doing
this.  I'd rather colaborate on something that exists that
have to reinvent it just to keep using ZConfig.


Well, maybe they could use ZConfig? Has anyone asked them?
Either that or make the config switchable for the edge case where you 
want to use paste deploy. But please, don't force a change like this 
through for one particular piece of interoperability that not many of us 
seem to feel as passionately about as you :-S


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

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



Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

2006-03-13 Thread Chris Withers

Jim Fulton wrote:

Would it be possible to write a configuration file that loaded
it's own schemas?  


Not sure what you mean...


For example, suppose I wanted to configure
zope and twisted, could I do something like:

  import zope.app.appsetup
  import zope.app.twisted
  import zope.testrunner


I think it's %import you're looking for.


  site-definition site.zcml


%import site.conf? ;-)


  interrupt-check-interval 200

  server
type HTTP
address 8080
  /server

  zodb
filestorage
  path Data.fs
/filestorage
  /zodb

  accesslog

logfile
  path access.log
/logfile
  /accesslog

  eventlog

logfile
  path z3.log
/logfile

logfile
  path STDOUT
/logfile
  /eventlog

  tests-pattern f?tests$
  tests-path src
  module-pattern 
!^(ZConfig|BTrees|persistent|ThreadedAsync|transaction|ZEO|ZODB|twisted|zdaemon|zope[.]testing|)[.] 


Okay, not sure what the troublesome bit of the above is...


Then free the main program from having
to specify a schema?


Again, not sure what you mean...

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

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



Re: [Zope3-dev] a new zcml directive?

2006-03-13 Thread Martijn Faassen

Lennart Regebro wrote:

On 3/10/06, Martijn Faassen [EMAIL PROTECTED] wrote:


For instance, one that looks like this:

zope:annotation for=IBar factory=Foo /



That doesn't look like configuration.


What does it look like to you?

If hooking up adapters is considered to be configuration, why is hooking 
up annotations not configuration?


Regards,

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



[Zope3-dev] Re: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings

2006-03-13 Thread Philipp von Weitershausen
Jim Fulton wrote:
 Log message for revision 65931:
   Redeprecated a number of things that didn't generate warnings
   before. Sigh. Also fixed all the depecation warnings generated by
   running the zope.component tests.
   

...

 Added: Zope3/branches/jim-adapter/src/zope/component/back35.py

I'm certain that the stuff in this file was already deprecated (and
generated deprecation warnings), so I think we can definitely get rid of
it and don't need to keep it around.

...

 ===
 --- Zope3/branches/jim-adapter/src/zope/component/back35.py   2006-03-12 
 21:46:52 UTC (rev 65930)
 +++ Zope3/branches/jim-adapter/src/zope/component/back35.py   2006-03-12 
 21:46:54 UTC (rev 65931)
 @@ -0,0 +1,133 @@
 +##
 +#
 +# Copyright (c) 2006 Zope Corporation and Contributors.
 +# All Rights Reserved.
 +#
 +# This software is subject to the provisions of the Zope Public License,
 +# Version 2.1 (ZPL).  A copy of the ZPL should accompany this distribution.
 +# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED
 +# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 +# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
 +# FOR A PARTICULAR PURPOSE.
 +#
 +##
 +Features that will be deprecated in Zope 3.5
 +
 +$Id$
 +
 +import sys
 +import warnings
 +
 +from zope.interface import Interface, providedBy
 +from zope.component.bbb.interfaces import IServiceService, IDefaultViewName
 +from zope.component.service import GlobalServiceManager
 +
 +# Try to be hookable. Do so in a try/except to avoid a hard dependency.
 +from zope.hookable import hookable
 +
 +def getGlobalServices():
 +from zope.component import getGlobalSiteManager
 +return GlobalServiceManager('servicemanager', 'zope.component.service',
 +getGlobalSiteManager())
 +
 +def getGlobalService(name):
 +return getGlobalServices().getService(name)
 +
 +def getServices(context=None):
 +if context is None:
 +return getGlobalServices()
 +else:
 +# Use the global service manager to adapt context to IServiceService
 +# to avoid the recursion implied by using a local getAdapter call.
 +try:
 +return IServiceService(context)
 +except TypeError, error:
 +from zope.component.bbb.exceptions import ComponentLookupError
 +raise ComponentLookupError(*error.args)
 +
 +getServices = hookable(getServices)
 +
 +def getService(name, context=None):
 +return getServices(context).getService(name)
 +
 +def getServiceDefinitions(context=None):
 +return getServices(context).getServiceDefinitions()
 +
 +# Presentation API
 +
 +def getView(object, name, request, providing=Interface, context=None):
 +view = queryView(object, name, request, context=context,
 + providing=providing)
 +if view is not None:
 +return view
 +
 +from zope.component.bbb.exceptions import ComponentLookupError
 +raise ComponentLookupError(Couldn't find view,
 +   name, object, context, request, providing)
 +
 +def queryView(object, name, request,
 +  default=None, providing=Interface, context=None):
 +from zope.component import queryMultiAdapter
 +return queryMultiAdapter((object, request), providing, name,
 + default, context)
 +
 +queryView = hookable(queryView)
 +
 +def getMultiView(objects, request, providing=Interface, name='', 
 context=None):
 +view = queryMultiView(objects, request, providing, name, context=context)
 +if view is not None:
 +return view
 +
 +from zope.component.bbb.exceptions import ComponentLookupError
 +raise ComponentLookupError(Couldn't find view,
 +   name, objects, context, request)
 +
 +def queryMultiView(objects, request, providing=Interface, name='',
 +   default=None, context=None):
 +from zope.component import queryMultiAdapter
 +return queryMultiAdapter(objects+(request,), providing, name,
 + default, context)
 +
 +def getViewProviding(object, providing, request, context=None):
 +return getView(object, '', request, providing, context)
 +
 +def queryViewProviding(object, providing, request, default=None, 
 +   context=None):
 +return queryView(object, '', request, default, providing, context)
 +
 +def getDefaultViewName(object, request, context=None):
 +view = queryDefaultViewName(object, request, context=context)
 +if view is not None:
 +return view
 +
 +from zope.component.bbb.exceptions import ComponentLookupError
 +raise ComponentLookupError(Couldn't find default view name,
 +   context, 

Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

2006-03-13 Thread Jim Fulton

Chris Withers wrote:

Jim Fulton wrote:





I'd like to be able to use configuration files for the
test runner, but I really don't want ZConfig to be a
dependency of the test runner.  I also don't want to
go through all of the gymnasics required to develop a ZConfig
schema just for the test runner.



What are these gymnastics you speak of?


Have you written a ZConfig schema?  Have you tried to read the
documentation on writing one? Have you writtem an application
that uses ZConfig? If you had, I think you'd know what I was
talking about.

This isn't all that common. 



Hmmm, the number of DeprecationWarnings I seem to see with Zope 
3-related stuff would appear to disagree with that...


These aren't due to new features added and discarded.  This is
generally due to refinement based on experience.

...


Note that in my proposal, I proposed supporting the ZConfig
format, at least for a while.



Isn't there some way we could make this switchable so we don't have to 
make either/or choices?

(I'd still be verymuch in favour of seeing ZConfig as the default.)


I don't know what you are asking, since I said in this thread and in
the proposal that we could support the old format.


I assume this was done because it's too much of a PITA to write ZConfig
schemas.



I think you assume wrong there...


Oh? What evidence do you have?  Do you think it was done because
meaningless options are considered a good thing?


Paste Deploy provides a framework for doing
this.  I'd rather colaborate on something that exists that
have to reinvent it just to keep using ZConfig.



Well, maybe they could use ZConfig? Has anyone asked them?


Why don't you do that.  In fact, why don't you lobby to
have it added to the standard library?

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] RFC: Use ConfigParser for High-Level Configuration

2006-03-13 Thread Chris Withers

Jim Fulton wrote:
Have you written a ZConfig schema? 


Yup, a few, as well as adding a couple of options to zope.conf, which 
totally abuses ZConfig :-/



Have you tried to read the
documentation on writing one? 


Yup :-)


Have you writtem an application
that uses ZConfig? 


Yup, couple...


If you had, I think you'd know what I was
talking about.


Well, admittedly, it's been a while since I wrote the schemas for 
MailingLogger (although that had to be updated for Zope 2.8) and an even 
longer while for Process 
(http://www.simplistix.co.uk/software/applications/process) and X2Y 
(http://www.simplistix.co.uk/software/applications/x2y) but I don't 
remember it being particularly painful.


X2Y, in particular, is quite an extensive app with lots of plugins, each 
with their own schemas, and I just had a look at the schemas again now 
and find them pretty easy to understand.


I must be missing something... is there something particularly complex 
that you're doing?



These aren't due to new features added and discarded.  This is
generally due to refinement based on experience.


potato / potato - tomato / tomato...

Hmmm, that doesn't work so well when it's written down :-/


I don't know what you are asking, since I said in this thread and in
the proposal that we could support the old format.


OK.


I assume this was done because it's too much of a PITA to write ZConfig
schemas.


I think you assume wrong there...


Oh? What evidence do you have?  Do you think it was done because
meaningless options are considered a good thing?


I would assume it's because someone saw an abstraction that wasn't 
really there, as with cache managers in Zope 2.


But, that's just an assumption and likely to be wrong. svn blame may be 
more useful here...



Well, maybe they could use ZConfig? Has anyone asked them?


Why don't you do that.  


I presume 
http://www.webwareforpython.org/archives/list/paste-users.en.html would 
be the right place?



In fact, why don't you lobby to
have it added to the standard library?


Sure, I'll give it a go, but if there's already several in there, I can 
see people being reluctant, even if the ones that are in there are 
inferior :-/


Still, Guido did eventually admit HTMLParser.py, so there's some hope :-)

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Moving to docutils 0.4.0?

2006-03-13 Thread Andreas Jung


I would like to update Docutils for Zope 2 trunk and Zope 3 trunk to v 
0.4.0.


Any objections for

- importing docutils as top-level module on svn.zope.org

- replacing src/docutils with an svn:externals definition

?

Andreas


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



Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

2006-03-13 Thread Stuart Bishop
Jim Fulton wrote:

 Have you written a ZConfig schema?  Have you tried to read the
 documentation on writing one? Have you writtem an application
 that uses ZConfig? If you had, I think you'd know what I was
 talking about.

I have. Our chunk of our schema.xml is over 600 lines including comments and
whitespace and defines 22 sections.

We needed a configuration mechanism for Launchpad and related tools. I
decided to go with ZConfig to integrate our configuration with the rest of
the Z3 configuration. This was with Zope 3.0 and integrating our config with
the Z3 config was quite problematic.

We gained a little doing it this way. Having the Z3 configuration with our
own configuration information made is easy to maintain the multiple configs
we need to maintain (several production configs and developer workstation
configs, maintained in the RCS alongside the code). In theory, we could
generate documented configuration templates but we haven't done that -- we
just maintain the commends in 'default' configuration.

We lost a fair bit of flexibility doing it this way. Field validation needs
to be done the ZConfig way. There are issues with non-required fields in
non-required sections giving us grief. There seem to be namespace issues,
despite being hierarchical (eg. we have librarianlibrarian_server
instead of just librarianserver, it seems because server is already
used by Z3 so we can't call our section that). These issues might be ZConfig
in Z3.0 issues, or problems with how we are using it. If the issues we are
having are our fault, I would also call that a problem with ZConfig as the
documentation is not detailed enough to match ZConfigs complexity. Pulling
in configuration information should be light weight, but I find ZConfig puts
too much burden on developers for little gain. Despite being very complex,
it seems to lack features that we need or the features don't work the way we
need them too (eg. we really need to say 'this config file is identical to
that one, except these fields are changed. Extending ZConfig to do this did
not seem fun.).

An alternative would have been a .ini or xml format similar to what you have
already described. I elected to proceed with ZConfig to see how we went and
to integrate our config with Zope3's. In hindsight, I think we would have
had a simpler, more flexible and more easily extensible system if we had
gone with .ini or xml instead.

Migration for us shouldn't be a problem, we access to our configuration is
via a simple API so we can replace the guts. I expect to reimplement our
config machinery when I get a chance to work on low priority tasks (we have
issues with what we have, but it works).

So +1 I guess. Although I personally would prefer using XML, as I think it
will be more readable for complex configurations as it is better able to
represent heirarchies and provide more flexibility to developers.

-- 
Stuart Bishop [EMAIL PROTECTED]
http://www.stuartbishop.net/



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



Re: [Zope3-dev] a new zcml directive?

2006-03-13 Thread Stephan Richter
On Monday 13 March 2006 06:20, Martijn Faassen wrote:
 In your example, the ZCML doesn't show that we actually are setting up
 an annotation, and it doesn't show for what we're setting up an
 annotation for in the first place either. It's one intrepretation of
 ZCML that it should show these things. The other interpretation of ZCML
 is that its main task is just hooking components into the system.

Yes, I agree with that. I tend to like the first one and use it that way. I 
commonly  use the ZCML File of a package to get an overview of what features 
it provides.

 Perhaps we should make explicit which ZCML we want to have, as its
 design can be quite different depending on that choice.

Yes, I think this would be a good idea.

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] a new zcml directive?

2006-03-13 Thread Gunnar Wrobel
Stephan Richter [EMAIL PROTECTED] writes:

 On Friday 10 March 2006 10:19, Martijn Faassen wrote:
 What do people think?

 +1 We use this pattern for every annotation in SchoolTool and it gets old 
 really quick. One argument that could be made is that the code in the 
 function could be in the constructor. This is bad, because the __init__ 
 method should not do any writing on other objects.


I looked at the schooltool code a while ago and the annotation thing
was something that I also noted as duplicated in there. Since I wanted
to use annotations in a similar way I wrote a package that defines
such an annotation ZCML directive.

You can download the package here:
http://dev.gentoo.org/~wrobel/zope.annotation.tar.bz2. It still has a
weird hack in the README.txt and is not polished in any way but I
believe it should work. I am a Zope3 newbie so don't expect too much
From the thing. But I thought it might be of interest to the ongoing
discussion.

Don't hesitate to tell me why the package sucks :) Still eager to
learn more about Zope.

Regards

Gunnar

-- 
Gunnar WrobelGentoo Developer
__C_o_n_t_a_c_t__

Mail: [EMAIL PROTECTED]
WWW:  http://www.gunnarwrobel.de
IRC:  #gentoo-web at freenode.org
_


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



Re: [Zope3-dev] zc.table and zc.resourcelibrary feedback

2006-03-13 Thread Martijn Faassen

Benji York wrote:
Martijn Faassen wrote: 

[snip]
A second issue seems to me a bug in the javascript. When I use 
StandaloneSortFormatter I can click on the title of a column to sort

to see a sorted view. This works wonderfully well. Unfortunately the
 javascript is a bit simplistic in that it simply adds the
sort_on:list parameter over and over to the URL. This makes for very
long and ugly URLs. Want me to work on a bugfix?



Please.  The current JavaScript is very much the simplest thing that
will possibly work.


I looked into it and have written some new JavaScript, but I realized 
that the sorting behavior currently is apparently dependent on the 
amount of items in the 'sort_on' list in the URL. As far as I can 
understand, getRequestSortOn flips the sorting order for each time a 
particular field is mentioned in the URL. I don't know how exactly this 
works in the case of form-based tables, where this information is, I 
believe, POSTed.


Encoding this information in the amount of times a particular item is 
present in the URL (or post body) seems odd. Was the motivation again 
the simplest thing that will possibly work? To really fix it, the sort 
order itself (forward or reversed) should be encoded in the URL (or 
POST), something like sort_forward=Column or sort_reversed=Column. I 
currently do not understand why this approach wasn't taken in the first 
place...



The third issue is more like a missing feature. I was playing with
the batching support, and I got it to work. Still, I had to write a
bit of batching code myself and to make it fully work, I'd have to
make sure of not showing 'previous' at the beginning of the fist
batch, not showing 'next' at the beginning of the last batch, and the
like.


Yes, when writing zc.table we weren't quite sure how the batching
should/would work and were using it in two independent projects.  Both
eventually grew code that's probably much like you wrote.  It would be
interesting to work on a default batcher.


Maybe I'll get to look into this. I still need to consider how it all 
should work together with sorting. Any hints?


Regards,

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



[Zope3-dev] what is ZCML?

2006-03-13 Thread Martijn Faassen

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. If we're setting up a skin, we use a skin directive. If 
we're setting up an adapter, we use an adapter directive.


Even if two directives underneath only set up adapters (such as 
browser:page and zope:adapter), we still think it's valuable to have two 
directives, as we make explicit what we are doing.


ZCML should be readable without having to consult Python code a lot. 
I.e. if we set up an adapter, we know what interface it's working for 
and we know what interface the adapter is providing just by looking at 
the ZCML.



I believe that the first interpretation is the traditional 
interpretation of ZCML.


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.


(the third interpretation of ZCML is that it's evil and should be 
destroyed I'd like to leave out of this discussion - the outcome doesn't 
matter that much if you're of that persuasion)


Of course, these interpretations have never been made very explicit. We 
have discussions where they are implicitly present, though. Reducing the 
namespaces in ZCML drastically makes more sense from the second 
perspective than from the first. Adding a new ZCML directive to support 
annotations makes more sense from the first and doesn't make much sense 
from the second interpretation.


Which one of these interpretations is the right one for the future?

I realize that the interpretations I sketch out may be extreme ends of a 
spectrum. I haven't seen a lot of advocacy the removal of browser:page, 
for instance. It may be that the real ZCML should be in the middle of 
these two interpretations. If so we should make our criteria explicit 
somehow, too - when do we really want to add a directive, and when do we 
really not want to remove a directive?


Perhaps there is whole other perspective possible on ZCML that resolves 
this whole issue. Let us know if you have one!


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] zc.table and zc.resourcelibrary feedback

2006-03-13 Thread Gary Poster


On Mar 13, 2006, at 10:59 AM, Martijn Faassen wrote:
[...]

Thanks for looking into this Martijn.  We have some internal versions  
of a sortable zc.table factory that take a different approach, and  
are not using the client-side part of the zc.table code much at all.   
If you're willing to look at it and consider integrating it into  
zc.table, one of us will send you the files privately.  You up for that?


BTW, I think I listed in the release announcement that both of these  
packages could use some TLC.  Thank you generally for considering  
giving them some!


I would love to see resourcelibrary developed in these directions, fwiw:

- pluggable insertion, to address one of the concerns in your  
original message.  I don't remember exactly what Benji and I talked  
about.  Maybe the resources would not be snippets but callable  
transformations.  Maybe we could provide a factory for one kind of  
transformation which could be combined to effectively get the same  
behavior as our current transformation?  A piece of code could  
request a transformation, which might depend on other  
transformations?  Maybe this is too general.


- order-aware dependency insertion: IIRC, the algorithm for gathering  
the necessary dependencies doesn't honor order, which may be a  
problem in some cases.  order-aware could get fragile, though--for  
instance, if one resource says it depends on A and then B, and  
another says it wants B then A, what to do?  Maybe it's necessary to  
have one spelling for order-unaware dependencies, and another for  
order-aware dependencies; maybe that itself is insufficient...


- lighter-weight insertion into the publishing framework.  No one  
(including myself) has followed up materially on Jim's old discussion  
of in-Zope publication pipelines.  The request approach is heavy, and  
maybe a WSGI pipeline element is too heavy also.  It would be nice to  
resolve this, though: replacing the request factory is a bit crazy.


It's not a priority for us to work on these things right now, but we  
open-sourced some of the less-polished packages in hopes that others  
would see their possibilities, as you did, and be intrigued. ;-)


Gary
___
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] RFC: Use ConfigParser for High-Level Configuration

2006-03-13 Thread Dieter Maurer
Jim Fulton wrote at 2006-3-12 15:54 -0500:
Dieter Maurer wrote:
 Jim Fulton wrote at 2006-3-11 18:03 -0500:
 
...
Where is this documented?
 
 
 I do not know. I saw a feature description in the mailing list.
 Fred and Tres (the authors) should be able to tell you whether
 there is a formal documentation and where you can find it.
 
 
Let's pursue this a bit.

Would it be possible to write a configuration file that loaded
it's own schemas?
 
 
 Yes -- with some restrictions: as I described in my previous mail.
 
   The feature essentially works as follows:
 
  You have an abstract section type in your primary
  schema, usually usable in a multisection.
 
Examples: ZServer server, ZODB storage, the general extension
abstract section type
 
  In your module/package, you define your own section type
  implementing the abstract section type in its component.xml.
  You are completely free in its keys and subsections.
 
  In the configuration file, you import your module/package (which
  makes available the definitions in its component.xml) and
  instantiate one or more of the section types defined there.
 
  Your application/module looks for the sections of its type
  and uses them.
 
   The restriction: you cannot have new keys on the top level -- all
   must be nested in a section type defined by your component.xml.
   But, this, I consider an advantage (ZConfig here behave similar
   to a ConfigParser approach).

So the example I gave won't work.  In a schema, I have to have an
abstract type for each thing I might want to add.  But I don't know what
I want to add.  This doesn't sound very extensible.

You can have a *SINGLE* abstract type -- fixed for any extensions
you may imagine and use this as the hook in your component.xml.

Such a single abstract type was added to the Zope schema to
make almost arbitrary extensions possible.

I can't fathom the ZConfig documentation so I don't really know what
an abstract type is.

It is essentially a name, which can be used at various places
in your schema and implemented at other places in different ways.

 I don't know how restrictive it has to be.
Can I define an abstract type that matched anything?

Yes. I even think you currently cannot impose restrictions on
the sectiontypes claiming to implement the abstract type.

Can I define a schema that just defines an abstract type that
matches anything?

I think you must also use the abstract type in a section/multisection
definition. But that would be all.



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



[Zope3-dev] Broken Tests

2006-03-13 Thread Benji York
It looks like revision 65953 (updated to Docutils 0.4.0) broke the 
unit tests.  For details see 
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/builds/382/test/0 



Andreas, do you have any idea why that might be?
--
Benji York
Senior Software Engineer
Zope Corporation
___
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



[Zope3-dev] Re: New way of using skins

2006-03-13 Thread Philipp von Weitershausen
Florian Lindner wrote:
I think ovarall, Phillip should support those named layers.

That feedback is a little late. The proposal had been around for months!
By the way, from what I read in the old layer code (which seemed to be
yours), I got the impression that named layers and skins were slated for
deprecation but simply not officially deprecated yet.

 Yes, I have my interface registered with:
 
 zope:interface
 interface=.interfaces.ICentershockSkin
 type=zope.publisher.interfaces.browser.IBrowserSkinType
 name=centershock
 /

Note that this makes the interface a skin. Layers don't have to be
registered at all anymore.

 class ICentershockSkin(zope.app.rotterdam.Rotterdam):
 
 
 I've tried to use the name centershock in either a layer or a type attribute, 
 but nothing worked.

You will have to state the layer using standard dotted names to access
the interface, e.g.: layer=.interfaces.ICentershockSkin.

 Only giving the the python path with the layer attribute 
 worked. The type attribute does not even seem to exist, although I understood 
 Philipps proposal that it should replace the layer.
 (tested with a resource directive)

Ooops, sorry, I forgot to properly update the Implementation Status.
Done now.

Philipp
___
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



[Zope3-dev] Re: a new zcml directive?

2006-03-13 Thread Philipp von Weitershausen
Lennart Regebro wrote:
 On 3/10/06, Martijn Faassen [EMAIL PROTECTED] wrote:
 
For instance, one that looks like this:

zope:annotation for=IBar factory=Foo /
 
 
 That doesn't look like configuration.

No, it's an on/off switch. Me likesss it.

Philipp

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



[Zope3-dev] Re: a new zcml directive?

2006-03-13 Thread Philipp von Weitershausen
Marius Gedminas wrote:
 I'd prefer
 
 from zope.annotation.adapter import AnnotationAdapter
 
 getFoo = AnnotationAdapter(for_=IBar,
interface=IFoo,
factory=Foo,
key=FOO_KEY)
 # I suppose the key could be optional; you could use a dotted
 # interface name by default
 
 and then the ordinary
 
 zope:adapter factory=.foo.getFoo /

+10

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



[Zope3-dev] Re: what is ZCML?

2006-03-13 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeff Shell wrote:
 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.

It spells out lots of site policy which must *not* creep back into the
software.

 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.

Really?  You have no options which an admin might want to change, either
on a site-wide basis or within a single folder?  How about choices like
whether to accept HTML 4.0 versus XHTML 1.0?  What about tag blacklists?

 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)

We need to get beyond the idea that Python is the ideal place to spell
everything.  It is particularly bad to have to modify the software
shipped by the developer in order to change policy, which is where we
are going if we continue down this road.  Having to accept choices made
by a component developer is a barrier to reuse;  we won't win brownie
points for all our cool components if we make it hard to use a
comoponent without accepting either *all* or *none* of its configured
policy choices.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEFhdD+gerLs4ltQ4RAptSAJ4lvBZ2f7iwodYUP8l9J4j+nqoYcQCgr5qb
c4HIIpb1Kkm/KuQ7yMYiGdU=
=F/SR
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Broken Tests

2006-03-13 Thread Andreas Jung



--On 13. März 2006 16:49:27 -0500 Benji York [EMAIL PROTECTED] wrote:


It looks like revision 65953 (updated to Docutils 0.4.0) broke the unit
tests.  For details see
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/b
uilds/382/test/0

Andreas, do you have any idea why that might be?


I fixed the problem in managerdetails. Docutils seems to perform tighter 
type checking. Since the reST adapter defines 'unicode' as input_encoding we
need to pass a unicode string (see managerdetails.py). The other problem is 
also already fixed.


Apart from that I did not receive and buildbot mails indicating the error.
Is there a problem with buildbot?

Andreas

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