[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