[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"> </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 " " 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