[Zope3-dev] Zope 3 Source organization

[Martijn Faassen]

Tres Seaver wrote:
> > - Separated presentation code into separate trees to make it
> >    easier for people working on presentation only.  The idea was
> >    that presentation folks didn't want to scan through the regular
> >    sources to find presentation code.
> 
> I think this was a false goal:  we were trying to satisfy an audience
> who doesn't (yet, anyway) exist, penalizing the folks who actually work
> in the Zope3 code every day.

Actually the presentation folks were right there at the sprint in december.
I am not sure whether we succeeded in our goals as we lost almost all of them
again, I think, before they even saw the new hierarchy.

I think the goal in itself is fine; we want to support independent
presentation folks. I think we know from experience in other systems
as well that separating out the views from the source code can be useful there. 

What we are still seeing is that these people aren't here. I'm not
sure where the problem lies. Perhaps we don't advocate it enough or
perhaps Zope 3 is just too hard to penetrate, still.

We should investigate the why of this. 

> > - Separated interface code into separate trees.  This was driven
> >    by two things:
> > 
> >    o People working on presentation need to consult interfaces.
> >      There's no point separating the presentation code if people
> >      still have to search the regular code for interfaces.
> > 
> >    o Tres at one point lobbied for separating the interface code
> >      into a separate tree.
> 
> The only case I can see for separation is where true pluggability is a
> high-priority goal:  e.g., you have an important use case for supplying
> alternate implementations of a component, and the real cost of
> abstracting away the interface and the browser bits will pay *immediate*
> returns.
> 
> Note that I will contend that pluggability is *not* a goal for
> straightforward content objects!

I've been trying to make a closely related point elsewhere in the thread.
I also think this goes further than just hierarchy reorganization.

> In cases where the abstraction is worthwhile, the browser bits will
> presumably depend solely on the interfaces;  we should therefore locate
> the browser bits *with* the interfaces on which they depend.  Such
> interfaces and dependent browser bits then form the framework into which
> concrete implementations plug themselves.

A perspective I had not considered yet. Here the interfaces would be
almost more part of the view than part of the content.

Anyway, one development model is this:

           views            -- view designers

         interfaces         -- view designers ask for features,
                               content designers supply features

           content          -- content designers

This development model would seem to be supported by separate hierarchies.
I think we can all agree that this is indeed a useful development
model. I love being able to hand over the UI part of an application to
a view designer myself.

But the problem is that our current development model is this:

view - interface - content --  programmer A

view - interface - content --  programmer B 

view - interface - content --  programmer C

which is, by and large, because this is a programmer driven project. One of my
complaints is that I have to go through all this work to provide pluggability
but then there's nobody else that will then plug into it. :) I'd prefer
developing something useful first and then expose pluggability later
when it becomes necessary.

A response we could have is to make things easier for programmers, at
the potential risk of making things harder for UI designers in the future.
Another response would be to try to drag some UI designers into this
discussion. The risk there is that it seems to be a very hard thing to
do. I'm not sure what that means.

Regards,

Martijn