On Mon, Dec 6, 2010 at 10:43 AM, Seth <seedifferen...@gmail.com> wrote:
> 1. What would a larger Pyramid app look like directory/module wise?
> Wouldn't this look more like a default Pylons 1/TG 2 setup?
> (controllers-*ahem*-views in a "views" dir, models in a "models" dir,
> etc)
URL Dispatch has "view handlers", which are classes containing view
methods, so the equivalent of Pylons1 controllers. You would normally
use handlers.py and models.py in small applications, and handlers/ and
models/ in large applications. The application templates are still in
flux but will probably default to handlers.py and models.py.
You can use function-based view callables, in which case views.py
would be appropriate, but this is more of a BFG pattern than a
Pylonsish pattern.
> 2. Are the Pyramid developers intentionally moving toward a less
> "object dispatch" setup, and a more declarative setup where routes and
> views are explicitly defined (no magic or ponies)?
I think Pyramid is moving toward URL Dispatch for everyday use, and
reserving Traversal for the specialized use cases that Chris explains
better than I can.
This move is natural based on BFG's history, and the new situation of
future Pylons newbies, which is forcing Pyramid to be more accessible
and simpler out of the box, rather than just being a "hackers'
framework" as BFG was. BFG was descended from Zope and its ZODB object
database. Traversal is ideal in this situation, especially if your
models are in the database, because the URL hierarchy is
unpredictable. (You can add an object or container to the database,
and it changes the possible URL hierarchy.) But "normal WSGI
applications" have a fixed URL hierarchy going to a fixed set of
views, so URL Dispatch can describe that more simply. I don't know
BFG's evolution intimately but I think URL Dispatch was added as an
option at some point, and as Chris began using it in his own
applications he found it more and more useful for the basic URL
structure, and limiting Traversal to hierarchies that really are
dynamic. That's the use case for the "Hybrid" approach in the manual.
I originally thought Traversal was the same as TurboGears dispatch and
wrote that in some documentation; I'll change those. The truth may be
that TurboGears has a dispatching model that is not in Pyramid, but I
don't see why it can't be fitted on top of URL Dispatch the same way
it was over Routes, if TurboGears users want to stick to their
familiar way of dispatching.
> 3. With the movement away from controllers to a view-based setup, does
> this make a Pylons 1 style "map.connect('/{controller}/{action}/
> {id}')" route setup totally foreign?
"/{action}/{id}" definitely works. "/{handler}" is problematic because
that variable is the fully-qualified dotted name of the handler; e.g.,
config.add_handler('hello', '/hello/{action}',
handler='mypackage.handlers:Hello')
-OR-
from mypackage.handlers import Hello
config.add_handler('hello', '/hello/{action}', handler=Hello)
You don't want to expose the fully-qualified handler name in the URL,
for both security and aesthetic reasons.
> 4. Would a typical "large" Pyramid app then have lines and lines of
> route/view definitions in the __init__.py (or other config file)?
You'd need one line for each handler class. An app would have to get
very large before it would have more than a dozen handlers. If you're
using "{id}", you'd need one line with it and one without it; e.g.,
"/hello/{action}" and "/hello/{action}/{id}", because some actions
take an ID and others don't. This is identical to the Pylons1 default
by the way, because minimization (which allowed optional components on
the right side of the URL in the same route) is no longer recommended.
You'd also need a line for any custom URLs that don't fit these
patterns, e.g., "/".
Regarding the relationship of the 'action' variable to view methods,
in Pylons1 they are always the same. In Pyramid they normally are too,
but it's possible to define multiple actions that map to the same view
method (presumably each with a different template). I doubt this will
be used except in specialized cases, but it's worth understanding the
difference, which is described in the "View Handlers" chapter of the
manual.
--
Mike Orr <sluggos...@gmail.com>
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
