On Mon, Nov 15, 2010 at 10:34 AM, Chris McDonough <[email protected]> wrote:
> On Mon, 2010-11-15 at 09:03 -0800, Ben Bangert wrote:
> In the meantime, here are some salient bullet points that we can
> probably write about in a more suit-friendly post at some point:
Just to expand on these.
> - Pyramid has more complete narrative documentation than does Pylons.
Pylons has a hard-to-fix hole in its documentation: everything
provided by dependency packages. There's a mismatch between what the
dependency docs provide and Pylons users need. For instance,
FormEncode usage, or initializing a Beaker SQLAlchemy backend. Ben
suggested importing the dependency docs and customizing them for
Pylons, but that is a monumental task that would take months,
especially copying in all the API functions (which would no longer be
autogenerated).
Pyramid solved this problem in one stroke because its manual already
covers many of these holes. Several things which are dependencies or
middleware in Pylons are built into Pyramid, or they are being brought
in-house (e.g., Routes), so their docs are more finished and better
integrated. This frees up developer time to work on other aspects of
the framework.
> - You can use Pyramid to create "single file" applications. This means,
> if you wish, you can disuse "paster serve" and its attendant .ini file.
This is useful only for the smallest production apps, but it has a
niche for one-file demos.
> - Pyramid provides a set of decorators that can move configuration
> settings closer to the code that they relate to (see the "view_config"
> decorator and the "subscriber" decorator).
More on this below.
> - Pyramid applications, written as per the guidelines in the
> documentation, are more easily unit-testable, because a) they don't
> encourage using "stacked object proxies", which often require dicey
> setup and b) they often use "renderers" which means that you can test
> the return logic of a view without parsing HTML in a plain old unittest.
> There is a well-defined configuration protocol that can be used in both
> application setup and test setup that takes much of the mystery out of
> writing unit tests.
It's difficult to unit test a Pylons application because 'config',
'url', and 'app_globals' work as normal only during requests. During
test initialization or unit tests you have to access them in various
special ways, and every time we provide a way, somebody finds a
situation where that way doesn't work. I have gone to implementing
every unit test as a pseudo functional test (using the TestController
infrastucture), but even still it's hard to write all the tests I
want. Pyramid has a much better testing infrastructure (so say Ben and
Chris -- I haven't tried it yet), so that you can initialize tests and
test parts of view logic and other "user data structures" in isolation
-- without running into dependencies on magic globals.
> - Pyramid has an event system. Users can subscribe to (and publish)
> events to hook (or signify) various points in the request cycle. This
> usually makes for better extensibility than needing to override
> hardcoded application logic.
The event system standardizes several special cases that have been
built into Pylons. It can replace .__before__, setting template
globals, replace some middleware functionality, etc. It allows users
to insert their own processing logic, and avoids the need to subclass
PylonsApp or WSGIController for certain customizations advanced users
have wanted. Many of the hooks may not be used much initially, but
people will find reasons to use them later.
> - There is an easy way to have more than one static files folder, and an
> easy way to generate URLs to static resources in multiple places (even
> Apache resources). Pylons comes configured with a single static
> resource directory and provides minimal help for URL generation.
>
> - Pyramid has an easy way to map exceptions to view callables. If you
> want to show some particular view when your application raises an
> exception (an arbitrary one, even one you might define), it's easy to do
> in Pyramid. It's less easy in Pylons.
These two can interact for static folders. By default a static sub-url
is initalized ('/static'). You can also create an overlay (e.g., over
'/') by defining a secondary handler ("controller") to trigger if a
primary handler raises a certain exception. So if the secondary
handler catches HTTPNotFound, it's a de facto overlay. A static
secondary handler would do the opposite of Pylons' default (e.g., it
would serve static files after the dynamic handler has been tried),
which would probably not harm existing applications.
> - Pyramid "view predicates" allow you to register view callables for
> very specific configurations. For example, you can register a view
> callable which is only called when the request method is POST, the
> request is an xhr request, and a "foo" parameter is in the POST
> parameters. This is not possible (or at least not straightforward) in
> Pylons.
This is another case of moving related configuration closer together.
In Pylons there are two places to restrict HTTP methods, in the route
map or at the action method. If the request doesn't match a
POST-restricted route, it will try another route. If the request hits
a POST-restricted action, you'll get an exception with no fallback. In
Pyramid, you can specify it at the view, and the router will look for
another view that does allow the HTTP method.
Another way to look at Pyramid is like a free-trade agreement. By
removing barriers between Pylons web developers (i.e., letting them
use each other's code more easily, in this case Pylons and BFG), it
allows those developers to create more add-on features over time. You
as an application developer or nervous boss may not see many
advantages at first, but they'll come in the form of more add-on
products over time than would apear otherwise, and access to
previously-inaccessible products. E.g., if it becomes feasable to run
Zope products in Pyramid (which we're exploring for Plone), that could
enable access to its search products and other things.
--
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.
