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