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

[ueck at net-labs.de]

Quoting "Phillip J. Eby" <pje at telecommunity.com>:
> 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.

hehe .. i know .. the whole publisher stuff is quite complex.
 
> 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.)

sounds resonable. 

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

one could then, within some component close the the traversal-root
also do the work for parsing headers and request-type to decide
wether it is a Browser/WebDAV/XMLRPC/SOAP-Request and
adapt to more specific Interfaces (e.g. IXMLRPCHandler) if needed.
but this component is only plugged into the publishing if this feature
is needed(same for ++XXX++/@@-URL handlers).

would this be the intended way to extend functionality ?

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

and an uptodate list of remaining items to traverse to.
 
> 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.

this is especially usefull, if you don't want to implement all needed 
framework-parts yourself ;-)

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

the parrallelism of Traversed-Path vs. Component-Tree will still exist ?

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

i think i like this :)

how can we get ahead ?

cheers Ulrich

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/