My apologies to anyone who encountered this problem (reported anonymously overnight):
AttributeError: 'SubMapper' object has no attribute '__exit__'. It's fixed now in the asplake/routes repo and will be in due course in bbangert/routes if I haven't already tested Ben's patience past breaking point. It was another merge error and completely my fault - I was careless in the placement of some new code and didn't want to add tests for the "with" syntax for fear of building in an unwanted dependency on Python versions. Apart from that, happy new year! Mike On Dec 29 2009, 9:54 am, "Mike Burrows (asplake)" <[email protected]> wrote: > Oops - merge error, fixed. I should add a test for that. You can add > requirements at the collection level too - it adds a tiny inefficiency > I suppose but it looks neat, e.g.: > > map.collection('events', 'event', conditions=dict(sub_domain=True), > requirements=dict(id='\d+')) > > On Dec 29, 9:32 am, Chris <[email protected]> wrote: > > > That's great news! > > > Quick question, is setting conditions at the collection() level > > supported? For example, most of my urls require a subdomain. > > > map.collection('events', 'event', conditions=dict(sub_domain=True)) > > > File "/Routes-1.11dev-py2.6.egg/routes/mapper.py", line 164, in > > connect > > if isinstance(value, dict): > > NameError: global name 'value' is not defined > > > On Dec 29, 2:51 am, "Mike Burrows (asplake)" <[email protected]> > > wrote: > > > > I can't speak for Routes 2 but I'm pleased to report that my changes > > > will soon make it into dev Routes. Actually "delighted" would be a > > > better word - it's my first formal contribution :-) > > > > A nice next step would be to refactor a published example or two. A > > > squeaky clean tutorial example with a tidy routing config and no > > > redundant decorators would be nice, don't you think? If anyone > > > maintains suitable candiate and would like a collaborator, please get > > > in touch. > > > > Regards, > > > Mike > > > [email protected]http://positiveincline.com > > > > On Dec 29, 7:36 am, Chris <[email protected]> wrote: > > > > > This looks pretty cool, and the pretty printer is very helpful! > > > > Again, thx for the blog post. > > > > > I'm just a little hesitant to move forward with adopting it in my app > > > > at the moment because if routes 2 comes up with something completely > > > > new/different, then I'll be depending on this new branch or migrating > > > > my routes later when routes 2 is available. > > > > > I know api changes for a commonly used lib like routes should not be > > > > made lightly and require thinking time, but I sure would like to know > > > > which way it is headed. > > > > > On Dec 22, 2:42 am, "Mike Burrows (asplake)" <[email protected]> > > > > wrote: > > > > > > Sorry, couldn't resist... > > > > > > with mapper.collection( > > > > > 'myresources', > > > > > 'myresource', > > > > > collection_actions = ['index', 'new'], > > > > > member_actions = ['show', 'update']) as c: > > > > > c.link('new', name='create_resource', method='POST') > > > > > c.member.link('delete', method='POST') > > > > > > >>> print mapper > > > > > > myresources GET /myresources > > > > > new_myresource GET /myresources/new > > > > > myresource GET /myresources/{id} > > > > > update_myresource PUT /myresources/{id} > > > > > create_resource POST /myresources/new > > > > > delete_myresource POST /myresources/{id}/delete > > > > > > Alternatively you could model 'new' as a nested subresource but this > > > > > takes a couple more lines and probably not worth the bother here. > > > > > > Mike > > > > > > On Dec 21, 10:27 pm, Jonathan Vanasco <[email protected]> wrote: > > > > > > > On Dec 21, 3:54 pm, Mike Orr <[email protected]> wrote: > > > > > > > > def resource2(self, name, path, new=True, edit=True, delete=True): > > > > > > > > GET /myresource : view index > > > > > > > GET /myresource/new : new form > > > > > > > POST /myresource/new : new action > > > > > > > GET /myresource/1 : view record 1 > > > > > > > GET /myresource/1/edit : edit form > > > > > > > POST /myresource/1/edit : edit action > > > > > > > GET /myresource/1/delete : delete form > > > > > > > POST /myresource/1/delete : delete action > > > > > > > I don't like stuff like this, so I could care less. But... > > > > > > > If you're going this route, it might make sense to do canned > > > > > > conditions for the most likely implementations, like ned=True would > > > > > > set up new, edit and delete. > > > > > > > i've seen that in a few different settings. most notably the Amazon > > > > > > S3 > > > > > > implementation -- where that option really does clean up a lot of > > > > > > code > > > > > > and make it easier to work with. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
