Closed DanielSiepmann closed 3 years ago
Agree.
Whoops, I just noticed, it's the book we are talking about here, I thought it was the guide. For the guide, I would agree. For the book, I am not suere. I think there are some arguments for keeping Fluid included in there (even if it is 3rdparty) because this is a self-contained walk-through for extension development. The Fluid parts are closely linked to the controllers, pulling it out, you miss a basic part.
Actually, I would prefer it if we consider the entire topic of (extensions) development and consider all currrent resources (core API, Extbase/Fluid Book, Extbase / Fluid guide, ...) and decide on a general structure for it.
I think the viewhelper-reference should be separated, everything else depends on context and can be decided independent. What about fluid is missing if I don't mistake is a stand-alone description for these challenges:
Considering the usage of fluid in this wider context might have impact on the documentation in general I think.
We currently document Fluid within:
That's just to much. I would try to remove the information from all these places and to put them into a single point of truth, which can be referenced instead.
We only should keep contextual information, e.g. how to write the TypoScript configuration or how to assign variables from within Extbase or exchange the View.
But we should definitely not explain the concepts of Layouts, Partials and Templates in various places. Same goes for Syntax, ViewHelpers, etc.
I would suggest a single Fluid Documentation bases on the 3rd Party Library, where TYPO3 and Extbase specifics can be explained in sub contexts. E.g. add hints that TYPO3 makes use of registering global ViewHelper Namespaces and custom VariableProvider, or the default paths for Fluid Files within Extensions.
I am all for removing duplicate explanations in various places.
I was only worrying, if the book might suffer from this. If you can pull Fluid out and at least keep / add the information somewhere, how someone combines Extbase with Fluid, (e.g. using actions and templates), I am all for it.
Actually, what you are suggesting does better reflect the current practices where often Fluid is used, but Extbase not necessarily (e.g. in the core).
Obviously, you will have to find good entry points in the new Fluid docs where someone using the ExtFlu book can lookup stuff and add links in the ExtFlu book.
If you document Fluid as a standalone thing in the new docs (meaning it does not necessarily have to be combined with Extbase), then this glue (combining Extbase with Fluid) would be missing. But you could add it there and point the people from the book to that section and add some explanation in the book, this shouldn't be a problem, I hope.
I would suggest: let'ts stop talking about it and look at a draft for the new structure. Otherwise this discussion is too abstract.
This is an ongoing problem which cant be solved here
Fluid is a standalone template engine. So there should be a nice documentation about the Template engine. Also TYPO3 provide a system extension to enhance and integrate the template engine into TYPO3.
My proposal would be to split Extbase and Fluid into two separate documentations for now. Where we can decide later to split the Fluid documentation further, if helpful.