[TYPO3-english] Gridelements, semantic content and the right strategies

Thomas Skierlo pubtsk1 at pix-pro.eu
Tue Aug 14 13:22:18 CEST 2012


Hi,

I am trying to replace my huge TemplaVoila page template and FCE 
collection by Fluidtemplate and Gridelements, while keeping everything 
semantic and clean. With a responsive layout (like the one from Twitter 
Bootstrap) one problem is an empty column, since floating elements do 
not have a width unless something is included.

Old school solution (ugly and semantically wrong)

<div class="container clearfix">

	<div class="span3 left">&nbsp;</div>

	<div class="span9 right">This columns isn't empty</div>

</div>

the correct markup would be:

<div class="container clearfix">

	<div class="span9 offset3 right">This columns isn't empty</div>

</div>

The correct method can be implemented into the page layout easily and 
straight forward by means of Fluid and nested <f:if> blocks. But when it 
comes to customized content elements, like subgrids, everything is 
getting rather old school. No Fluid at all in Gridelements extension. 
Only Typoscript, which can't really solve my problem like Fluid does.

If I want to build a 3-column subgrid element without empty divs or 
faked content like "&nbsp;" or "onepix.gif", I need a Typoscript monster 
with ugly register usage (exactly like in TV before).


# Gridelements setup

tt_content.gridelements_pi1.20.10.setup
{

	# ID of gridelement

	#  	subGrid_9_3-3-3

	1 < temp.gridelements.defaultGridSetup

	1 {

		columns {

			# colPos ID left column

			0 < .default

			0.stdWrap.ifEmpty.cObject = LOAD_REGISTER

			0.stdWrap.ifEmpty.cObject.leftContentEmpty = 1

			0.required = 1

			0.innerWrap = <div class="span3">|</div>

			# colPos ID center column

			1 < .default

			1.stdWrap.ifEmpty.cObject = LOAD_REGISTER

			1.stdWrap.ifEmpty.cObject.centerContentEmpty = 1

			1.required = 1

			1.innerWrap = <div class="span3">|</div>

			1.innerWrap.if.isFalse = {register:leftContentEmpty}

			1.innerWrap2 = <div class="span3 offset3">|</div>

			1.innerWrap2.if.isTrue = {register:leftContentEmpty}

			# colPos ID right column

			2 < .default

			2.required = 1

			2.innerWrap = <div class="span3">|</div>

			2.innerWrap.if.isFalse = {register:centerContentEmpty}

			2.innerWrap2 = <div class="span3 offset3">|</div>

			2.innerWrap2.if.isTrue = {register:centerContentEmpty}

			2.innerWrap2.if.isFalse = {register:leftContentEmpty}

			2.outerWrap = <div class="span3 offset6">|</div>

			2.outerWrap.if.isTrue = {register:leftContentEmpty}

			2.outerWrap.if.isTrue = {register:centerContentEmpty}

		}

		wrap = <div class="row">|</div>

		wrap2 = <div class="span9">|</div>

		wrap3 = <div class="row">|</div>

	}

}

(Code untested, but probably working)

The core problems are:

 1.

    The center column must know about the content in the left column,
    the right column must know about the content in the center and left
    column -- and, depending on that information, must customize the
    markup. This is no trick at all in Fluid, but it's a nightmare in
    Gridelements. Is there any better way than using LOAD_REGISTER to
    check the availability of content in the direct neighborhood?

 2.

    It seems not to be possible to priorize a column. If I change the
    sequence in Typoscript, register values are not available when
    needed, so I must include my content from left to right.

 3.

    Don't even think about localization (this is no question, but
    currently a fact for gridelements)

This are my technical questions. The next one, which is more important, 
is a more strategic one.

On Forge Gridelements is listed under the TYPO3 4.7 tab. This implies a 
tight relation to the core. According to some messages from the Forge 
issue tracker of gridelements it even might slide into the core -- as a 
sysext. For me, this impression was the major reason to use this extension.

My personal history of templating with TYPO3 startet with 
Automaketemplate and markers. After I understood this concept I learned 
that TemplaVoila was the much better approach and I started all over 
again. Now I am feeling that it's time to move on, since TV days might 
be over shortly. TV always delivered what I expected and it allowed me 
to avoid various community extensions by using it's mighty FCE concept. 
While working with TYPO3 I learned one thing: The best extensions are 
the ones which are not installed.

What I am missing is any kind of information about the RIGHT strategy 
for future TYPO3 evolution. Is there any? Like: "Use ExtBase/Fluid and 
Gridelements. This ensures that you will not have to start over again in 
12 month". In old TV days there was an additional extension to TV, the 
TV Framework. I never needed that, because I understood TV very well and 
did not need any further assistance by an extension for an extension. 
Today I hear about ExtBase, Fluid, Gridelements and FED/Flux. Which of 
them should I use to survive the next 2 major releases? Or should I 
return to the good old markers? Even Indexed_Search from 4.7.3 still 
uses them, and it's new, Fluid based templates are non working 
experimental ones from the very first stadium and without any useful 
documentation.

Besides the more technical questions from above I am interested in 
strategies -- and I truly believe that I'm not the only one. I am not 
talking about strategies for extension developers, I mean strategies for 
TYPO3 integrators.

TIA for all input

Thomas



More information about the TYPO3-english mailing list