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

[Jigal van Hemert]

Hi,

On 16-6-2014 15:16, Christoph Moeller wrote:
> com/mittwald/posts/650380621683779 I'd like to get some of your opinions
> concerning the current (and future) state of TYPO3 templating approaches.
>
> At the moment, IMHO, there are too many options to implement templates
> and content elements in TYPO3. To name a few, let's start with an

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

Others are provided by a few extensions.

To make marker based templates easier to handle the first solution was 
AutomakeTemplate which inserted the markers for you based on some 
configuration options. Then there was TemplaVoilà which handles 
templates for you, has a point&click mapping tool and changes the page 
module for some features (including a first form of backend layouts).

For Fluid templates quite a few tools are available, mainly to implement 
"missing" functionality. Not too much is missing when you look into it. 
Without too much trouble you make your own content elements by re-using 
existing fields and storing other information in flexforms (data you 
don't need to use to sort, search, etcetera can be stored in flexforms 
without causing problems).

Grid Elements implements "backend layouts" inside content elements (plus 
a lot more), which seem to be the missing functionality to implement 
things like structural content elements (a content element which 
contains the column structure).


> TemplaVoila, as a very complex extension, has had its era - which is
> over now - and leaves many customers with a pile of problems. This, on
> top of the 6.2 upgrade chores, makes many of our (probably any
> agencies') customers think about the long-term cost implications of
> running TYPO3 for complex sites.

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?

> But unfortunately, from time to time the maintainers of some essential
> extensions leave their projects for whatever reasons. Let's stick to the
> TV example, or take Dmitry's feelings towards RealURL. Whenever I asked
> my employees what they disliked most about TYPO3 during the last couple
> of months, the No.1 answer was "stability and compatibility issues with
> essential low-level extensions (RealURL, TV, GE, ...)". In other words,
> it takes a huge amount of time to dig through forge, web, github,
> whatever to find out how to get something essential up and running in a
> new project using the latest stable TYPO3 core. Before you ask, we're
> giving back most of the workarounds and patches to the authors of the
> respective extensions, of course, and things get better all the time.
> But choosing the right approach, in general, used to be much easier, and
> that's what I think needs to be thoroughly re-thought.

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

> How shall the TYPO3 project as a whole cope with this? Should the TYPO3
> association take influence and sponsor the development of _the_
> templating feature-set to be included in future core versions? Should
> the existing extension authors be asked to cooperate, e.g. by sponsoring
> templating code sprints? Or should this be "ignored" as it is, and let
> the broad masses decide which approach "wins" in the long run (until it
> is abandoned, again)?

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.

-- 
Jigal van Hemert
TYPO3 CMS Active Contributor

TYPO3 .... inspiring people to share!
Get involved: typo3.org