[Zope3-dev] Local site configuration is too hard

Mon Feb 21 10:50:12 EST 2005

Hi Jim

> -----Original Message-----
> From: zope3-dev-bounces+dev=projekt01.ch at zope.org 
> [mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On 
> Behalf Of Jim Fulton
> Sent: Monday, February 21, 2005 4:18 PM
> To: zope3-dev at zope.org
> Subject: [Zope3-dev] Local site configuration is too hard
> 
> It's too hard on many levels:
> 
> - It's too hard for site managers to use
> 
> - It's too hard for programmers
> 
>    - We make people implement a dead chicken: ILocalUtility.  If they
>      don't make this meaningless offering, their objects won't be used
>      as utilities. Heck, they won't even be addable to site-management
>      folders.
> 
>    - The Python APIs for registering utilities are too hard to use.
> 
> On the bright site, ZCML is user-friendly by comparison.
> 
> We need to do better.  I think we need to review how we got here and
> brainstorm and try some different ideas.
> 
> Here's a start.  These are more or less random observations:
> 
> First, a lot of complexity arose from the desire to support
> through-the-database product development, distribution, installation
> and update.  This was driven by some issues with updating software in
> ZEO clusters.  We eventually figured out another approach for updating
> ZEO clusters and have abandoned the goal of through-the-database
> development. This allowed us to simplify the local-configuration
> machinery quite a bit, as Stephan has recently and heroically done.
> 
> The component architecture is very powerful and provides a clean
> development model, however, it isn't helpful to force site managers to
> use it as the basis of site management. A site manager knows that they
> need to add some kind of component, however, they don't understand the
> type of the component in terms of a dotted interface name.  I think
> that the concept of adding objects to a site to perform a function is
> fine. After all, it worked well in Zope 2.  I even think that the
> concept of registration is OK, if we can cast it in the right light.
> I think it's reasonable that we will need to tell the system whether
> and how to use an object is reasonable, but we should make this as
> easy as possible for end users.
> 
> To make our job easier, we should concentrate on utilities for now.
> Zope X3.1 should not include "modules", "page folders" or adapter
> registrations. I would go so far as to rip this stuff out of the
> trunk. We'll add it back later.
> 
> We can't improve things any more before X3.1.  Improving the
> site-management experience for managing utilities has to wait for
> X3.2.
> 
> The pluggable authentication utility is only usable by experts today.
> I think it provides a poignant, though perhaps extreme, example of the
> challenges if local site management.
> 
> I think the basic idea of tools, trying to raise the configuration
> abstraction above utility interfaces was sound, however, I think
> the execution has not turned out well.  Part of the problem 
> is that the
> original assumption was that there would be certain types of utilities
> for which there would be many instances, differentiated by name.  For
> example, there might be multiple database adapters, or multiple
> caches.  In practice, there usually aren't multiple utilities of the
> same time.  Even when there are, there aren't many.  Treating tool
> types as virtual folders is way to heavy in most cases.
> 
> Another problem with the existing tool mechanism is that it creates
> virtual folders that hide site-management folders.  I don't think this
> is really helpful. It makes things more mysterious.
> 
> Content managers add objects to folders to build a site.  What's
> wrong with site managers adding objects to folders?  Nothing, IMO.
> I think it's helpful to review how we got to where we are.  We used to
> have lots of registries: Services, Utilities, Database Adapters,
> Caches, etc...  People had 2 places to manage components, the
> individual registries and the site-management folders.  We decided to
> try emphasizing the registries and deemphasizing the folders.  OK, we
> tried and, I think, we failed.  The current UI is mysterious.
> 
> I suggest going back your our Zope roots.  Managing a site should
> happen by adding objects to and managing objects in site-management
> folders.  When we add an object to a site-management folder, we offer
> to register it.  We offer two registration interfaces. The default
> interface checks to see if the object provides any tool types.  If it
> does, it offers to register it as one of the tool types, showing the
> tool descriptions (rather than dotted interface names).  There can be
> an advanced interface that shows the actual interface names as we do
> now. Perhaps there could be a button for toggling between the advanced
> and basic interfaces. In general, however, we need to bother to
> provide a registration UI that sucks a lot less than what we have
> now. In particular, we need to provide some helpful text that explains
> what all of the inputs mean.
> 
> OK, enough for now. Thoughts? Comments? Anybody else have any ideas?

Why not use a registration tasks/wizards.
I think the site management is not that bad,
but configuration is more like a task then container and item.

It would be nice to have a directive where I can register 
a task for adding or configure a utility.

There whould be two kind of task, add utility in a defined way
and configure utility which can be used for allready added utilities.

A developer could develope tasks in python and register them
as possible task which can be fired on a site manager folder 
by a user.

I think we don't have problems with the site management folder
implementation now. Stefan did some great work which simplifies 
the hirarchie.

The next step I think is just to provide task oriented 
adding processes and not sugesst peopels its just a folder
an you can add items which will work.

Possible task can offer just a 'Add' button or for complexer 
tasks it should be possible to provide different pages like
add wizards or edit wizards.

I agree with, that we can't give this UI to the users right now.
But perhaps it's ok to add a new level at top of this existing
site management implementation instead reinvent the wheel.

I can't imagine that we get an easier way if we reimplement it.
I think we have to implement more logic and userfriendly UI on 
top of this concept.

Regards
Roger Ineichen

> -- 
> Jim Fulton           mailto:jim at zope.com       Python Powered!
> CTO                  (540) 361-1714            http://www.python.org
> Zope Corporation     http://www.zope.com       http://www.zope.org
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
> 