[TYPO3-mvc] Harmonization and Streamlining of CMS Fluid and FLOW Fluid

Claus Due claus at phpmind.net
Mon Mar 23 15:28:31 CET 2015


Guys, I encourage you to think much broader than this.

Which ViewHelpers to put in Fluid itself should not be
decided based on how many ViewHelpers are useful
to CMS and Flow. It should be based on which are
useful to a standalone version of Fluid.

Please look again on https://github.com/NamelessCoder/TYPO3.Fluid

I've removed the ViewHelpers from there which simply
don't make sense as generic ViewHelpers which - just
as an example - render links to controller actions. This
should not be the responsibility of the template engine
itself, imho.

I suggest using the ViewHelpers I chose to include in
the decoupled Fluid plus a handful of those from VHS
which deal purely with structures. The rest should be
shipped in a package that fits the product they target.
This means shipping one CMS package of ViewHelpers
which is perfect for generating links in CMS - and one
package which can do that but in another framework.

If you wish, call this package `mvc:` as namespace and
plan to allow *this* particular group of ViewHelpers to
be provided by another package.

Use Fluid as a composer dependency and construct a
bridge that connects this to the framework. Then let part
of this bridge be the ViewHelpers belonging to the `mvc:`
scope. Make migrations like Flow already does; str_replace
based replacements of link-generating ViewHelpers, form
renderers etc. or go even further and create a custom View
that automatically redirects these namespaces.

But whatever you do, please consider that Fluid should
be able to work without either CMS or Flow and let that
be the rule of thumb used when judging whether or not
a ViewHelper makes sense in the `f:` namespace.

Thank you :)


More information about the TYPO3-project-typo3v4mvc mailing list