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

[Ulrich Eck]

On Wed, 2004-06-02 at 23:20, Phillip J. Eby wrote:
> No.  ITraversable is only responsible for traversing the name it has been 
> given.  IHTTPHandler is responsible for adjusting PATH_INFO and SCRIPT_NAME 
> as traversal progresses.
> 
> The reason for this division is that ITraversables can be used in non-HTTP 
> contexts, such as traversal to resources from skins, and data path 
> traversal in DOMlets.  These kinds of traversal should not have any effect 
> on HTTP variables in the environment, or else anything that needs to know 
> what URL was actually in effect would get confused.

so .. would it make sense to factor out Traversal to some more general
concept that has no knowledge about the way it is used at all except
that there is some path to go (described by an url-part) through the
component-tree. 
this could then be used to implement imap/ftp like folderish
representations of the component-tree or be used within config-options.
it would allow to model the users-view independent from the actual
domain-model .. sounds interesting for gui-apps as well.


> We need to more precisely specify which interfaces do what.  I've decided 
> also that IHTTPHandler is a base class of IHTTPApplication, where the 
> latter is the interface that applications are adapted to by a container 
> (like the web runner, supervisor, FastCGI control, etc.).  This then makes 
> it easy to put a transaction/error handling wrapper around the root 
> component of a web app, without forcing the serialization format to specify 
> that an object is "top level".
> 
> What I meant to say is that if you design an application's site layout with 
> the XML format, it should be composable.  You should be able to "include" 
> that XML file into a larger application, and just have it work.  So, there 
> shouldn't need to be anything in the configuration that says, "I'm the root 
> of the site".

yes .. most frameworks do not allow this.

> However, to make this more flexible, it's possible that it could be given a 
> plugin architecture, so as to allow registering plugins to do additional 
> pre or post processing functions, and I suppose that these functions 
> themselves could be plugin-ized.

this is probably what i meant when i said in irc: we need something like
corba-interceptors for plugging in the framework-services into the
http_handler-chain.

> In the current system, TraversalContext can compute both a "traversed URL" 
> and an "absoluteURL" by keeping track of the previous TraversalContext.  I 
> suppose I could do the same with 'environ', i.e. having each 'environ' have 
> a pointer to the previous environ traversed from.  And the IHTTPApplication 
> could set the initial environment's base "absolute" URL.

i'm not yet clear about: is environ one instance that is usually passed
through, or is the general case to copy the environ and hand it over to
the next handler (like domletstate) ?

> All in all, this is mainly a matter of rather tedious rewriting, while 
> adding tests.  One of the annoying things about the Zope dependency of 
> peak.web is that it was hard to write good unit tests that didn't depend on 
> Zope, too.  And, it was hard to define sufficiently small units, because so 
> many things were emergent properties of a larger system.  It should be a 
> lot easier to write tests for small operations against 'environ' dictionaries.

:)

> The rewriting will take a while, though.  When I've replaced all the 
> existing code, I will not yet have replaced the functionality, because we 
> will be losing Zope-supplied functions like cookie parsing, query string 
> and form post parsing, cookie setting on responses, character set 
> negotiation, and all of that sort of thing.  Those will have to be written 
> as property factories and added to the configuration, but that also makes 
> them good candidates for contributed patches.  And so, as soon as a 
> 'web.lookup()' function exists, that would be a good time when volunteers 
> such as yourself could start writing factories to replace functionality we 
> currently get from Zope X3.
> 
> Contributions should include unit tests that can be integrated into the 
> peak.web test suite.
..
> Anyway...  did that answer your question?  :)

yup .. sounds like a good starting point for the refactoring of p.w.

cheers
Ulrich

-- 
--------------------------

Ulrich Eck
net-labs Systemhaus GmbH
CEO & Code-Artist
Ebersberger Str. 46
85570 Markt Schwaben - Germany

eMail: ueck <at> net-labs.de
phone: +49 8121 4747 10
fax:   +49 8121 4747 77