[Zope3-dev] Zope 3 Source organization

[Martijn Faassen]

Stephan Richter wrote:
> On Monday 14 July 2003 03:36, Hannu Krosing wrote:
> > One option would be to keep related application/interface/presentation
> > files in same directories and differentiaote by name, ie. MyApp.FooApp,
> > MyApp.FooIface, MyApp.FooRepr
> 
> I would really not like this, I think. Then I prefer the current method. I 
> think this method removes us too far from other naming conventions, like the 
> one in Java for example.
> 
> Now that I think about it some more, I really would like to have interfaces 
> and browser back into the code tree. I think the separation is useless. I 
> have had not one experience yet, where I have not looked at code, ifaces and 
> views at the same time.

I think the problem is not so much that separate hierarchies exist. In
theory for pluggability having a separate interface and view hierarchy
is good. The problem that we're writing a lot of code that does not need
this pluggability, not right away, at least, and that it makes it harder
to set up new code.

The component architecture tries to ensure that you create a view against
an interface, and that a class just implements the interface. This is
nice; that you have to look at all three indicates that the code you
were working on did not need this decoupling (yet).

> When writing views you will have to look at the code 
> eventually. This might not be ideal, but I found myself doing it all the 
> time.

We need to offer a development model that supports this mode of
development -- tightly coupled code. Zope 3 is very good at decoupling
code, but it's not good at supporting tightly coupled code. We consider
this code inflexible and bad, but it's the code that gets a lot of
the world's software going. In XP it'd also be often the code you start
out with, doing the simplest thing you can possibly do.

> Also, I think we do not expect people to edit the actual FS code that 
> much, since development will happen in the ZODB anyways.

I'm not sure what this means. I am getting slowly worried hearing a lot
about the currently vaporware ZODB-based development model as solving
the problems we have with the filesystem model. I'm not sure if this
was your intended meaning though.

Regards,

Martijn