OrderableReferenceField

Now I am able to

• use them for creating simple references and contentish references (UML association classes)
• add KeywordIndexes
• add contextually target objects
• add new target objects recursively (tried only 2 levels)
• add new target objects with and without use of portal_factory.
  

FIX TO THE FIELD CLASS

I was working ok with orderable reference fields, until I added a KeywordIndex.

Then, I got systematically an exception in the getRaw method when adding a reference to an object and saving.

I've overcomed the problem by modifying the getRaw method: I commented the line where the references are being sorted.

After this change I didn't notice negative side-effects.

FIX TO THE WIDGET TEMPLATE

When I tried to activate the addable support ('addable' field property, 'addable' TGV in the UML model), I realized it wasn't working, although the 'addable' macro, defined in the 'addable_support' template, is being called as in the template of the ReferenceWidget.

In order to get some clues, I had to browse a number of files; among them:

• base_edit.cpt
• base_edit.cpt.metadata
• edit_macros.pt
• orderablereference.pt
• addable_support
• addreference.cpy
• addreference.cpy.metadata
• content_edit.cpy
• content_edit.cpy.metadata

The implementation of the addable support is very complex, almost magic.

Eventually, I found the cause of the problem inside the orderablereference.pt template: I realized that a few lines of python code in the first 'define' instruction of the 'edit' macro, were responsible for wasting the results of such an elaborate mechanism.

THE PATCH FILES

You can find here the patch files.

RESIDUAL PROBLEMS

I noticed a couple of small residual problems:

• if you reorder the references in the right box, and then you add a new reference, the reordering is being lost; but you can reorder the references after adding new ones
• if you use the "addable support" mechanism recursively (you add a reference with a new target object to a new target object), when you perform the last 'save', the context is not the original source object but its parent folder; frankly, I'm not able/interested to investigate on that.