[Zope] Zope needs this (and Dynamo has it)

[Martijn Faassen]

Richard Moon wrote:
[snip discussion why marketing is important]
> I feel there is also an issue with the product itself. Zope seems to work 
> on two levels - you have a very high-level part - I'm thinking of the 
> security model, the SQL methods and the Z Search interface, the drop-in 
> products like SquishDot etc. These set Zope apart from other technologies 
> which people might use (PHP/ASP etc).
> 
> You also have a low-level  part (External methods etc). Because Zope has 
> the high level part it encourages the thought that there is not much 
> 'programming' needed to develop a Zope site. But sooner or later you are 
> going to hit a wall - for example questions you see asked on this list such 
> as "how do I assign a value to a variable". Well the answer is ...
> 
> <dtml-call expr="REQUEST.set('abc_search', strip_abc(abc_text))">
> 
> ... a string of gobbledygook. (So what does the dtml-let tag do is the 
> obvious question that springs to mind.)

If you have a programmer and a web designer around it's possible to 
seperate the two tasks quite well, though, in my experience. Likewise a
situation with a programmer and a content manager, which is the situation
I'm in right now.

Still, both the web designer and the content manager want to know more
about Zope, and this does throw them off into the deep end (Python,
DTML, object oriented programming, etc).

> It is great that Zope has the low level stuff but I feel that work needs to 
> be done
> 
> 1) To analyse actual usage of Zope to see what features are being used and 
> which areas of usage cause concern/difficulty
> 2) To Implement high level dtml tags to implement them.
> 
> I've stuck my neck out here - feel free to chop it off.

I won't chop it off; you're right. Though I would say a simpler DTML
is only half of the story; the other half of the story is already there --
people _can_ use drop-in components. It's just that we need more and
better drop-in components (with possibly a nicer interface, ala Zope PTK
and/or Zope Mozilla).

Still, a simple variety of DTML would be nice. Currently you can
successfully use a subset of DTML, which almost has no arcaneness but
is still very powerful. PythonMethods will help even more there. Still,
DTML allows too much, so it's too easy to move into the arcane domain. Also
some of its powerful features have the side effect that some of the simple
features look too complex.

So perhaps we should create a seperate language, based on the subset,
with simplified syntax, which _doesn't_ allow fancy stuff. The fancy
stuff would be in DTML-methods or PythonMethods of some kind. Perhaps 
even the HTML would be in seperate methods. Perhaps some XML-ish Zope
glue language, like this:

<zopeglue>
<var object="header"/>

<assign name="age" object="get_age"/>
<var object="show_age_intro" arguments="age"/>

<var object="layout.table_header"/>
<in object="get_above_age" arguments="age">
<var object="myrecord" arguments="in_item"/>
</in>
<var object="layout.table_footer"/>

<assign name="age" object="getage">
<var object="footer"/>
</zopeglue>

And then some IDE that allows you to easily create all objects you
refer to here. Perhaps something wiki-like; any object name that you refer
to in the glue that can't be found will be presented in a list after you
edit the glue, and you can create objects for it then.

Ideas, ideas, now for some time. :)

Regards,

Martijn