[PEAK] PROPOSAL: Remove ZODB/Zope X3
Phillip J. Eby
pje at telecommunity.com
Tue Jun 1 13:15:22 EDT 2004
At 06:19 PM 6/1/04 +0200, Ulrich Eck wrote:
>On Sat, 2004-05-29 at 23:36, Phillip J. Eby wrote:
> > I've been reviewing the latest version of Zope X3, and it appears to me
> > that it's a waste of time to keep chasing compatibility with it in
> > and peak.model. So, I'd like to propose some changes to the affected
> > ZODB 4 and peak.model
> > ---------------------
> > Anyway, this API should fix a lot of quirks and warts in the current
> > DM-based API, such as the inability to check whether an object "exists" at
> > retrieval time. I'll probably write other posts later to flesh out this
> > design further, and the path along which the existing code will be
>+ 1 ( +10 for eventSource integration )
> > Zope X3 and peak.web
> > --------------------
> > Thus, I believe we can end our dependency on Zope X3 for publishing
> > support, but the changes to peak.web will be substantial. In addition to
> > the changes I've outlined above, we would also be dropping the use of
> > adaptation to convert components to their decorator/view objects. We'll
> > still have decorators, but they'll be registered via the configuration
> > system instead, allowing "placeful" lookups, and getting rid of the
> need to
> > have the page, error, and traversal protocols for registration
> > purposes. Indeed, we should end up with it being possible for most
> > decorators to be defined by simple configuration, without coding (as is
> > currently required).
>+1 for that as well.
>i'm willing to help here (as my time allows) if it is not more work to
>design/communicate ideas vs. write code ;-)
My current implementation plan is to first add the XML deserialization
framework, so that we can have XML configuration to define
decorators. Then peak.web refactoring, and then finally the peak.model
stuff. I'm currently doing some of the redesign of peak.web in my head. I
think that I've got most of the issues resolved, but the overall picture is
rather tricky to hold together.
I think there are going to be two basic interfaces: IHTTPHandler and
ITraversable, roughly as follows:
"""Return '(status,headers,output_iterable)' tuple"""
"""Return traversed-to-object, or raise not allowed/not found"""
In each case the method is allowed to modify 'environ', but it is not
guaranteed that the modification will have any effect on the caller. (That
is, the caller may pass them a copy of the caller's environ.)
Most implementations of IHTTPHandler will check to see if the environ
indicates a need to traverse further, and if so, call an appropriate
ITraversable's traverse method to obtain the new object, then adapt the new
object to IHTTPHandler and delegate the handle_http call to it.
ITraversable, however, will not be the one to make changes to the
HTTP-specific environ values such as PATH_INFO and SCRIPT_NAME. Only
IHTTPHandler will make those changes. However, I'm thinking that
ITraversables will still be required to update something in the environ to
reflect the path travelled.
Anyway, ITraversable would be used for resources and for accessing data in
templates. The use of 'environ' would supplant the current usage of both
ITraversalContext and IWebInteraction. This will eliminate the current
extremely tight coupling between your chosen Interaction/InteractionPolicy
class and the entire rest of the application. Under the new system, you
can carry down any "globals" from any component to any child component,
without having to make them part of a single Interaction class. Instead,
such values will be stored in 'environ' under a property name, and you'll
use functions to compute (and cache) them, thus opening the system to
There are still some bits to be worked out with regard to how absolute and
relative URL's get calculated, but the rest is mostly just nailing down
division of responsibilities, defining names for certain values in
'environ', and establishing API calls to get at most of the things that one
now gets at via attributes of the context or the interaction.
At that point, peak.web will be something of a microkernel, with only two
very simple interfaces for someone to implement, and lots of imperative API
calls that can be used to do useful things. To make it easy-to-use,
however, we'll then define controller classes (replacing the previous
Decorator concept) and an XML vocabulary for defining/declaring them. And
as time goes by we'll likely end up writing lots of HTTP utility functions
to do things like extract cookies, set cookies, etc. given an
'environ'. But, since these functions won't be bound into "request" or
"response" types, any component will be free to use alternative ways of
accomplishing those tasks, should they need to do so.
Anyway, once we have the basic XML vocabulary, you'll write XML to design
your site's traversal hierarchy, including the equivalents of "Specialists"
and "ZClasses" to wrap your domain objects with views. The rest will be
resources (such as templates) and maybe a few custom classes or functions
for the remaining functionality, and over time we'll add things like form
objects and specialized DOMlet widgets to minimize the number of things
you'll have to actually write.
(Oh, and there will need to be a SystemController class somewhere that
wraps an application's RootController with transaction handling and error
trapping. But that'll be about it.)
More information about the PEAK