On Mon, 2010-12-06 at 12:14 -0800, Mike Orr wrote:
> 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.
I think the idea that Pyramid is moving to URL Dispatch for "every day"
use is maybe a bit overgeneral, because it really depends whose day
you're talking about.
Pylons 1 and other frameworks like it are very much geared towards
single-purpose non-extensible bespoke applications. If you write these
sorts of apps every day, and you don't often deal with hierarchical
data, then, yes, you may want to use URL dispatch exclusively, which
means you're going to be more attracted to "add_route", and
"add_handler" than someone else might be.
However, if your day consists of maintaining a large system that is
either very extensible (it may itself be a framework of some kind,
extensible by your customers or third party integrators), or your data
set is extremely hierarchical, you'll probably be attracted to using
traversal.
You can make generalizations about which group is "larger" or "more
representative", but in reality, both groups have a good number of
constituents, and Pyramid-the-core-framework isn't likely to favor one
over the other. Individual paster templates might, however.
> 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.
(An aside, unrelated to this discussion: this statement puzzles me.
It's not like BFG has really changed that much since becoming Pyramid.
It's not "just a hackers framework" now that its name was changed?
Really?)
> 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,
Your apps may have a fixed URL hierarchy going to a fixed set of views,
and many other apps may too. But there is no such thing as a "normal
WSGI app". Every bare WSGI app invents its own dispatch mechanism.
WSGI is sort of besides the point here I think.
I think you personally want it to be a flat, ordered set of lookups, and
that's fine. But I don't think it's "abnormal" for view lookup to not
work this way.
> 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 personally still often use traversal for applications that have a
fixed data hierarchy, or sometimes even *no* data hierarchy. I just
find URL dispatch easier to *explain* to people. I think, however, that
traversal is just as valid a viewfinding mechanism as URL dispatch is,
and has some distinct advantages. It just takes longer to explain.
> 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.
Indeed, some TG folks I believe are inventing such a thing.
>
> > 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.
