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

[Christopher Warner]

On Sun, Feb 12, 2012 at 8:58 AM, Christopher Lozinski <
lozinski at freerecruiting.com> wrote:

>  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 EmailFasterhttp://textfaster.com
>
> Expect a paradigm shift.http://MyHDL.org
>
>
> _______________________________________________
> bluebream mailing list
> bluebream at zope.org
> https://mail.zope.org/mailman/listinfo/bluebream
>
>
I just got around to reading this, technically speaking and at least in my
use cases I don't see the need to expose TTW if it isn't required, which is
very rarely if ever. For the most part I'm of the mindset that TTW should
never be exposed past a default interface for whatever one may be
programming on for testing purposes. The tao of ZCA requires that maybe a
programmer, actually be a programmer, and design his or her application
before they write it IMHO. Yes, this takes time and isn't as rapid a
process as some would like. Yes, it is slower and takes a little more time
to wrap your head around if you aren't familiar with the concepts and yes
laziness is default. However, if you've been doing this long enough and
writing any sort of application that is even slightly complex, it's
inherently useful.


-- 
Christopher Warner
http://cwarner.kernelcode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/bluebream/attachments/20120227/87482815/attachment.html>