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

[Jigal van Hemert]

Hi,

On 16-6-2014 17:42, Christoph Moeller wrote:
>> 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.

Templating engines are meant for presenting data (combining elements 
from a template with content to create output for frontend or backend).

The usability for editors you mention are things like drag&drop, backend 
layouts (also inside content elements as implemented by grid elements), 
etcetera.

> 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.

In many cases extensions "fell apart" because extensions didn't stop 
using deprecated features until they were finally removed.
A few examples:
- a class autoloader was introduced in TYPO3 4.3. In 6.0 it was changed 
for the use of namespaces, and the core and extensions had to rely on 
that feature instead of using require_once() to load a class. Quite a 
few extensions still didn't use the autoloader and started to cause 
fatal errors.
- a new mail API based on SwitftMailer was introduced in TYPO3 4.5. 
There was a handler in place to convert calls to deprecated function 
into calls to the new mail API. Besides information in the form of 
publications the authors of some extensions which extensively use mail 
functions were contacted directly with code examples on how to support 
both the old and the new functions. It was not until the old functions 
were actually removed and the extensions started to fail that some of 
these extensions were finally updated.
- the XCLASS functionality was changed to make it more flexible. In 
most, if not all cases, it required only an extra line of code to make 
it compatible with both the old and the new situation. You can guess 
what happened.

There is a beta phase in the development of the core (in the case of 6.2 
that was rather long too) and during that time no new features are 
introduced (except things that are clearly stated at the start of the 
beta phase) and the API isn't changed. This is a perfect time for 
extension authors and people for whom these extensions are mission 
critical to test if the extensions are compatible.

How can the TYPO3 CMS universe cause this to happen? It would be so nice 
to simply upgrade extensions, upgrade core and know that in almost any 
installation things just work.

> 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.

- it's very hard to reach a consensus what the absolutely necessary 
features are
- it's very hard to reach a consensus on the best way to implement this

To use one of the features you mention as an example: URL scheming.
There are so many variations of what is considered the "right" URL 
scheme. In the past the core had one extra scheme included 
(simulateStatic), but many people wanted other solutions. Now the core 
only provides the means (hooks, etcetera) for extensions to influence 
the URL scheme. You can decide whether RealURL, coolUri, simulateStatic 
or whatever solution is good for your situation.

>> 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.

You probably don't want to hear this, but how many did offer support in 
any way to the developers of those mission critical extensions? If 150 
companies, integrators, agencies would hire an extension developer(team) 
for one hour a month there would already be a full time position to 
ensure the further develop and support of that extension.

> 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.

Well, get a few people together who also feel that it's very important 
to them. Collect the requirements from the community. Organize an event 
where you collect experts in usability, interaction, design and let them 
design how this should work for most of the users of TYPO3 CMS. Then 
collect a team of developers (not the hardest part as most want to 
improve core functionality).

> Sure, and I second that. But why is the new FORM element a sysext then?

It was a replacement for the old one (a simple form should be present). 
It's quite old and a bit of the background can be found at:
https://forge.typo3.org/news/91

> 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.

Currently the goal is: the core should provide basic functionality to 
make it possible to create a website and the content. The rest can be 
provided by extensions. The core provides an API, hooks, signal/slots, 
etcetera to facilitate functionality of those extensions.

> 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.

Funny that you mention this. TYPO3 (CMS) started as framework with CMS 
functionality on top of that. You can still see that we have a system 
extension 'cms'. Later on it became apparent that TYPO3 would not be 
anything else but a CMS, so this extension became mandatory (this was a 
very long time ago :-) ).

Neos uses a similar approach with a framework part (Flow) and several 
packages (content repository, TypoScript, etcetera). Flow is more a PHP 
framework than a specific CMS framework, so it's more likely that the 
separate packages will stay separate in the future.

-- 
Jigal van Hemert
TYPO3 CMS Active Contributor

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