What is "Fluid powered TYPO3" and is it recommended?
Asked Answered
N

2

8

What is to be understood by "Fluid powered TYPO3" (as stated by http://fedext.net/) and what are its benefits for the integration?

Are there other modern templating approaches for TYPO3 6.x that would be best practice to switch to now?

I don't understand the different systems that are around at the moment and I need some clarification.

The background of the question, what I am looking for:

  • Don't use Templavoila
  • Keep it simple, little coding overhead
  • That's why I still use markers!
  • Enable Custom content items in the backend like FCEs in TV
  • Foment "structured content" approach in TYPO3: predefined inputs and detailed rendering vs. "Anything goes" like in css_styled_content

And what about https://github.com/Ecodev/bootstrap_package ? Is it recommendable?

Nachison answered 19/7, 2013 at 8:52 Comment(0)
R
3

Fluid offers a much cleaner approach of dividing template logic from display logic and controller logic. Your result will be structured much better when using the possibilities fluid and the mentioned extensions like vhs provide (like layouts and partials).

The usage is actually very simple but can still be combined with the oldschool marker approach (you can do things like <f:cObject typoscriptObjectPath="lib.marks.MAIN-MENU"/>). If you need more flexibility in the backend like in TV, you (of course) have to code some things yourself.

The easiest way is to use an extension which is created by modelling it in the backend to fit your custom needs, but you can also adjust the rendering of pages and/or default content elements by using typoscript and the fields given (like pages.layout, header_layout, section_frame and so on).

So you always have the choice between detailed inputs (extbase extension objects) and using the TYPO3 default things like page properties and RTE config in combination with some typoscript magic (css_styled_content).

So as a conclusion I strongly recommend using fluid templates and additional extensions like vhs as they provide a lot of (additional) power and reusable templates while still let you use markers if you want to. Personally, I also prefer to enhance or limit the RTE in the backend in favor of writing too much special code for an FCE-like result.

BTW: There are very good autocomplete features by using the DTDs/XSDs from fedext.net in your IDE which made my template programming much faster (like 25%).

Ratha answered 19/7, 2013 at 12:55 Comment(5)
Thanks @Ratha - can you recommend a "getting started" tutorial on setting up a fluid "powered" site? And: where do I find a kickstarter for modelling such a fluid (/extbase) extension?Nachison
As you are from Switzerland I suppose you understand this German link: typo3blogger.de/templating-3-0-mit-typo3-fluidtemplate-teil-1 I also added a link to the "extension builder" extension to the answer (the new kickstarter).Ratha
As of meta.stackexchange.com/questions/109956/… one shouldn't, but: Merci!Nachison
Michael, did you use bootstrap_package (link added to the question) as well already? It seems to go in the same direction, but again, looks like a lot of overheadNachison
No, haven't used that. We use the skeleton framework most of the time.Ratha
D
5

Although this question is fairly old by now (I didn't see it until now) and you probably already found out more about what Fluid Powered TYPO3 offers:

The features you ask for (TV-style FCEs, low coding overhead and especially the last one which is more regarding the process than the tool) are exactly what Fluid Powered TYPO3 is all about:

  • We provide simple ways to get page and content templates recognised by TYPO3 and made available to use by the site's content editors.
  • We use a common API approach (which is built on top of TYPO3's TCA/TCEforms) which you can use in both page and content templates to add custom fields (as an example: create a field to set the color of the site's header or configure a content element to have a blue background, and so on).
  • We use Fluid which is (as Michael already stated) a superb rendering engine.

But this is just a small part of the possibilities you have with the extensions (currently there are 20 - no, really, 20) which all provide different feature sets: there's the ViewHelper library VHS which you can use with any type of Fluid template, there's fluidpages, fluidcontent and fluidbackend which lets you place template files in a recognised path and made available to use without further hassle, there's view which lets you use overlay paths for plugin templateRootPaths (example: override only one template file from EXT:news without having to copy all template files from EXT:news). There's builder which can generate extensions, ViewHelper unit test classes, test your Fluid templates and more. There's tool which contains a range of Extbase Service-type classes that you can use in your own Extbase plugins. There's fluidwidget which is a great base for complex Fluid Widgets. You've got side utilities like *extbase_realurl* which can generate automatic realurl rules for any Extbase plugin. And there's schemaker which can let you create your own XSD schemas for your own ViewHelpers (or any version of for example fluid itself, or VHS, or flux etc.).

And there is more than this. Simply put, we offer you every tool you need to create every type of site, template or plugin. Our tools have one primary focus: efficiency.

It sounds like a huge mouthful but it isn't as complicated as it seems. Usually you will start off by using three or four of the extensions and their purpose is quite clear: Flux allows you to add the form fields which content editors use to configure content, pages and plugin instances; VHS provides a large number of multipurpose VieWHelpers to use whenever you need more than just those included with Fluid. And then one or both of fluidcontent and fluidpages which are -very- simple in that all they do is allow you to use template files as content elements or page templates.

There is quite a bit to get used to - this is true of any framework - but we spent a lot of effort on making the API the same across the line, which means anything you learn in one context (for example page templates) you can use in others (like content templates and backend modules).

If you want to save time and be consistent when creating content, pages and plugins, Fluid Powered TYPO3 (which is the umbrella name for all those twenty-something extensions) will do exactly that for you.

I can recommend taking a few minutes to read the new tour I published on fedext.net - the URL is http://fedext.net/tour/form-api.html - it primarily speaks to developers who've touched on Extbase and Fluid earlier, but even if you're used to "just" working with TYPO3 the main points should make sense.

And if you need more details than this you are welcome to find us on Github or on IRC (#typo3 on Freenet). We're always happy to help new users.

Cheers,
Claus aka. NamelessCoder

Disfranchise answered 6/9, 2013 at 22:52 Comment(4)
Thanks Claus - have you held a talk/demo somewhere that could be watched online to get a more hands-on approach? (I've listened to the podcast on t3bits.de/t3b002-fluid-powered-typo3 already) Or do you even do workshops?Nachison
Hi Urs - I've played with the idea of doing brief webinars but it still is just an idea. I think I may try one of those in january/february 2014 so keep an eye out ;)Disfranchise
Looking forward to that!Nachison
Amending the answer regarding talks. We have a recording from T3CS14 (german only) over at Vimeo where there is also a 2nd and 3rd part coming. vimeo.com/96504671 I think we'll link them on fluidtypo3.org and if demand is high put some subtitles around it.Alpinist
R
3

Fluid offers a much cleaner approach of dividing template logic from display logic and controller logic. Your result will be structured much better when using the possibilities fluid and the mentioned extensions like vhs provide (like layouts and partials).

The usage is actually very simple but can still be combined with the oldschool marker approach (you can do things like <f:cObject typoscriptObjectPath="lib.marks.MAIN-MENU"/>). If you need more flexibility in the backend like in TV, you (of course) have to code some things yourself.

The easiest way is to use an extension which is created by modelling it in the backend to fit your custom needs, but you can also adjust the rendering of pages and/or default content elements by using typoscript and the fields given (like pages.layout, header_layout, section_frame and so on).

So you always have the choice between detailed inputs (extbase extension objects) and using the TYPO3 default things like page properties and RTE config in combination with some typoscript magic (css_styled_content).

So as a conclusion I strongly recommend using fluid templates and additional extensions like vhs as they provide a lot of (additional) power and reusable templates while still let you use markers if you want to. Personally, I also prefer to enhance or limit the RTE in the backend in favor of writing too much special code for an FCE-like result.

BTW: There are very good autocomplete features by using the DTDs/XSDs from fedext.net in your IDE which made my template programming much faster (like 25%).

Ratha answered 19/7, 2013 at 12:55 Comment(5)
Thanks @Ratha - can you recommend a "getting started" tutorial on setting up a fluid "powered" site? And: where do I find a kickstarter for modelling such a fluid (/extbase) extension?Nachison
As you are from Switzerland I suppose you understand this German link: typo3blogger.de/templating-3-0-mit-typo3-fluidtemplate-teil-1 I also added a link to the "extension builder" extension to the answer (the new kickstarter).Ratha
As of meta.stackexchange.com/questions/109956/… one shouldn't, but: Merci!Nachison
Michael, did you use bootstrap_package (link added to the question) as well already? It seems to go in the same direction, but again, looks like a lot of overheadNachison
No, haven't used that. We use the skeleton framework most of the time.Ratha

© 2022 - 2024 — McMap. All rights reserved.