Decoupling Output

[nibra]

1. Summary

The separation of the visual preparation and presentation of the content from its management is what we call
decoupling of the output.

The aim of this specification is to decouple the output layer from the core of the CMS so that necessary changes to the
CMS code require as few changes as possible to the templates and their overrides.

2. Why Bother?

Every major version so far has stirred up resentment among users because not only programme code but also templates,
layouts and overrides had to be revised. If we succeed in reducing the points of contact between the CMS core and the
actual views to interfaces, not only will the adaptation effort for templates, layouts and overrides be considerably
less, it will even be possible to offer output layers with completely different frontend libraries than before.

The solution developed here is to be incorporated into Joomla 5.

[brianteeman]

I have been waiting to hear more about this proposal - guess I will have to wait a bit more to hear about concrete ideas for this. In the absence of those these are some unfiltered thoughts that have gone through my head in recent days

1. Didnt we fundamentally do the same thing with beez and hathor? Which both failed long term as we didnt have the capacity to support multiple layouts.
2. This idea has bounced around since mambo in various iterations and has never worked
3. How to avoid once again breaking every single template in existance
4. Yet to see how the claim it will reduce the effort involved will be less
5. We actually go back in time where template and extension developers dont have a common ui to build to and they end up having to do more not less.
6. I've seen first hand the pain points in building sites with a cms which has almost zero points of contact. The time for development increases massively - ever wondered why drupal companies employ so many staff? Building with a template engine eg twig is the only way I see to reduce the points of contact. But that just adds a new layer of development instead of removing one and making life easier
7. Considering the number of interfaces there are in core alone its a massive piece of work and no it can't be automated. Can we really justify spending the time on this when there are so many existing pieces of code that need completing.
8. Why dont we go the whole hog and remove the points of contact between joomla and php and then let users chose the language they want. Yes obviously thats in jest but from my perspective its no different to what is briefly outlined here.

Why Bother.

Instead of solving the pain and following a non-disruptive mode of development this theoretical proposal actually does the opposite. Whereas I was able to update my j3 site with a custom template of my own to j4 with almost no effort (maybe I was lucky) the same would not be true here.

I am not saying there is no problem to resolve. We absolutely can reduce to near zero the dependence of core with any frontend library. A good start was made for this with j4. Why wasn;t it done completely? Time, Time, Time and more time.

[dgrammatiko]

@brianteeman couple of things:

We actually go back in time where template and extension developers dont have a common ui to build to and they end up having to do more not less.

This was impossible (or extremely hard) without CSS Variables, but that's not the case anymore! All you need is a design system and a set of defined global CSS Variables. Also everything regarding to the past cases are erased simply because the W3C Platform now has the APIs needed which wasn't the case for many years. On top of that, has, where and is pseudo selectors would enable a new kind of css frameworks as @media enabled css frameworks like bootstrap. It's a great time to work on the web right now...

[brianteeman]

css variables has nothing to do with html markup

[dgrammatiko]

css variables has nothing to do with html markup

Well, it has, in the sense that with has, where, is and CSS Vars basically you can have classless markup...

[brianteeman]

Keep dreaming

[dgrammatiko]

Keep dreaming

I prefer to keep myself educated on the current state of the platform, but also dreaming is a good option

[Hackwar]

I support this RFC with a few buts:

1. The backend needs to be excluded from this and only support one style/framework.
2. There need to be automatic checks to keep the n layouts we want to support in sync. A start could be the JIssues bot marking PRs which only fix one layout and not the other.
3. We have to couple this with a quality initiative which extends APIs/custom fields/etc to be usefull beyond the exact way it is used in the core. At the same time, this means automatic quality assurance. (Yes, I'm responsible for that.) Basically, we want third party devs, integrators and designers to do additional work and we should at the same time make it easier for them in other areas, hopefully reducing the overall workload for them.

The goal of this in the end is to not force site owners to do an extensive refactoring when we release a new major version, just because we switched (the version of) our CSS framework.

[brianteeman]

Until someone can find a solution that does not break every single joomla 4 web site that is using even a single template override then this is just a pipedream.

[Hackwar]

The technical solution isn't that difficult, I would even say "trivial". The problem is a lot more organisational. See your 1. and my 2. for the big issue.

[brianteeman]

and I would say it is "impossible" rather than "trivial"

[Hackwar]

We are moving all extension layouts into a template override folder and instead of loading from the extensions folder, our classes load from that folder. If a template has a layout override, that file takes precedence in the file search. All of that is pretty similar to what we have right now. Default to the BS5 layouts unless otherwise stated and you are done. Add a fallback to the extensions folder for legacy extensions and that part is covered as well. The minimum changes necessary for the core are probably 20 lines of code and existing extensions will keep on working the same way they did before.

[brianteeman]

We are moving all extension layouts into a template override folder and instead of loading from the extensions folder, our classes load from that folder. If a template has a layout override, that file takes precedence in the file search.

And that is what will break every existing template override

[Hackwar]

Why should that break any existing template override?

[Hackwar]

I mean, you aren't using absolute paths in your code, are you? Otherwise it is just one more path the respective method is searching for the right layout.

[brianteeman]

will even be possible to offer output layers with completely different frontend libraries than before.

As soon as you do that you have broken the connection between the existing override and the core. Resulting in at a minimum a failure for the override check to be useful.

Anyway it is all mute as we have already shown that we do not have the capacity to maintain this in the long term. I see nothing in either the community or the code that would change that. All it will end up being will be a change in physical file location for no purpose or benefit.

[Llewellynvdm]

Please continue discussions here: joomla/joomla-cms#39464