4 posts tagged with "querysearch-expanders"

Changes and improvements​

Legacy constraint methods​

The when(boolean, QueryConstraint) and whenOrElse(boolean, QueryConstraint) methods have been removed after being marked as deprecated for three years. These methods were fundamentally flawed as the constraints are passed as a parameter adn as such evaluated immediately, instead of only when the condition is true as per the design of these constraints.

The exists(qualifiedElementName, variableName, constraint, queryOptions) constraint method has now been marked as deprecated. This method was superseded by a new exists() method in version 1.7.0, which takes a QueryBuilder instance as an argument. Using the QueryBuilder instance if more version transparent and more readable.

Meta-model​

The QuerySearchOptionType element has been removed in favor of using the new ValueType system introduced in the elements metamodel. This change aligns the querySearch metamodel more with the elements model which it extend and will allow for more flexibility as the metamodel is refined further. This change was also planned for quite a long time ago and the reason the model was still considered unstable. With this change now implemented, the querySearch metamodel can now be considered to be stable and will no longer be subjected to large breaking changes in the future.

Meta-model​

Following changes to NS model infrastructure, which now introduces options for every DataElement, the QuerySearchOption and QuerySearchOptionType elements have been removed. This functionality has so far not been adopted in such a way that it would have an impact. The new Option and OptionType elements in prime-core are now used as an alternative.

Meta-model​

Though still under development and prone to changes, this version introduces a very large structural change in the meta-model for QuerySearch, which may affect other expansion resources and early adopters.

The QuerySearch element now has DataElement as its parent element, rather than Component like it did before. This is the correct intended structure for the model, which was previously not possible due to technical limitations. What this affects:

• Expansion resources:
  • QuerySearch.component field no longer exists and is now only accessible as QuerySearch.dataElement.component.
  • QuerySearch instances are now registered in DataElement.extensions[] instead of Component.extensions[].
• Application projects:
  • QuerySearch model xml files have moved from <componentRoot>/model/querySearchs to <componentRoot>/model/dataElements/<dataElement>/querySearchs.
  • The QuerySearch model files should no longer contain a DataRef to the parent DataElement.

QuerySearchResolver​

The QuerySearchResolver class was moved from the data layer to the logic layer. Since this is used most commonly to resolve references to other components, the use of Cruds classes in the data layer will create high coupling between those components, which is not intended.

To transition to the logic layer implementation, the Agent classes should be used when resolving data for elements in other components. In this scenario there is also no need to use dependency injection with EJB, as the agents do not require this.

A transient option querysearch.transient.dataLayerResolver.enable has been supplied to revert the behavior of the expanders for backwards compatibility. But keep in mind that this option will be removed in the future and has only been supplied for short-term compatibility if needed, allowing for planning to upgrade the codebase. This option will once again expand the QuerySearchResolver in the data layer, rather than the logic layer.