<br><br><div class="gmail_quote">On Sun, Feb 12, 2012 at 8:58 AM, Christopher Lozinski <span dir="ltr"><<a href="mailto:lozinski@freerecruiting.com">lozinski@freerecruiting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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?<br>
<br>
How did I get here?<br>
<br>
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. <br>
<br>
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.
<br>
<br>
It is not just missing, it is intentionally thrown out. The best
description for the reason is here. <br>
<br>
<a href="http://wiki.zope.org/zope3/NamespacesInTemplates" target="_blank">http://wiki.zope.org/zope3/NamespacesInTemplates</a><br>
<br>
I quote: <br>
<blockquote>
<p> 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.</p>
<p> 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.</p>
</blockquote>
<br>
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. <br>
<br>
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. <br>
<br>
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?<br>
<br>
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.<br>
<a href="http://www.peterbe.com/plog/size-Zope3,Django,TurboGears" target="_blank">http://www.peterbe.com/plog/size-Zope3,Django,TurboGears</a><br>
On the other hand, maybe all I have to do is use one of the
traversal hooks to wrap objects with acquisition code. <br>
<br>
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. <br>
<br>
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.<br>
<br>
What do you think? <br><span class="HOEnZb"><font color="#888888">
<pre cols="72">--
Regards
Christopher Lozinski
Check out my iPhone apps TextFaster and EmailFaster
<a href="http://textfaster.com" target="_blank">http://textfaster.com</a>
Expect a paradigm shift.
<a href="http://MyHDL.org" target="_blank">http://MyHDL.org</a></pre>
</font></span></div>
<br>_______________________________________________<br>
bluebream mailing list<br>
<a href="mailto:bluebream@zope.org">bluebream@zope.org</a><br>
<a href="https://mail.zope.org/mailman/listinfo/bluebream" target="_blank">https://mail.zope.org/mailman/listinfo/bluebream</a><br>
<br></blockquote></div><div><br></div>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.<div>
<div><div><br></div>-- <br>Christopher Warner<br><a href="http://cwarner.kernelcode.com" target="_blank">http://cwarner.kernelcode.com</a><br>
</div></div>