Add ViewHelpers for BackendModules to the Core

I understand. In what way would you like to have it enforced? I mean, devs would still need to inherit from an abstract base controller, right? Or did I get the idea wrong and there should there some other magic involved?

In any case: enforcement means that it is always there, even when it is not needed/wanted. See the log module and also beuser module for some actions where you would explicitly need to disable the module template again.

I’m pretty sure that this will be used, especially if we switch core modules to use it and make it part of extension_builder module code generation. Besides that, not using it would make it way more complicated for devs to get reasonable backend module output. Imho simplicity always wins and I personally can’t see a way to make it simpler for devs (see examples above). But as I said, if your proposal enables an even more simple way to achieve the same, I’m more than happy to support the efforts to get it in. It is just, that I currently can’t image how it can be simpler, so you would need to help me out here :slight_smile:

I outlined the pros of my approach, but I don’t want to hide possible cons. Here is my summary:

Pro

  • Simple. Since it is Fluid, even non PHP programmers could customize the docheader of modules
  • Clean separation of controller and view. Enabling different output without touching controller code (needed e.g. in log module)
  • Compact. You can see at one glance which buttons are used, how the menu is and what requirejs modules are loaded (try that with plain module template api, no matter what additional abstraction is added)
  • Flexible. Buttons, Menu, even the complete docheader can be easily different for different views (actions). Without that, controller code would need conditions on actions.

Con

  • Main module layout view helper needs to be added only once (this is now checked and an exception emitted otherwise) and all other VHs need to be children of that one (which is a strict requirement, which can’t easily be changed).
  • It is (easily) possible to add HTML outside the main VH (this would result in invalid HTML so the “benefit” in doing so is pretty low).
  • The view helpers added won’t be view helpers in the sense that they won’t directly render things in the place they are used (which is also true for other core VHs like the <f:layout> VH).
  • Usage of ModuleTemplate isn’t enforced (which is also a pro, see “Flexible” from above).

All cons are perfectly acceptable for me as the pros outweighs them more than enough.

But as I said, I accept any other conclusion or any other concept that has a similar or better balance between pros and cons.

Just one note on the “enforcement”. To put it simple: There is simply NO reason to not have a docheader, even if it has only one button at the right side, which is “bookmark”. So I fully agree with Susi to enforce this.
Visual unification is a key concept for easy understanding of UIs, IMHO.

A different aspect where a new base class is not really optimal, is that that we have usecases where we want to use some controllers for BE and for FE. If I would only need to switch the layout that would be super convenient.
(e.g. A special filter action for some database table, which is used for FE as well as for BE editors withing a dedicated “app”)

Please look at the log module like it currently is in the core. It needs a docheader when rendered standalone, but must not have one when rendered within the info module. It is not something I made up, but an actual requirement we have. How would you solve this, when the docheader is strictly enforced?

Also look at the backend user module, which has actions that does not even have a template. why initialize the doc header stuff there, when it is discarded later?

Look at other modules which return json for Ajax actions like the EM, and this maybe only if the format is set to json. How should be deal with an “enforced” docheader there?

Oh, wait, that is exactly what I proposed and have implemented :slight_smile:

The thing is, that is another example where we cannot enforce a docheader as we would then also render it in the frontend ^^

Seems I was not precise enough, sorry.

I’m talking high-level here, not code level. I just wanted to emphasize that a module, displayed in BE has to have a docheader. At this level I don’t care, where things are rendered, reused etc. In the end there must be a docheader.

I can imagine a code-structure that just asks the docheader to add a button, but the code does not instantiate or render the actual docheader, that has to happen centrally somewhere, preferably by the Core.

For the log module: If the output of an action needs to be reused in different context, it simply must not use a layout, but simply provide a template that covers what is actually needed. This means the log module should actually be just a wrapper action, providing the docheader and stuff, and should just call the actual action, which generates the search and the result stuff. Then this “actual action” can be used with no issues in different module, like info.
If such an “actual action” requires something in the docheader, then there should be an API like described in the paragraph above, which simply states “I want my button in the docheader, do that for me.”

I see thedocheader like a toobar API - I just add buttons (currently not caring whether this happens in the controller, the view class or in the Fluid template). For me the docheader seems to be something that can be strongly standardized, even with little to no customization possibilities.

I would like the concept to also keep in mind that we should provide:

  • strong and safe defaults (the 90% case)
  • little room for dev mistakes

Since this topic is open for one more month I will take some more time to think about the whole topic and the code proposals. Thanks so far.

There was never a disagreement on this level :slight_smile:

Did you actually look at my proposal? It (as far as I understand your statement) exactly covers what you request.

Sorry, I could not follow what you have written there, but the impression remains, that you did not look at the code in my proposal, which makes discussion a little bit more complicated.

My proposal covers the possibility to just render content if needed (Info module):
https://review.typo3.org/#/c/51088/3/typo3/sysext/belog/Resources/Private/Layouts/Default.html

or the full Module:
https://review.typo3.org/#/c/51088/3/typo3/sysext/belog/Resources/Private/Layouts/ModuleTemplate.html,unified

Defined on a template level. Layouts are optional here but work great.

That is already the case with the basic API. No different point of views here. It is only about how and where to configure the docheader. I propose: in the template. Susi proposes: in the controller

Have to think on it a bit more, but to be clear:

I actually propose: in the view (since I totally agree that it is view logic)

Hm, ok. But here you wrote:

Which still requires the controller to compose the $menuConfigurationData $docheaderButtonData and $metaInformationData.

It could work out somehow, if each module is required to bring its own view object (which inherits from a base view class) where the configuration of the view is done. However I’m not sure if this is really easier to understand for devs.

I updated the topic description to reflect the current state of the discussion. I think we can go the ViewHelper way, if we add a tutorial somewhere “visible” on how to write backend modules.

Wohoo :hatched_chick:

Any other comments on that topic? @liayn @opi99 @pgampe @mjonuschat

Sounds good. Especially if we get documentation on how to write backend modules :wink:

No, no comments, as I’m no Extbase BE Modul. But this may help me to upgrade the source later.

This topic was automatically closed after 10 days. New replies are no longer allowed.