Community
Participate
Working Groups
On some properties, there is a need to search in the whole model. A dailog box opens that gives the opportunity to find elemnts in the model that might match. IN the bottom of this dialog box, the recent searches are provided. In the case the previous search was done in another model, this model is loaded in memory and according to the model load strategy there can be a notification to tell to the user that this previous model will be loaded. This is too intrusive. The "recent" section of the dialog box should be ignored if the previous search was done in another resource
What about linked resources, such as imported Primitive Types ? I think the history should be specific for each model (According to the model's location in the workspace, probably - you will lose the history when moving or renaming the model, but I don't think we can have a better control on that...) This may become difficult when editing more than one model in the same resource set. I will check that.
Basically, we have two options for avoiding the problem : - The first one is to make a specific history for a given resource - The second one is to make a specific history for a set of resource, based on its root resource Both solutions have advantages and drawbacks. If you edit the Model A, it will have a specific history. If you edit the Model B, which imports A, then edit an element of A from this diagram, you will have either the history of A (In the first case) or the history of B (In the second case). Both can be interesting... This choice only makes sense when A isn't read-only. When A is read-only, only the history of B is interesting. Which solution do you prefer ? By the way, the first option is easier to implement, as it only needs the current edited object to retrieve the resource, while the other one needs an access to the ServiceRegistry to find the root model (And we currently have some problems with the service registry : Bug 359075)
(In reply to comment #2) > Basically, we have two options for avoiding the problem : > > - The first one is to make a specific history for a given resource > - The second one is to make a specific history for a set of resource, based on > its root resource > > Both solutions have advantages and drawbacks. > > If you edit the Model A, it will have a specific history. > If you edit the Model B, which imports A, then edit an element of A from this > diagram, you will have either the history of A (In the first case) or the > history of B (In the second case). Both can be interesting... > > This choice only makes sense when A isn't read-only. When A is read-only, only > the history of B is interesting. > > Which solution do you prefer ? > > By the way, the first option is easier to implement, as it only needs the > current edited object to retrieve the resource, while the other one needs an > access to the ServiceRegistry to find the root model (And we currently have some > problems with the service registry : Bug 359075) In both cases, the history will be lost when you move or rename the resource.
Fixed in r5700 (Branch 0.8.X) Merged to the trunk in r5701 The first solution has been retained.
Seems to work. Verified OK. Still some tests to do. Waiting one more week before closing.
