I've used custom properties extensively and are a big part of what I have been doing lately. Don't be afraid to add a property by which YOUR code can identify another description. Just add them in your own package.  I don't think you will ever get around iterating through a description to find the one you're after. But you can use another property to store the found description, so it optimizes...

I wrestled for some time with finding a way to allow descriptions in a container to "communicate" with one another. Its kind of basic to what we want to use objects for, if one field changes another needs to know about it. But in the memento world, these rules that we might put in a setter method are of no use because they will not execute until the memento is committed.

So I came up with an api of sorts, a set of properties, that give you a way to link descriptions together so that components built knowing about these properties can handle events and perform needed operations *on the memento*. It works well with with JQuery. Still quite a work in progress (i.e. it's really ugly code right now) but its in the Magritte-JQueryWidgetBox package in the Magriite 2 addons repository if you have the stomach for it :) I removed the widget box components from the functional test so it could run in a stock Seaside 3.0 image. The functional test is the only test in the package btw, ahem 8]

Anyway, I've stayed up too late bragging about my crap, but it shows what can be done with custom properties. 


On Mon, Sep 19, 2011 at 11:07 AM, Yanni Chiu <yanni@rogers.com> wrote:
The general case, for dynamic instance-based descriptions, is complicated. Is there some scope for a specialized MAContainer that deals only with static class-based descriptions, using names that are unique within the container? Would this affect the MAContainer protocol in some way?

On 19/09/11 3:26 AM, Jan van de Sandt wrote:
Hi Lukas,

Thanks for the info. It is indeed more complex than it seems.

Would it help if a description has a unique name within a MAContainer?
So a container would have an ordered dictionary of children instead of
an ordered collection.


On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli <renggli@gmail.com
<mailto:renggli@gmail.com>> wrote:

   Uniquely identifying descriptions is a much harder problem than it
   looks like: descriptions evolve, change, get extended and refactored.

   At ESUG in 2006 there was a longer discussion about this problem: The
   question was how to identify descriptions that were dynamically
   created and edited by users in different images and stored to an OODB.
   The only reasonable solution was to use UUIDs.

   It is easy to programmatically add UUIDs, but ideally they should also
   cover the #description* methods.


   On 19 September 2011 07:02, Yanni Chiu <yanni@rogers.com
   <mailto:yanni@rogers.com>> wrote:
    > On 18/09/11 8:05 AM, Jan van de Sandt wrote:
    >> I don't like these options for identifying a child description
    >> they depend on properties that are used for other things. I am
    >> about adding an some kind of 'name' property to the description
    >> hierarchy. I am curious how others have handled this issue.
    > I use both methods, and don't like either method.
    > In some cases, I had to use the label. IIRC, it was because it was a
    > chain'ed accessor.
    > _______________________________________________
    > Magritte, Pier and Related Tools ...
    > https://www.iam.unibe.ch/mailman/listinfo/smallwiki

   Lukas Renggli
   www.lukas-renggli.ch <http://www.lukas-renggli.ch>

   Magritte, Pier and Related Tools ...

Magritte, Pier and Related Tools ...

Magritte, Pier and Related Tools ...