[Twisted-web] Add segmentsResolved method to inevow.IResource

[Matt Goodall]

Hi all,

On the #twisted.web channel we've had numerous discussions about a
couple of edge cases to do with resource location. Specifically:

1. The located resource is just a proxy to a real resource. Where do I
return the real resource from since locateChild is not called once all
segments have been resolved? A suggested solution has been to return the
real resource from renderHTTP. That is conceptually wrong and also a bit
awkward to support. It's also broken in svn trunk at the moment ;-).

2. I have to access to query parameters in every rend_* method. Is there
a way of processing the query parameters just once so they are already
available in the rend_.* methods? So far, the solution seems to be to
override renderHTTP, process the query parameters (and store them
somewhere) and then call up to the parent class's renderHTTP method.

3. A page displays a list of objects and each object has a delete
action. What's the best way to handle the deletion? There are a few ways
I have seen this implemented: use a form for each object; use a fake
child URL segment and pass the object's id as a query parameter; pass
the object's id as a query parameter to the list page itself (this means
overriding renderHTTP because locateChild is not called, as in #1).

The are probably countless other similar cases.

I propose that we add one more method to the IResource API - a "hook"
method that is called when the final segment has been located, i.e.
there are no more path segments to process. The IResource definition of
the method would look something like:

    def segmentsResolved(self, ctx):
        pass

Suggestions for better names welcome. Perhaps youAreIt is better name
;-).

If the result of calling segmentsResolved is None renderHTTP would be
called as normal. If something not None is returned then it must be an
IResource (or adaptable, deferred, blah blah blah) and will be used as
the resource for that URL from then on. Hmm, I guess segmentsResolved
should be called repeatedly until a None is returned to allow for
proxy->proxy->proxy->real but that's just implementation.

It think that should cover most use cases I have seen and, conceptually,
seems much, much cleaner than what we do right now.

Cheers, Matt

-- 
     __
    /  \__     Matt Goodall, Pollenation Internet Ltd
    \__/  \    w: http://www.pollenation.net
  __/  \__/    e: matt at pollenation.net
 /  \__/  \    t: +44 (0)113 2252500
 \__/  \__/
 /  \          Any views expressed are my own and do not necessarily
 \__/          reflect the views of my employer.