New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.0] Use JLayout in view instead of the template files #13684

Closed
wants to merge 6 commits into
base: 4.0-dev
from

Conversation

Projects
8 participants
@yvesh
Member

yvesh commented Jan 22, 2017

Summary of Changes

The goal of Joomla 4 is to move the template files (like default.php) into JLayouts everywhere, this PR is a first draft on that. It's keeping backward compatibility by loading the old template file / override if it exists.

The goal is to make layouts reusable, e.g. use them in views, modules etc. and to decouple the content from the view.

Testing Instructions

Apply and make sure everything is still working with the b/c option.

Then

Remove / Rename the default.php in components/com_content/view/article/tmpl/default.php and see if the JLayout file is loaded and shows the article title.

Documentation Changes Required

We need to update JDocs after finalising the approach.

@yvesh yvesh changed the title from Use JLayout in view instead of the template files to [4.0] Use JLayout in view instead of the template files Jan 22, 2017

cs
@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jan 22, 2017

Contributor

Are you really sure you want to do that?
JLayouts were designed to be reusable layout snippets, they were not desgined to be full layout files.
They come with an additional overhead which isn't needed in current layout files, also they likely need more PHP logic in it which currently is taken care in the view class itself.

What is the gain we have for using JLayouts?

Contributor

Bakual commented Jan 22, 2017

Are you really sure you want to do that?
JLayouts were designed to be reusable layout snippets, they were not desgined to be full layout files.
They come with an additional overhead which isn't needed in current layout files, also they likely need more PHP logic in it which currently is taken care in the view class itself.

What is the gain we have for using JLayouts?

@yvesh

This comment has been minimized.

Show comment
Hide comment
@yvesh

yvesh Jan 22, 2017

Member

@Bakual We can use the jlayouts in different places, like modules. E.g. show two articles in one page, one with com_content one with a module. The current system is way too tightly coupled (this context etc) to the view and jinput.

Member

yvesh commented Jan 22, 2017

@Bakual We can use the jlayouts in different places, like modules. E.g. show two articles in one page, one with com_content one with a module. The current system is way too tightly coupled (this context etc) to the view and jinput.

@zero-24

This comment has been minimized.

Show comment
Hide comment
@zero-24

zero-24 Jan 22, 2017

Contributor

Please take a look into the travis problem https://travis-ci.org/joomla/joomla-cms/jobs/194201747

Contributor

zero-24 commented Jan 22, 2017

Please take a look into the travis problem https://travis-ci.org/joomla/joomla-cms/jobs/194201747

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jan 22, 2017

Contributor

I agree with @yvesh - I think this is a positive move because it gives modules greater flexibility to use the views of components

Contributor

wilsonge commented Jan 22, 2017

I agree with @yvesh - I think this is a positive move because it gives modules greater flexibility to use the views of components

@laoneo

This comment has been minimized.

Show comment
Hide comment
@laoneo

laoneo Jan 22, 2017

Member

I guess it would be a good idea to move then some logic then out of the layouts to reduce complexity of the layouts.

Member

laoneo commented Jan 22, 2017

I guess it would be a good idea to move then some logic then out of the layouts to reduce complexity of the layouts.

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Jan 22, 2017

Member

👎

You are massively coupling JViewLegacy to an HTML rendering layer, and even moreso you are locking the view layer to a single rendering implementation. Although lets be perfectly honest here, support for non-HTML output in Joomla is a practical joke.

The view layer should be format agnostic and if needed subclasses for specific formats (see https://github.com/joomla-framework/view/tree/2.0-dev as an acceptable example).

Another issue is you will introduce backward compatibility breaks preventing smooth template upgrades between 3.x and 4.x. Worse than a conversion from Bootstrap 2 to any other templating framework. Any component view which implements JLayout will not support the current layout paths and override system.

I suggest marking this a RFC PR at this time. It needs a lot of work and discussion outside of a few people in London before it should be seriously considered.

Member

mbabker commented Jan 22, 2017

👎

You are massively coupling JViewLegacy to an HTML rendering layer, and even moreso you are locking the view layer to a single rendering implementation. Although lets be perfectly honest here, support for non-HTML output in Joomla is a practical joke.

The view layer should be format agnostic and if needed subclasses for specific formats (see https://github.com/joomla-framework/view/tree/2.0-dev as an acceptable example).

Another issue is you will introduce backward compatibility breaks preventing smooth template upgrades between 3.x and 4.x. Worse than a conversion from Bootstrap 2 to any other templating framework. Any component view which implements JLayout will not support the current layout paths and override system.

I suggest marking this a RFC PR at this time. It needs a lot of work and discussion outside of a few people in London before it should be seriously considered.

@yvesh

This comment has been minimized.

Show comment
Hide comment
@yvesh

yvesh Jan 22, 2017

Member

Another issue is you will introduce backward compatibility breaks preventing smooth template upgrades between 3.x and 4.x. Worse than a conversion from Bootstrap 2 to any other templating framework.

@mbabker Not getting you here. If there is an old override in the template (for the default.php etc.) or one for the JLayout this one is loaded in favour of the JLayout. The changes should be b/c to 3.

Member

yvesh commented Jan 22, 2017

Another issue is you will introduce backward compatibility breaks preventing smooth template upgrades between 3.x and 4.x. Worse than a conversion from Bootstrap 2 to any other templating framework.

@mbabker Not getting you here. If there is an old override in the template (for the default.php etc.) or one for the JLayout this one is loaded in favour of the JLayout. The changes should be b/c to 3.

@Bakual

This comment has been minimized.

Show comment
Hide comment
@Bakual

Bakual Jan 22, 2017

Contributor

We can use the jlayouts in different places, like modules.

You want to use eg a list or form layouts in a module? I doubt it. The only layout you possibly want to use is the article one. And even that one you probably want to adjust for a module (eg remove the infoblock and have a different title tag).

What we could use is a generic, flexible "content" JLayout. Basically the article layout but it could be used by other components as well. That would be a regular JLayout located in the global layout folder. It could be used also for the blog and featured view.

I guess it would be a good idea to move then some logic then out of the layouts to reduce complexity of the layouts.

Imho, the goal should be to get rid of a lot of the "design" parameters and instead make it very easy for the user to adjust the layouts. Eg by using a drag and drop layout builder. That would be an awesome project. But it's something completely different from this PR 😄

Contributor

Bakual commented Jan 22, 2017

We can use the jlayouts in different places, like modules.

You want to use eg a list or form layouts in a module? I doubt it. The only layout you possibly want to use is the article one. And even that one you probably want to adjust for a module (eg remove the infoblock and have a different title tag).

What we could use is a generic, flexible "content" JLayout. Basically the article layout but it could be used by other components as well. That would be a regular JLayout located in the global layout folder. It could be used also for the blog and featured view.

I guess it would be a good idea to move then some logic then out of the layouts to reduce complexity of the layouts.

Imho, the goal should be to get rid of a lot of the "design" parameters and instead make it very easy for the user to adjust the layouts. Eg by using a drag and drop layout builder. That would be an awesome project. But it's something completely different from this PR 😄

@laoneo laoneo referenced this pull request Mar 6, 2017

Merged

[j4] Namespace com_content #14370

@laoneo

This comment has been minimized.

Show comment
Hide comment
@laoneo

laoneo Mar 6, 2017

Member

You want to use eg a list or form layouts in a module? I doubt it.

Why not?

I agree here with @mbabker, the layout changes shouldn't be done in JViewLegacy, probably in a new class like JViewLayout which extends JViewLegacy.

But in general I'm in favor of having JLayouts over views. It is more clear what is needed to come in and what will get out.

Member

laoneo commented Mar 6, 2017

You want to use eg a list or form layouts in a module? I doubt it.

Why not?

I agree here with @mbabker, the layout changes shouldn't be done in JViewLegacy, probably in a new class like JViewLayout which extends JViewLegacy.

But in general I'm in favor of having JLayouts over views. It is more clear what is needed to come in and what will get out.

@mbabker

This comment has been minimized.

Show comment
Hide comment
@mbabker

mbabker Mar 6, 2017

Member

With the namespacing effort and rethinking the entirety of our MVC right now, one thing I think I might suggest is leaving JViewLegacy as an extension of a new Joomla\Cms\View\Html and we use the opportunity to start building format specific base view classes similar how to https://github.com/joomla-framework/view/tree/2.0-dev/src is set up. Having a single base view class that does all the things seems like bad design. Even JDocument has some of the responsibilities split correctly across formats.

Going back to my original comment, as long as B/C is preserved, we should probably be OK to move forward in the direction of using JLayout as the view renderer for HTML views.

Getting a little froggy now, I even did an implementation of the Framework's 2.0 View package using JLayout in https://github.com/mbabker/joomla-next/tree/master/libraries/core/Renderer if we wanted to think about how to redo the view layer of MVC using the Framework's view package instead of JViewLegacy, but there'd either need to be a massive legacy layer or the two would have to co-exist as a new implementation.

Member

mbabker commented Mar 6, 2017

With the namespacing effort and rethinking the entirety of our MVC right now, one thing I think I might suggest is leaving JViewLegacy as an extension of a new Joomla\Cms\View\Html and we use the opportunity to start building format specific base view classes similar how to https://github.com/joomla-framework/view/tree/2.0-dev/src is set up. Having a single base view class that does all the things seems like bad design. Even JDocument has some of the responsibilities split correctly across formats.

Going back to my original comment, as long as B/C is preserved, we should probably be OK to move forward in the direction of using JLayout as the view renderer for HTML views.

Getting a little froggy now, I even did an implementation of the Framework's 2.0 View package using JLayout in https://github.com/mbabker/joomla-next/tree/master/libraries/core/Renderer if we wanted to think about how to redo the view layer of MVC using the Framework's view package instead of JViewLegacy, but there'd either need to be a massive legacy layer or the two would have to co-exist as a new implementation.

@mbabker mbabker added this to Request For Comment in [4.0] MVC Layer Apr 7, 2017

@brianteeman brianteeman modified the milestone: Joomla 4.0 Jun 8, 2017

@brianteeman

This comment has been minimized.

Show comment
Hide comment
@brianteeman

brianteeman Apr 8, 2018

Contributor

Is this PR still relevant or should it be closed?

Contributor

brianteeman commented Apr 8, 2018

Is this PR still relevant or should it be closed?

@laoneo

This comment has been minimized.

Show comment
Hide comment
@laoneo

laoneo May 23, 2018

Member

Actually it is as we have now an HTMLView available where we can extend from.

Member

laoneo commented May 23, 2018

Actually it is as we have now an HTMLView available where we can extend from.

@wilsonge

This comment has been minimized.

Show comment
Hide comment
@wilsonge

wilsonge Jun 14, 2018

Contributor

This is so outdated I'm going to close it for now. The concept we should come back to though.

Contributor

wilsonge commented Jun 14, 2018

This is so outdated I'm going to close it for now. The concept we should come back to though.

@wilsonge wilsonge closed this Jun 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment