The task is to add a "Portal" feature to the SEAD Query API. Each portal specifies a set of facets (possibly with implicit filter criteria) that can be requested the API consumers.
In short, the following feature changes are needed on the query API:
Add the portal concept to the facet data and domain model
Enable facets to be associated to a portal
Allow facets to be shared between portals
Add service that returns available portals to the consumer API
Add service that returns associated facets for a specific portal
There are several possible ways to implement this kind of feature:
1) let portals have their own (implicit) filters that are added by the query builder upon compile
2) let portals have no filter logic of their own and only act as a grouping of facets, or
3) let a portal be assigned to a single, implicit facet that are always added to the facet change
Methods 1) and 3) would reduce the number of new facets, but would also require changes in the facet query engine i.e. add the portal feature inside the engine. Method 1 is a more intrusive change since it affects the domain model to a greater extent.
The 2nd method requires less programmatic changes but would instead increase the number of facets.
Introducing portals within the query engine is deemed more complex and time-consuming from a developer perspective, and since development time is limited, the 2nd approach at a glance seems to be, if not the best, at least the safest. Adding a large number of facets to the system is for know a manual task which make it error prone and time consuming.
Method 3) is deemed the most reasonable method to implement.
The task is to add a "Portal" feature to the SEAD Query API. Each portal specifies a set of facets (possibly with implicit filter criteria) that can be requested the API consumers.
In short, the following feature changes are needed on the query API:
There are several possible ways to implement this kind of feature:
1) let portals have their own (implicit) filters that are added by the query builder upon compile 2) let portals have no filter logic of their own and only act as a grouping of facets, or 3) let a portal be assigned to a single, implicit facet that are always added to the facet change
Methods 1) and 3) would reduce the number of new facets, but would also require changes in the facet query engine i.e. add the portal feature inside the engine. Method 1 is a more intrusive change since it affects the domain model to a greater extent.
The 2nd method requires less programmatic changes but would instead increase the number of facets.
Introducing portals within the query engine is deemed more complex and time-consuming from a developer perspective, and since development time is limited, the 2nd approach at a glance seems to be, if not the best, at least the safest. Adding a large number of facets to the system is for know a manual task which make it error prone and time consuming.
Method 3) is deemed the most reasonable method to implement.
All cases require end user testing.