Re: Leaf Resources with child Leaf Resources

On 06:09 pm, [email protected] wrote:
>Sorry, let me be more clear:
>
>I have a Resource let's say CustomerRestService which is a leaf and 
>handles
>everything related to '/customer'
>Then I want a CustomerAddressRestService Resource, which is also a leaf 
>and
>should handle everything related to '/customer/<customerId>/address'.

Well.... my first reaction is that this doesn't make sense.  Leaves 
don't have leaves.  That's what makes them leaves.

Your CustomerRestService is not a leaf resource.

Why do you think it should be one?
>So I need a leaf Resource (i.e. it actually intercepts 
>GET/POST/PUT/DELETE
>requests to the root '/customer' URL)
>with a child leaf Resource (which intercepts the GET/POST/PUT/DELETE
>requests to its root '/customer/<customerId>/address' URL).
>
>Twisted does not really allow for nested leaf resources, but REST is 
>all
>about nested URL schemes, e.g.

Right.  Because "nested leaf resource" is self contradictory.
>Customer -> Customer Address
>Customer -> Customer Phone
>Customer -> Customer Invoice -> Customer Payment
>
>etc.
>
>Taking CorePost out of the picture and just going back to raw 
>twisted.web,
>how would you recommend that be done?

Apart from what I said above, and still not really understanding why you 
want this, the implementation of the traversal mechanism is exposed as 
`twisted.web.resource.getChildForRequest`.  After you stop traversal 
with your first "leaf" resource, you can finish it by calling 
`getChildForRequest` manually, and then manually rendering the resulting 
resource.

Jean-Paul