[ZDP] Re: Ordering objects and ZDP Tools (again)

[Rik Hoekstra]

Maik Roeder wrote:
> 
> Hi Rik !
> 
> Here are the alternatives:
> 
> 1. Implementation with a fixed property in DocumentFolder
> 
> Negative:
>    Each object will have an order property even if it is not needed
>    Only one order possible although we could add another ordertype when needed
> Positive:
>    You can always count on an order property being there
> 
> 2. Implementation with a fixed property in each Subclass of DocumentFolder
> 
> Negative:
>    Each Subclass object will have an order property
>    Only one order possible although we could add another ordertype when needed
> Positive:
>    Only those subclasses of DocumentFolder that need an order get one
and:     more specific (and will save me from working around
acquisition)

> 
> 3. Implementation with free property on instances
> 
> Negative:
>    You have to pay attention that the property is really there
>    You have to define and keep conventions on naming the properties
> Positive:
>    You can support multiple order properties as needed
> 
> I would vote for the first possibility. We just introduce a new property
> "order" to the DocumentFolder property sheet. This is set to a default
> of 0. Each existing ZClass now has this property, and it is set to 0.
> Each newly created ZClass instance will also get the property set to 0
> when it is created, which would be provided for by the DocumentFolder
> constructors.

about the acquisition problem: the content and whatever other folder
specific dtml documents do not have such a property but acquire one from
their container folder. This can be overcome by checking the order
property of a DTML Method != container. Or is there a generic way to
test if something is a ZClass instance, or I should make a list of
allowed meta-types. All of these are clumsy, but the problem may be
overcome.

> 
> It is up to the user to decide if he wants to change the order of
> the items. This will not happen too often, I would think. 

? why not, depends on the type of documents (faq order for instance may
change quite often)

> You can add
> the funtionality of changing the order into the DocumentFolder, which
> is the best place to put it, and it would be generic. No need to think
> about property naming conventions and all this.

OK, that's true

> 
> It is up to the views to decide whether they want to respect the order
> provided. Views can also decide what to do with the orders with a value
> of 0. Views also don't have to worry about different naming schemes
> and also the Catalog can now sort on the order, which may be needed.

yes, that _may_ be an advantage. Although.... A use case: 
we have two documents, one a snippet and the other a FAQ, both with a
keyword dtml. The FAQ in the faq is unimportant and has an order
property of value 2000 (which will keep it at the end of the faq list
and there are more than 50 faqs about dtml). The snippet, however, is
also unimportant and has an order of 50 (keeping it down at its list
which is maintained by another maintainer). Now the Catalog sorted on
order will keep the snippet above the faq, for no obvious reason. 
Now this is not very important, but the order property when used
generically will lead to strange orderings.


> 
> I can think of no other way to keep things more simple. I think
> we only need one order, but if you can show me that we really need
> different ways of ordering in one Folder, then I will have to admit
> that my vote is wrong.

I think that's not the point, as you could always add a custom ordering:
the point is you do not (always/automatically) want to mix up orderings
if you do not view items in their container context (see my point
above). 
This said, I really do not mind adding the generic order to the Document
Folder class. Shall I proceed like that then?

Rik