[TYPO3-english] worried about 4.x (6.x)
Kay Strobach
typo3 at kay-strobach.de
Mon Oct 15 09:23:35 CEST 2012
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
>
--
http://www.kay-strobach.de - Open Source Rocks
TYPO3 .... inspiring people to share!
Get involved: http://typo3.org
Answer was useful - feel free to donate:
-
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2
- https://flattr.com/profile/kaystrobach
More information about the TYPO3-english
mailing list