[Zope3-dev] New Software Space UI

[Jim Fulton]

Stephan Richter wrote:

Stephan, I'd really like to get some ideas from some other folks.
You and I are too close to this ...

> On Wednesday 05 January 2005 11:11, Jim Fulton wrote:
> 
>>I better questions are questions like:
>>
>>- What would be a useful way to create, manage, and configure utilities
>>   through the web?
> 
> 
> I think the "Tools" tab was not too unsuccessful, but I think we can just 
> merge its functionality into the standard contents view of a site management 
> folder.

Well,

The tools tab works well when there are generally more than one of a
kind of tool, as in database connections or workflow definitions.
It's too heavy for tools that typically have one instance.

Part of the mission of tools is to provide an overall view of a site.
Site management folders, which I think are useful for organizaing work
obscure this.

> Here is how I would like utility registration to behave:
> 
> I go to the site management folder and add a utility. The registration for 
> this utility should automatically be created and activated. Here the name of 
> the utility in the SMF and the registered name are the same.

That doesn't work for the very common case that a utility is unnamed.

 > If someone wants
> to change it, they can always go to the registration and do that.

Only if registrations change quite a bit. Currently, you can't change
the registration key.

 > Also, when
> utility is renamed in the SMF, there should be an option to change the 
> registered name as well.

I think this would be a mistake.  An advance in Z3 was to separate
registration from manegement.  They are really independent.
I'd be OK, in some UI, with using the registration name as the
default item name, but *not* the other way around.

> In the case that an active registration already exists for a particular 
> interface/name pair, a screen should appear that asks the user what to do.

Agreed

> Possible options include (a) Deactive the old registration and activate the 
> new one or (b) leave the new one deactivated.

Yes

> This functionality would require some additional infrastructure. Specifically, 
> we need to know which provided interfaces are utility interfaces.

I agree we probably need something like this.

I think we should step backward a bit further.  I think that Paul is right
that many users don't want to think of these in terms of interfaces, but in
terms of kinds of things.  Of course, this is where tools come in.  Hm.  Perhaps
the tool concept is sound but just needs to have it's UI rethough a bit.


 > I propose
> to use the same mechanism we use for content types and require utility 
> interfaces to provide an `IUtilityInterface` marker interface. If a utility 
> provides several utility interfaces, several registrations will be created.

I think we already have this with the tool type.

> Some utilities, namely the ones that used to be services, should *always* be 
> unnamed. Thus, for UI purposes *only*, I would suggest that we introduce the 
> concept of an `IUniqueUtility` or `IUnnamedUtility` marker interface that 
> marks which utilities should stay unnamed. 

This is an interesting idea.  Perhaps this can be part of the tool definition.
Or, perhaps this brings us back to services.  Perhaps a service is a type of
utility that you expect to have one of.  I'm not sure. Something to think of.

>>- What would be a useful way to create, manage, and configure adapters
>>   through the web?
> 
> 
> Until now we have had very little experience with TTW adapters, but I would 
> suggest to have a simple interface at first that simply creates an adapter 
> registration.

Adapter registration for what?

 > Note that the code I am developing now will allow for
> multi-adapters.

I encourage you to slow down. In any case, anything you do now wrt adapters
is a prototype and should not be included in 3.1.

> Later we can improve this UI in combination with persistent modules. It would 
> be so cool, if we could go to a class in a persistent module and say, 
> register this class as an adapter requiring this interface and providing that 
> one.

I don't see much point in TTW adapters without persistent modules.

> 
>>- What would be a useful way to create, manage, and configure views
>>   through the web?  This is a little bit different than adapters because
>>of the use of templates.
> 
> 
> I think the current way of doing this is pretty good and straight forward.

What way? Are you refering to page folders?

> 
> Now that we are at it, I think we should think about TTW development in 
> general. Once you can have persistent modules, you would also want persistent 
> content components. We need to be able to register them and provide basic 
> menu entries.

This is a *huge* undertaking.  I, for one, don't have much bandwidth for it.

> 
>>Two partial sucesses in the current UI, IMO, are:
>>
>>- Through-the-web modules.  These are currently broken for largely
>>   shallow reasons. I think, however, that the concept that through-the-web
>>   Python code should be managed as modules is sound.
> 
> 
> I really plan on getting them working again unless it is too deep in the 
> zodbcode code.

It's not. In fact, the issue has to do with the registration model,
which you are restructuring.

> 
>>- Page folders allow designers to work on templates without having to
>>   do configuration themselves. Basically, a page folder is configured
>>   once with a default configuration and any templates added to it
>>   get that configuration.
> 
> 
> I agree.
> 
> These are just some initial thoughts to get the discussion going.

I strongly encourage you to limit your current scope to cleanup,
and utilities.  TTW utilities are needed for configuration.  This
should be straightforward and getting this working nicely would be
a huge step forward.

I think TTW development (prototyping) will require a lot of effort to
do well.

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