Block control visibility conditions: Integrate with Logic module
Opened this issue · 2 comments
@nicolas-jaussaud I think I'll start a pull request for this. There are several things to figure out on the side of the Logic module, before it's ready to be integrated into the Fields module and the Blocks plugin. I'll make notes as I go forward, so we can discuss and decide when it's ready for you to take over and continue developing it.
Mixing frontend and backend logic
Logic rules can be partially evaluated on the server side, replaced with true/false, then the transformed rules can be passed to the frontend.
Possible solution:
Evaluate on backend
<Rule control=control_name value=example />Evaluate on frontend, every time control value changes
<Rule dynamic control=control_name value=example />I suppose I'll write a little utility function for "walking the tree" of the logic rules, that allows for transforming the rules as neeed.
Rules that refer to logic variables
We'll need to pass to the frontend any logic variables used in the rules, so the evaluator can refer to it.
<Logic name=weekday_seminar>
<Rule not logic=weekend_seminar />
</Logic>This can be done while walking the tree, to detect any rules using the logic attribute and gather all logic variables being used.
Separate JS and PHP evaluators
I still plan to publish the TypeScript evaluator as an NPM package @tangible/logic. I decided it will be better to separate it from the PHP Composer module, because I want to use the JS evaluator for the "frontend template engine" in the future.
I apologize for the lack of feedback on this recently, thank you a lot for all your help
I'd also want to apologize in advance if I'm long to reply in the coming weeks, I'm a little late on some client work that I'll probably have to prioritize (I also might work a little less than usual as I will be moving out from my place soon)
Evaluate on frontend, every time control value changes
<Rule dynamic control=control_name value=example />
I agree with the proposed solution of explicitly defining when the rule evaluation is dynamic, it should avoid misunderstanding
It might feel a little bit more wordy however, especially in the context of block controls because it's going to be set to dynamic most of the time, but if we remove it we will start being ambiguous again (and it will also remove the possibility to evaluate server-side only in the block controls context)
Logic rules can be partially evaluated on the server side, replaced with true/false, then the transformed rules can be passed to the frontend.
That might not be super relevant for now as we only have the controls use case anyway, but it makes me wonder:
Since we can always evaluate server-side rules on the front-end but can't do the opposite, should we always make sure that every rule exist at least on the backend side so that every rule can be evaluated in both context?
By that I mean that a rule could have either:
- an evaluation callback on the backend side only
- an evaluation callback on the backend and on the frontend
But we won't have rules that will only have a frontend evaluation callback, as we have no way to evaluate that on the backend