[Zope-dev] Comments on ZPatterns

[Ty Sarna]

In article <395A0742.4BDD8599@nipltd.com>,
Chris Withers  <chrisw@nipltd.com> wrote:
> 1. Too much jargon... by far... Lots of complicated words that are
> meanlingless to the layman and don't help to convey the concepts. This

Can you point out some examples of which ones you think are especially bad?

> is compounded by the standard Zope problem of minimal documentation
> aimed at the advanced developer. Can someone who understadns this all
> take the time to write a ZPatterns guide to compliment the Wiki and
> maybe simplify or explain in great detail all the terms (especially the
> new ones that have popped up in the last few weeks)?

Naming has been a struggle.  It's hard to come up with descriptive names
for these things.  Part of the confusion is that some things have been
renamed in an effort to make the meanings clearer in the long term.  But
short term, it's confusing and it seems like there are lots of new
concepts, when in fact there are just several names for the same concept
(Implementor -> Specialist, Rack-mountable -> DataSkin, etc).  I'll also
admit that Rack-mountable was a clearer name, but it was no longer
accurate.  We tend to err on the side of a name that doesn't clearly
describe something instead of a name that clearly describes something,
but describes it *wrong* so that you think you understand something and
really don't.  ("Well, at least the name tells you that you don't know
what it is!", as I've said :-)

> 2. Feature runaway. It seems every day something new (and more
> confusing) has been added to ZPatterns. I think ZPatterns will only work
> if it is kept as simple and functional as possible. My view (bearing in

You mention in another post that you feel lots of unnecessary features
have been added -- can you give some examples of which ones you feel are
extraneous? There has been only one major feature added in ZPatterns
0.4.0, which is the ability to have Rack-mountable-like things that
don't live in racks.  This is important for PTK-like applications where
you don't want to lump everything into one container, but would instead
like to have it distributed between member's folders, for example.  I
think it was worth it. 

Part of the percieved feature runnaway I think is due to the renaming
issue described above.  Also, a lot of what looks like adding of
features is actually reorganization and simplification of features that
were already there.  There's no need now for SQL Racks vs.  LDAP Racks
vs.  ZODB Racks, for example.  New features were added, but mainly to
avoid the need for other features to even exist.  In a lot of ways, the
code keeps getting simpler and shrinking (as an example, look at the
early LoginManager releases vs what's there now -- the code shrank
considerably and got much clearer!)

Future versions will follow this trend.  For example, we're probably
going to introduce a simple language to replace Generic Attribute
Providers, Generic Triggers, and such.  This actually will end up
eliminating stuff from ZPatterns and making it clearer, as there will be
less types of objects. It should also help the "I have to visit 4
different menus to set up one simple thing" problem. It will keep more
of the configuration together so you can see exactly what is going on.
I think it will be easier to explain and document as well.

> mind my limited understanding ;-) would be to concentrate on Containers,
> Container Groups and Plugins on the one front and Racks, Specialists and
> the various providers and agents on the other.

The PlugIns stuff is indeed separate, and is not really a part of
ZPatterns as much as it's stuff that we wrote to make ZPatterns and
other Zope products easier to write. You can pretty much ignore it if
you won't be writing python products or working in ZPatterns internals.

> PS: The main reason I'm writing this is because I think ZPatterns are
> very very cool but may well get ignored because no-one understands them
> and they're too buggy and complicated to get working :/

0.3.0 is pretty stable, I think. 0.4.0 alphas have been buggy. But they
*are* alphas, after all. You were warned :^)

From the unattributed mail you posted from someone else:
> > P.S. ABout ZPatterns: everyone I spoke to was thought the basic idea
> > behind  ZPattern was good and sound and nice and so on. But _everyone_
> > complained about it being too pretentious (with all the computer science
> > claims and theory behind it) 

What, you want something that's *not* based on any theory, just random
ideas? :^)

> > and introducing too many unnecessary new
> > concepts (racks, specialist and what have you). All this is very

Racks and Specialists are key concepts.  Saying that they're unecessary
and should be eliminated is like saying OO programming would be simpler
if they got rid of all the extra ideas like classes and objects.  Probably
so, but what would be left???

ZPatterns is new, and it can be confusing, and there is not enough good
documentation (or working examples -- I'm surpised this is one thing
there hasn't been much complaint about).  But, it is a lot like Zope in
this respect.  As someone who used Zope for quite a while before it was
even called that, and spent much time banging my head against the wall,
I'm guessing I have a pretty good idea of how you feel.  I've gained a
new sympathy for DC.  A lot of these complaints and comments look
suspiciously familiar to me...  It took time to figure it all out and
for Zope to improve.  So, please be patient...  we (Phillip especially) are
doing a lot of this on our "spare" time.  More and better documentation
would be nice, but at the moment we have a LOT of high-priority work
projects to finish (two major rollouts on two continents in two weeks --
fun!) , and it's hard to find time right now to work on things in
ZPatterns that don't directly affect our paid work.  (Much the same
situation DC is in a lot of the time, I suspect). 

So, in summary, please bear with us.  We're working on improving the
situation.  And if you have criticism of weak areas, please be as
specific as possible so we have a better idea of what we need to work on
communicating better or changing in the software to make clearer. 
Thanks!