Skip to content
This repository
Browse code

rework rails section

  • Loading branch information...
commit a091495e63444264cbd6588f8e37f7c10ca1dadc 1 parent d27cd5f
Chris McDonough authored January 09, 2011

Showing 1 changed file with 46 additions and 26 deletions. Show diff stats Hide diff stats

  1. 72  docs/designdefense.rst
72  docs/designdefense.rst
Source Rendered
@@ -700,32 +700,52 @@ built using :app:`Pyramid` as a base.  See also :ref:`apps_are_extensible`.
700 700
 Pyramid Provides Too Many "Rails"
701 701
 ---------------------------------
702 702
 
703  
-:app:`Pyramid` provides some features that other web frameworks do
704  
-not.  Most notably it has machinery which resolves a URL first to a
705  
-:term:`context` before calling a view (which has the capability to
706  
-accept the context in its argument list), and a declarative
707  
-authorization system that makes use of this feature.  Most other web
708  
-frameworks besides :term:`Zope`, from which the pattern was stolen,
709  
-have no equivalent core feature.
710  
-
711  
-We consider this an important feature for a particular class of
712  
-applications (CMS-style applications, which the authors are often
713  
-commissioned to write) that usually use :term:`traversal` against a
714  
-persistent object graph.  The object graph contains security
715  
-declarations as :term:`ACL` objects.
716  
-
717  
-Having context-sensitive declarative security for individual objects
718  
-in the object graph is simply required for this class of application.
719  
-Other frameworks save for Zope just do not have this feature.  This is
720  
-one of the primary reasons that :app:`Pyramid` was actually
721  
-written.
722  
-
723  
-If you don't like this, it doesn't mean you can't use
724  
-:app:`Pyramid`.  Just ignore this feature and avoid configuring an
725  
-authorization or authentication policy and using ACLs.  You can build
726  
-"Pylons-1.X-style" applications using :app:`Pyramid` that use their own
727  
-security model via decorators or plain-old-imperative logic in view
728  
-code.
  703
+:app:`Pyramid` provides some features that other web frameworks do not.
  704
+These are features meant for use cases that might not make sense to you if
  705
+you're building a simple "bespoke" web application:
  706
+
  707
+- An optional way to map URLs to code using :term:`traversal` which implies a
  708
+  walk of a :term:`resource tree`.
  709
+
  710
+- The ability to aggregate Pyramid application configuration from multiple
  711
+  sources using :meth:`pyramid.config.Configurator.include`.
  712
+
  713
+- View and subscriber registrations made using :term:`interface` objects
  714
+  instead of class objects (e.g. :ref:`using_resource_interfaces`).
  715
+
  716
+- A declarative :term:`authorization` system.
  717
+
  718
+- Multiple separate I18N :term:`translation string` factories, each of which
  719
+  can name its own "domain".
  720
+
  721
+These features are important to the authors of :app:`Pyramid`.  The
  722
+:app:`Pyramid` authors are often commissioned to build CMS-style
  723
+applications.  Such applications are often "frameworky" because they have
  724
+more than one deployment.  Each deployment requires a slightly different
  725
+composition of sub-applications, and the framework and subapplications often
  726
+need to be *extensible*.  Because the application has more than one
  727
+deployment, pluggability and extensibility is important, as maintaining
  728
+multiple forks of the application, one per deployment, is extremely
  729
+undesirable.  Because it's easier to extend a system that uses
  730
+:term:`traversal` "from the outside" than it is to do the same in a system
  731
+that uses :term:`URL dispatch`, each deployment uses a :term:`resource tree`
  732
+composed of a persistent tree of domain model objects, and uses
  733
+:term:`traversal` to map :term:`view callable` code to resources in the tree.
  734
+The resource tree contains very granular security declarations, as resources
  735
+are owned and accessible by different sets of users.
  736
+
  737
+In a bespoke web application, usually there's a single canonical deployment,
  738
+and therefore no possibility of multiple code forks.  Extensibility is not
  739
+required; the code is just changed in-place.  Therefore, the features listed
  740
+above are often overkill for such an application.
  741
+
  742
+If you don't like these features, it doesn't mean you can't or shouldn't use
  743
+:app:`Pyramid`.  They are all optional, and *lots* of time has been spent
  744
+making sure you don't need to know about them up-front.  You can build
  745
+"Pylons-1.X-style" applications using :app:`Pyramid` that are purely bespoke
  746
+by ignoring the features above.  You may find these features handy later
  747
+after building a "bespoke" web application that suddenly becomes popular and
  748
+requires extensibility because it must be deployed in multiple locations.
729 749
 
730 750
 Pyramid Is Too Big
731 751
 ------------------

0 notes on commit a091495

Please sign in to comment.
Something went wrong with that request. Please try again.