TYPO3.Fluid

Thanks for the reminder.

This change will be obsolete, if Eel is available in Fluid for FLOW3 and also in Fluid for extbase

How will Eel be integrated in Fluid? A view helper? I couldn't find a ticket about that - is there one? Do we need one?

If there is a ticket, and we are going to use Eel instead of implementing the logical operators within the boolean ViewHelper attributes, then this issue should depend on the other issue.

There is no other Issue/Ticket yet. Just created two tickets.

IMHO we need to do two separate steps

• First of all Eel should be available within Fluid (the FLOW3-Package). I think the easiest way would be to implement a Eel-ViewHelper. (#38379)
• Then the Eel-Package (and this new VH) should be backported to extbase (and become a part of extbase) (#38380)

Actually Eel should be integrated into Fluid using the syntax of "${eel-expression}".

Greets, sebastian

Hej Sebastian,

what's the advantage of having a new build-into-fluid syntax ( ${..} ) instead an eel viewhelper, except of being a little shorter? I think a viewhelper will be much easier to implement instead of extending the fluid template parser.

Tobias Liebig wrote:

what's the advantage of having a new build-into-fluid syntax ( ${..} )

Can you think of an example and compare the syntax?
I'm not sure how that would look like in eel, but with a new ViewHelper it is probably rather technical:

1 <f:if condition="{f:eel(query: 'foo == \'bar\'')}">

Bastian Waidelich wrote:

Tobias Liebig wrote:

what's the advantage of having a new build-into-fluid syntax ( ${..} )

Can you think of an example and compare the syntax? I'm not sure how that would look like in eel, but with a new ViewHelper it is probably rather technical: [...]

i'd be totally fine with that, if it means its easier to implement, which actually means we could have it earlier in Fluid for extbase :-)

i guess in Sebastians suggestion it would be like:

1 <f:if condition="${'foo == \'bar\''}">

Hey,

@Bastian: even easier:

<f:if condition="${foo == 'bar'}">

@Tobias: I'd rather not implement a half-baked solution which has poor usability -- rather change the Fluid parser for that.

Actually the eel parser contains already a RegEx for detecting eel expressions: http://git.typo3.org/FLOW3/Packages/TYPO3.Eel.git?a=blob;f=Classes/Package.php

It's still very poor and needs to be dramatically improved, but once that is done Fluid can be extended quite easily to support that. However the improvement can be done test-driven.

Greets, Sebastian

Sebastian Kurfuerst wrote:

@Tobias: I'd rather not implement a half-baked solution which has poor usability

I agree. No problem in having an eel ViewHelper in some other extension but I'd not "ship" that with Fluid.
If implementing eel to the parser turns out to be too complex for now, we should at least support literal comparison (#6757)

I'm not sure if it's a good idea to add a new syntax construct for expressions in fluid. It could confuse people on when to choose eel syntax "${ ... }" and when to choose standard fluid syntax "{ ... }".
If I'm not mistaken, eel could theoretically completely replace standard fluid syntax in functionality, right? So why not make it really replace the fluid internal expression parsing. Maybe the current parser could still be a fallback solution for when the eel package isn't available or not installed properly, but they should share the same fluid syntax IMO.

I think to re-use the same expression parser is generally a great idea and was also a motivation when writing Eel. But there are some (minor?) problems we need to solve to make it a smooth replacement:

• Fluids ObjectAccessorNode does support access to public getters (getFoo() and isFoo()) and public properties (for objects, array keys (for arrays and ArrayAccess).
• Eel allows to call just about any public method of an object, which could be unwanted in Fluid (imagine a destructive method being called in the view). So we need some method whitelisting or language feature support (e.g. disable method calls in Fluid Eel) here to make it safe.
• Additionally we need to replicate the ObjectAccessorNodes behaviour when accessing properties to make Eel a replacement in Fluid. But that should be rather trivial.

I think using the same syntax could cause some harder edge cases, imagine building arrays for example:

<f:if condition="{blog.name == 'My blog'}">
<f:link.action ... arguments="{blog: post.blog}">My blog</f:link.action>
</f:if>

Syntax-wise the arguments array looks like an Eel expression, but it is handled by an ArrayNode in Fluid. For an Eel Expression, it has to be written as arguments="{{blog: post.blog}}" or we introduce a Ruby 1.9 like shorthand "object" / array notation: arguments="{blog: post.blog}". But there are a lot of templates in the wild, where something like arguments="{name: '{f:some.viewhelper(arg: \"Foo\"})'" is used. Right now I think this works in Fluid because it just uses Regular expressions and recursively parses the template (Sebastian?).

To make it consistent we would need to replace everything but the shorthand syntax in Fluid with Eel expressions.

Alexander Berl wrote:

If I'm not mistaken, eel could theoretically completely replace standard fluid syntax in functionality, right? So why not make it really replace the fluid internal expression parsing. Maybe the current parser could still be a fallback solution for when the eel package isn't available or not installed properly, but they should share the same fluid syntax IMO.

Any chance to get this going again maybe? I think it would be a huge step forward and would appreciate it.

Christopher Hlubek wrote:

Object / Array access looks the same in Fluid and Eel, but there a some differences:

• Fluids ObjectAccessorNode does support access to public getters (getFoo() and isFoo()) and public properties (for objects, array keys (for arrays and ArrayAccess).
• Eel allows to call just about any public method of an object, which could be unwanted in Fluid (imagine a destructive method being called in the view). So we need some method whitelisting or language feature support (e.g. disable method calls in Fluid Eel) here to make it safe.

As far as I see, the method calling is controlled by the Context. So would it be a possible solution to create a "FluidContext" which throws an exception in its call method?
Then within Fluid if Eel is available, a new EelEvaluator is created as well as a FluidContext and all expressions evaluated that way.

• Additionally we need to replicate the ObjectAccessorNodes behaviour when accessing properties to make Eel a replacement in Fluid. But that should be rather trivial.

Isn't the ObjectAccessor already used in the Eel Context::get() method, which afaik is responsible for all non-method call access (i.e. public properties and everything accessible via getters).

I'm not sure when/where the ${} syntax is needed though... also the array notation has to be checked, but I can't imagine that being a big problem.

Just a small ping ... Anything we can help with maybe?

I didn't put any effort into this patch as it seems like eel should solve the issue.
No idea about if and when eel is available in Fluid and backported to extbase too.

Stefan Neufeind wrote:

Just a small ping ... Anything we can help with maybe?

You're free to try working out a solution to the problems mentioned in using Eel inside Fluid, maybe with the hints I gave it will be a good starting point. Anything you find will be valuable information and maybe even a good solution turns out that can be used directly