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