[BlueBream] How to simplify Zope 3 development

[Alex Clark]

On 2012-09-07 17:32:19 +0000, Christopher Lozinski said:

> First thank you for your comments.  Here I am far from the nearest Zope
> developer, so this email list is my lifeline to feedback.
> 
> 
> So how does hiding ZCA in ZOPE 3 differ from the alternatives?  It is
> clear that Pyramid and Grok are the two most closely related
> technologies.    I will call Zope 3 with ZCA hidden BlueBream.    First
> let me compare BlueBream with Pyramid.  Then BlueBream and Grok.
> 
> First of all Pyramid has been doing great in the market, so I trust that
> it functions, is bug free, and the docs are up to date.   In contrast
> Zope 3, and BlueBream seem mostly dead, although ZTK has a few users.  I
> believe pyramid is doing way better than Grok.


Well, let's get the terminology straight. "Zope 3" is entirely dead. 
Its remnants have been divided up into (more or less) the ZTK and 
Bluebream. ZTK is a set of reusable libraries (more or less) and 
Bluebream is the application server.


> 
> Second Pyramid only uses the ZCA from Zope, nothing else.   I believe.
> Correct me if I am wrong.
> 
> But Pyramid and Zope 3 are really very philosophically different.
> Pyramid is designed to optimize run time performance.  I am much more
> concerned about developer time required.
> 
> Their default security policies are different. Zope 3 wraps every object
> in a security space suit to test for permissions, Pyramid just tests
> once at the display page.  Although it could optionally use Zope 3
> security.
> 
> If I want to do TTW development, then I need to have Zope 3 style
> security.  As a TTW developer, I want to be able to view any url, and
> the methods it calls,  but only if the user has the right permissions.
> Which means that all methods are display pages, and need to have
> security on them.
> 
> The next difference between Pyramid and Zope 3 is the schema. Zope 3
> Schema like Ruby on Rails, should make it possible to bring up some
> sophisticated applications quite quickly.  And then customizations can
> be made to the user interfaces if desired.  In contrast, in Pyramid,
> CRUD and validation requires more work.   Please correct me if I am wrong.
> 
> It is also important to consider the world views of the relevant
> communities. I believe that the Zope 3 world, while it has mixed
> feelings, is more favorably inclined to TTW development than the Pyramid
> world.
> 
> As for Grok, I think I agree with James Clark's position, that it moves
> ZCML to python.  Meaning that it still keeps the Zope Component
> Architecture.  What I want to do is to hide the Zope Component
> Architecture for beginners, and new projects.  Then make it possible to
> use it when it becomes necessary.   In particluar if I only have one
> class with a certain interface, ZCA imposes a burden on me.
> 
> I think security is really the center of all of this.  I like roles,
> principles and permissions, and lists of them, called registries.  But
> then Zope 3 grants permissions to interfaces.  And one has to get into
> registering classes and interfaces.  I think the new developer would be
> happier to just assign permissions to methods.  Or better yet, acquire
> permissions for all methods in a class.  That works for starters.  At a
> certain point they will realize that these methods have one permission,
> and a few methods have another permission, and they make those changes
> on some methods, or possibly will start to want to use interfaces.   And
> at that point they should be allowed to do so.
> 
> And of course eliminating the need to register classes, and interfaces
> in ZCML is a wonderful simplification.  If I need to find something,
> just look it up on the ZODB tree.
> 
> So hiding ZCA makes it easier for anyone to use BlueBream, and
> particularly makes it easier for new developers and new projects.  Just
> make it python objects on the ZODB.
> 
> Are there any other parts of ZCML that need to be hidden?
> 
> And of course I love TTW development, where a nice web page allows me to
> add Principals, Roles and Permissions.
> 
> I hope that provides a clear vision for where I think this technology
> should go.   At least I know what I need to do next.  Namely dig into
> the security libraries to figure out how to do this for the applications
> I want to build.
> 
> Comments are hugely appreciated.
> 
> 
> Christopher Lozinski


-- 
Alex Clark · http://pythonpackages.com