[Zope3-dev] Re: z3 in z2 land, zcml vs. yaml, and a new year

Jim Fulton jim at zope.com
Mon Jan 5 10:25:36 EST 2004


tav wrote:
> rehi all,
> 
> i just spent the last week scouring through the zope 3 source, list and
> wiki, and it's been one hell of a ride!

:)

> with the exception of zcml, i have been bloody impressed by everything i
> have seen so far. a big thank you to everyone involved. it's been well
> worth the wait.

I'm glad you like it.  The waits not over yet. We've got a lot of work to
do to finish.

> unfortunately, the brilliance of z3 has placed me in quite a dilemma.
> see, i wasn't expecting it to have reached the level of "stability" and
> usability that it has. but now that i know, i am not too keen on going
> back to zope 2 ;p

:)

...

> if i am going to focus exclusively on z3, this effectively comes down to
> assessing some particular features of z2, and how likely (and how soon)
> they are to manifest in z3.

It's very difficult to predict how long things will take because:

- Most of the people working on Z3 are volunteers and have lots
   of other commitments,

- There are so many people who have cool ideas for exciting new
   things, it's often hard to get people working on more basic things.

> 1. full webdav support.

This depends on whether anyone is working on it. Sidnei got
pretty far. I don't know what the current status is.

> 2. python scripts.
> 
>    i understand that persistent modules will be replacing
>    the functionality of python scripts(?)

In part.

In Zope 3, I make a distinction between "software" and "content".

Software is code that applied to many objects. Components
are software. Software is managed in site-management folders,
which are outside the normal content hierarchy.  Persistent
modules are used to create database-managed software in Python.

Content may include "active content", which is content that
includes program ligic. See:

   http://dev.zope.org/Zope3/SiteScripter

and *especially*

   http://dev.zope.org/Zope3/ActiveContent

We haven't decided how we will create active content in Python.
Some folks have threatened to work up a proposal for this, but
that hasn't happened yet.

My leading is to have something module-like along the lines of
Even Simpson's PythonLibraries:

   http://mail.zope.org/pipermail/zope-dev/2003-September/020429.html


...

>    will subpath be supported?

No

>    i appreciate that the scripting community isn't one of z3's
>    current focuses, but i would like to make it one.

Great! Note that just saying you want something to be a priority
isn't going to move things along muchg faster. Contributing will.

>    will these persistent modules be able to implement
>    interfaces?

Sure.

 >    i.e. could one verfiy that a given persistent
>    module supports a specific interface?

I don't know what you mean by verify. There are crude tools
that do do partial verification.

>    i see a lot of potential for introspectable components
>    created ttw, and dynamically exchanged and utilised over
>    the web/plex...

Yup.  You should look at:

http://dev.zope.org/Zope3/ThroughTheWebDevelopmentInZope3

which lays out my vision for TTW site development, including automated
software product installation and management.

> 3. utilities.
> 
>    am i right in understanding that utilities are effectively
>    "localised" services?

No.  Utilities are no more local that services.

We've said that services are akin to CMF tools, however, we will
more often use utilities where the CMF uses tools.

Utilities are just components that are registered by interface
and name.  Utilities will be used for a variety of purposes, including
database connections, workflows, factories, and so on.  They are
persistent in the sense that a single instance may be created
and used over and over. This is in contrast to adapters (and views),
which must created for each use.

>    how does one go about creating them? (can one create them?)

For file-sustem created utilities, this is described in the programmer
tutorial:

   http://dev.zope.org/Zope3/Zope3PythonProgrammerTutorialChapter1

Implementation of TTW utilities hasn't been well documented. You
should be able to figure it out by looking at src/zope/app/services/utility.txt.


> 4. zodb throw-aways.
> 
>    i noticed a few messages suggesting that z3 zodbs need to
>    be occassionally thrown away.

This has been overstated, IMO.  This has also been rather frustrating,
as I have gone through a lot of effort to avoid the need for this.

There are 2 issues:

1. Zope 3 uses ZODB 4 and ZODB 4 doesn't have broken-object support.
    If you remove or otherwise break a class for an object stored in the
    ZODB, you will be unable to load the folder containing that object.
    If that folder is the root folder, you're toast.

    I hope, by the end of the month, to switch Zope 3 to using ZODB 3.
    (We are suspending development of ZODB 4 indefinately.)

2. We have performed some very major refactorings in Zope 3. This is
    a good thing. I have endeavored to include automated data conversion
    as part of these refactorings.  Unfortunately, I have been unable to
    get people to test the data conversions prior to making releases.
    I think that this is because it hasn't really been a high priority
    for people to keep their existing databases, which is OK.  <shrug>

...


> 5. __used_for__.
> 
>    everyone seems to specify a __used_for__ in their views/adapters,
>    but after much grepping of zope source code, i couldn't figure
>    out what exactly the attribute is used for.

This is discussed briefly in the tutorial.

>    is this merely a helpful convention for people reading the source,
>    or is there some magick that i am not aware of?

A this point, yes.  I had planned to provide some machinery to compare
__used_for__ with registrations in ZCML as a sort of a type check. For
various reasons, this never happened.

I think that the main value of this is as documentation.  I have some ideas
for a nicer syntax, but there are more important things to do at this point.



> 1. interfaces.
> 
>    i understand that z3 interfaces and z2 interfaces differ
>    substantially.
> 
>    so, can i simply grab zope.interface and zope.schema from z3
>    and use them in z2?
> 
>    i don't see why, but one can never be too sure in the magical
>    world of z2. will things break if i do so?

As Casey mentioned, there's an alternative Interface package
that allows Zope 3 interfaces to be used in Zope 2.


> 2. new-style classes.
> 
>    why exactly are all classes in z3 new-style classes?

Well, they aren't.  We *do* need to use new-style classes for
Persistent objects for the same reasons we used ExtensionClass
in Zope 2.

Other than that, you can use aby sort of classes you want.

>    can i simply use new-style extensionclass from zope HEAD,
>    and then specify new-style classes in z2?
> 
>    does everything needed for this work now, or do changes
>    have to be made still?
> 
>    can i use old-style classes and then move onto new-style ones?
>    what are the implications of this?
> 
>    i apologise for my ignorance on this front, but would
>    appreciate some enlightenment.

np

It doesn't matter what sorts of classes you use for adapters
and views.  If you are creating content components in Zope 2,
those will need to be classic Zope objects. (This may begin to change
in Zope 2.9).



> now, i understand that some of you (zope corp and martijn in
> particular), have made use of z3 in z2 land.
> 
> is this true?

Yes.

 > if so, could you please provide some brief details? many
> thanks!

Well, Casey shared some info.  I'm hoping we can find some time soon
to write our experience up more formally.

...

> finally, on the topic of zcml, i have to unfortunately express serious
> discontent =(

Sorry to hear that.

> i was obviously not there when the decisions were made, so arguably i
> have no right to be discontent, but i shall make a plea nevertheless.
> 
> zcml terrifies me.

I think you are overreacting.

> and, i am not alone in this regard.
> 
> zcml will be, as far as i can tell, the biggest barrier to zope3 adoption.

Perhaps, but I doubt it.

> separation of component configuration is obviously quite attractive,

Yup.

 > but
> i have to ask... is it necessary for it to be so "powerful" ?

I don't know what you mean. I don't think ZCML is all that powerful,
or really complex.

> it reminds me a lot of the rdf world, where certain attractive
> abstractions were implemented, resulting in something so complex and
> powerful that in 6 years of rdf, very little of value has been achieved.

Well, we really have implemented only what we needed. ZCML has gone through
one major refactoring driven by experience and need.

> secondly, if it's seen to be absolutely necessary, can we at least use
> an alternative format? emacs with the nxml-mode makes zcml just about
> palatable, but unless i had spent a *lot* of time developing in it, i
> would still be terrified by it.

Your terror is puzzling to me.  I'll admit that I don't find XML
very pretty, but it certianly isn't scary.  Something nice about it
is that it is a *standard* syntax.

> can i suggest yaml <http://yaml.org> as a potential alternative. e.g.

Sure, but it won't do you any good. :)

This has been discussed at length. There are waaaaay more important
things to do than mess with the configuration syntax,

This is not going to be changed any time soon.

> compare and contrast:
> 
> ----
> <adapter
>    for=".interfaces.IWikiPage"
>    provides="zope.app.interfaces.file.IWriteFile"
>    factory=".wikipage.WikiPageWriteFile"
>    permission="zopeproducts.zwiki.EditWikiPage"
>    />
> <event:subscribe
>     subscriber=".wikipage.mailer"
>     event_types="zope.app.interfaces.event.IObjectAddedEvent
>                  zope.app.interfaces.event.IObjectModifiedEvent
>                  zope.app.interfaces.event.IObjectRemovedEvent
>                  zope.app.interfaces.event.IObjectMovedEvent" />
> ----
> 
> with something like:
> 
> ----
> adapter:
> 
>  for:		.interfaces.IWikiPage
>  provides:	zope.app.interfaces.file.IWriteFile
>  factory:	.wikipage.WikiPageWriteFile
>  permission:	zopeproducts.zwiki.EditWikiPage
> 
> event:
> 
>  subscriber: .wikipage.mailer
> 
>  event_types:
>   - zope.app.interfaces.event.IObjectAddedEvent
>   - zope.app.interfaces.event.IObjectModifiedEvent
>   - zope.app.interfaces.event.IObjectRemovedEvent
>   - zope.app.interfaces.event.IObjectMovedEvent
> ----
> 
> the latter is, imho, far far easier to read and more pleasant to work with.

I respeectfully disagree. I far prefer the xml syntax because I know how to
parse it. It's standard.

...

> i hope my criticism on this front doesn't offend anyone. i am simply
> keen to maximise adoption of zope 3 and make my own usage of it a
> pleasurable one.

Fair enough. I hope my rejection on this front, at least for now, doesn't
offend you.


> and, finally finally, can i propose starting afresh on a new zope 3 wiki
> for the new year?

Great. When do you want to get started on it? ;)

> there's a wealth of information lost amidst the list and the current
> wiki. but most of it is not accessible in an ordered manner, some of it
> is out of date, etc.
> 
> starting afresh (on zope3.org?) will give us a good firm foundation to
> point to and attract new developers. i am willing to dedicate my
> energies towards this. how do i start?

Starting over may seem like an easier way to start, but I really
don't think it is.  I think it would help much more to review/garden what's
there.

If you want to play with starting over, you are free to take a stab at it.

> despite my zcml criticism, it truly is an exciting time to be a zope
> developer.

Great!

> and, again, a big thank you to all involved. have a great new year!

Let's all work together this year to:

- Get Zope X3 out!

- Begin the transition from Z2 to Z3 by getting Zope 2.9 out as
   soon as we reasonably can.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org





More information about the Zope3-dev mailing list