[Zope] FYI: Python product tutorial updated

[seb]

> I'd be very interested to hear any ideas you folks have
> on ways to help "make simple things simple" for development
> and to allow people to deal with complexity only as they
> begin to need it...

I entirely agree with Jerry's points about the standard zope
distribution.  There are various architecture / grammar / security
issues that need to be adressed in Zope.  However, I believe a much
higher priority should be given to a rationalised set of
documentation, plus a core set of products and templates, to be included
with the standard Zope distribution.  It
should be easier to upgrade or add modules; I read a suggestion
somewhere that a product standard should be produced, to which all
products must conform (package layout, etc).

Here's my thoughts in more detail, FWIW:

Who are the target users of zope?  My personal take is:

1) application developers (in the unzoped world, java, php, perl
hackers)
2) interface developers (html coders, designers)
3) content managers

I've been using zope for about a month now, (and *thinking* about using
it for more than a year!) and my thoughts on
simplicity for these users are:

1) application developers

Application developers should *expect* a steep initial learning curve. 
Even python took me a little while to get my head round, but it was
worth it.  PHP is only easy because it follows a paradigm that people
have learned elsewhere.  There's no point trying to shield application
developers from the complexity of zope.  But we need to hold their hand
until they can do it by themselves.  
The _ONLY_ hurdle to my zope enlightenment is (surprise) the
documentation.  In particular, what consistently holds me back is the
lack of api documentation.  I'd like to see something like javadoc-style
API descriptions.  I know, it's open source, I could do it myself.  I
know, I'm covering old ground.  But I can't state enough how immensely
frustrating it is to spend 5 hours trying to work out how to do
something that you *know* you could do in 5 minutes in PHP.  I don't
know much about the ZDP and I'm sure they're putting in a lot of effort,
but my feeling is that it is _very_much_ in the best interests of DC to
promote a decent set of references.
Even something as simple as repackaging the ZQR and including it in the
standard distribution would be a start.  When I get some time I'd love
to help with this.

2) dtml is too much like a programming language and I'm finding it a big
effort to abstract the logic away from DTML sufficiently.  Interface
developers want "<dtml-var latest_news>" rather than "<dtml-in
objectIds('news')>...", etc, in their HTML.  The mechanisms for doing
this are already present in zope but the onus is too much on the
application designer to come up with ways of doing this.  I always end
up doing application logic in DTML documents because it's easier (and
_quicker_) than spending a while coming up with an abstract design and
then coding it all in python and loading it as External methods and then
having to debug it all.  Efforts like ZPatterns and the PTK are the way
forward here: toolkits and design patterns that make common tasks
easier.  A project to come up with patterns and toolkits for common
template-building tasks would be valuable.  It should also be easier for
application developers to create custom DTML tags.  There should be a
simple way to package tags and install tags, and then a library could be
started on zope.org.  For example, a question recently posed on the
mailing list was how to include the contents of another web page in your
own document.  The obvious answer is an External method - however,
wouldn't it be neater to encapsulate this functionality in a tag? (i'm
sure this debate has been worked through before...)

>                            ... A Graphic Standards
> "Template" that can be applied in the form of a "wrapper",
> and can be adjusted trough a forms based interface with
> options for colors, type style, background images, etc.
> 

3) I understand skinnable CMS interfaces are on their way.  At the
moment I have to re-code the whole management interface from the bottom
up for each client, which is a real drag.  I'm really looking forward to
this feature. 

Seb