Bug 485545 - [Facet] Add a mechanism to delegate the evaluation of a query to the "Super" Facet/Custom
Summary: [Facet] Add a mechanism to delegate the evaluation of a query to the "Super" ...
Status: NEW
Alias: None
Product: Papyrus
Classification: Modeling
Component: Views (show other bugs)
Version: 1.2.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-11 08:08 EST by Camille Letavernier CLA
Modified: 2017-09-08 09:52 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Camille Letavernier CLA 2016-01-11 08:08:33 EST
With the current FacetManager implementation, it is possible to delegate the evaluation of a query to the static supertype. However, in most cases, we don't want to delegate to the static type: we want to delegate to the query that is next in the queue (This is computed dynamically).

In general, Facets are independent from each other, so instead of:

- DefaultFacet
-- GenericFacet
--- SpecificFacet1
---- SpecificFacet2

We have:

- DefaultFacet
-- GenericFacet
-- SpecificFacet1
-- SpecificFacet2

And each of these Facets only know about their static super-type (DefaultFacet in this case). If SpecificFacet2 is not able to compute a result for a query, it will only be able to delegate to DefaultFacet, because it knows nothing about SpecificFacet1 and GenericFacet.

In EMF Facet 1.X, the delegation was dynamic, i.e. the facet manager computes a priority queue of facets for a given query, and if a facet cannot return a result, it delegates to the next one in the queue. We need something similar for Papyrus Facet.

It may be useful to keep the current mechanism for "static" delegation, but we also need a dynamic one (In most cases, the Static one is not so useful, but there is no need for removing it)

Dynamic priority queues can also allow more advanced customization, such as "decorating" a label returned by another query (e.g. adding a pre-/post-fix)
Comment 1 Camille Letavernier CLA 2016-01-11 08:09:34 EST
This is also related to Bug 485539, as the computation of the priority queue needs to be cached for performances reason (Both bugs require a refactoring of the FacetManager algorithm)