Martijn Faassen wrote:

John Goerzen wrote:

...

We specifically do not care about this :-) Now, digicool is a company, and they probably DO care about this. Making Zope Free Software is a great way for them -- and us -- to benefit. So your comments should be addressed at them if you want them to make the sale. Not me, a Linux hacker.

I care about making Zope more popular, as there will be more Zope users, more Zope hackers, and better free Zope support. More cool Zope goodies. More Zope related jobs. I care about Zope marketing.

(..More Companies packaging, enhancing and distributing Zope and Zope based products) Yes, I care too. And for the exact same reasons. The more popular Zope becomes, the better it is for all of us.

Even if you only care about Free software, you care about marketing it, as you care about what's 'right', and therefore you want people to use the right stuff; Free software. Right? :)

Alexander Staubo obviously was interested in Zope marketing. Why tell him 'we' don't do that, while some of us are definitely interested? Free software is about people doing what they want. Let us do want they want and don't speak for me. :) Thanks.

Yes. Alexander has brought up a very (IMO) relevant issue. It is in the interest of the entire community to make Zope well known and I feel marketing should not be left just for DC to take care of. I see a number of articles/sites about 'app servers' which don't mention Zope but mention others (including some mickey mouse servers I've never heard of). Eg: http://serverwatch.internet.com/appservers.html Why? Maybe Zope isn't talked about at all outside some circles? Altavista shows about 1058 pages linking to zope.org (compare php.net:12,000 ; apache.org:60,000). Why? If nobody does anything, this will take time to change. If we want this to change faster, all of us have to actively market Zope. This involves talking about in appropriate newsgrousps, putting up zope webpages, making Zope easier to learn and use, adding flashy features etc. All this can make a whole lot of difference. Shalabh

I have started a list of Pro-Zope Material here.. http://www.zope.org/Members/BwanaZulia/zope.html I am hoping to add some performance benchmarks, quotes, etc... In other words a good place to get that information that you need to submit to the client. I would like to see something like this done on a better (bigger scale) as part of the DC marketing, but this is a start. Any suggestions, links, comments would be great... JMA

From: Patrick Phalen <zope@teleo.net> Organization: TeleoNet Date: Wed, 8 Mar 2000 08:50:32 -0800 To: zope@zope.org Cc: paul@digicool.com Subject: Re: [Zope] Zope needs this (and Dynamo has it)

[Shalabh Chaturvedi, on Wed, 08 Mar 2000]

:: I see a number of articles/sites about 'app servers' which don't mention Zope :: but mention others (including some mickey mouse servers I've never heard of). :: Eg: http://serverwatch.internet.com/appservers.html :: Why? Maybe Zope isn't talked about at all outside some circles? :: :: Altavista shows about 1058 pages linking to zope.org (compare php.net:12,000 ; :: apache.org:60,000). Why? :: :: If nobody does anything, this will take time to change. If we want this to :: change faster, all of us have to actively market Zope. This involves talking :: about in appropriate newsgrousps, putting up zope webpages, :: making Zope easier to learn and use, adding flashy features etc. :: All this can make a whole lot of difference.

Yesterday, I was asked, by a client, to put together a side-by-side comparison of Zope and Vignette for presentation to their IT managers. I did a lot of searching on the Web, but found only the one article from this list last October, which was written by someone with no experience with either of the two!

Frequently, people have asked for this sort of data on this list, but I've never seen a coherent answer. It's a FAQ.

Digital Creations might be able to help here, since they have direct experience with clients who have started with Vignette and switched to Zope. It would probably be "impolitic" for DC to author a public article taking Vignette to task, but certainly they could help an independent author with facts. If that article could then be published in DevShed or Web Development, or another visible place, it would give us all something to point to. Search engines would index it. The word would spread.

Vignette is often characterized as the "industrial strength" CMS, so it would seem a good target for a comparison, especially due to its high cost.

_______________________________________________ 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 )

On Thu, Mar 09, 2000 at 07:31:07AM -0500, Paul Everitt wrote:

PCWeek did a shoot-out of various CMS packages about six months ago. They created a "scoresheet" that might be useful. Unfortunately, Vignette stood by their policy of not allowing their software to reviewed, so it includes several other CMS packages.

Can they do that? How? Something funny in the license agreement? -- Stephen Pitts smpitts@midsouth.rr.com

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

Martijn Faassen wrote:

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>

I don't think a new syntax should be brought about. There are too many things to learn already, it will only add to the confusion. I do agree that dtml is complex and something needs to be done about it. Probably a subset of the current dtml itself - with minimal additions which make somethings easy - would be good. Also (if this is seriously being considered) I would favour for a somewhat different paradigm: Instead of:

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

We could have: <dtml-var object="layout.table"> <param name="datasource" value="get_above_age"> <param name="columns" value="Name,Age"> </dtml-var> The advantage here is that: o One logical presentation element (a table) is one element in dtml code. o One-to-one relation is possible between the code and any GUI entity being used to design (think ZStudio). This means the layout.table can be one icon that is dropped into a design view and it's parameters specifed through some fancy widget. Also when the code is stored and reloaded, it would still be possible to display the same GUI entity in the design view and it's parameters would be editable. Discussions on the above have taken place on the ptk and zope-moz lists. Regards, Shalabh ______________________________ Shalabh Chaturvedi icq://43284067 http://advogato.org/person/shalabh/

Martijn Faassen wrote:

Shalabh Chaturvedi wrote:

...

I don't think a new syntax should be brought about. There are too many things to learn already, it will only add to the confusion.

That's true, but that shouldn't hold us back indefinitely; some things are can only be improved after a while if they're redesigned from scratch, otherwise the back-compatibility issues become too complicated. I don't know if DTML is at this state though, and any new language proposal should be something to consider for the (very) long term.

If we can gather enough support for something like this, I'm all for it.

...

I would favour for a somewhat different paradigm: [ paradigm snipped ]

The advantage here is that: o One logical presentation element (a table) is one element in dtml code.

But you lose some flexibility in defining table headers and footers; you have to be careful your simple language becomes too rigid, making too many assumptions.

Um, no. Since the code that defines 'layout.table' is also available and editable, (just like any other object). So you can not only code the specific header you want into the object, but also create a parameter which can be used like so: <dtml-var object="layout.table"> <param name="datasource" value="get_above_age"> <param name="columns" value="Name,Age"> <param name="table_tagattrs" value=" border=0 bgcolor=green"> </dtml-var>

...

o One-to-one relation is possible between the code and any GUI entity

Hm, what you're proposing is some higher level object (a product) that does tables (in this case). That would in fact be rather neat.. Our simple glue language could become extremely simple if we have sufficient higher level components, and if it's easy enough to code up your own components. I'm doing something like that for web forms in my ZFormulator product.

I learnt you're doing something similar (from Rik). I have to look at it. What I'm suggesting is that instead of having to create a product every time you want a higher level object, we could have a framework so that you could just create an object that does it. The goal would be to make it easy for everyone to code their own component objects (or templates, or patterns, or whatever) Another thing I would like is that people start looking at 'documents' differently. Instead of 'my_element_header' and 'my_element_footer', people think of 'my_element' which takes one or more parameters. (Please don't flame me, it's Paul who started all this :-) PTK List thread: http://lists.zope.org/pipermail/zope-ptk/2000-February/000347.html Zope-Moz List Thread: http://lists.zope.org/pipermail/zope-mozilla/2000-February/000125.html Cheers, Shalabh ______________________________ Shalabh Chaturvedi icq://43284067 http://advogato.org/person/shalabh/