gistfile1.md

5. It's a jungle up there

So now we have no shipped preferentially treated extensions and we lack some way of distributing these. We already have TER and it works wonderfully (but could use a performance checkup). But what TER doesn't have is an official way to indicate that an extension is worth while; a favourite of the community proven to add value. Twitter has the "verified" badge, Apple's App store has the "Featured Apps". TER has a download count and graph which by the way lacks a time scale.

Why don't we introduce a "recommended" and/or "official" flag on TER? Allow such extensions to be listed specially. Raise them as top priority for suggestions. Ship the core extensions from our Swiss army knife as "official" extensions. And let the community decide which ones will get that distinction; not some arbitrary number hits from an Apache log (sincerely, no offence! I realise exactly why the solution is the way it is and I respect it! I only wish to make it better).

There's another perspective here. It's almost a tradition in TYPO3 that if XYZ does not fit our exact intention, we go ahead and roll our own. If we got around this and were able to pipe efforts into improving existing solutions I am certain we could all benefit. The examples are plenty. I don't mean to appear arrogant or hipster about this, but again: in my experience FluidTYPO3 and before that, FED, were first movers - later on joined by other alternatives like Gridelements and DCE (the former of which is at least planning to adopt the principles of Flux). This is nothing personal against those projects or their teams but they're solving the same problem already solved by FluidTYPO3. But they all make the same mistake of not relying on convention-over-configuration and not fully utilising the powers given to us through Extbase. If these efforts had gone in one direction instead, imagine where we could have been now?

So the second perspective is: having a way to selectively recommend extensions might encourage the pooling of efforts into those extensions. I hope FluidTYPO3 to be among those selectively recommended, but that's up to the community. But I digress into meta - ever so slightly.

(taken from https://fluidtypo3.org/blog/news/open-letter-call-for-conventions.html)

Just for the record: When Gridelements was created in early 2011, there was no existing Flux or Fluidcontent to be improved. Even when GE was released to the TER for the first time there was no Flux around yet. And there are good reasons, why we did not have Gridelements based on Extbase.

While "convention over configuration" might be a good idea and Fluid together with the VHS view helpers works like a charm in the frontend, the additional Fluid layer you created to configure old school flexforms IMHO still is questionable. Gridelements will have a dataprovider to enable Flux users to provide grid layouts based on Flux though, so people don't have to decide between the solutions and can use the best of both approaches without conflicts.

After all: These are the reasons, why we went into the same direction but used another path to get there. IMHO this is the good thing about an Open Source product providing a complex but solid API, that you are not forced to do it in a certain way, but are free of choice.

To second this conversation: At the end its all about communication and thriving to find a good way to innovate.

On the subject of Fluid and Flux: My vision for Fluid. The idea of DataProviders is fine but the problem is a different one - namely to have a shared approach to embedding metadata. It is incorrect to approach this as a question of flexforms vs. TCA. Flux does both of those when used correctly.

Jo, you spoke about a session to determine a possible future for a nested content model in TYPO3. I'd just mention here that Flux already serves this exact purpose. I furthermore have the idea for a new TCA field type which contains grid definitions exclusively. Of course written in a way that is able to consume multiple types of inputs. Again, Flux's PHP and TS APIs make perfect sense for that.

Flux can be your DataProvider and it doesn't have to be used as ViewHelpers. To quote myself:

It's almost a tradition in TYPO3 that if XYZ does not fit our exact intention, we go ahead and roll our own.

With Flux I tried to not roll our own but make an API/interoperability for TCA that allows multiple sources to be consumed. IMHO this is a better approach than your "just write TCA" preference. The idea here is portability - TCA is the opposite of portable.

Like the article says, Flux has transparent APIs for TS, PHP and Fluid. Some apply in any framework, some only apply in TYPO3 (so far) but the essence is: it has the APIs that could work in other frameworks than TYPO3. But that's not really the point of this article - it's more two new discussions:

1. Should we have a shared API for embedding metadata in templates? I of course say yes.
2. Should Flux be this API? I say it could be and that there are many reasons aside from just Fluid, for doing so.

I'm happy to discuss either one in the vision article but it really (also) should be discussed on internal gatherings.

When you quote me about "just writing TCA" you should mention that this always came together with: We need an easy to use interface to create TCA for custom content elements automatically. There once was the extension kickstarter to do that, but it was far from being as comfortable as I would have liked it to be.

"It's almost a tradition in TYPO3 that if XYZ does not fit our exact intention, we go ahead and roll our own." - Which is exactly what you did for quite some time, because you favor i.e. "convention over configuration", Extbase, Fluid and Flexforms - So now telling other people that they wasted a lot of time because they didn't follow your approach but someone else's or the core instead does not help that much.

BTW: Please correct me if I'm wrong, but the TCA field type for grid definitions pretty much sounds like another Flexform field to me. As far as I understood, the core team on the other hand is trying to get rid of flexforms as far as possible.

We should really discuss stuff like that live and at the appropriate places, which IMHO would be Developer Days, User Experience Week and/or Core sprints. For the "Structured Content Elements" - and only for those, not for custom content, FCE, DCE or however you might call them - there is a blue print and a connected issue in the tracker, which can serve as a base for that discussion.
https://forge.typo3.org/issues/67134

This may be a personal flaw of mine, but I am starting to take a bit of offence here - feeling misrepresented.

Before Flux was called Flux, it was called fed. This one existed in early May 2011 and before that on git, and before that some of the code related to metadata in templates was in wildside_extbase. So it is not correct that there was no solution to use when gridelements was created. FED was officially released to TER in May 2011. Gridelements came around in September 2011. In the case of DCE, that came around in 2012. True, the first iteration of child content support in FED wasn't exactly top notch, but part of the reason for that is that nobody pushed for it to change - they just created their own. Like the chronology demonstrates. You can state many reasons for not using Flux (when it was called FED) but chronology and "no prior art" are not valid reasons here.

At the time FED received its nested content feature, the only existing solution of noteriety was TemplaVoila and you may or may not be aware, but I did ask about and offered to assist with Fluid support for TV before I considered rolling my own.

So now telling other people that they wasted a lot of time because they didn't follow your approach but someone else's or the core instead does not help that much.

I'm saying it mainly because they didn't follow the core's Extbase approach with Views and Controllers and it is the lack of respect for these patterns that are the main problem, causing our solutions to be grossly incompatible. Convention over configuration is not my idea. I am simply adhering to the ideas about convention that come from the core via Extbase/Fluid.

To be fair: DCE is currently using controllers which is great. It is nicely prepared and integrated; Views replaceable, can be rendered with sub-request dispatching, supports signals, avoiding all XCLASS etc. - definitely heading in the right direction there.

BTW: Please correct me if I'm wrong, but the TCA field type for grid definitions pretty much sounds like another Flexform field to me.

You need to have more imagination than to just assume the absolute hackiest solution is the one that will and must be chosen. It could be an inline edited relational record field. It could simply be boilerplate activated like sys_category relations. Or EAV.

And you know there are legacy reasons why FlexForms were chosen and are still used. You may think the right thing to do is to avoid them - I on the other hand think there should be an effort to re-implement them as relational records or (I hate to suggest this) maybe even an EAV, for performance reasons.

But it might be easier to just create it than to design it by committee. The requirements are quite clear (and they are exactly what you have put into that forge issue, btw). Along with some of the other ideas I have about taking advantage of existing conventions to give things a more drop-in-and-detect style behavior; e.g. automatically detected content and page templates via template paths configured for sysext frontend itself, with custom controllers supported if detected. Which pretty much requires a solution for embedded metadata. Which I've pretty much already decoupled from Flux - https://github.com/NamelessCoder/TYPO3.Fluid.Flux. I am very much already working on all of this.

The Q is: will I finish the POC this week or the week after that? :)

No offense intended, so keep calm and flush cashes. :-) The concept of Gridelements dates back to the User Experience Week in 2009, has been partly implemented into the page module of 4.5 as Backend Layouts by Steffen Kamper and myself in 2010 and then finally been applied to content as well in 2011.

One of the reasons why we did not consider FED for the content level was the sponsor's clear decision against Extbase which was a PITA back then. Since there is no need for Extbase to improve the page module of the core anyway, we were able to implement stuff with the existing hooks. In the latest 7.x compatibility branch I was even able to remove the datahandler hooks. So implementing it would be easily done by moving the draw item and page renderer methods from the hooks to the core. Still without any MVC framework overhead around.

But instead of rushing that approach into the code base of CMS, what we are asking for in the blue print is not to start with prototyping but with a clean and precisely defined plan before any line of code gets written. And therefor I kindly ask you to reconsider what you actually wrote in your post: Don't reinvent already existing things just because they don't fit your expectations in some points but really join forces instead and lets tackle that stuff together. So it will fulfill everybody's expectations in the end.

Next up would be the session at the developer days. Until then we can improve the blue print and finalize the one for the list module, since this will need to deal with nested structures as well.

Have a good night.