RFC: New utility class for Eel evaluation

Creating Neos & Flow Code
1

This was brought up by @bwaidelich on Slack, but I think it’s much better home is here…

Hey Fusion & Eel fans,

do you agree that the static Neos\Eel\Utitlity class is hard to use?

It leads to glue code like https://github.com/Flowpack/Flowpack.NodeTemplates/blob/master/Classes/Service/EelEvaluationService.php in many places and it’s currently not possible to detect an Eel expression before evaluating it (without duplicating code that is).

Rigorous suggestion:

  1. Deprecate the Neos.Fusion.defaultContext setting in favor of a global Neos.Eel.context
  2. Deprecate the static Utility in favor of a singleton with a really easy to use interface like: $this->eelXYZ->evaluateEelExpression($expression, $variables) that throws an exception if the given $expression is not valid
    2a. Maybe add a second method that allows to specify a custom context, too!?
  3. disallow special characters (particularly dots) in the context names to prevent those nasty nesting issues

See https://github.com/neos/flow-development-collection/pull/1437#pullrequestreview-240079235 for the related discussion [that triggered this post.]

1 Like
2

I’m all for a proper Service class as Bastian suggested, which can be injected and removes the necessity for all the glue code.

Basically, the base implementation of that service would look a lot like the EelEvaluationService linked above, but incorporate the functionality of the EelUtility.

3

I like the idea of a global eel context but I think we need the option to add additional default context for cases like ui or backend modules where you may need helpers that should not be exposed to the integration layer.

1 Like