Remy,
Comments below.
Remy Suen wrote:
Hi Ed, thanks for your response.
On Thu, Dec 3, 2009 at 1:59 PM, Ed Merks <ed.merks@xxxxxxxxx>
wrote:
> > Consider a stack that has two parts, A and B, with a
generated id of
> > partContainer.0.
>
> Are you talking about URI fragments here? E.g., //@partContainer.0
Right. I didn't want to make it specific [to URIs] but yeah, same idea.
I was generalizing it to make it clear that a third-party could
implement their own model reconciler and have it injected into an e4
application if they so desire.
> Index-based references are fragile in this way, but that's an issue
> primarily when the references are cross resource and the
referenced resource
> can change on its own. I wonder if in your scenario something as
simple as
> calling EcoreUtil.resolveAll would force all proxies to resolve
before you
> start applying changes would avoid the problem....
I tried to write some code with that method added but it didn't seem
like it made any difference. Though perhaps I am using it incorrectly
and/or our ecore file isn't setup right to leverage this feature.
Yes, I'm not really sure how the broken references issue arises so not
sure if eager resolving would help.
> Specializing XMIResourceImpl to override useUUIDs to return true
will ensure
> that a UUID is associated with the object as soon as it's attached
to that
> resource; these UUIDs are preserved if you move the object from
one resource
> to another UUID-enabled resource. They won't change over time, but
take a
> lot of space to maintain...
Thanks for the tip, Ed. This certainly resolves the auto-generation
problem. It seems to me that all the id information would be lost when
a "completely" new model (add a new part for my v2 application) is
deployed, correct?
They're universally unique so yes, if there is a new model, then
they're new objects with different/new IDs.
I think the memory issue can become a scalability problem but hm...
If we set the memory issue aside, I think what I need is a way to flag
a field as being an identifier and non-null/empty.
Setting EAttribute.isID to true and marking it as required, i.e., lower
bound 1 will do that. It must be unique in the entire resource...
If the a new object is instantiated through the EMF editor (i.e.
I right-click on a 'Window' and I go 'New Child' > 'Children Part'),
the tooling should detect this and automatically generate an id for it
on the fly and assign it so it shows up in the 'Properties' view.
You could modify the generated item providers to do such a thing. The
validator will check the constraints above.
The non-null/empty requirement should be validated via the EMF
editor and/or at runtime in case the person uses a text editor to edit
the model. This ensures that there are minimal changes between the new
and old models during a layout change between updates of the
application. This would be similar to overriding 'useUUIDs' to return
true except that that seems to be a purely programmatic approach for
ensuring identifiers are generated and cannot be tied in with existing
EMF tooling. Perhaps I'm wrong here?
It seems to accomplish the same thing actually.
Of course, the idea above is not fool-proof since if I'm the designer
and I accidentally deleted a part then I added it back by hand (instead
of using undo), the generated id would be incompatible with the
previous version.
When an object is removed from a resource, the UUID is remembered and
if it's added back, the same ID is associated with it.
I suppose I could add code to consider these cases and handle
them "intelligently" though this seems to imply an excessive amount of
conditional statements, "guessing", handwaving, and pixie dust that is
not within my budget.
Pixie dust is a valuable commodity!
> Is there any existing attribute on a
> partContainer that might act as a key (unique within that one
reference) or
> as an ID (unique within the whole resource)?
We have an MApplicationElement that defines a java.lang.String 'id'
attribute (though not every model object in the e4 model extends that
interface, MKeyBinding would be one example). It's intended to be
unique but since it's a modifiable attribute a conflict could occur in
theory but I suppose if you're going to go ahead and change the
identifier then you probably know what you're doing (or so I hope). If
you had two workbench windows then I suppose it's not unique globally
as it would not be unheard for the user to have the same view open in
both windows. Nonetheless, it should be unique within that container
anyway.
It would have to be unique within a resource to be an ID. It might make
a useful key as well.
> Oops, I did all the commenting in line like it was a newsgroup
question.
> Sorry.
I guess we'll just do the talking here then. :P
Regards,
Remy
----------
Remy Suen
Eclipse Platform/UI Committer
IBM Ottawa
613-356-5162
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|