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)

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.