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.
