[Zope] Re: reality check - The REAL issue
Sam Gendler
sgendler@teknolojix.com
Fri, 10 Dec 1999 14:54:07 -0800
Would it be possible to end this religious fundamentalism on the zope list. Cold
Fusion has some areas in which it is much stronger than zope, and some in which it
is much weaker. The same goes for other solutions. The same goes for operating
systems. Differnet applications/OSes are appropriiate for different tasks, and I
make my choices based on cost, ease of use, customer preference, speed, and a host
of other parameters. The fact is, when I have a customer who wants me to build a
web application that would be maintainable by less sophisticated computer users,
it is difficult in every platform.
To my mind, zope's issue with regard to documentation/usability is that it is a
product that has obviously evolved, rather than been designed from the ground up.
As a result, there are many inconsistencies in the way it works. Zope is a
tremendously powerful tool, but it is very difficult to learn because depending on
what you are trying to do, you need to solve problems in very different ways.
Just look at the source code. You can tell that what code is written by different
people, as there doesn't even seem to be a whole lot of standardization of
programming style. This is fine by me, as it has resulted in a very powerful too
that is free, and undergoing rapid development. However, coupling this issue with
a lack of documentation of any of the features that truly makes zope powerful does
become somewhat of a drag. It is all well and good to have an application server
with all of this power, but if it takes me days to figure out how to do something,
it would still be faster to write it as an apache module, servlet,
ASP application, or whatever. the complexity of zope is reaching a critical mass,
as evidenced by the increasing amounts of confused user email on the mailing
list. It does little good to have DC adding features that cannot be used due to
the steepness of the learning curve.
Additionally, zope seems to be at a critical juncture, as it starts to get media
attention and market mindshare. However, all the attention consistently focuses
on usabililty at some point. I really do think it is time that the __zope
community__, lead by DC, do something to provide adequate documentation, and to
perhaps clean up some of the usability inconsistencies at the same time. To all
of the complainers on this thread, why don't you pick one small area of the
current docs that you think are insufficient, and do what you can to improve
them. I am sure that DC and the ZDP will do what they can to provide detail that
you are lacking, that you can then add to the docs.
I see an awful lot of questions about running PCGI and FastCGI on Apache, Roxen,
ApacheNT, and IIS. I also see certain people consistently providing the answers
to the questions. last time I looked at the ZAG, there was no detail about how to
do this. How about those people that have working installs of Zope with another
webserver submit configs to me, and I will compile them into a document providing
working examples. However, I would like at least a single line description of
what your Rewrite rules are doing, especially if they are doing anything out of
the ordinary. Particularly those folks with fastcgi experience, this would be
very useful.
If someone else with some ZClass experience wanted to write up instructions for
writing a ZClass stub in python, which is mentioned as possible in the ZDG, but
with no instruction on how to go about doing it, I would find that exceedingly
useful. I managed to hack some things up from ZDiscussions, but that was by
writing a self contained base class that was inherited by the ZClass. I want to
know how to write python code that belongs as part of the ZClass, and I have no
idea how to go about doing that.
If someone wanted to document how to use the _ namespace with some real world
examples, so that people without python experience could decipher that page of the
dtml guide, that would be tremendously useful and should cut down on a lot of
traffic on the list.
There is no need to contribute an entire document to the current zope docs. Just
put together a more easily understood version of a current page and I am sure that
some at DC will get it integrated with the docs.
If someone wanted to go through the How To's and get them integrated into the
correct places in the docs, that would be terribly useful to. Why are we waiting
for DC to do it.
Remember that the folks at DC know how to use Zope, so they don't have a huge
incentive to provide documentation at the expense of the rest of their business.
If you want it fixed, fix it yourself.
--sam
Craig P Avnit wrote:
> On Fri, 10 Dec 1999, you wrote:
> > ----- Original Message -----
> > From: Craig P Avnit <craig@londonplaza.co.uk>
> > To: <zope@zope.org>
> > Sent: Saturday, December 11, 1999 4:44 AM
> > Subject: Re: [Zope] Re: reality check - The REAL issue
> >
> >
> > > On Fri, 10 Dec 1999, you wrote:
> > > > Everyone is talking about the difficulty in using Zope and how good Docs
> > > > would help. I believe, in part, documentation is just masking part of
> > > > the problem. Zope is way-to-difficult to use. If you're a programmer,
> > > > you can trudge through and figure out how Zope works. But I'm not a
> > > > programmer.
> > > I have yet to see any non programmer deploy a cold fusion, vignette, or
> > any
> > > other application server solution. Zope is not nearly as difficult to
> > > implement as a java servlet based solution.
> > >
> > > You will always lose functionality when implementing ease of use in a
> > > development environment.
> >
> > Isn't that the definition of a 'bad' development enviroment.
> >
>
> Are you trying to tell me that Cold Fusion, ASP and Websphere are good because
> they are easy to use. The problem with developers on those platforms and most
> windows developers, are that they code the most horrificaly bloated application
> known to man.
>
> Cold Fusion doesn't come close to Zope and Python in functionality and rapid
> development.
>
> > >
> > > > I don't know what's going on at the code-level, and
> > > > frankly, I don't want to have to know. If Zope is to truly adopt a wide
> > > > user base, it's got to be easy enough that the average user and install
> > > > and deploy Zope. Right now, it's just to complicated for me use. I've
> > > > got a business to run, I don't have time to mess around with the
> > > > particulars.
> > > >
> > >
> > > That is why there are people out there like the fine folks at DC, who can
> > > concentrate on supplying you with the functionality you need to allow you
> > to
> > > concentrate on your business.
> >
> > I thought the whole idea behind open-source was that there is
> > a critical mass of users that has to be reached for the flow on
> > benefits. Those benefits won't arise if the open-source application
> > isn't competitive, it won't be competitive if it isn't easy to use and
> > it certainly won't get a critical mass if there is an understanding
> > that 'best' practice, performance and use are not the watch words.
> >
>
> I agree, but the point a click mentality doesn't help either. You don't use
> linux because you are in a desktop environment, if windows is so good show me
> an ISP that trusts there operations to it, I don't. Unix and linux strengths
> lie in the server arena at the moment. I run a linux box at home, full printer
> access and all the Destop applications I need. I don't have 5 % of the problems
> the average window user has.
>
> > One reason I haven't move to linux is that it is still not as easy to
> > use as windows, I just don't want to learn the geekisms. Now to
> > add positively to this to debate, what Zope really needs is a glossary
> > of terms, then a one page overview of all components that has
> > been 'tested' against a panel of average windows users (the
> > industrial standard), if they can understand it anyone that
> > matters can. ;-).
> >
>
> Windows are the industry standard for home PC's and desktop, not mission
> critical high end apps, and distributed computing. Unix is the standard here.
>
> I agree that zope does need to be easier to use, and the docs can be improved,
> but I cannot agree with wanting to aspire to windows mediocrity, or heaven
> forbid that windows users are the only ones who matter. Most organisations run
> in spite of windows not because of it.
>
> >
> > Could anyone point me to a one-page description of
> > a product, where it resides, what it can do for me and
> > how it interrelates with the other Zope components.
> >
> >
> >
> >
> >
> >
> > >
> > > > Just a thought,
> > > >
> > > > Brian
> > > >
> > > > _______________________________________________
> > > > 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 )
> > > --
> > > Craig P Avnit
> > > Director
> > > London Plaza Ltd
> > > Tel: +44 (0)7000 64-5768
> > > Fax: +44 (0)7000 64-5769
> > > http://www.londonplaza.co.uk
> > >
> > > _______________________________________________
> > > 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 )
> > >
> --
> Craig P Avnit
> Director
> London Plaza Ltd
> Tel: +44 (0)7000 64-5768
> Fax: +44 (0)7000 64-5769
> http://www.londonplaza.co.uk
>
> _______________________________________________
> 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 )