Decoupling Output

[Llewellynvdm]

This RFC has passed the official entrance vote in the production department.

• This feature is eligible for the Core.
• A working group will be formed to work out the implementation details through this RFC process.
• Official RFC Documentation can be found here: Decoupling Output rfc#36

What Next

• Reading over the comments made here: Decoupling Output rfc#36 please continue the discussion here on this thread.
• Give more Use Cases here.

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.

[Llewellynvdm]

What’s your use case?

If this feature sounds helpful to you, please reply to this comment with your use case. The more details and examples, the better we can understand your needs. Thank you!

[brianteeman]

what has this to do with the simple cck proposal or is it a copy paste error

[Llewellynvdm]

Thank you, typo on my part. I have now fixed it.

[brianteeman]

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.

While that may be true to some extent for a percentage of users who upgraded from 3 to 4 how will this proposal not mean that every user will have to upgrade every template and every override when they upgrade to 5.

With the complete absence of anything concrete in this rfc it is a futile debate.

I asked numerous questions about this before it was even put to a vote but sadly few answers, presumably as there is nothing more than buzzwords and meaningless waffle in the rfc and nothing concrete. joomla/rfc#36 (comment)

All of which probably explains why a majority of the electorate did not vote in favour of this RFC

[Llewellynvdm]

This is the vote: https://github.com/joomla/rfc/blob/eb021dec1860b01b3f39e6fad6c5b59a315df84f/proposed/decoupling-output-meta.md#entrance-vote-prod2022016

The majority did not vote against this, is the actual result. That because of the correct interpretation of abstinence in the vote means neither in favor nor against it. So it means I don't have an opinion, or as it says I abstain from voicing my opinion. Just saying that they were not in favor is not a clear reflection of the vote.

The actual application of this feature has not been decided, just that this would be a great feature to have.

Why don't you jump at the opportunity to explain how you would like to see it implemented.

[brianteeman]

This is the vote: https://github.com/joomla/rfc/blob/eb021dec1860b01b3f39e6fad6c5b59a315df84f/proposed/decoupling-output-meta.md#entrance-vote-prod2022016

The majority did not vote against this, is the actual result. That because of the correct interpretation of abstinence in the vote means neither in favor nor against it. So it means I don't have an opinion, or as it says I abstain from voicing my opinion. Just saying that they were not in favor is not a clear reflection of the vote.

Whichever way you look at it the majority of people did not vote in favour i never said anything about voting against

The actual application of this feature has not been decided, just that this would be a great feature to have.

Having joomla print out money would also be a great feature

Why don't you jump at the opportunity to explain how you would like to see it implemented.

How about because its a daft idea and will never be implemented in a way that satisifies the specification. I prefer not to waste my time and hope that others dont either.

And yes as you saw I presented a big list of questions about this months ago - no answer

Seriously an RFC should contain far more than such a meta description - at least at a high level an explanation of how it could be achieved

[nibra]

Seriously an RFC should contain far more than such a meta description - at least at a high level an explanation of how it could be achieved

Absolutely agree - in its final version, when it will be opened for the Acceptance Vote. The Entrance Vote just says, that this would be a valuable feature and that it makes sense to put efford into it. Not more, not less. The purpose of this discussion is to find a viable way to implement this feature.

[dmitriitux]

We were designing our own library to completely separate graphics, like a software builder in php, which ends up generating html, kind of like the classes in Qt. But we came to the conclusion that we can't afford such a development in terms of our team's masthead (not enough resources).
We have come to the end and are now applying a sort of structural layout.
That is, for example, we have a Sidebar renderer. As they do it by default, redefine the template in php and write their own layout in php. For example, we make a class Sidebar and add structured data to it according to the interface, and templates are given this class and there is a clearly laid structure, which does not change. This is similar to what you use in part for the admin panel, toolbar generation, etc. Only there is no html, only pure structures in the form of classes with table hashes inside.

[dmitriitux]

In the end, these structures are passed to the templates and everyone outputs them as they need.

[dmitriitux]

I can make you a sample and send. =)

[PhocaCz]

Dmitrii, too bad the system was not finished - it looked promising, it would be great to give more details about why you didn't finish the system (only manpower problem?). I think it would be a valuable lesson for Joomla project.

[dmitriitux]

@PhocaCz Staffing problems, there just aren't enough people in the team. We are a capitalist company after all =) We have to do it here and now and we just can't afford to do it with our resources. It is only possible to develop as a large community. That is why we decided on structural layout with php classes.

[nibra]

I can make you a sample and send. =)

Please do!