NamelessCoder

simple open+close non-active tag in root context:

• <tag>x</tag>

simple open+close non-active tag with hardcoded attribute in root context:

• <tag attr="foo">x</tag>

simple open+close non-active tag with object accessor attribute value in root context:

NamelessCoder

Idea: Content Types API for TYPO3

This brief aims to outline an idea I had for TYPO3: an API for registering various content types that can then be used by editors. Currently we have a multitude of different ways such content types can be achieved, even with sub-types for plugins and sub-sub-types in the form of Extbase-based plugins.

It would make sense to have a common API for all this.

First part of solution: autoloaded configuration file returning objects

NamelessCoder

The following are examples of new syntax capabilities that will/may become possible if switching Fluid away from regular expression parsing, to a lexer yielding a stream of tokens that can then be parsed to become a Fluid "syntax tree".

The lexer is a research project, in progress, but nearing completion. I plan to combine it with a "streaming node parser" which only processes the tokens it must, as opposed to processing everything like the current Fluid parser does.

Some of these already work - most of them are being researched

NamelessCoder

Dear reader,

This is a small article to explain the vision and strategy for replacing the TYPO3 caches with a PSR-6 implementation. In the article I will explain the background of caches in TYPO3, the similarity it has to the PSR-6 standard, and the strategy for replacing such a vital component with as few problems as possible.

Current status: framework is almost entirely replaced and the vision described here is being prepared as merge requests.

Note, I have intentionally put the references to chosen framework last in this article. Please read the article before you check the foot note references - that way you will keep in mind all my decisions when reading the capabilities of the

NamelessCoder

<?php

/*
 * Demonstrates how to configure `namelesscoder/typo3-cms-multilevel-cache` for
 * added L1 (runtime) and L2 (memcached) caches on existing database-backed caches.
 *
 * Tip: if your site changes frequently, consider assigning a low expiration time
 * on the "default_memcached" cache configuration.
 */

NamelessCoder

This mini-article describes the methods of dependency injection, what each method implies in terms of both performance and simplicity.

1. Constructor injection

---

This method is half manual and quite well known. Declare your classes' dependencies as constructor and pass the dependencies when you construct your instances. This approach completely skips the automation around detection of injections - but performs the best of all methods.

NamelessCoder

Vision: Grid as TCA type for TYPO3

Synopsis

This little gist is an attempt to describe my vision for a nested content / grid feature for TYPO3. It contains a description of the vision I have and relates this vision to the current blueprint and WIP which are available at https://wiki.typo3.org/Blueprints/StructuredContentContainers and https://review.typo3.org/#/c/41936/.

NamelessCoder

<?php

$test = new ArrayIterator(array(1, 2, 3));
$exec = [];

foreach ($test as $l1) {
        $exec[] = 'outer ' . $l1;
        foreach ($test as $l2) {
                $exec[] = 'inner' . $l2;
        }

NamelessCoder

<?php

/**
 * Content Element Definition Provider
 * 
 * Contains methods to either remove/change or add
 * content definitions to the new content wizard
 * and content type selectors.
 * 
 * Same instance is used for removing and adding

NamelessCoder

My vision for TYPO3 content/page integrations

Estimated 15 minute read

Continuing from my vision for Fluid I'd like to describe another vision related to it. Where the first article is mainly about what we could do with the Fluid template engine outside of TYPO3, this article focuses on what we can do with it in TYPO3. It assumes the previous vision was realised.

The vision can be summarised as follows:

> We should have a way to drop-in replace and add content templates, instead of requiring massive amounts of boilerplate configuration/code. And we should have a method for managing nested content which is provided by the core itself.