On Thu, Nov 4, 2010 at 4:44 PM, Kevin J. Smith <[email protected]> wrote:
> Hi,
> Someone pointed out pyramids to me
> (http://docs.pylonshq.com/pyramid/dev/narr/introduction.html) and I am a bit
> confused with the relationship between pyramids and pylons. I have been
> using pylons for over a year now and have never heard of pyramids (and that
> includes passively following this mailing list.) From the page on pyramids
> it seems to suggest that pylons post 1.0 will be using pyramids? If so,
> statements like "no controllers" kind of frighten me ... and quite frankly
> most things that are Zope related frighten me.
> Anybody care to clarify?
The Pylons 2 codebase has been going in a BFG-ish direction for
several months (search pylons-discuss and pylons-devel for "marco" and
"bfg"). Pyramid is just a new name for it. It hasn't been announced
yet so your surprise is understandable.
Basically, the Pylons and BFG developers decided to merge their
codebases into one framework. So Pyramid is a fork of BFG with all the
Pylons 2 stuff merged in (and Routes too). The name "Pylons" has grown
from being a single framework to a developer community that maintains
three frameworks: Pylons 1, BFG 1.3, and Pyramid. TurboGears is
considering joining the merger but has not yet committed to it. It
depends on whether they decide to rebase TG on Pyramid or stick with
Pylons 1.
Pyramid supports multiple API styles. Configuration can be imperative
(Pylons-style: instantiating objects and calling methods) or
declarative (BFG-stye: an XML-based configuration file). Routing can
be transversal (a la TurboGears) or URL dispatch (Routes-style). The
Pyramid manual is forked from the BFG book, but it's being geared
toward the Pylons style, so imperative and with URL dispatch.
Pyramid has a different MVC vocabulary. The model is the model, but
the view is the callable that processes the request, so the equivalent
of a Pylons action method. A "view handler" is a class containing view
methods, so the equivalent of a controller. This was just documented
today, so read the chapter on "View Handlers". Some of the chapters
in the manual refer to Pyramid's other modes, so they're irrelevant to
a Pylons-style application. I'm making a howto to explain the relevant
parts.
There are some changes in the syntax. Routes configuration changes to
``config.add_hander()`` or ``config.add_route()``. A view method looks
like this:
class MyViewHandler(object):
def __init__(self, request):
self.request = request
@action(renderer="/index.mako")
def my_view(self):
return {"var1": "value 1"}
This, obviously, is TurboGears-ish, but not exactly the same. You can
mount a Pylons 1 application as a URL overlay, so that you can upgrade
it one page at a time, or add new pages but keep the old pages as-is.
Only a small part of Zope is coming in: the component architecture and
interfaces. Application developers don't need to worry about that,
it's all preconfigured in the Paster application template. The
component architecture is a generic plugin system: it allows you -- if
you want -- to switch out and replace parts of the framework as easily
as switching template engines. It allows the components, routing, and
configuration data to all be specified in the same format in the same
configuration file, if desired. But a normal Pylons-like application
would not do this, it would use a familiar INI file, and a module
that's equivalent to environment/middleware/routing.py
--
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.
