At 17:01 08/03/00 +0100, you wrote:
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.
Me too - only trouble is I'm the programmer. I'm struggling and I can't afford to retire just yet :-)
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).
I am impressed with the products I've seen so far but they can always be improved and there's certainly room for more. Perhaps there should be a coordinated 'wish list' on zope.org so that developers can pick up on needed products, or collaborate on enhancements of existing products ?
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.
Agreed <dml-var object> is a pretty good start for most people.
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>
Well that's a bit further than I was proposing. Perhaps I would settle for dtml which accessed the REQUEST object more simply. However your syntax looks good.
And then some IDE that allows you to easily create all objects you refer to here.
And browse all the objects and all the methods and attributes defined on them.
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
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Richard Moon richard@dcs.co.uk