Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358886

Summary:	[property view] dialog box keeps recent searches and loads other models
Product:	[Modeling] Papyrus	Reporter:	Raphael Faudou <raphael.faudou>
Component:	Core	Assignee:	Camille Letavernier <cletavernier>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	0.8.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Raphael Faudou

2011-09-26 09:25:50 EDT

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

Comment 1 Camille Letavernier

2011-09-28 09:53:13 EDT

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.

Comment 2 Camille Letavernier

2011-09-30 09:52:05 EDT

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)

Comment 3 Camille Letavernier

2011-09-30 09:52:57 EDT

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

Comment 4 Camille Letavernier

2011-10-05 05:25:25 EDT

Fixed in r5700 (Branch 0.8.X)
Merged to the trunk in r5701

The first solution has been retained.

Comment 5 Raphael Faudou

2012-03-20 15:19:05 EDT

Seems to work. 
Verified OK. Still some tests to do. Waiting one more week before closing.