[Zope3-dev] Number of languages in Zope 3

[Jeffrey P Shell]

On Monday, March 31, 2003, at 12:55  AM, Chris Withers wrote:

> Steve Alexander wrote:
>> Someone who wants to install Zope will need to know the simple 
>> configuration language (ZConfig). And that is all.
>
> What class of user will _only_ want to install Zope?

The person at an ISP, Server Room, etc, who just has to install Zope 
and some products (possibly) developed by someone else.  This is a 
substantial class of users.

I only use Apache to run mod_proxy to pass control over to Zope and 
Roundup, hence I only know that little subset of Apache's configuration 
language.  I don't touch any other Apache configurations or extensions, 
nor even use Apache for serving up static HTML.  I just need to 
configure it occasionally and that's it.

>> Someone who wants to write their own product will need to know a 
>> programming language (Python), perhaps a templating language (Page 
>> Templates) and a complex configuration language (ZCML).
>
> What are the benefits of needing to know three as opposed to two 
> languages here?

Because HTML and Code being intertwined sucks.  ZCML is what makes Zope 
3 so fundamentally different from Zope 2.  It is what gives a 
developer, an application integrator, or a deployer the very fine level 
of control needed to install and configure components independent of 
the programming language.  Right now, configuration in Zope 2 happens 
in the __init__.py files of Products.  They happen in a certain order 
and while they are editable, are not exactly things you want to touch.  
Some __init__.py files configure little registries and components, such 
as the one in Formulator which sets up all of the available field types.

ZCML gives much greater control over this whole process than you can 
get by merely importing Python packages.

>> Someone who wants to write templates will need to know a templating 
>> language (Page Templates or DTML or both).
>
> Under what circumstances would they need to know more than just the 
> templating language in order to produce such templates?

When they want to do more than just templating.

>>  > Why do you consider that a desirable goal?
>> I need an answer to this question before I can make sense of what 
>> problem needs to be addressed.
>
> Simplicity is always better. Having to know extra languages definitely 
> reduces simplicity!

Considering that Zope + ZODB cuts down on the need to know SQL 
(something that you need to know with almost ALL other frameworks, 
whether you're using legacy data or just need to store simple objects), 
I don't think things are as bad as you think.

>> If you want to fully understand a project written in the ".NET" 
>> framework, you may need to know all of these languages, plus the 
>> configuration language that .NET uses.
>> http://msdn.microsoft.com/vstudio/partners/language/default.asp
>> How many languages do you count there?
>
> A lot. Why are we aspiring to be .NET?

If you want things to be bone dead simple, stick with something like 
PHP or one of the MANY "PSP" packages out there for Python.  Anything 
of Zope's magnitude needs (and uses some combination of):

- Base programming language for implementing components.
- Scripting language for working with those components (ASP, prior to 
ASP.NET, separated scripting languages from programming languages.  
ASP.NET does a better job of unifying things).
- Some configuration language for just running the server 
(WEB-INF/web.xml in Tomcat, Apache Configuration Files, foo.ini files, 
`config.py` files, etc).
- Some configuration language for describing exposed components, 
interfaces, etc.  This language, sortof a specialized ADL (Architecture 
Description Language), is significant in any kind of component 
architecture.  From the simplified Web Services architecture (using 
WSDL) to CORBA/CCM (CORBA IDL) to COM/.NET (COM's plethora of IDL's, 
assembly descriptors, etc), there is typically something that says 
"this is what this component is all about".

On that last one, since Component Architectures (which is a significant 
part of the Zope 3 story) are supposed to be built out of 
many-little-black-boxes, there needs to be a way to know what those 
black boxes do and to put them together.  In theory, one could build a 
powerful and unique Zope 3 application by just combining all of these 
boxes together by doing custom ZCML.

That's the part I like.  While the language still bugs me - I know that 
if I wanted to use something like the CMF but really really really 
really didn't want to install certain features, I can write a custom 
ZCML file that doesn't automatically import the default one from that 
package, but instead registers and configures *only the parts I need*.  
Using this, I imagine we could see more custom Zope installers that are 
complete applications, similar to the Silva, Plone, or BizarShop 
installers that exist today.  You'll be able to wrap up a totally 
custom Squishdot installer that required NOTHING of its users to get up 
and running, because you'd control how Zope configured its components 
and runs.  All they'd have to do is set up the ZConfig file to set up 
which ports they run in - a process that will be much easier than 
saying "Go to the 'start' shell script, change the -P parameter to be 
the base of what you want..." (or worse, telling them to go to the 
windows registry, find the arcane key value, and try to tweak the z2.py 
options in that tiny little text field that regedit gives you).

At least, that's my understanding and hopes and dreams.