Smalltalk › Frameworks & Tools › Magritte, Pier and Related Tools

Accessing the children of a MAContainer by name ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Jan van de Sandt

Accessing the children of a MAContainer by name ?

Hi,

In Magritte a MAContainer has a collection of MAElementDescription objects called children. Often I would like to access a child using it's name. Currently a MADescription doesn't have a name property. Most of the times it does have a label and an accessor so I can find a child like this:

| accessor |

accessor := #eventStatus asAccessor.

MBBooking description detect: [ :each | each accessor = accessor ]

MBBooking description detect: [ :each | each label = 'Event status' ]

I don't like these options for identifying a child description because they depend on properties that are used for other things. I am thinking about adding an some kind of 'name' property to the description hierarchy. I am curious how others have handled this issue.

Jan.

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas Renggli

Re: Accessing the children of a MAContainer by name ?

I think the accessor is an ideal object to identify descriptions,
because it uniquely identifies a description.

Instead of duplicating the accessor you could ask the description for
its accessor:

accessor := MBBooking descriptionEventStatus accessor.
MBBooking description detect: [ :each | each accessor = accessor ]

If you do not depend on the extension mechanisms of descriptions, you
could also direct call

MBBooking descriptionEventStatus

to get the description. A bit ugly I agree, we should refactor the
creation of descriptions so that also individual descriptions can be
cheaply retrieved.

Lukas

On 18 September 2011 14:05, Jan van de Sandt <[hidden email]> wrote:

> Hi,
> In Magritte a MAContainer has a collection of MAElementDescription objects
> called children. Often I would like to access a child using it's name.
> Currently a MADescription doesn't have a name property. Most of the times it
> does have a label and an accessor so I can find a child like this:
> | accessor |
> accessor := #eventStatus asAccessor.
> MBBooking description detect: [ :each | each accessor = accessor ]
> or
> MBBooking description detect: [ :each | each label = 'Event status' ]
> I don't like these options for identifying a child description because they
> depend on properties that are used for other things. I am thinking about
> adding an some kind of 'name' property to the description hierarchy. I am
> curious how others have handled this issue.
> Jan.
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Yanni Chiu

Re: Accessing the children of a MAContainer by name ?

In reply to this post by Jan van de Sandt

On 18/09/11 8:05 AM, Jan van de Sandt wrote:
>
> I don't like these options for identifying a child description because
> they depend on properties that are used for other things. I am thinking
> 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

Re: Accessing the children of a MAContainer by name ?

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.

Lukas

On 19 September 2011 07:02, Yanni Chiu <[hidden email]> wrote:

> On 18/09/11 8:05 AM, Jan van de Sandt wrote:
>>
>> I don't like these options for identifying a child description because
>> they depend on properties that are used for other things. I am thinking
>> 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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Jan van de Sandt

Re: Accessing the children of a MAContainer by name ?

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.

Jan.

On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli <[hidden email]> 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.

Lukas

On 19 September 2011 07:02, Yanni Chiu <[hidden email]> wrote:
> On 18/09/11 8:05 AM, Jan van de Sandt wrote:
>>
>> I don't like these options for identifying a child description because
>> they depend on properties that are used for other things. I am thinking
>> 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
_______________________________________________

Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Yanni Chiu

Re: Accessing the children of a MAContainer by name ?

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?
--
Yanni

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.
>
> Jan.
>
> On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli <[hidden email]
> <mailto:[hidden email]>> 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.
>
> Lukas
>
>
>
> On 19 September 2011 07:02, Yanni Chiu <[hidden email]
> <mailto:[hidden email]>> wrote:
> > On 18/09/11 8:05 AM, Jan van de Sandt wrote:
> >>
> >> I don't like these options for identifying a child description
> because
> >> they depend on properties that are used for other things. I am
> thinking
> >> 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 ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

John McKeon

Re: Accessing the children of a MAContainer by name ?

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.

John

On Mon, Sep 19, 2011 at 11:07 AM, Yanni Chiu <[hidden email]> 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?
--
Yanni

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.

Jan.

On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli <[hidden email]
<mailto:[hidden email]>> 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.

Lukas

On 19 September 2011 07:02, Yanni Chiu <[hidden email]
<mailto:[hidden email]>> wrote:
> On 18/09/11 8:05 AM, Jan van de Sandt wrote:
>>
>> I don't like these options for identifying a child description
because
>> they depend on properties that are used for other things. I am
thinking
>> 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 ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

relators.jpeg (191K) Download Attachment