Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Invalid ChildCreationDescription returned while creating new a instance from a Reference widget #2460

Closed
adaussy opened this issue Oct 10, 2023 · 0 comments · Fixed by #2502
Closed

Invalid ChildCreationDescription returned while creating new a instance from a Reference widget #2460

adaussy opened this issue Oct 10, 2023 · 0 comments · Fixed by #2502
Assignees
@frouene

Comments

@adaussy
Copy link
Contributor

adaussy commented Oct 10, 2023

While creating a new instance using the "+" button from Reference Widget that represents a containment reference the presented candidates are incorrect. The creation description should be limited to the reference being edited. In the current implementation it return all pair of <ERefence,EClass> that match the criteria <ParentType,ChildType> whereas it should take into account the current containment reference.

Using the following meta model:

image

It easy to reproduce a case where we can create "Entity one in refC1" while editing the reference "Refc2".

image

Causing the weird behavior:

BugREferenceWidgetWrongCandidateCreation

To reproduce:

InstanceProblem.zip
Studio.zip
@frouene frouene self-assigned this Oct 23, 2023
frouene added a commit that referenced this issue Oct 24, 2023
@frouene
[2460] Fix create object type list from reference widget create modal.
416228e 
Bug: #2460
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
@frouene frouene mentioned this issue Oct 24, 2023
Merged
39 tasks
@frouene frouene linked a pull request Oct 24, 2023 that will close this issue
[2460] Separates the management of element creation from the reference widget in specific services #2502
Merged
39 tasks
frouene added a commit that referenced this issue Oct 24, 2023
@frouene
[2460] Separates the management of element creation from the referenc…
faa012d 
…e widget in specific services

Bug: #2460
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
frouene added a commit that referenced this issue Oct 24, 2023
@frouene
[2460] Separates the management of element creation from the referenc…
bc90ba0 
…e widget in specific services

Bug: #2460
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
frouene added a commit that referenced this issue Oct 27, 2023
@frouene
[2460] Separates the management of element creation from the referenc…
18697dc 
…e widget in specific services

Bug: #2460
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
pcdavid pushed a commit that referenced this issue Oct 30, 2023
@frouene @pcdavid
[2460] Separates the management of element creation from the referenc…
f7e854d 
…e widget in specific services

Bug: #2460
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
pcdavid pushed a commit that referenced this issue Oct 30, 2023
@frouene @pcdavid
[2460] Separates the management of element creation from the referenc…
9dde437 
…e widget in specific services

Bug: #2460
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
@pcdavid pcdavid mentioned this issue Oct 31, 2023
Merged
pcdavid added a commit that referenced this issue Oct 31, 2023
@pcdavid
[2460] Reference widget default handler/provider do not need to be @s…
23a5163 
…ervice

In #2502 both
ReferenceWidgetDefaultCreateElementHandler and
ReferenceWidgetDefaultCandidateSearchProvider are defined as Spring
Boot services.

This means they will always appear in e.g.
List<IReferenceWidgetRootCandidateSearchProvider> along with the
"normal" (application-provided) one. They need to return false on
canHandle() to be ignored when iterating on these lists, which seems
wrong as they actually *can* handle all descriptionId. Then we also
inject them (a second time) through their concrete type to use them as
fallbacks/actual defaults.

Do not mark them as @Services.

They can (correctly) return true on canHandle.

In the few places where we explictly want these default
implementations, create them explicitly.
ReferenceWidgetDefaultCandidateSearchProvider has no constructor
dependency, ReferenceWidgetDefaultCreateElementHandler only needs the
IEditService, which we can get easily.

Bug: #2460
Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>
frouene pushed a commit that referenced this issue Nov 2, 2023
@pcdavid @frouene
[2460] Reference widget default handler/provider do not need to be @s…
242a1ab 
…ervice

In #2502 both
ReferenceWidgetDefaultCreateElementHandler and
ReferenceWidgetDefaultCandidateSearchProvider are defined as Spring
Boot services.

This means they will always appear in e.g.
List<IReferenceWidgetRootCandidateSearchProvider> along with the
"normal" (application-provided) one. They need to return false on
canHandle() to be ignored when iterating on these lists, which seems
wrong as they actually *can* handle all descriptionId. Then we also
inject them (a second time) through their concrete type to use them as
fallbacks/actual defaults.

Do not mark them as @Services.

They can (correctly) return true on canHandle.

In the few places where we explictly want these default
implementations, create them explicitly.
ReferenceWidgetDefaultCandidateSearchProvider has no constructor
dependency, ReferenceWidgetDefaultCreateElementHandler only needs the
IEditService, which we can get easily.

Bug: #2460
Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
frouene pushed a commit that referenced this issue Nov 2, 2023
@pcdavid @frouene
[2460] Reference widget default handler/provider do not need to be @s…
42033b5 
…ervice

In #2502 both
ReferenceWidgetDefaultCreateElementHandler and
ReferenceWidgetDefaultCandidateSearchProvider are defined as Spring
Boot services.

This means they will always appear in e.g.
List<IReferenceWidgetRootCandidateSearchProvider> along with the
"normal" (application-provided) one. They need to return false on
canHandle() to be ignored when iterating on these lists, which seems
wrong as they actually *can* handle all descriptionId. Then we also
inject them (a second time) through their concrete type to use them as
fallbacks/actual defaults.

Do not mark them as @Services.

They can (correctly) return true on canHandle.

In the few places where we explictly want these default
implementations, create them explicitly.
ReferenceWidgetDefaultCandidateSearchProvider has no constructor
dependency, ReferenceWidgetDefaultCreateElementHandler only needs the
IEditService, which we can get easily.

Bug: #2460
Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>
Signed-off-by: Florian ROUËNÉ <florian.rouene@obeosoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@frouene frouene

Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@adaussy @frouene