[Zope3-dev] Re: Zope 3 web root

[Jeff Shell]

On 2/17/06, Shane Hathaway <shane at hathawaymix.org> wrote:
> Incidentally, I find it difficult to make any argument about anything
> because I fully appreciate many sides of the issue. :-)

You and me both :)

> Gary Poster:
> > one could argue that ZODB-based TTW dev got to be so  problematic
> > *because* it was so successful.  There are strengths there.
> >
> > That said, I'm eager to see what you might think up as an  alternative:
> > I think both paths might be fruitful.

Personally, I like the idea of third party alternatives. I think one
of the most extreme and interesting "portlet" style implementations is
Seaside's halos. When they're turned on, from what I can tell from the
few times I've looked at Seaside and related documentation, you have a
lot of customization power. It's not for everybody. But I think it's
an implementation that personalizes Zope 2 style Through The Web
capability by localizing what you edit to the component that you see.

http://blogs.inextenso.com/seaside/blog/learning/0cf6f89c-7824-11d8-81ca-000a27b05150

http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/

CSS, HTML, and Smalltalk Source for everything is accessible - but
it's accessible *in place*, not buried in a completely foreign
interface or buried deep within a master template or script... It's
still object oriented. Fascinating. But as I said earlier, this is
something that Smalltalk's image oriented development supports (where
all of the code lives inside a virtual machine/environment, away from
any concept of files). The ZODB *can* behave like this, but that only
works best if all concept of code-in-the-ZODB-image is separate from
any-kind-of-data that might be in it.

Anyways, that's an aside. It's not something I nor any of my customers
need. But it would be an interesting thing to see someone take up.

> The web root is my best idea for an alternative.
>
> Although I've been talking about addressing the needs of new adopters,
> I'm really trying to address *my* needs.  I want to build a complex web
> site using Zope technologies, but I don't yet know enough about what I'm
> building to be able to do any model/view separation.  I intend to write
> dirty, filthy, unmaintainable code.  It's the right thing to do!  If it
> works, I'll clean it up.  If it doesn't, I'll throw it away and try
> something else.  If I write it with Zope technologies, I know I can
> succeed at cleaning it up because Zope has the most powerful tools out
> there.  If I write it with Apache, I'm certain I'll end up building my
> own framework to support whatever flavor of messiness the solution
> generates, it'll take twice as long, and it will be impossible to clean
> up, so I'll have to start over if I want it to last.  Gimme Zope!
>
> While I'm writing messy code, I also invent messy processes along the
> way, and ZODB can't easily support my random new processes.  I often
> write automated tests for messy code.  I often think to myself, "what is
> the ugliest possible way I can write this?"  Then I really do it and
> laugh.  That gets me moving when I'm stalled.  Sometimes I rewrite
> something ten times, relying on version control to get me back.  It
> turns out that the CMF skins tool is much better at supporting this kind
> of work than Zope 3 currently is.
>
> I want Zope to encourage clean code just like everyone else, but
> interesting things rarely start out clean!  If Zope wants to be a
> platform that people can use to invent crazy new things, it has to allow
> for messy code and processes.

Where doesn't it allow this? I wrote about this in Griddle Noise
earlier this week. I feel more free to mercilessly restructure in Zope
3. I feel free to write things crappy or mediocre initially. Most of
our big projects have been done under hard deadlines and technical
debt was accrued along the way. But much of that debt was easy to pay
back, sometimes with just a day or two of postmortem reconstructive
surgery.

How is the skins tool better than actual Python classes as view
objects? They're still on the file system. They can still be under
version control. The page templates are still on the file system. They
can still be under version control.

I guess I still don't understand how you're using Zope 3, because it
sounds like you're using it very differently than I am. I've long
since abandoned the ZMI. I never see that list of addable objects (in
fact, in my newest applications, I completely bypass IAdding). I
basically see the "Zope 3 ZMI" long enough to add one of my
sites/applications. At that point, my skins take over, and that's all
I see. The rotterdam skin is there as last resort to get out of
trouble or to tweak local utility configurations.

I guess I've just made some supporting libraries and frameworks to
help me. I had this with Zope 2 too, but it's been easier to do with
Zope 3. I encourage everyone to do this.

--
Jeff Shell