[Zope-Coders] Zope 3; getting in on the act?

[Martijn Faassen]

Tres Seaver wrote:
> Martijn Faassen wrote:
> >I notice there's a lot of exciting activity on Zope 3. So, can someone
> >tell us external checkin-folks:
> >
> > * what the plan is (is this in the fishbowl?)
> >
> > * how can we help? (implementation help, design help, testing help)
> >
> >I realize adding more people on a project can make it more complex
> >to manage, and you have direct lines of communication to each other,
> >but it seems interesting and I think us contributors might be able to,
> >well, contribute. :)
> 
> The current work is aligned with the ZopeComponentArchitecture
> 
> proposal in the fishbowl:
> 
>   http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage

I've already been tracking this and have contributed various pages probably
way out of sync with Zope Corp thinking about some issues I see
(ExplicitVersusImplicitFeatureWrapping and FeatureFinding). Nobody ever
responded to those..

> and is pushing to remove all the "science fiction" from
> Jim's tutorial:
> 
>   http://cvs.zope.org/Docs/ZopeComponentArchitecture/PythonProgrammerTutorial

But I never heard about this stuff. Is this linked from the wiki? It should
be.

> We could certainly use more feeback, both on the wiki (in particular,
> the "URL madness" page,
>   http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ExplicitNamespaceControlInURLs
> has gotten very little comment)

Well, I read it and think I understand some of the issues. I'm looking at all
this from the perspective of XML DOMs. ParsedXML uses a layer of proxy objects
to add functionality (such as Zope stuff) to the basic underlying DOM nodes.
This is very ComponentArchitecture-like. One issue I'm currently trying
to resolve is that one can have different sets of proxy node wrappers
depending on how one is using the DOM tree. The first is the classic
'expose-DOM-to-Zope' one, but the second is a new XMLWidgets implementation
which allows one to associate other objects with the DOM nodes dynamically
(based on their properties and context). These objects can define new methods
on the DOM node, so the nodes now act as if they're equipped with new
possibilities (such as 'render()').

The problem is that I'd like to let Zope know from an URL that I want it
to wrap the DOM in the widget way and not the default way. Something like:

xmldoc;ns=xmlwidgets/0/5/3

might be useful. Though my response initially to the ';' in URLs is
still eek ooh, icky..

In fact, I am dealing with another problem right now which might be
useful for URL parameters as well. I'm trying to support different ways
of addressing individual DOM nodes in a document through an URL. One way
is a child node index path (the nth child of the nth child of the nth child),
but this has some disadvantages (brittle to changes in the DOM). So I 
have various other schemes with their own advantages and disadvantages, 
but again I have the trouble on how to let the document know I'm using them.

Using URL parameters one could do:

xmldoc;urlscheme=childnodes/0/5/2

xmldoc;urlscheme=elementids/e5/e3/1

xmldoc;urlscheme=id/155B

xmldoc;urlscheme=robust/doc/1/chapter/3/p/1/text/foo/bar/baz

which I think seems neat. How much thought has gone into interfaces to
*generate* these parameterized URLs? I'd like to be able to say something
like: I want a URL to *this* object using *this* scheme.

>, and on the tutorial.

> At this point, we are trying to get enough of the architecture
> stable to remove a couple of gnarly risks;  we will then be in
> a position to enlist volunteers to help build out the "full" Zope
> framework atop the architecture.

Sounds like a good approach.
 
> Our current plan is to build a "Zope 3x" release which makes new
> component development possible (and even easy), while neglecting
> (mostly) forward-compatibility.  The actual "Zope 3.0" release
> will follow, tackling the forward-compatibility problem.

What do you mean by 'forward-compatibility'? Don't you mean backwards
compatibility with Zope 2.x? Or am I missing something here? Anyway,
if I understand you right, that is a good approach. Zope 2.x code should be
supported as best as we can, but it shouldn't be allowed to 
make the new architecture ugly right from the start, by influencing it
everywhere with its sometimes bad and implicit assumptions.

> In the meanwhile, interested parties can check out the current
> "spike" as:
> 
>   $ cvs -d :ext:cvs.zope.org:/cvs-repository co -r Zope-3x-branch Zope3
> 
> and run the (not very interesting, yet) Zope3 server via:
> 
>   $ cd Zope3
>   $ python2.2 z3.py

The source is interesting. I'll be taking a look.

Thanks for the explanations!

Regards,

Martijn