[PEAK] PROPOSAL: Remove ZODB/Zope X3 dependencies/"compatibility"
ueck at net-labs.de
ueck at net-labs.de
Wed Jun 2 15:05:16 EDT 2004
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
> 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.
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
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 ?
This mail sent through IMP: http://horde.org/imp/
More information about the PEAK