[TYPO3-dev] Once again - the future of TYPO3 templating/grid approaches

[Christoph Moeller]

Hi Jigal,

> There are currently actually two templating systems provided by the core:
> - marker based (the familiar ###MARKER_NAME### stuff) in TypoScript 
> handled by the TEMPLATE object
> - fluid based, in TypoScript handled by the FLUIDTEMPLATE object

which are great but of course only cover the frontend development part, not the useability for editors.
This actually was the USP of TV and is now partly reimplemented by GE.

> Others are provided by a few extensions.

Which is great, as well. But things regularly fall apart when upgrading the core and the used extensions haven't been adapted yet. Again, no offense towards the extension authors, but it shows the structural problem. In the non-involved world out there, this is perceived as "better don't upgrade TYPO3, or things will break". My experience, yours might differ.

> To make marker based templates...
> For Fluid templates ...
> Grid Elements ...

Why not take the best out of all these worlds (extensions) and combine that to a "minimum viable product" approach that helps TYPO3 excel in terms of backend editing and frontend development possibilities? I don't think that a CMS can live without both excellent FE development and BE editing concepts and solid URL scheming in 2014. 

> The problem is more that you want to bet on a certain solution which 
> often depends on single author or a company to maintain it for free. 
> Perhaps if an extension becomes more important for a larger group this 
> group should try to activate a team for the support and maintenance of 
> this -- mission critical -- tool?

Sure, would be great if that worked. What's more mission critical than FE development, BE editing and control over the generated URLs? Everybody building TYPO3 sites needs that to be rock-solid in my opinion. It's easy in any other CMS product, but overly hard in TYPO3 at the moment. Let's make that better.

> What is essential for you may not be essential for others. If you use 
> CoolURI instead of RealURL, create your website without TemplaVoilà and 
> Gridelements this list of essential extensions suddenly becomes quite 
> different.
> This functionality is not included in the core for a number of reasons:
> - time available for core developers
> - keep the core lean, because not everybody wants the same solution
> - extensions can be updated a lot faster

Sure, and I second that. But why is the new FORM element a sysext then? Where should we draw the line between core and extensions? 
I think stuff that everybody needs, such as a robust template/grid engine for FE output and BE editing, and maybe even URL routing, belongs to the core. And these essential features need to be rock-solid.

NEOS and CMS are quite different here. For NEOS, I totally agree - keep bloat out at all price, since it's rather a CMS package on top of full-blown FLOW web apps. But v6.x CMS is primarily a full-blown web CMS, needing all the expected solid web CMS functionality. And that includes state-of-the-art templating and editing capabilities.

> There is no single "right" solution. Diversity is actually a good thing 
> here. Again, if you make money with a free solution you might need to 
> invest in the future of that solution.

Looking forward to investing in the right approach :)

Cheers and thanks, Jigal
Chris