[Zope-Coders] Re: [ANN] Proposed Features for Zope 2.7: OrderedObjectManager

[Yuppie]

Shane Hathaway wrote:
> Ok, here's the basic problem.  Excuse my lack of vision :-) but I don't 
> see why it is useful for all folders to retain a stored order.  I can 
> see the usefulness of certain folders retaining stored order, such as to 
> control presentation, but for most folders I would think that stored 
> order is really just an unnecessary burden.  I think the basic folder 
> class wants to move *away* from storing order.
> 
> So answer this: Folder already does too much.  Why does it need even 
> more responsibilities?  I don't object to ordered folders, but I don't 
> understand the need for them everywhere.
> 
> Shane

I know you are much more experienced in this area, but this is the way I 
see the problem: (I might be wrong in some points and hope you'll 
correct me if necessary.)

1.) The main trade off for folders is that between ordered collections 
and big collections.

Big collections should be implemented as btree folders and ordering 
would be very expensive (and useless). Ordered collections don't scale 
very well.

2.) Small unordered collections work fine with both solutions. It would 
be waste of degrees of freedom to make 3 kinds of folders. (basic, 
ordered, btree)

3.) If you agree so far, the question is:
Should the basic folder be a btree folder or an ordered folder?

The answer of Zope 3 is AFAIK: The basic folder is a btree folder. And I 
don't want to criticise that.

The answer of Zope 2 is: The basic folder has some characteristics of an 
ordered folder. You didn't make btree folder the default folder, because 
you didn't want to break existing products building on top of Folder.

You say: "Folder already does too much." But I never heard of plans to 
cut down Folder in Zope 2. I don't think that's an option anybody wants 
to discuss.

So the remaining question is (at least in my view):

What is the "unnecessary burden" of adding the API for ordering to the 
Zope 2 Folder and what could we win?

The burdon is: manage_renameObject has to be changed. The result will be 
a minor impact on renaming speed and an other position of renamed 
objects. I'd guess at least 99% of users don't recognize the difference 
or prefer the new renaming in place.

So the main burden is the ZMI change. We need at least a button, better 
a column in manage_main to switch to Position sorting.

The benefit is: Less monkey patching of manage_main and more 
posibilities just one klick away.


Cheers,

Yuppie