Fluid Standalone - maintenance und further development

Added by Daniela Diebowski over 2 years ago

BO: Claus Due
EURO: 37'620.00
EAB Responsible: Boris Hinzer


Replies (3)

RE: Fluid Standalone - maintenance und further development - Added by Ric van Westhreenen over 2 years ago

Like with the other requests regarding specific extensions and functionality, I have one central question:

- what value does this bring our members of the TYPO3 Association and the TYPO3 Community?
- what is the current and expected usage of this functionality?

RE: Fluid Standalone - maintenance und further development - Added by Mathias Schreiber over 2 years ago

90% of TYPO3s presentation layer is Fluid.

Regarding values:
  • More performance
  • More stability
  • Easier to use for Developers
  • More range within the development (not TYPO3 community)

RE: Fluid Standalone - maintenance und further development - Added by Claus Due over 2 years ago

I think this isn't so clear from the application itself so I thought I would add it here.

In addition to the specific desired features (which Mathias explained the reasons for) the last line says that one intention is to be able to react quickly to requests for features (coming from TYPO3 CMS use cases), but an even more important intention is to be able to give top priority to any bugs or performance issues that may be discovered in TYPO3 CMS's usage of Fluid, whether they exist in Fluid Standalone or the TYPO3 CMS Fluid adapter. I could add to those that will be focusing on the stability part for a good while, since our implicit goal is the best possible state of this library to accompany TYPO3v8 LTS (flip the order of the top two items, then you have our prioritised values we want to add; 1) stability, 2) performance, 3) ease-of-use, 4) new developments like the parser refactoring).

And to be a bit more precise about the intention with the (rather large) TemplateParser refactoring: with this we hope to provide many more methods for Fluid adapters to change the way Fluid parses templates. To name a few specific things that would become possible:

  • Using EXT:myext/... references anywhere in templates, pointing to images, files, styles etc. - not just inside ViewHelper arguments and not requiring special translation when used as VH arguments.
  • Extracting <style> and <script> tags from templates even when they exist outside a rendered section, then piping them through pagerenderer for proper concatenation (legacy approaches will still be supported of course)
  • Supporting any desired style of array syntax, variable references, brace styles etc. (for one, the ability to replace
    { and }
    with for example
    [[ and ]]
    if this better fits a specific template.

And more that I haven't even thought of yet. The three use cases above are inspired by Flow's resource interceptor and a couple of previous feature requests that we have had to reject because of the need to refactor this specific class.

Hopefully this added some more concrete answers to "how would TYPO3 benefit".

    (1-3/3)