[Zope3-dev] Allowing views to be registered for classes rather than interfaces.

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:

...

> I suspect the problems arise because we have a lot of small objects and
> code fragments interacting with each other; the patterns in which they dance 
> are frequently complicated and hard to remember.

By far, the common case is that you have 2 objects, a view, and the
thing it's viewing. The component architecture simply separates these into
two objects. The pattern is very simple.

Granted, objects may have multiple pages, where each page is a separate
view. You can choose to implement this as a single view if you wish, at least
wrt Python.

> Where Zope 2 has overly
> fat objects and interfaces and a problem as a result, Zope 3 has overly
> complicated patterns and interfaces where none are yet needed.

Could you give an example?

 > Code
> evolves from ill-defined patterns that are closely tied together to
> more pluggability as it turns out to be needed. With Zope 3 at present
> one is forced to support endless pluggability right from the start.

This is FUD.  What sort of "endless pluggability" are you forced to
support? Does the contact example support "endless plugability"?

While I think that there is *some* merit to the argument that you and
Phillip are making that you should be able to write a view or adapter
against an implementation, rather than an interface. I think the
sweeping characterizations you are making are inaccurate and unhelpful.

> Admittedly his is far more common with Zope 3 framework code than Zope 3
> application code -- but since the Zope 3 framework is in many ways a Zope 3 
> application it still has me worried.

You got frustrated by a bit of the framework code that has some essential
complexity to deal with a hard, but important problem.  The complexity
of this code arises from the problem it is addressing (automated software
installation), not from the way the software is created.

...

> A suggestion that I already made to you in private is giving each class its
> own interface that is unique to itself.
 >
 > Often now interfaces have
> to be created in the interfaces tree and we have to import them all
> over the place, refer to them from ZCML, etc, while we are writing
> *very specific application code*. We have to bear the full brunt of the
> component architecture when we're not altogether sure whether this
> interface is reusable at all. This is really bad for prototyping; 
> programmers can't be expected to come up with reusable interfaces
> right away.
> 
> So I propose the following:
>  
>    * each class implements its own unique marker interface
 >
>    * this interface is just 'there' for importing from some obvious
>      location.

So the programmer doesn't have to implement it.

I think you are asking for what Phillip suggested,
the ability to register a view for a class, rather than
an interface.

>    * It's also easy to refer to this interface from ZCML.

Presumably by just refering to the class.


> This way it's possible to hook up things directly, in effect through class,
> but does not require much extra machinery or new ZCML directives to make
> this work (as we introduce a marker interface).
> 
> If we then later on notice that there is something reusable going on, 
> you can:
>  
>   * now introduce the actual handwritten interface.
> 
>   * make sure by altering code that the classes now implement this interface.
> 
>   * change around the various directives in ZCML so they now hook up to this
>     interface.
> 
> I realize that this makes it more likely that functionality is added
> through changing code, not through addition of new code. While I think
> that goal is admirable and useful in gluing different components written
> by multiple independent people together, in reality components often
> evolve in sync and are written by the same group, and they evolve by
> their code changing. This is a normal and acceptible programming practice.
> 
> The advantage of this proposal is that the whole interface tree
> remains where it is, but can still be forgotten about when writing
> new code. It cuts down on one typical location in the interface tree,
> view tree, content tree triad.

But leaves the extra view tree, which is still a hassle.

> Possibly a similar pattern can be followed for default views that
> are just 'there'. I don't know what that would look like, but it might
> leverage schema/forms without requiring the extensive directives.

Explicit is better than implicit. No magic please.

> The goal of these proposals is to make it possible for the programmer to
> just focus on the actual problem at hand and solve that instead of
> setting up all this infrastructure that has to be tied together first
> before Zope 3 will even start. The solution that the programmer wrote won't 
> be reusable from the start, but very importantly it gets the job done quickly.
> 
> There's a tradeoff in programming; you can get the job done in a nice
> pluggable reusable way, or you can get the job done *quickly*. Zope 3
> is very good at the former, but it should improve the latter a lot.
> Often it has been said that various ZMI features will solve this,
> and I'm sure they will help, but the same must the case from Python.

I'll note that an important benefit of interfaces aside from plugability
is a clear specification of what the contract is.  With interfaces, I
have much better separation of concerns.  I know how I can change an implementation
because I know what it's contract is.  Certainly all code in the core
should have clear contracts.

So, I think the essense of your proposal is to allow components to be registered
against implementations, rather than interfaces. In theory, this speeds development
by allowing one to connect content and views without the bother of creating an
interface first.  I think this has some merit, however, I'll note that:

- It won't simplify ZCML at all

- Most content objects now use schemas, so it is rare that you'll be
   able to avoid defining an interface first anyway.

I'm quite open to this proposal and would be curious to here what other
people think.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org