On Nov 24, 7:39 pm, Mike Orr <[email protected]> wrote:
> On Tue, Nov 24, 2009 at 10:47 AM, Mike Burrows (asplake)
> > Yes it uses standard Rails routes, and no it doesn't address output
> > formats (nor will it).
>
> I'm not sure what this means.  XML, JSON, YAML, and text are all
> output formats, which it does.

Ah - I just meant that I have no intention to model the formats
produced by the application.

> Yes there's a small module to map the Rails
>
> > routes to described_routes' internal model and another to add Rake
> > tasks (analagous to adding "paste described_routes" or something).
>
> What would a "paster described_routes" do?  Add a bunch of routes and
> their various controllers?

Probably just produce a human-readable report, like "rake routes" does
for vanilla Rails and "rake described_routes" does but better ;-)

> I think I would rather see a case where the original route definitions
> were in a generic format (and described_routes may be as good a format
> as any), and a ``map.import_()`` method that imports them into the
> route map.  That way the routes are defined in only one place, and the
> application is automatically updated (or broken) whenever routes
> change. "paster described_routes" could create the controllers, but if
> it inserts into the route map you'd have problems when you change the
> routes later: because how would you keep routing.py and the original
> route definitions in sync?

See above.  Described_routes works with the existing routing so
there's still only one representation to maintain, and I wouldn't wish
to limit frameworks to what described_routes can express so I don't
push it as an input format.

> >> Pylons does not have a routemap pretty printer. That might be worth adding.
>
> > I do plan to do this, just a question of time - maybe my next plane
> > trip!  A Python version of the underlying data structure exists
> > already so it shouldn't be a huge amount of work.
>
> That would be great.  The data structures in Mapper and Route are
> rather opaque and underdocumented though. We're considering a more
> transparent structure for a future version of Routes.

>From a brief encounter in the paster shell it's an easy enough
structure to explore.  Rail's documentation here isn't great either.

> > On a related subject, I'm a little concerned that Pylons has the
> > choice of constraining methods via Routes (potentially resulting in
> > 404s which seems wrong to me) or via the @restrict decorator.  IIRC
> > there's the third choice of a @dispatch decorator but I haven't tried
> > that (maybe I should - I'm currently using different URLs for my POST
> > actions).
>
> Yes, there are three ways to do it.  I don't know when each one was
> added to Pylons or why, but I suspect it's because people wanted
> TurboGears-style decorators.  I'am not sure whether restricting the
> methods via Routes or the decorators is better, although I lean toward
> Routes to keep it all in one place.  The security-obsessed would use
> both. : )

You ok with the 404s then?

> --
> Mike Orr <[email protected]>

Regards,
Mike

--

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