[TYPO3-english] worried about 4.x (6.x)

[Tobias Liegl]

Hey Thomas, Kay,

I think you should have a look at the Dynamic Content Elements (DCE) 
Extension. This should be what you are searching for:

http://typo3.org/extensions/repository/view/dce

You can create new elements in the TYPO3 Backend and style them with 
Fluid (also in the Backend) - and without the need to use Templavoila.

Regards,
Tobi


Am 15.10.12 09:23, schrieb Kay Strobach:
> 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:
>> Hi,
>>
>> spoiler ahead - apologies for the long text -- but it has to be this
>> way. Don't read if you don't have the time.
>>
>> it's perfectly clear that any thread like this must get the emotions
>> boiling, because one party is blaming the other for not taking the right
>> decisions or doing a bad job. I am quite sure that all developers are
>> working hard to improve the technology and to get TYPO3 to the next
>> level. This list, as well as the product TYPO3, wouldn't exist, if many
>> devoted people wouldn't have done a perfect job for many, many years --
>> and are still doing today.
>>
>> To get an understanding of the integrator side please listen to my
>> personal history of TYPO3 usage. I started to learn TYPO3 basics in
>> 2008, building up a first, small, dev-site, using marker based
>> templates. While I did that I noticed the limitations, and that there
>> was another way to do things, which might be more powerful. After
>> reading "Futuristic template building" I instantly knew that this was
>> the way to go in future. Only TV seems to offer a way that one
>> (sub)content element is aware of other content elements within the same
>> data structure. You definitely need something like this to create FCEs
>> like tabs or accordions or even grid-elements with one empty column,
>> which must be handled differently to columns which aren't empty if the
>> markup should be semantic. From there on I lived with the CON aspect of
>> elements not being movable to other installations easily. Except this I
>> never reached any limits with TV.
>>
>> At that time the first rumors came up about a new TYPO3, which should be
>> developed in parallel to the existing 4.x branch and which should offer
>> a migration path for older versions once finished. A Manifesto, which is
>> much more than a letter of intent, was ensuring that I took the right
>> decision with TYPO3, because I noticed that people did care about
>> migration paths. At that very moment one alternative could have been to
>> build up a perfectly new CMS, which no migration paths at all. People
>> could have moved on with v. 4.x and than face a new learning curve for
>> the new technology, once this is ready for production.
>>
>> At that time I definitely preferred the Manifesto way, because I felt
>> that old-school ext.developers would stop further development and
>> support for "old" extensions instantly if all work would be lost after a
>> year or two. Even with the Manifesto still in place many of them stopped
>> support for their old extensions, which directly leads to the current
>> situation of TYPO3 being the best car in the world, with only a lack of
>> 2 tires. Everybody involved is perfectly sure that it will be the best
>> car on the marked again if someone would build the 2 tires missing. One
>> of the two tires missing is a working replacement for TV. Now you might
>> say: Hey, we gave you Extbase and Fluid, a Fluidtemplate object - and
>> FCE-killers like gridelements oder FED/Flux from the community. At least
>> I heard those words a couple of times, so I decided to stop my
>> commercial work a couple of month ago and move on to the new templating.
>>
>> The FLUIDTEMPLATE object works as a direct replacement of the TV page
>> template. Migration can be done withing a day without loosing anything.
>> BON. Only thing which is missing is a decent way to get some constants
>> into the Fluidtemplate, without defining them as variables. I asked for
>> help on the lists last month, but never got a hint or a solution.
>> Anyhow: Consider the page template done by means of Fluidtemplate. 100%
>> TV replacement. And even fun to do.
>>
>> Next in line was the "Grid" which modern, semantic and responsive
>> layouts like Twitter/Bootstrap need -- as well as all websites with a
>> modern look and feel. So I installed the first so called FCE killer:
>> Gridelements. With this extension one can build multicolumn content
>> elements which do their job, but since every column is handled
>> individually it seems not to be possible to manipulate content of one
>> column depending on the content of another column. Tried to find help on
>> the lists, but didn't get any. Tried to offer my help to one of the team
>> members (I tried it only once by email), but didn't get any reaction.
>> When it comes down to real grid-elements (=fixed multi-column
>> structures), I would give the current Gridelements ext. a 80% as TV
>> replacement, the BE view get's a 120%.
>>
>> My next try was to use Gridelements for a real FCE: An accordion. To
>> build up the 2-tier markup you either have to visit the database
>> multiple times (which is bad) and use another custom element (accordion
>> content) instead of "any content element" (which isn't good either) OR
>> you will not succeed. Sections are not supported, and sections are
>> needed to build some advanced FCEs. Current trunk version would get a
>> 20% as TV-FCE replacement from me. Spent 3 weeks with gridelements. Work
>> still unfinished.
>>
>> Next was FED/Flux: Did like the possibilities, but didn't like the
>> general concept from the very beginning. Wrapping private directives my
>> IDE doesn't understand around Fluid directives my IDE doesn't know
>> either, kind of parser for a parser. Started with the page template
>> following the detailed explanations on the very good and helpful website
>> -- but didn't succeed. No output at all except fatals. Maybe I've only
>> installed a broken version from trunk? Don't know. Spent 3 or 4 days
>> until I moved on to getting the job done by an own extbase extension. I
>> never loved the idea of "writing an extension" just to get a custom
>> content element -- in my naive thinking this basic scaffolding should be
>> part of the CMS base functionality.
>>
>> Now, after spending a couple of month with extbase I still didn't
>> succeed in building my own content elements. Had issues with caching and
>> localization. Tried to analyze other, basic, extbase extensions from TER
>> to get a way to handle BE modules, but didn't find many suitable for my
>> learning. I am quite sure that it's possible to do the job with extbase,
>> but once you got stuck the time needed to get a step further is much too
>> long to still behave responsible.
>>
>> Another possible player might be "WEC content elements" way back from
>> 2010. It addresses some of my current problems and it supports sections.
>> But the project is not available on forge, has no issue tracker and
>> seems not to be active any more. Didn't try it. Was getting too tired
>> trying stuff.
>>
>> During the last days I took a first look at Typo3 Neos. My primary
>> aspect of this first look was to find deeper similarities to extbase
>> from the current 4.x versions. My first impression is that it might be
>> much easier to start all over again without any extbase knowledge from
>> 4.x, except DDD and MVC principles. At least Fluid looks similar.
>> Awareness of content seems to be built-in. Very promising. But: Not
>> ready for production. Can learn it today, but wouldn't use it for a
>> while for real life projects. If I now move on with my current problems
>> to Neos, I still have no solutions for them in the 4.x range. Besides
>> that: Does anybody still believe in any later migration path? From 6 to
>> Neos? I don't. Typoscript2 has not similarities with the current
>> Typoscript and markers are (luckily) unknown. So we might be in that
>> very situation which would have been the only alternative in the early
>> times of the Manifesto.
>>
>> One thing seems to be pretty clear: There's no room for TV in the Neos
>> world, so my motivation to get it to version 6.x wouldn't be too big,
>> since it will be the final -- call it burial - level. On the other hand,
>> there is no current alternative. At least I couldn't find any. Now
>> substitute TV with any other important extension name, and you'll get
>> closer to the real problem we are all facing today.
>>
>> Please don't be too harsh with people getting nervous about TYPO3.
>> Better listen to their words by filtering out any emotions which might
>> spoil the real meaning. Many people did invest a fortune to "understand"
>> TYPO3. To learn, how it can be used to even build up an own business. If
>> they feel, that their personal invest is taken at risk, they are getting
>> nervous. Some will tell you about that feelings, others will not, just
>> moving on to other products silently.
>>
>> I would have loved to participate much more in the community, either by
>> member fees or personal labor. Just imagine my 4-month struggle with a
>> working FCE replacement, which isn't been over yet. What a waste of
>> time, one might think. Would love to give back my solution to the
>> community, but couldn't find any. Would love to give my time to the
>> community, but can't spare any because I have to keep up with new
>> techniques.
>>
>> What I am missing is a TYPO3 team "above" the core team -- let's call
>> them "Big Picture Ensurers", "Keepers of Usability" or "Tamers of
>> Scientists" (especially the last task is often the most unpleasant, but
>> mostly needed one). Is the current official version of TYPO3 INCLUDING
>> mission critical community extensions still able to build up a modern,
>> 2012 website? Is it still a suitable base for integrators, or has it
>> moved to a state which can only be handled by developers? If so,
>> wouldn't it be fair to share this very important information? And
>> please, don't mention 4.5LTS. It is not really a long term solution.
>> What might help with the problems might be another LTS commitment. At
>> least this worked better than the Manifesto :-)
>>
>> I'm quite sure that extbase/Fluid is excellent. Probably FED/Flux is
>> excellent too. Why not combine both into one, or even add Gridelements,
>> for BE presentation? I didn't find "my" solution in any part of the
>> active players group.
>>
>> Why don't give the outside world a break by slowing down any further
>> development of new technology before the old one had a decent chance to
>> keep up? At least until all basic scaffolding can be done with on-board
>> tools or system extensions. Until that time only good old TemplaVoila
>> seems to be able to give all the answers needed when it comes to templates.
>>
>> Can't imagine that I'm the only one with this FCE problem today. Where
>> can I join any kind of FCE task force or at least get in touch with
>> others struggling with the same beast right now?
>>
>> Would have loved to post my words outside an indexed world of search
>> engines, but for people like me this list is the only place available
>> for discussions of essential matter. I spent too much time with TYPO3 to
>> have any defeatist motives -- which would take all my personal invest at
>> the risk of total loss.
>>
>> Kind regards,
>>
>> Thomas Skierlo
>>
>
>