[Zope3-dev] Local site configuration is too hard

[Jim Fulton]

Roger Ineichen wrote:
> 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.

Yes, that could be helpful.

> I think the site management is not that bad,

I think you know too much to be objective now. :)

> but configuration is more like a task then container and item.

Yup

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

Yes, perhaps

I agree that we need ways for the developer of a utility to
improve the registration experience. Wither by providing an
explicit registration UI (task) or by providing hints (e.g. tool
type) that can allow the default UI to do a better job.

> 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.

I think you are right.  I think the architecture is OK.
(Well, I;d like to get rid of the requirement that local
utilities provide ILocalUtility, but that's another topic.)

> 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'm not suggesting that we reimplement the underlying architecture.

> I think we have to implement more logic and userfriendly UI on 
> top of this concept.

I agree.

Jim

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