[BlueBream] Does Missing Acquisition cause Zope 2/4 BlueBream Split?

[Christopher Lozinski]

I always wonder why the huge Plone community does not move over to
BlueBream/Zope 3?  Worse yet Zope 2 is now becoming Zope 4, so the
bifurcation is permanent.  What is going on here?  Is the lack of
acquisition in BlueBream the cause of the split?

How did I get here?

I am trying to put together a rapid prototyping environment much like
Zope 2 TTW interface on top of BlueBream.   It is really way past time
for me to have left Zope 2.  But it is not so easy to do.  Surprisingly
no one has gone before me.

There are a number of small problems, missing python scripts, getting
ZAM.DEMO to work, things like that.   All fixable.  But there is one
huge problem.  Acquisition is missing from BlueBream. 

It is not just missing, it is intentionally thrown out.  The best
description for the reason is here.

http://wiki.zope.org/zope3/NamespacesInTemplates

I quote:

    In Zope 2, page templates take advantage of implicit acquisition to
    find components and read data. Implicit acquisition works well, but
    it hurts reusability by making it difficult to discover what
    contracts the templates rely upon.

    Zope 3 abandons implicit acquisition in favor of explicit contracts
    and well-defined components. While this is an important step
    forward, template authors relied heavily on implicit acquisition and
    something almost as easy needs to replace it.


I think  I understand the issue. There are really different philosophies
of software development.  In a large project you want interfaces,
contracts that code has to follow, so one developer does not break
another one's code.  So one bunch of code can be reused by someone else.
  In small single developer projects, often funded by the developer
himself, you just want the code up and running quickly. 

So the whole Zope 2 TTW paradigm was great for small projects.  Shared
headers and footers get moved up to the top of the acquisition tree. 
Things used in just one branch, move down the tree.  It is  a powerful
prototyping paradigm.   And of course completely breaks down in large
group projects where no one person knows what is used where, and where
in the tree it should be.  And it breaks down when you want to reuse the
code in another project.

Still the whole Plone world is still on Zope 2/4.  Maybe it is because
of acquisition.  And BlueBream seems quite dead in the market.  If we
brought acquisition over to BlueBream, and got the TTW stuff working,
would more Plone users move over here?  Would this community come back
to life?

Is this hard to fix?  I sympathize with the person who said BlueBream
code is scary.  It really is quite complex. Used to be  350K lines of code.
http://www.peterbe.com/plog/size-Zope3,Django,TurboGears
On the other hand, maybe all I have to do is use one of the traversal
hooks to wrap objects with acquisition code. 

Maybe my biggest wish is just to have people to talk to about this
stuff.  The one senior guy who knows this stuff is quite focused on well
getting a well defined project request from me.   I think I know what
needs to be done, but I am not yet confident about it.  Feedback is
hugely helpful.

Of course my huge breakthrough was from reading the web page on the
defense of the Pyramid architecture.  I now understand that there are
different development models required. In the BlueBream case,  both the
complex ZCA model and simple TTW development models need to be supported.

What do you think? 

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/bluebream/attachments/20120212/467ac5fb/attachment.html>