Pyramid and Zopache have the same geneology, but are philosophically very different.  Pyramid is focussed on the needs of corporate developers.  Zopache is targetted at end users.  Corporate developers want to use relational databases, url dispatch, Apache, unix, github, buildout, setuptools, pypi, python, WSGI and vi.  End users do not want to deal with any of those technologies, they want user-friendly browser-based technologies, like ckEditor, ACE Editor and the ZMI.


Target Market

Corporate developers care about performance. How fast will the computer run? End users care about the user experience. How easy is it for the end user? Pyramid is focussed on unix developers. Unix Geeks. Zopache is focussed on creative professionals. People who want to create a multimedia portfolio for themselves. Zopache users either do not know or do not want to use all those technologies. They just want to put up their web site using a browser. KISS.

And of course Pyramid has lots of developers working on it, and tons of users. Zopache only has a single developer. But in the long run, the end user market is orders of magnitude larger than the corporate developer market.


Pyramid and Zopache make heavy use of interfaces, but Zopache also makes use of Zope.schema.  Pyramid uses zope.interface for view dispatch and security.  Zopache also uses zope.interface for view dispatch, but not for security. 


Zopache uses Zope.schema and z3c.form for defining user interfaces.  Pyramid does not.  Grok and Zopache use interfaces and schemas for generating forms.  Pyramid supports any python forms package.  Zopache uses interfaces and schemas for defining ZClasses.  

Pyramid Vs ZTK Security

Pyramid Zopache, Grok, and ZTK all have different security models. 

Pyramid and Grok have security on views.  That is a good idea.  They implement it differently.   Grok has a requires directive used to specify what permission is required, and a rich vocabulary for assigning permissions.  Pyramid also specifies the required permission for views, but then it queries the content objects to see if they support that permission.  Pyramid objects, or classes have an __acl__ attribute.  It either returns the permissions for viewing that object, or it is called to return the permissions.  So Pyramiid ties security to the content classes definition.  I prefer the Grok approach. 

ZTK   also supports security on objects.   Grok removes security on objects during traversal.  Zopache will also be using security on objects.  ZTK places security on objects, involves wrapping them in a security proxy. ZTK has two layers of security.  The defines a generic security model.  Then zope.securitypolicy defines a very zope-2 like security policy. 

zope.securitypolicy  lets you allow or deny permissions.  

The initial release of Zopache has a simple security model. When you register you get a branch of the tree under you.  You can add and edit objects on that branch, others can view them.  




Why is the Pyramid Job Market written ing GROK/ZTK?

I love  python, objects, the ZODB and Object Traversal.  I want to have nothing to do with relational databases and URL dispatch.  They just make the system more complex.   For ZClasses, I needed zope.schema.  For creating CRUD Forms from zope.schema I needed zope.formlib.  For displaying a person (represented as a tree of objects), I needed z3c.form.  If you want to build a corporate application with some security on it, Pyramid is fine.  But since I wanted to build an application where the users control the security on their folders, articles and groups, I very much need zope.securitypolicy.  Nothing else like it out there.   So there are specific technical reasons why I choose Grok/ZTK.

But the issues are deeper than that.  There are two deep phiolosphical difference between the Grok/ZTK approach and the Pyramid approach.  Pyrmaid is focussed on cmoputational performance.  I am focussed on developer efficiency. Labor and time to market are more valuable than servers.  For me development speed is much more valuable than computer speed.  So rich libraries with lots of useful functionality is what I prefer. 

 Pyrramid takes the currently popluar approach of lots of small libraries performing different functions. I see things as a graph of objects all interconnected.  There is a tree of objects (ZODB).  Objects have fields(zope.schema).  Those fields are displayed in forms (zope.formlib,z3c.form).  Those forms have security requirements (zope.securitypolicy) based on where they are in the tree of objects.   Objects are accesse by traversal.  Securiy is accesssed during traversal.  I just do not see how these pieces can be build separately from each other.  I live in a world of object graphs.  Graphs are interconnected.  

  I prefer the power of monolithic frameworks.   I want a rich framework that does a lot for me.   Pyramid offers a very stripped down minimalsit environment.  Choose your database, configuration options, user interface, and security machinery.  

In any case, I find it very interesting that the PYramid Job market is built in Grok?ZTK. 

Zope Component Architecture (ZCA)

Pyramid and Grok/Zopache both depend on the Zope Component Architecture, but they handle it differently. ZCA is a rich meta-object infrastructre on top of the python language. It provides class meta informaiton, which is useful in many different ways. But it does add complexity to the system. Pyramid hides it under their own api. They just use it for selecting the correct view. Developers just get a simple python object model. They can choose from multiple form libraries.

In contrast Grok manages the ZCA using directives. Grok directives make the ZCA very easy to use. They look like python commands but are executed at load time, maybe not at run time. Grok uses the ZCA not only for selecting views, but also for creating, editing and displaying forms, based on the interface classes.

I invite you to Register and then link to your own blog postings and software packages..

Powered by Zopache, Grok, Zope and ZODB

Robots Crawl This