I'll add a comment to issue 21 with the small fix to connect() that makes submapper nesting work correctly (so that requirements dicts get merged, for example).
Then there's the routes prettyprinter - there's no command for it but even in the paster shell I have found it useful. That leaves collection(). If you feel it may be too radical for Routes that's OK I guess, but I will continue to use it - resource() is just too clumsy (as is the Rails one for that matter, though with fewer limitations). Whether collection() is the way forward or not, some attention to the level of duplication necessary within routing.py and between routing.py and the controllers would surely be good for all. > I'd also like to see a resource route object in the routing table. > Currently map.resource creates a bunch of independent routes, which > don't have a group identity when introspected. But that's another > issue and longer term. Like described_routes ;-) But that's only a representation, not a routing implementation. Seriously though, I have been wondering if a hierarchical organisation internally would be good for performance too. Regards, Mike On Dec 21, 8:54 pm, Mike Orr <[email protected]> wrote: > On Mon, Dec 21, 2009 at 3:31 AM, Mike Burrows (asplake) > > <[email protected]> wrote: > > > I was intrigued by the mention of resource() > > The Atom-REST syntax for resources is mainly beneficial to > non-interactive user agents (robots and front ends), and cases where > the resource is isolated from a "web site" (Amazon S3). But when the > resource is embedded in a visual web site, it goes against traditional > website usage. Traditionally the form and its action were at the same > URL, and POST was used for all actions. So GET displays the form, and > POST creates/updates/deletes the resource. RESTifarians call this > inferior and it has been drummed out of Routes and Pylons (although it > can be reconstructed manually). This led to the splitting of the > controller action from one method (for both display, validating, and > processing), to two (one for display, another for > validating/processing), and the @validate decorator which tries to > synchronize the two but is inadequate for edge cases (what if the > validator needs state such as the current record ID or database > record?). > > I also notice that all the biggest social networking sites -- > Facebook, MySpace, YouTube, etc -- totally violate REST at all levels, > with query string monstrosities that we would never use. Yet that has > not caused the sites to be unpopular or the owners' stock dividends to > fall. > > Another thing is that map.resource has no delete confirmation form, so > I have to add one to every application. And it creates all routes > even if some are disallowed by application policy; e.g., creating > resources or deleting them. Perhaps the site insists that all > creation or deletion is done outside the web. > > So I think there's room for a compromise, a kind of resource route > that's not Atom compatible but still has good URL structure, and a > one-method action. I don't have the exact specs on hand but it's > something like this: > > 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 > > If the boolean args are false, routes for those actions would not be created. > > I'd also like to see a resource route object in the routing table. > Currently map.resource creates a bunch of independent routes, which > don't have a group identity when introspected. But that's another > issue and longer term. > > - coincidentally I was > > > working on the post [1] below in which I refactor my way to a much > > more flexible alternative that builds on the new SubMapper idea. I'd > > be interested to know what people think. > > > [1] DRY up your routes - a Pylons routing > > refactoringhttp://positiveincline.com/?p=561 > > Could you make Routes tickets for these? Then they'll be easier to > follow up on. > > .submapper is documented now, but I'm not sure if readers can infer > all the cases you describe. > If not, it just needs some examples > addedhttp://routes.groovie.org/manual.html (search for "submapper") > > The new methods may be more radical than Routes wants to do, but > having it in tickets will make them easier to address. Or maybe you > already did; I see there's one ticket by > you.http://bitbucket.org/bbangert/routes/issue/21/add-submappersubmapper > > -- > Mike Orr <[email protected]> -- 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.
