[Zope] Looking for Zope vs. Others at-a-glance comparison

[Bill Anderson]

Jason Cunliffe wrote:
> 
> > Completely calm and friendly opinions follow...
> 
> yes thanks..
> 
> > I don't think it's any more difficult to create an attractive
> > (graphics-wise) site in Zope than it is with PHP or ASP or plain old
> > Apache-served HTML files.  Quite honestly, I'm not qualified to do it with
> > any tool. :-)  I get the feeling that a lot of people expect Zope to
> design
> > sites for them.  Maybe they're expecting too much.  Or maybe I'm expecting
> > too little???  Or maybe it's that most of the people using Zope today
> (like
> > me) are not pretty-site designers, but people that want a powerful tool to
> > manage the most important part of a site...content.
> 
> I agree absolutely that Zope is on level with PHP, ASP apacheHTML in terms
> of ease.
> My point is that Zope allows one to create powerful highlevel functionality
> at many levels, wrapping, hiding, abstracting, reusing, modularizing things
> which potentially could allow graphic designers to jump in and do great
> work. But out of the box it does not and for perhaps cultural reasons will
> not..Zope is largely based on reusable templates, and chunks of 'smart-html'
> better known as DTML.
> 
> What Manila has done is to provide some reasonable default templates for
> getting useful site development work done 'out of the box' - they have
> provided a structure template, and well defined access to changing the
> obvious things people want to change.
> 
> Perhaps the only product which does for Zope is Squishdot.. and I think that
> largely explains why most Zope sites are Squishdot or modified squishdot
> sites.

Then you need to get out more ;)
I have visited man, many zope sites, and only a few were squishdot based.

...

> This means tools with the flexibility of zope but not in it its present
> state of awareness.
> 
> > It's the site designers.  Zope isn't designed for assistance in creating
> > attractive sites.  It's designed for creating manageable sites.  It's
> > completely up to the designers to make it attractive, using tools designed
> > to do so.  Zope (in my experience) does nothing to limit the ability to
> make
> > a site attractive, but it does do buckets for increasing manageability.
> 
> Yes. I quite agree..But why are there no attractive Zope sites?

Maybe you just have an entriely different idea of attractive? I have seen several site I would classify as 'attractive'.
I have seen sites that you wouldn't know were on a Zope server unless you noticed something like index_html in a link.
 
> My argument is that zope does nothing to HELP one's ability to make a site
> attractive.

And others arew arguing that it should not. Apache does nothing to help the 'attractiveness' of a site, nor should it.

> Actually it does limit one's ability. for example look at even the syntax
> for making an image object borderless? it aunt obvious.. and it could/should
> be part of the image object properties

None of my images have problems with that. border=0 is pretty damned easy.

 
> --or how about a rollover button.. Yes that is a JavaScript problem perhaps,
> but what about including that as a BASIC feature of modern websites. But
> imagine if that alone was made easier by zope.

See the ActiveImage (?) product that does this.

> Navigation bar objects would be another big plus.
> Or how about a web page 'Table object' which made allowed one rapidly to
> group and include other zope object in a useful and productive way.

There are, I beleive, at least two products that do this.
 
> This is not gratuitous graphics this is stuff which is common to most
> websites. All the HTML tools do this.

Exactly. The HTML tools. That is where it belongs, not in a server.

> In zope a designer [= end user content manager] needs to be able to work
> with higher level tools which function with acquisition just like
> standard_html_header etc.
> 
> for example [ad hoc]:
> 
> 1) Create a folder, some a sub folders and 'dummy' dtml documents.
> 2) Add a navigation bar creating basic links to the above. This would auto
> create a set of matching named methods
> 3) Add a style_object  which would allow one to apply css or similar across
> the above. Again auto-create matching named methods in each folder to allow
> low level tuning to happen later
> 4) create a standard_table_object with named areas to allow population adn
> linking of HTML/DTML etc
> 5) Create standard_site_overview document which would link to the above,
> including standard_report_methods which would spit out the stats/properties
> on each part so you could see each section in a browser but also print out.
> 
> As I understand it all the above is daily business in zope, using all manner
> of dtml-in and -with, sequence-item iterations etc. But just bundling and
> linking these would allow a lot more people to jump and get on with making
> great Zope sites.
> 
> This is not reinventing Dreamweaver3.

And none of this is something Zope prohibits. Do not confuse lack of IDE-type tools for editing HTMl with A Zope
Server's features and functionality. You are describing things thout should be a function of the HTML editing tools, not
the Server.

> This is accepting that real world work on web sites post-1995 needs the
> above to be productive for designers to work well in these environments.
> 
> > I'm comfortable that the zope.org developers will agree that their site is
> > not the greatest thing on earth, esp. when it comes to prettiness.  It is,
> > however, consistent, easy to use, informative, and provides some nice real
> > world examples of Zope's power.  Using any of the already available
> > calendar-like products for Zope, DC could easily create a calendar to
> browse
> > through stuff.  Again, it's not a limitation of Zope, the developers just
> > didn't do it.
> 
> Yes and I am continuously curious why they did not?

Perhaps they simply don't share your views.

> Again we can learn from Manila.
> When you create a Manila page it comes with instantly usable templates.
> Zope only does this for its own management screens which are invisible to
> end users.
> 
> When you create a Folder in Zope it offers you
> 
>  -Create public interface
>  -Create user folder
> 
> And if you select yes you will get 'index_html' and 'acl_users' included..
> THIS is the entry point I am talking about
> The 'Add a Folder' page needs to offer more so that it can default to the
> immediate bones of a useful site, methods and links. The irony to me is that
> such a feature would really show off Zope strengths and save a mountain of
> time. It would allow many other skilled people to jump in and do some great
> work .. Hell it would help create new work for zope programmers.

Many have done work like this. Perhaps you should spend more time investigating the additional products available for
zope before drawing down judgement that this doesn't exist.
 
> People would pay for useful modules like this because they would save
> valuable time adn still leave the source open.
> best of both worlds.. could be loaded could as .zexp and off you go..
> 
> But because of the steep learning curve of ZopeDTML and resistance of Zope
> programmers to 'visual design' discussion.. they are short changing and
> ducking the real gain issue = 'project workflow' which is the backbone of
> content management.

Now you are mixing issues. project workflow is independant of graphical or visual design. Programmers write code, and
others determine HTML appearences.
 
Here is an idea. If you think you can design a better looking Zope.org, do so. Then tell everyone where it is, and let
everyone comment on it. I, for example, find most of the zope.org site quite appealing.

If you don;t think zope.org and any other zope sites are attractive you should open you horizons, and see that many
sites based on zope are attractive, at least to others.

To have an aopiniuon that other zope sites are unatractive, and to then apply that opinion to a claim that zope won't
let you do that, or that the lack of 'attractiveness' (again, IYO), is a fault of zope is fallacious.

--
Do not meddle in the affairs of sysadmins, for they are easy to annoy,
and have the root password.