[BlueBream] BlueBream TTW

Fri Feb 3 17:22:13 UTC 2012

Okay, I am starting my third attempt at getting BlueBream to do my
bidding.  I am trying to build a Zope 2 TTW-like development environment
on top of BlueBream.

How did I get here?  Let me take it from the top.  I like the
dynamically bound languages Objective-C, Smalltalk and Python.  Static
binding in C++ makes no sense to me.   While Objective-C was quite dead
for a while, the iPhone has made it popular, and of course Python is
doing great.  Next we need a database, relational databases are such a
pain particularly for storing trees.  There are a number of closed
source commercial object-oriented databases with interesting features,
but in the python world, ZODB seems to be the open source market
leader.  Nothing much in the Objective-C world.   So ZODB brings me to
Zope.  Of course Zope 2 had its problems.  The ZCA Zope Component
Architecture is so much smarter.  Which brings me to BlueBream.

But this mailing list appears dead.  The website download page has the
most recent version as released a year ago, enough to scare even the
most hard-core BlueBream supporter away.   When I posted a tentative
email, I was discouraged, go use Pyramid they kindly suggested.

So I took a much closer look at Pyramid.   That community seems to have
grown so much in the last year.  But I just do not like the stripped
down computational model it presents.   The whole BlueBream Schemas make
so much more sense to me.  The more work the framework does, the less
work I have to do.  Or the faster I can do it.  And I have lots of work
I want to get done quickly. 

But I learned a very important lesson from the Pyramid guys.

http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/designdefense.html

They hid the ZCA from the end users.  Sure software geeks love the ZCA,
but it is really too complex for the average user.  That is the piece I
was missing.  Pyramid wisely hides it.  If we do a TTW development
environment, then lots of stuff needs to be hidden.  A simpler
computational model is needed.  Just instantiating objects onto a tree
is quite simple.  Furthermore the ZMI registration feature needs to be
hidden.   Just automatically register all views in the global register. 
And do not think of having adaptors registered, we want a simple
computational model for the newbies.   No adaptors! No ZCA!  That comes
later.  Sure all of that stuff needs to be there under the hood, but
hide it from the TTW interface.  KISS!

So what do we use as the foundation to build this?  Well there are three
TTW interfaces. I have looked at them all.  ZMI, ice.control, and ZAM. 
ZMI is so ugly.  And it gets so much bad press.  And the registration
part used to  confuse me.  Ice control has this lovely TTW python
interpreter.  And ZAM.demo, which two of us now report does not install
correctly, looks great.  It is extensible, if you can figure out the code. 

But I am back at using the ZMI.  It actually does what I want.  Add a
dtml method and view it, no problem!  I believe if I just get the
folders that use acquisition, and figure out how to use the PAU for
authentication I should be good to go.  I will also need python, TTW. 
Just straight python, not restricted python.   Why even bother with
restricted python, no one but me should have permissions to edit the
python code.

I can just feel some of my readers cringing as I write this.  I held off
writing this for a while, I have no desire for the bad vibes.  In fact
they kept pushing me away from this approach.  But I now better
understand why this email generates negativity. 

There are really two different computational models.  One is the classic
python file system based developer model.  You are actually editing text
files and using the Zope Component Architecture.  The other is the TTW
Zope 2 approach.   It has its strengths.  Each has their use cases.  But
if you are locked into one world view, the natural thing is to reject
the other point of view.   Really no point in getting into arguments
with people who see the world differently.  So rather than discouraging
this point of view, please let us allow each other to take different
approaches.  

And yes, if you do want to get into a serious discussion about this
stuff, I would be open to it.   In general I would love to talk with
anyone who understands these issues. 

I am never quite sure what I am going to do next.  Plans always change,
but here is my general idea. Rather than working in the abstract, I have
an application I am building TTW, starting with the ZMI.  
Strategically, what I want to do is use the Zope Schemas to define my
classes, and then implement the methods TTW.  I just need a class that
first looks up the methods in a TTW folder. You can see the code for how
to do this in ZClasses.   Later I can move the whole Schema definition
thing into a TTW model.

Why am I writing this?  Mostly to connect with other people who see
things the same way.  Partially because it helps me clear up my
thinking.   Partially because it generates useful information from the
readers.   At the very least, I will breathe some life into the
BlueBream mailing list. 

And compliments and thanks to all the people who wrote Zope 2,
BlueBream,  the BlueBream website, documentation and the excellent page
on defense of Pyramid Architecture.  Lots of great engineering has been
done here.  Now we just need to simplify it for newbies.

-- 
Regards
Christopher Lozinski

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

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