[PEAK] PROPOSAL: Remove ZODB/Zope X3 dependencies/"compatibility"

[Phillip J. Eby]

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 
> peak.web
> > and peak.model.  So, I'd like to propose some changes to the affected 
> packages:
> >
> >
> > ZODB 4 and peak.model
> > ---------------------
>[snip]
> > 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 
> migrated.
>
>+ 1 ( +10 for eventSource integration )
>
>
> > Zope X3 and peak.web
> > --------------------
>[snip]
> > 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:

     class IHTTPHandler(Interface):

         def handle_http(environ,input,errors):
             """Return '(status,headers,output_iterable)' tuple"""


     class ITraversable(Interface):

         def traverse(environ,name):
             """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 
expansion.

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