Hi Lennart! Lennart Regebro wrote:
I'm all confused now.
I'll try to clear some things up: 1.) There is a complete implementation on yuppie-ordersupport-branch. I startet this branch to get feedback on implementation details and changes to the proposal. 2.) We have to structure the discussion the way you startet. use cases =========
For me, ordered support is useful in two cases:
1. For people want to make menues or lists of document/objects, and want them to be in a specific order. This requires ordering of the objects, and to display that ordering.
2. When you make objects and services that rely on an ordered list of subobjects. For example, say that you have a service of some kind that uses several plugins to perform functions, and it has to call these plugins in a particular order.
Is there anything I have missed?
Don't think so. But there are also special use cases why and how people do 1. or 2. UI ==
When it comes to UI, you need to have a way of ordering and sorting the objects, and of course displaying the cureent order. There are two ways to do that as I can see it.
1. Use the currentZMI object listing, "main.dtml". That saves you from having two user interfaces. It would be nice to have a sorting function too, to sort on id, title and date, and this is alredy availiable in the ZMI, and that means it doesn't have to be duplicated it.
2 Having two separate interfaces, one being the normal ZMI view, and the second being a ZMI tab where you order and sort the objects. There are benefits to this, for example it means that you can sort the ZMI object list without changing the ordering. It also keeps the main.dtml exactly as it is today, since the ordered support would instead add a separate tab, and it would keep the main display less cluttered.
I do not as of today have an opinion on this last matter.
Well. We chose to use main.dtml, but you just see the ordering UI if you switch to position sorting. API === This is the Interface we defined: <http://cvs.zope.org/Zope/lib/python/OFS/Attic/IOrderSupport.py?rev=1.1.2.2&content-type=text/vnd.viewcvs-markup>
When it comes to API, I would expect an API with two methods. One to move to a particular position, where 0 is first and -1 is last, as per normal Python standard, and the other where you move relatively, where negative numbers move you towards the front and positive towards the back.
As an example of this I give you my OrderedDictionary.py, which have: def order(self, key, order) and def move(self, key, distance)
Have a look at 'moveObjectsByDelta' and 'moveObjectToPosition'.
There would also be functions to move a set of keys one step forward, one step backwards, first and last that are callable through the ZMI with a list of ids, to make it easier to do web user interfaces.
'moveObjectsUp', 'moveObjectsDown', 'moveObjectsToTop' and 'moveObjectsToBottom'. again UI ========
I do have ONE opinion (wow!): I personally preferr the type of UI where you check the boxes of the objects you want to move, and then click a button to move all of them up/down/first/last as opposed to the UI that has one up/down/first/last button per object.
That's the way we did it. Cheers, Yuppie