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.


Reply via email to