Home » Modeling » EMF » loading bottom-to-top or postLoad()?
| loading bottom-to-top or postLoad()? [message #381985] |
Fri, 23 January 2004 12:58  |
|
Originally posted by: joerg.von.frantzius.artnology.nospam.com
Hi,
when I have a containment hierarchy (by means of references) A->B->C,
and I want to maintain a Map on A to find the B object for a C object, I
run into problems. I maintain the Map on A by notification when a B
object is added to an A object.
The problem is that loading from a Resource works top-to-bottom: first A
objects are created, then B objects, which are then added to their
respective references on A objects, and afterwards the C objects are
created and added to their B objects. Unfortunately, that means that by
the time when the B objects are added to A objects, the B objects'
references to C objects are null. When I listen to those additions, I
end up with null values in my Map.
There are of course workarounds possible, but I can't find them exactly
elegant. It would be nice to either have loading working bottom-to-top,
so that each level is consistent in downward direction when one is
notified of its existence, or to have some kind of postLoad() method
being called after the whole hierarchy has been loaded.
What do you EMF guys think?
Best regards,
Jörg.
|
|
|
| Re: loading bottom-to-top or postLoad()? [message #381986 is a reply to message #381985] |
Fri, 23 January 2004 15:26  |
 David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Joerg von Frantzius wrote:
> It would be nice to either have loading working bottom-to-top, so
> that each level is consistent in downward direction when one is
> notified of its existence, or to have some kind of postLoad()
> method being called after the whole hierarchy has been loaded.
Hi Jorg,
Are you not expecting the model ever to be built up in memory, rather than
loaded from a resource? If so, it would seem that your solution should be
able to handle properly the more natural order of building the model: adding
B's to an A before it has been populated with C's. So, I'm not sure I see
the value in making the load build the model in the unnatural bottom-to-top
order that you propose.
I think there's a better way to solve your problem. As you suggested, an
adapter makes sense, but you just need your A objects to be able to react to
two kinds of changes:
1. Whenever a B object is added or removed to or from the A object, it
should check whether the B already contains any C's, adding or removing them
from the map, as appropriate.
2. Whenever a C object is added to or removed from any of the B objects the
A object already contains, it should add or remove them from the map, as
appropriate.
So, the A should maintain an adapter that handles notifications from itself
and from its B's. In order to see notifications from the B objects in 2,
the adapter will need to automatically attach and detach itself to them in 1.
EContentAdapter, in the org.eclipse.emf.ecore.util package, already solves
the general problem of adapting on a whole containment hierarchy in this
manner. I'd suggest you subclass it and override notifyChanged() to do the
map addition/removal (just make sure selfAdapt() still gets called).
Cheers,
Dave
|
|
|
| Re: loading bottom-to-top or postLoad()? [message #382002 is a reply to message #381986] |
Mon, 26 January 2004 05:28 |
|
Originally posted by: joerg.von.frantzius.artnology.nospam.com
Dave Steinberg wrote:
> Joerg von Frantzius wrote:
>
>> It would be nice to either have loading working bottom-to-top, so
>> that each level is consistent in downward direction when one is
>> notified of its existence, or to have some kind of postLoad()
>> method being called after the whole hierarchy has been loaded.
>
>
> Hi Jorg,
>
> Are you not expecting the model ever to be built up in memory, rather
> than loaded from a resource? If so, it would seem that your solution
> should be able to handle properly the more natural order of building
> the model: adding B's to an A before it has been populated with C's.
> So, I'm not sure I see the value in making the load build the model in
> the unnatural bottom-to-top order that you propose.
Taking gravity into account, building things up bottom-to-top doesn't
seem all that unnatural to me ;-)
No, seriously, I think it absolutely depends on the application what is
most suitable here. In my case, at creation time of A, I need all
references "down" the tree to be established, but in a different
application, it might be at creation time of B that I need the
references "up" the tree.
Anyway, it would be nice to have some notification when the hierarchy
has been loaded completely, so that any references either down or up can
be resolved after all objects have been created in memory. In my
application, Bs are never added to As before they were populated with
Cs, so I would like to avoid having to listen to those events only for
the purpose of loading the model. I would get to hear them also after
the model is loaded, when I don't need them anymore.
Some kind of "post-load" event, which would occur only once, would come
in very handy here to initialize/resolve references after all objects
have been loaded into memory. This would make loading structures easier
that contain more references than those declared in EMF. I'd think that
having such redundant references that can be computed at runtime (and
which consequently should not be expressed in EMF and persisted) is a
common requirement. Some kind of postLoad notification also is a feature
found in many frameworks providing persistence, as in Entity Beans, JDO
or CORBA 3.0.
>
> I think there's a better way to solve your problem. As you suggested,
> an adapter makes sense, but you just need your A objects to be able to
> react to two kinds of changes:
>
> 1. Whenever a B object is added or removed to or from the A object, it
> should check whether the B already contains any C's, adding or
> removing them from the map, as appropriate.
>
> 2. Whenever a C object is added to or removed from any of the B
> objects the A object already contains, it should add or remove them
> from the map, as appropriate.
>
> So, the A should maintain an adapter that handles notifications from
> itself and from its B's. In order to see notifications from the B
> objects in 2, the adapter will need to automatically attach and detach
> itself to them in 1.
>
> EContentAdapter, in the org.eclipse.emf.ecore.util package, already
> solves the general problem of adapting on a whole containment
> hierarchy in this manner. I'd suggest you subclass it and override
> notifyChanged() to do the map addition/removal (just make sure
> selfAdapt() still gets called).
Thanks for the input, this surely is what I have to do for the time
being, if I don't want to trigger initialization from outside after
loading the model.
Regards,
Jörg.
|
|
|
| Re: loading bottom-to-top or postLoad()? [message #382076 is a reply to message #382002] |
Wed, 28 January 2004 15:35 |
|
Originally posted by: user.example.com
Hi Joerg,
Did you come up with a work-around to EMF's lack of post-load event? I'm
also working with a model that has many implicit references that must be
'built-out' post document load. Currently, I have a post-load call in my
edit-layer (i.e. the first time getChildren is called on the top-level
object) but this really doesn't work because some clients access the EMF
model outside of the edit domain. I suppose sub-classing ResourceSet (to
eagerly load all resources then call a home-grown 'postLoad') is the way to
go...
Thanks,
Jimmy
"Joerg von Frantzius" <joerg.von.frantzius@artnology.nospam.com> wrote in
message news:bv2q1m$b63$1@eclipse.org...
> Dave Steinberg wrote:
>
> > Joerg von Frantzius wrote:
> >
> >> It would be nice to either have loading working bottom-to-top, so
> >> that each level is consistent in downward direction when one is
> >> notified of its existence, or to have some kind of postLoad()
> >> method being called after the whole hierarchy has been loaded.
> >
> >
> > Hi Jorg,
> >
> > Are you not expecting the model ever to be built up in memory, rather
> > than loaded from a resource? If so, it would seem that your solution
> > should be able to handle properly the more natural order of building
> > the model: adding B's to an A before it has been populated with C's.
> > So, I'm not sure I see the value in making the load build the model in
> > the unnatural bottom-to-top order that you propose.
>
> Taking gravity into account, building things up bottom-to-top doesn't
> seem all that unnatural to me ;-)
>
> No, seriously, I think it absolutely depends on the application what is
> most suitable here. In my case, at creation time of A, I need all
> references "down" the tree to be established, but in a different
> application, it might be at creation time of B that I need the
> references "up" the tree.
>
> Anyway, it would be nice to have some notification when the hierarchy
> has been loaded completely, so that any references either down or up can
> be resolved after all objects have been created in memory. In my
> application, Bs are never added to As before they were populated with
> Cs, so I would like to avoid having to listen to those events only for
> the purpose of loading the model. I would get to hear them also after
> the model is loaded, when I don't need them anymore.
>
> Some kind of "post-load" event, which would occur only once, would come
> in very handy here to initialize/resolve references after all objects
> have been loaded into memory. This would make loading structures easier
> that contain more references than those declared in EMF. I'd think that
> having such redundant references that can be computed at runtime (and
> which consequently should not be expressed in EMF and persisted) is a
> common requirement. Some kind of postLoad notification also is a feature
> found in many frameworks providing persistence, as in Entity Beans, JDO
> or CORBA 3.0.
>
> >
> > I think there's a better way to solve your problem. As you suggested,
> > an adapter makes sense, but you just need your A objects to be able to
> > react to two kinds of changes:
> >
> > 1. Whenever a B object is added or removed to or from the A object, it
> > should check whether the B already contains any C's, adding or
> > removing them from the map, as appropriate.
> >
> > 2. Whenever a C object is added to or removed from any of the B
> > objects the A object already contains, it should add or remove them
> > from the map, as appropriate.
> >
> > So, the A should maintain an adapter that handles notifications from
> > itself and from its B's. In order to see notifications from the B
> > objects in 2, the adapter will need to automatically attach and detach
> > itself to them in 1.
> >
> > EContentAdapter, in the org.eclipse.emf.ecore.util package, already
> > solves the general problem of adapting on a whole containment
> > hierarchy in this manner. I'd suggest you subclass it and override
> > notifyChanged() to do the map addition/removal (just make sure
> > selfAdapt() still gets called).
>
> Thanks for the input, this surely is what I have to do for the time
> being, if I don't want to trigger initialization from outside after
> loading the model.
>
> Regards,
> J
|
|
|
| Re: loading bottom-to-top or postLoad()? [message #382077 is a reply to message #382076] |
Wed, 28 January 2004 16:32 |
Ed Merks
Messages: 25227
Registered: July 2009 |
Senior Member |
|
|
Jimmy,
If you need to do some processing once your whole document is loaded you might
consider doing it it XMLHandler.endDocument; we do things like resolving IDREFs
at that point. A Resource also produces a notification after it's loaded, so
that's another possible trigger to consider.
Jimmy Dean wrote:
> Hi Joerg,
>
> Did you come up with a work-around to EMF's lack of post-load event? I'm
> also working with a model that has many implicit references that must be
> 'built-out' post document load. Currently, I have a post-load call in my
> edit-layer (i.e. the first time getChildren is called on the top-level
> object) but this really doesn't work because some clients access the EMF
> model outside of the edit domain. I suppose sub-classing ResourceSet (to
> eagerly load all resources then call a home-grown 'postLoad') is the way to
> go...
>
> Thanks,
> Jimmy
>
> "Joerg von Frantzius" <joerg.von.frantzius@artnology.nospam.com> wrote in
> message news:bv2q1m$b63$1@eclipse.org...
> > Dave Steinberg wrote:
> >
> > > Joerg von Frantzius wrote:
> > >
> > >> It would be nice to either have loading working bottom-to-top, so
> > >> that each level is consistent in downward direction when one is
> > >> notified of its existence, or to have some kind of postLoad()
> > >> method being called after the whole hierarchy has been loaded.
> > >
> > >
> > > Hi Jorg,
> > >
> > > Are you not expecting the model ever to be built up in memory, rather
> > > than loaded from a resource? If so, it would seem that your solution
> > > should be able to handle properly the more natural order of building
> > > the model: adding B's to an A before it has been populated with C's.
> > > So, I'm not sure I see the value in making the load build the model in
> > > the unnatural bottom-to-top order that you propose.
> >
> > Taking gravity into account, building things up bottom-to-top doesn't
> > seem all that unnatural to me ;-)
> >
> > No, seriously, I think it absolutely depends on the application what is
> > most suitable here. In my case, at creation time of A, I need all
> > references "down" the tree to be established, but in a different
> > application, it might be at creation time of B that I need the
> > references "up" the tree.
> >
> > Anyway, it would be nice to have some notification when the hierarchy
> > has been loaded completely, so that any references either down or up can
> > be resolved after all objects have been created in memory. In my
> > application, Bs are never added to As before they were populated with
> > Cs, so I would like to avoid having to listen to those events only for
> > the purpose of loading the model. I would get to hear them also after
> > the model is loaded, when I don't need them anymore.
> >
> > Some kind of "post-load" event, which would occur only once, would come
> > in very handy here to initialize/resolve references after all objects
> > have been loaded into memory. This would make loading structures easier
> > that contain more references than those declared in EMF. I'd think that
> > having such redundant references that can be computed at runtime (and
> > which consequently should not be expressed in EMF and persisted) is a
> > common requirement. Some kind of postLoad notification also is a feature
> > found in many frameworks providing persistence, as in Entity Beans, JDO
> > or CORBA 3.0.
> >
> > >
> > > I think there's a better way to solve your problem. As you suggested,
> > > an adapter makes sense, but you just need your A objects to be able to
> > > react to two kinds of changes:
> > >
> > > 1. Whenever a B object is added or removed to or from the A object, it
> > > should check whether the B already contains any C's, adding or
> > > removing them from the map, as appropriate.
> > >
> > > 2. Whenever a C object is added to or removed from any of the B
> > > objects the A object already contains, it should add or remove them
> > > from the map, as appropriate.
> > >
> > > So, the A should maintain an adapter that handles notifications from
> > > itself and from its B's. In order to see notifications from the B
> > > objects in 2, the adapter will need to automatically attach and detach
> > > itself to them in 1.
> > >
> > > EContentAdapter, in the org.eclipse.emf.ecore.util package, already
> > > solves the general problem of adapting on a whole containment
> > > hierarchy in this manner. I'd suggest you subclass it and override
> > > notifyChanged() to do the map addition/removal (just make sure
> > > selfAdapt() still gets called).
> >
> > Thanks for the input, this surely is what I have to do for the time
> > being, if I don't want to trigger initialization from outside after
> > loading the model.
> >
> > Regards,
> > Jörg.
|
|
|
Goto Forum:
Current Time: Tue Oct 08 07:56:12 EDT 2013
Powered by FUDForum. Page generated in 0.02370 seconds
|
] 
Search
Help
Register
Login
Home
