[#33081] - [4.0][RFC] toolbars are not dev friendly
- Closed
- 5 May 2021
- Medium
- Build: 4.0-dev
- Draft PR
- # 33081
- Diff
- dgrammatiko:—toolbars-are-not-dev-friendly-4.0-dev
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary
Toolbars (either on J3 or J4) are rendered in the HTML part of the view. The process makes them inaccessible for front end devs to tweak/change/add/remove anything! WHY??
All it takes is to move the addToolbar() function's content to the view. That's it but I genuinely want to know why this totally unfriendly approach is the preferred way.
On top of that, I wanted to point out that both the old and the new code for the toolbar/buttons is totally useless. There's a factory that takes some arguments and calls a JLayout to render the button. WHY?? Just call the JLayout directly also JLayouts support sublayouts meaning there's a solution to the composition of the dropdown buttons.
In short, there's a lot of code that is totally useless as the JLayouts meet the requirements and then the whole output is not accessible to the front end developers. Not a good combo here...
Testing Instructions
To prove my point here's a version of com_content's articles view that uses JLayout and is completely accessible to frontenders and also 100% B/C (assuming that the bloated code is left there)
Actual result BEFORE applying this Pull Request
Expected result AFTER applying this Pull Request
Documentation Changes Required
Well the toolbar factory is not documented or am I missing the docs there?
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content |
| Labels |
Added:
?
?
|
||
@brianteeman I'm not trying to blame anyone here (I actually supported the toolbar factory, so if I wanted to do that I should start by looking at my mirror). My point here is that this part of the codebase is really hostile for front end devs (someone needs either JS or CSS hacks to customise even the simplest things on a toolbar)
I was just explaining. Its the nature of iterative development that without regular complete refactoring this will occur.
So you moved the content of a function to a layout which normally should only have html and not a complete php logic in it.
I don't think that this is the right approach for it. There must be a better way.
The process makes them inaccessible for front end devs to tweak/change/add/remove anything! WHY??
It called OOP, works kind like this (internally):
Toolbar::getInstance()
->appendButton(new FancyButton())
->appendButton(new MuchFancyButton());You define what buttons you need, and later they rendered accordingly to their layouts ( layouts/joomla/toolbar/...)
What you offer does not make much sense.
The toolbar itself rendered by mod_toolbar. Additionally you can override one of layouts/joomla/toolbar/.. layouts.
And use onBeforeRender event if need to add more buttons.
However there missed API like $toolbar->appendButtonAfter/Before() $toolbar->removeButton() (would be nice if someone can code it).
Save your time and push the red button ;)
So you moved the content of a function to a layout which normally should only have html and not a complete php logic in it.
I don't think that this is the right approach for it.
There must be a better way.
I just moved the code to showcase how naively Joomla overengineered this when the solution should be a few calls to some JLyouts. If we need a factory to construct a div with a bunch of buttons (there is no computation for the buttons or the container, it's just templating) probably we're doing it very wrong...
What you offer does not make much sense.
Sure, I mean to change some classes I need to write a Plugin and that makes much more sense. Right?
But I'm not gonna argue anymore here
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-05 09:01:55 |
| Closed_By | ⇒ | dgrammatiko |
To answer your question as to why? This is probably due to the iterative nature of development.