On Jun 13, 2011, at 6:30 PM, Laurens Van Houtven wrote:

On Mon, Jun 13, 2011 at 3:38 PM, exarkun@twistedmatrix.com wrote: Another thing we want is something closer to locateChild as Nevow and web2 had. The key feature is being able to consume multiple path segments (or none at all) at a time if desired.

Jean-Paul

I added it to the ticket.

Someone on IRC mentioned that locateChild isn't exactly perfect either -- how does it differ from the idealized API?

For the people who hadn't seen locateChild before (much like myself) -- the main difference is that instead of just taking the *next* segment, it takes all of the remaining ones, and instead of returning a single child, it returns a child and the remaining segments. A possible problem with this is that people might get the impression they should mess with the segments... Comments welcome.

Yeah, messing with segments is an issue. There's a thing that some Nevow applications would do which, while I'm not entirely sure it was a terrible idea, definitely exposed a weakness in this model. We called it an "internal redirect". The basic idea is that your resource gets called with "request, [a, b, c]" and you return "resource, [d, e, f]". The problem with allowing this is that it decouples the resource from any sane way to identify its URL based on the request. It's handy to have something like the 'prepath' attribute to assist in generating absolute URIs that can be passed to external systems, but you can't make that consistent in the face of code that arbitrarily manipulates the segments list.

Also, you can internally redirect this way based on path-based dispatch but you can't redirect based on hostname or other features of the request without mutating it. So it seemed like a lopsided half-feature.

One off-the-cuff idea to address this would be to have a 'path' object with an API of its own; something like this:

def locateDescendant(self, request, path): year, month, day = path.consume(3) rsrc = self.resourceFromDate(year, month, day) return rsrc

.consume(integer) is something of a strawman here; you'd probably need a way to say stuff like "consume all of the path segments" or "consume everything up to a segment with the value 'x'", so that we didn't lose the (legitimate) flexibility of having a list. We could of course just pass in a mutable list and not return it, but that provides a little more flexibility than I'd like, because it would allow you to do all the same stuff as returning your own arbitrary sequence.

Really this 'path' is actually cursor over the URI inside the request. It would be nice if the state associated with traversal were encapsulated entirely in that object, so that the request itself didn't get mutated as it traveled down the path.

I'm also not sure if it should be allowed to return an IResource (and basically use the IResource getChild behavior whenever you see an IResource...) or if it should only return the new things.

One return-type signature is a good idea. Convenience APIs are better. That said, if we do go with 2-tuple as the return type, good error reporting is crucial; it's very easy to accidentally return a resource.

Perhaps there could be an adapter: if entity.locateChild([a, b, c]) returns a (resource, [b, c]), the resource is adapted to IEntity (working title for I2NewResource2), and the adapter's .locateChild([b, c]) call gets translated into self.wrappedResource.getChild(b).getChild(c), or something.

That seems sensible.

I've been looking at this again recently and honestly it's beginning to feel like I'm reimplementing large parts of web2. Does that mean I'm doing it wrong?

On Jul 24, 2011, at 2:13 PM, James Y Knight wrote:

On Jul 24, 2011, at 11:36 AM, Laurens Van Houtven wrote:

...

I've been looking at this again recently and honestly it's beginning to feel like I'm reimplementing large parts of web2. Does that mean I'm doing it wrong?

Either that or that web2 was doing it right...

Of course, you don't really need to reimplement it, just copy the existing implementation from before it was removed, and s/web2/web/. :)

The main thing that web2 did wrong was introducing a new namespace and thereby confusion, not any particular detail of its implementation.

The web2 resource model was in most ways a nice upgrade from twisted.web. It even had a halfway decent compatibility layer. You should feel free to copy its implementation liberally (with the exception of the IStream interface, which has been discussed to death elsewhere). However, since web2 was half-baked in some regards, you may need to add test coverage, improve docstrings, or handle some corner cases in order to pass review.

But, in terms of implementation details, web2 was in fact "doing it right" for the most part.

-glyph