On 6/30/09 1:39 AM, Iain Duncan wrote:
>> Let's imagine a view "pets":
>>
>> from webob import Response
>>
>> def pets(context, request):
>> return Response ('OK')
>>
>> when a URL comes in that is for a paricular pet:
>>
>> from webob import Response
>>
>>
>> def pets(context, request):
>> if request.subpath:
>> petnum = request.subpath[0]
>> return Response('OK with petnum %s' % petnum)
>> return Response ('OK')
>>
>> when a URL comes in with a particular action for a pet:
>>
>> from webob import Response
>> from repoze.bfg.chameleon_zpt import render_template_to_response
>>
>> def pets(context, request):
>> if len(request.subpath) == 1:
>> petnum = request.subpath[0]
>> return Response('OK with petnum %s' % petnum)
>> elif request.subpath == 2:
>> petnum, action = request.subpath
>> return render_request_to_response('%s.html' % action,
>> petnum = petnum)
>> return Response ('OK')
>>
>> That's at least one way to handle it. Another way is to register a view for
>> "edit.html" against a "Pet" model.
>
> Thanks Chris, the latter is what I was thinking of. So, another
> question, can the *context* object be a *class* instead of an instance?
>
> IE, can the class Pet be the context, such that a class level
> __getitem__ returns the actual instance I'm after, and edit becomes the
> view ( action ).
This isn't a pattern that sounds familiar to me, sorry. The context is almost
always an instance. It can be anything of course, but if it's a class it won't
be traversed. If the class has a __getitem__, a TypeError will be raised
because it will be called as an unbound method with a single argument.
If I needed to do this, personally, I'd probably use traversal. I'd create a
"root factory" (passed into "make_app" as the first argument) that when called
with an environ returned an instance of some root object. The root object
would
have a __getitem__ that, given the identifier "pets" would return a Pets
object.
The Pets object would have a __getitem__ that, given an identifier, returned
a
"Pet" object representing that particular pet. Then I'd register a default
view
against the Pets object and both a default view and an "edit" view against the
Pet object.
That's because I've been using traversal for ten years and it's natural to me.
It's not very natural for most folks. It sounds like you're more used to "url
dispatch". In that case, were I you, I'd forget about traversal entirely and
create a few routes in the form:
"pets"
"pets/:id"
"pets/:id/edit"
e.g.
<route
name="pets"
path="pets"
view=".views.pets_view"
/>
... etc ...
Each one of these would go to a separate view that did the needful.
- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
