[TYPO3-english] worried about 4.x (6.x)
Thomas Skierlo
pubtsk1 at pix-pro.eu
Mon Oct 15 11:32:09 CEST 2012
Hello Kai,
I can't answer your question because my insight in the classic way of
doing things in TYPO3 core is not sufficient. I use irre as well as
flexforms, but I'm not sure if they are "good" or "bad". Basically I see
multi-content objects for two purposes:
1. )
Structural elements: Like a n-column grid. This is covered partly by the
current Gridelements extension. Problem is, that it doesn't offer a way
to make the content semantic, when it comes to an empty column (Either
because the editor wants to have one column empty or because the content
isn't entered yet).
Sample 2-column grid element (like Twitter/Bootstrap):
<div class="row">
<div class="span3">
Here goes some content
</div>
<div class="span4">
Here goes some other content
</div>
</div>
Now imagine the first column empty: Correct markup would look different:
<div class="row">
<div class="span4 offset3">
Here goes some other content
</div>
</div>
To create this markup, one needs to know about the content of column 1
when it comes to the rendering of column 2. I was trying hard, but
couldn't find a way to do it in Gridelements, not even with register usage.
2. )
Special Elements: Like tabbed content
Sample markup:
<ul class="nav nav-tabs" id="myTab">
<li class="active"><a href="#home">Home</a></li>
<li><a href="#profile">Profile</a></li>
</ul>
<div class="tab-content">
<div class="tab-pane active" id="home">...</div>
<div class="tab-pane" id="profile">...</div>
</div>
Again this needs awareness of all (sub)content elements when it comes to
the rendering of the <ul> and/or <div> sections, which depend on one
another. TV solves this by allowing elements which are not mapped, but
which are available when it comes to rendering of other fields. TV is
using Flexforms for this, but I have heard rumors that "Flexforms might
be bad"???
One clear must-have are sections. Define a container to pull in any
content element you like and tell the container how to handle it's
children. I thing, that's the real killer-feature of TV -- it can handle
sections. An (older) extension "wec_contentelements" tried to address
this too, but it doesn't seem to be alive any more. When it was
introduced in 2010, some critics didn't like the idea of "private" TS
extensions, like the "section" object. On the other hand, with an object
like this the filesystem could be used, and finished FCEs would be
movable to other installations easily.
Fluid (not necessarily extbase) would be ideal for both purposes, as
long as it can be used for the whole multi-content element, and not only
for each individual sub-content. Besides that Fluid is perfect for
sections. Now add your own, private ViewHelper -- and the world would be
a much better one, at least in terms of ECMS .
The best solution would be a multi-content element which is as basic as
possible, but which should be available for both worlds, pure Typoscript
or extbase. FLUIDTEMPLATE usage would be perfect first step. Currently
there are many major players who try to address "multiple-content". All
of them have to take care of sections, versioning, localizations,
copy&paste, visibility, moving around - all the little nitty-gritty
needed. How much easier would life be for them if there would be a core
way to handle that?
Regards,
Thomas Skierlo
> Hello Thomas,
>
> do you think it would be enough to have some flexforms to define be
> input with irre (like tv) and related templates in fluid?
>
> This way we could define:
>
> a) the flexform to get the input fields you need
> b) one ore more rendering definitions for the data of the flexform
>
> addition to b) as fluid can render complex objects this could be a way
> to go, as this would allow people to built "custom" fce's.
>
> Additionally this can be automated lateron, so that we do not need any
> programming at all (similar to old extensionmanager) :D
>
> Regards
> Kay
>
> Am 12.10.2012 15:17, schrieb Thomas Skierlo:
>
More information about the TYPO3-english
mailing list