NamelessCoder

plugin.tx_fluidbootstraptheme.view >
plugin.tx_fluidbootstraptheme.view.templateRootPaths.15 = EXT:fluidbootstraptheme/Resources/Private/Templates/
plugin.tx_fluidbootstraptheme.view.overlays.fluidtypo3org.templateRootPath = EXT:fluidtypo3org/Resources/Private/Overrides/Templates/
plugin.tx_fluidbootstraptheme.view.partialRootPaths.10 = EXT:fluidbootstraptheme/Resources/Private/Partials/
plugin.tx_fluidbootstraptheme.view.layoutRootPaths.10 = EXT:fluidbootstraptheme/Resources/Private/Layouts/

# OR:

plugin.tx_fluidbootstraptheme.view >
plugin.tx_fluidbootstraptheme.view.templateRootPaths.10 = EXT:fluidbootstraptheme/Resources/Private/Templates/

NamelessCoder

Introduction - please read!

I wrote this back in October of 2012 so please forgive those references to facts that are no longer relevant. I'd like to add that this isn't a personal attack although I realise (as I also state in the letter) that it is quite likely some may be offended. Offence is not my purpose here - I only have the community's best interests in mind although this letter is written as a personal opinion based on considerable experience.

Please accept it in the spirit it was written: for the common good.

NamelessCoder

<f:if condition="0" else="0 === FALSE" />
<f:if condition="1" then="1 === TRUE" />
<f:if condition="(0)" else="(0) === FALSE" />
<f:if condition="(1)" then="(1) === TRUE" />
<f:if condition="0 && 0" else="0 && 0 === FALSE" />
<f:if condition="0 || 0" else="0 || 0 === FALSE" />
<f:if condition="1 && 0" else="1 && 0 === FALSE" />
<f:if condition="0 && 1" else="0 && 1 === FALSE" />
<f:if condition="1 || 0" then="1 || 0 === TRUE" />
<f:if condition="0 || 1" then="0 || 1 === TRUE" />

NamelessCoder

My vision for Fluid

Estimated 15-20 minute read. Many perspectives included.

As some of you know: a while back I created a standalone version of the Fluid template engine and started banging the Twitter drums a bit about it. Since then, I have begun work on making this standalone version of Fluid a proper composer dependency of TYPO3. While this may not seem like a high priority task, it has far reaching implications in the vision I have for the future of Fluid.

Right from the start the goal has been not just to decouple Fluid from TYPO3/Flow - it has just as much been about extending and modernising the base Fluid so many, many adaptations become possible without modifying the engine itself. Humble brag: I spent a great amount of effort on making these things possible and the result is that by modifying implementations of classes that Fluid uses, one is able to modify nearly every aspect of how Fluid is processed - down to which arguments a ViewHelper supports and adding virtual

NamelessCoder

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.

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.

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

<?php

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

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

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

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.