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.

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

Abstracting of Model conditions via Scope class #524

Closed
georgehristov opened this issue Mar 14, 2020 · 4 comments
Closed

Abstracting of Model conditions via Scope class #524

georgehristov opened this issue Mar 14, 2020 · 4 comments

Comments

@georgehristov
Copy link
Collaborator

georgehristov commented Mar 14, 2020

Presently Model conditions and Fields are quite tightly coupled with the underlying persistence.
This results in necessity to define the Model condition at the lowest level.
I propose to introduce a class that will abstract this link. The idea is based on the way conditions are handled in Epesi and I believe this will enhance atk4/data.
I have developed already the refactored classes for epesi and if concept is accepted I can work on integrating them with atk4/data (as I really need this functionality).

The concept is as follows:

  • a class called Scope contains the conditions for the Model (scope).

  • when Scope is applied to the Model it is equivalent to applying several conditions to the Model.

  • Scope supports multi-level AND-OR grouping

  • Having Scope separated from Model enables saving the complete Scope object in persistence and applying it programmatically (think about saving user access and applying it to Model this way in the atk4/login)

  • Scope can be 'translated' to human readable text (using previous example would be "Group contains Customer")

  • Scope can be easily represented in UI using the https://querybuilder.js.org/

  • The simplest form of scope is Condition in the form of [$field, $operator, $value]

  • Condition field or value or both can still be expression

  • Condition value can be 'abstract', e.g. we use a text field to store multiselect values let's say company group encoded in the persistence like __vendor__broker__customer__. Then if we use Condition ['group', 'customer'] this is translated to actual condition to ['group', 'like', '%\\customer\\%']. This translation is performed by the field class.

  • Condition value supports also 'placeholders' - think of defining user access using access of a referenced model (Grant access of invoice items where user has access to invoice)

@DarkSide666
Copy link
Member

i like idea.

@georgehristov
Copy link
Collaborator Author

I published the code so far under feature/model-scope branch.
I decided to rename it to Scope as it sounds intuitive - devs can use directly $model->add($scope). It then adds the necessary conditions to the model.
Scope can contain unlimited number of nested scopes and conditions joined by 'AND' / 'OR'
The simplest entity is Condition which represents the [$key, $operator, $value]
Both Scope and Condition extend AbstractScope class.
Placeholder functionality for condition values is also implemented.

I managed to do it completely independent of the existing code but nesting of conditions does not work properly with current Model class as it does not support deep nesting of conditions the way Scope classes do.
If you like the implementation we may work in the direction of integrating Scope with Model so instead of keeping the scope under conditions it keeps it in a property of type Scope.

This way it will be easier and more intuitive to use the conditions / scope in persistence to retrieve data.

@georgehristov georgehristov changed the title Abstracting of Model conditions via Crits class Abstracting of Model conditions via Scope class Apr 6, 2020
@georgehristov
Copy link
Collaborator Author

I am working on the integration with Model and will push the results soon

@mvorisek
Copy link
Member

This is implemented, thanks @georgehristov !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants