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