2:05 p.m.
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.
2:52 p.m.
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 <jvdsandt(a)gmail.com> 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
7:02 a.m.
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.
7:24 a.m.
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 <yanni(a)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 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
9:26 a.m.
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 <renggli(a)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.
Lukas
On 19 September 2011 07:02, Yanni Chiu <yanni(a)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 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
5:07 p.m.
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 <renggli(a)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.
Lukas
On 19 September 2011 07:02, Yanni Chiu <yanni(a)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
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
5:08 a.m.
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<http://source.lukas-renggli.ch/@MQPvXVc6Gb8CgywA/UWuv1AEz?64>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 <yanni(a)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?
--
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 <renggli(a)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.
>
> Lukas
>
>
>
> On 19 September 2011 07:02, Yanni Chiu <yanni(a)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
> 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<https://www.iam....
> >
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch <http://www.lukas-renggli.ch>
>
> ______________________________**_________________
> Magritte, Pier and Related Tools ...
>
https://www.iam.unibe.ch/**mailman/listinfo/smallwiki<https://www.iam....
>
>
>
>
> ______________________________**_________________
> Magritte, Pier and Related Tools ...
>
https://www.iam.unibe.ch/**mailman/listinfo/smallwiki<https://www.iam....
>
______________________________**_________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/**mailman/listinfo/smallwiki<https://www.iam....
4454
days inactive
4459
days old
6 comments
4 participants
participants (4)
-
Jan van de Sandt -
John McKeon -
Lukas Renggli -
Yanni Chiu