Apologies if this comes out as a (near) dupe - I was sure I had replied to this!
On Nov 24, 5:44 pm, Mike Orr <[email protected]> wrote: > By described_routes I guess you mean > this:http://github.com/asplake/described_routes/tree Yes, that's it > It looks like a pretty printer for route definitions. Does it use a > standard Rails route map, or its own route objects? Does it create a > functional route map, or just its output formats? It says "framework > neutral", but then there must be some framework-specific code to > convert it to a native route map, no? Pretty printer, json/yaml/xml metadata generator and (via link headers and a small Rack middleware component) the provider of a simple resource discovery protocol. Unfortunately some of the later bits are better described in my blog than they are in the package itself, so apologies for that! > Pylons does not have a routemap pretty printer. That might be worth adding. I intend to, but it's the usual question of time. A Python port of the underlying datastructure and some of the format conversions exist already so it shouldn't be a huge piece of work. > Pylons does not handle nested resources very well anyway, so this > wouldn't be the only problem. But I don't think that > having-to-rename-variables applies. The only problem with combining > routes from multiple sources is if there's a collision in the route > paths or route names, or if a route is over-general and swallows URLs > intended for a later route. But if you're combining nested resources, > the nested one would normally go under a unique URL prefix. If you > tried to overlay two sets of routes at the same URL position, you > might run into collisions, but I doubt many people do that. In Rails, collisions are an issue already as each HTTP method generates a route for each URL (in reality it's a route per action, not per URL) so I'm used to them already. One thing that does make me nervous about a Pylons implementation is the multiplicity of options (no pun intended) around HTTP method discrimination, namely route requirements, @restrict decorators and (IIRC - not used them yet) @dispatch decorators. While we're on the subject, it seems wrong to me that Routes will generate a 404 for a correct URL but incorrect method. It's easy to guess why it does this, but it still seems wrong! > As for unique route names, that's just something you have to have in > order to generate them by name. ``map.extend()`` has an argument to > insert a set of routes under a URL prefix. Perhaps it needs a name > prefix argument too. You may be on to something here. In my work project we have taken to namespacing route names, but I'm not 100% sure that we've got it right yet. > The 'id' convention is based on the traditional generic route > "/{controller}/{action}/{id}" and ``map.resource()``. I thought both > of these were borrowed from Rails. That's my belief too. I tend to remove that generic route unless I have a very good reason to keep it though. > I normally do use specific variable names. But that's impossible when > you want to have a generic route that serves a variety of different > purposes. You can't have two routes whose paths differ only by a > variable name, because the variable name does not appear in the > incoming URL, so there's no way for Routes to determine which route is > wanted (and it would select the first matching route anyway). Indeed (route requirements aside). Yes, in the generic case "id" is as good a name as any other. Mike [email protected] http://positiveincline.com http://twitter.com/asplake -- 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.
