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

[Rik Hoekstra]

Maik Roeder wrote:
> 
> Hi Rik !

Hi
> 
> Some quick questions ...

Hm, It seems my mail wasn't too clear...;-(

> 
> Rik Hoekstra wrote:
> > - each folder/container type defines has a custom property named
> > 'orderpropname' (for example FAQFolderorder).
> 
> What do you need the name "FAQFolderorder" for ?

For two things:
1. to overcome the acquisition problem by using a unique name
2. to make more orderings for the same item possible (I don't see how)

in this scheme faqsections have their FAQSectionorder etc.

> 
> > - when a new instance is added to it, it is checked there is a orderpropname
> > (I still have to overcome the acquisitionproblem here) for the container.
> 
> Why do you want to check whether the orderpropname is defined for the container ?

if a container doesn't need to order its items, why bother?

> 
> > If there is, the instance gets a local property orderpropname, and a value of
> > 2000000 (or some arbitrarily large number). Your proposal of a default 0
> > seemed me to be not so intuitive to use for users changing orders, because
> > they have to put in numbers themselves.
> 
> 1. New objects could be listed first when you use 0, but would not need to be.
> 2. Deleting a value of "2000000" is not a nice thing to do when you have many new items
>    you want to order

OK. that's true. So what has more weight? The reverse ordering the users
would have to use or the problem of deleting? We could also use -1, to
indicate the items are not ordered yet.

> 
> > Unless, of course, you regard 0 as an exceptional category, which I'm not sure I am for
> > anyway. (Surpassing 2000000 items in a container wouldn't seem like a good idea anyway)
> 
> I don't unterstand what you mean with "exeptional category"

Like you indicated: that they do not have an explicit order yet. They
wouldn't have to be listed first. On the other hand: if a user who
wouldn't know about the ordering mechanisms wanted to make sure an item
was always first he'd be tempted to use 0 

> 
> > the rest is as we discussed before:
> > - ordering in the container is according to the values of the orderpropname,
> > only items with an orderpropname property set will get listed
> 
> This would be up to the view.

OK, but in this way it's easy to make a view to exclude items

> 
> > - changing order is by a form with 'records' fields for all items.
> > etc.
> 
> I don't know what a "records" field is.

Whoops, sorry. This is a form like the following example:
<tr><td>
<input type=""hidden" name="item.id:string:records" value="<dtml-var
id>">
<input type="text" name="item.name:string:records">
<input type="text" name="item.<whatever>:<string|int|list|...>:records">
</tr>
<tr><td>
<input type=""hidden" name="item.id:string:records" value="<dtml-var
id>">
<input type="text" name="item.name:string:records">
<input type="text" name="item.<whatever>:<string|int|list|...>:records">
</tr>
.
.
.

These are used by ZOpe like records or dictionary, which can be looped
with a dtml-in. This makes it possible to use the same type of input
over and over in one form (there is some documentation - if you want to
I can look it up)

> 
> > If this proposal is carried out, it would mean giving quite a lot of folder
> > items a custom property (that is a custom propertysheet as well).
> 
> No need for a custom propertysheet. You just add "orderpropname" to the standard
> DocumentFolder ZClass propertysheet.

Hm, how, when a ZClass is instantiated? But I want all FAQFolders to
have the same orderpropname.

> 
> > WOuld this cross your thoughts of maintainability of the ZDP Tools?
> 
> It would be nice if you can always be sure that the property exists, so putting
> it in the DocumentFolder (from which all other ZClasses inherit), is the
> best way.

but then we don't have unique names! And moreover, only real containers
should have them (not fragments, I would think)

> 
> > Any other drawbacks I haven't thought of?
> > Does this it seem feasible to integrate this with hierarchies?
> 
> I don't understand what you mean with "integration with hierarchies".

If you have unique names with bindings to a specific container type, I
thought there would be a way to provide for constistent ordering of
items, if you'd use the containers as sources in a hierarchy. Hm, that
doesn't sound too clear. Forget it for this moment, I'll try and think
up an example later. Doesn't matter.

Rik