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?

@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.

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

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

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

?

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.

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.

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 ?

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.

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.

Is this PR still relevant or should it be closed?

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

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