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

[Claus Due]

> We don't want implementations for Fluid (in CMS and Flow) to drift
> apart - especially syntax-wise/seminatically. So for instance a
> f:form.checkbox VH should work the same way in both products

Fair enough user experience concern.

> Therefore it was my intention to make them as in independent of
> the product as possible, so we can maintain them centrally.

Think decoupling. Take the fact that both CMS and Flow want the
same API of ViewHelpers and act accordingly:

* Create a package that contains this API as a bridge and make it
  possible to use this package in both frameworks.
* Make said package for example use a unified interface for form
  components, messages, validations etc.
* But don't put that into the template engine. It is a framework
  feature and as such, should be provided by the framework.

But I still recommend extreme caution here. I advise to not make
too many decisions about the exact nature of forms and to not
try to make those form practices apply to every Fluid, including
the standalone version. Assume it will be created and released.

> Think of the user again here: A user will be confused if the same
> VH works differently in Flow/CMS.

I'd take the liberty of arguing: would it confuse them more than that
ViewHelper being there in one system but not the other?

> [...] Some services could even be shipped with standalone Fluid,
> like some hashing service.

For a second think completely rational:

Should a template engine really be providing a form token hashing
mechanism for securing forms, a service to handle messaging?

Should it really be dictating with strong interfaces how exactly all
usages of forms should be in every framework that might utilise
Fluid as a rendering engine?

I'd say no and I don't mind repeating it a few more times ;)

> The more we provide strong defaults with standalone Fluid, the
> better maintainability will be for all products using Fluid.

Wrong, sorry, but that's just wrong.

The right version is: the smaller the Fluid core is and the fewer
choices this template engine makes about everything framework
specific the easier it will be to maintain *Fluid*.

What you are thinking about in your argument is making it easier
to maintain the CMS and Flow implementations of Fluid - not Fluid
itself.

Let us not force our decisions about MVC, forms, controllers,
validation, messaging, security etc. onto everyone else. We can
provide a secondary tool that does this "the TYPO3 way" but we
so very much should not try to force others to follow this way.