[Zope3-dev] Number of languages in Zope 3

[Jeffrey P Shell]

On Thursday, March 27, 2003, at 03:21  AM, Steve Alexander wrote:

>> What can be doen to reduce the number of languages necessary to know 
>> in order to use Zope 3 completely?
>
> Why do you consider that a desirable goal?

And what does "completely" mean anyways?  In some situations, Zope 
sites are managed and maintained by a single person.  In others, there 
are many people involved.  I myself make good effort to avoid 
deployment duties, where ZConfig comes in to play.

I generally agree with Steve, and I myself don't think it's much to 
worry about, for reasons I'll explain below.

> In any case, different languages are made for achieving certain tasks. 
> Everything is ultimately implemented in Python, so you can use that if 
> you really want to.
>
> More specifically...
>
> To avoid the need to know DTML, remove DTML from Zope 3.
> I don't think we can do that, because some people want to use DTML 
> with Zope 3.

I doubt that DTML will be "necessary to know" in order to use Zope 3 
completely anyways.  DTML still has its place, but it's significantly 
downplayed in Zope 3.  I still think DTML is awesome for SQL Methods, 
thanks to the extra SQL tags.  But if you're using Zope plus relational 
databases, you need to know SQL in order to use Zope 3 completely.  I 
guess that's another language to add to the list :).

> To avoid the need to know ZConfig, write scripts in python to start up 
> your Zope process as you need it.
> I expect that Site Managers will generally prefer to use ZConfig 
> because it is easy to use, and similar to the way other process-level 
> things in other pieces of software are configured.

Besides, in Zope 2 you need to be really comfortable with shells and 
processes and the vast array of z2.py switches and environment variable 
combinations.  ZConfig simplifies that process.  They day I never have 
to shout into the other room "Try dash-capital-p!" is coming.  Many 
people have written their own starters and stoppers that use various 
config file formats.

> To avoid the need to know TAL/TALES/METAL, write all of your page 
> templates using python string substitution syntax.
> I expect TALES will be more attractive to the majority of webpage 
> designers.
>
> To avoid the need to know ZCML, write python glue code to set up the 
> individual components that you want to use, and write python code to 
> make security declarations for your classes.
> Most product developers and site managers will prefer to use ZCML.

As most know, I view ZCML as a necessary evil.  One of the big things I 
fear about ZCML's attribute-dependent XML(ish?) syntax is that it will 
make it difficult to make third party XML tools be able to work with 
and generate ZCML code that is still easy to edit in the poorly 
configured version of 'vi' that I always seem to run into on deployment 
servers.

In any case, ZCML is only as good as its documentation, and I applaud 
the efforts that have been done thus far, but it still needs 
improvements.  One example - skins.  This is the documentation for the 
attribute name:

     name --

       The name of the skin.

That doesn't tell me anything that I can't already infer from the 
structure 'skin name'.  What is the name used for?  How are skins set 
up and referred to and used?  Why doesn't this link to any of that 
documentation?

Now might be a good time to start moving all of this documentation to 
reStructuredText and evaluate what we'll need from reStructuredText.  A 
recent addition to reST is the concept of "Interpreted Text Roles".  
These roles are a slightly ugly but necessary (and powerful) reST 
mechanism for doing local customizations.  We could use Roles to do 
cross-referencing to Interface documentation, namespace documentation, 
whatever.  With some of the other writers in the works, such as LaTeX, 
we could hopefully enable generation of HTML documentation that is 
well-indexed and well-linked.  Could etags or some other 
editor-magical-ZCML modes be written that would allow me to select a 
ZCML namespace in ${EDITOR} and say "show me the documentation"?

> To avoid the need to know Python, use only the TTW point-and-click 
> facilities of Zope, most of which aren't yet written, but are planned 
> for.
> Or, use J2EE and choose Java instead of Python. Or use 
> CGI/Other-server-technology and use the languages of your choice.

Actually, J2EE probably has as many "language requirements" as Zope 3 
might.  On top of Java, there is JSP/Taglibs, and at least one XML 
configuration file format. And EJB's are just confusing.  Other 
J2EE/Java server solutions add even more custom (typically XML) 
languages on top of everything (see Struts for an example).  Compared 
to other powerful servers (including ASP.NET, which also uses a lot of 
XML and has an all-new templating language that bears some similarity 
to TAL/TALES), Zope 3 comes out just about even.  Our programming 
language is easier to read than most, but I still think that ZCML is a 
lot harder to read than many of the Java server XML configuration files.

I don't think we need to reduce the number of languages.  As I said, I 
doubt DTML will be used much (if at all) by new developers.  TAL/TALES 
is a godsend.  ZCML is a necessary evil (in my view).  I don't hate 
ZCML, I just have some lingering concerns that are probably moot at 
this point anyways.

ZConfig is the only one that could *possibly* go.  It doesn't make 
sense for us to introduce ZConfig for Zope 2.7 and not have it in Zope 
3, and I also believe that its primary audience will find ZConfig 
easier to work with than ZCML.  Is there any thought to keeping the 
current 'server.zcml' stuff working so that it remains an alternative 
for people (typically individual developers) that don't want to learn 
ZConfig?  (Not that I think ZConfig will be hard to learn.  Typically 
you configure a site once and tweak occasionally anyways - I seldom 
touch my zctl based zope.conf files while developing, and I seldom know 
how the deployment server is configured - as long as it can run my 
code, I'm satisfied).


Jeffrey P Shell, jeffrey@cuemedia.com