I have tested this item ✅ successfully on 78e8e9e

I have tested this item ✅ successfully on 78e8e9e

I've injected the following code in the /components/com_content/views/article/tmpl/default.php (Code: $this->loadTemplate('myfunnystuff', 'year');)
After i createt the File year_myfunnystuff.php with an echo "Hello World!", the message was display on the Page.

Ready to Commit after two successful tests.

@Bakual if i remember well, you did not like that one.

Yep, imho this is useless as the same can already achieved by using sublayouts with the prefix default_ (eg default_foo). Maybe that feature needs to be better documented instead.
If you really need to load a sublayout from a different layout, then you likely should rethink your layout structuire instead (eg use default_ prefixed sublayouts).

@mbabker
You have to decide on this one.
I take off the RTC for now as anyway drone is not happy.

I think we should move all layout stuff into JLayouts. You can have any name you like.

JLayouts wasn't really designed for that. and I think they would be overkill for the regular template files.
But it may be a valid solution for the use case here as well. Eg if you use the same layout part in different places (views), use a JLayout. If you use the same layout part in different layouts of the same view (but not in other views), use sublayouts prefixed with default_.

JLayouts wasn't really designed for that. and I think they would be overkill for the regular template files.

The difference between layout files in components and modules versus JLayout is the former two are included in scope of their "owning" process (components from the view class in MVC layer, modules the ModuleHelper class) whereas the latter is scope isolated from the source (as it should be, creating the correct separation of concerns as it relates to the loading of data for a view and formatting it for display).

JLayout could very easily be the backbone of all rendering in core. It would come with major B/C breaks because you'd have to re-think how the layout components are integrated throughout core (menu items for different layouts, alternate layout params, etc.) and re-teach extension developers how to work without having direct access to the MVC layer in their layouts (and if I'm not mistaken for those who build or work with FOF they'd already have this experience).

So there's no technical reason why JLayout couldn't be used. It is all political and social.

Sure, you could use JLayouts for everything, but imho it's overkill. I don't think it's worth it.

Both the layouts and JLayouts are just a convenient way to separate the "echo" part of a view (representation layer) from the logic part. As you said the layout is still part of the view class while the JLayout file is part of a separate class. Both files aren't classes by itself, they're only holding the "echo" part of the respective class. Having the output in a separate file primary allows for easy overriding the output at template level. Both ways achieve that great. The only thing I think needs improvement is that the override paths used in the templates are not the same (layout files have crazy conventions for the overrides, JLayouts uses a much more intuitive way).

The whole abstraction to use a JLayout requires that you define upfront what the layout will be able to show (passing the whole view to the JLayout is a no-go). JLayouts also have more logic around it to find the possible overrides and allow some other cool things which are usefull for layouts across views and extensions.
For layouts which are used across multiple views (and extensions), this are great features and can simplify things a lot. For layouts used in a single view I don't see the gain in using JLayouts.

In the end both are just files that get included into a class. Both have access to their class. In case of regular layouts it's the view class, in case of JLayouts it is the FileLayout class.

But sure, if people think it's worth the effort to drop the layouts with 4.0 or 5.0 and move everything to JLayouts to better separate the logic part of the representation layer (view) from the real repsentation layer (layout), then it could be achieved with JLayouts ?

The whole abstraction to use a JLayout requires that you define upfront what the layout will be able to show (passing the whole view to the JLayout is a no-go).

That's the biggest point. A layout file on its own should NEVER be able to fetch data that it wasn't given for inclusion in the layout. Now granted, since we don't have a templating engine enforcing that and inherently we're still in "raw" PHP, one still has access to any part of the API that is accessible through said PHP calls (and with the amount of statics in our API, that's most anything as it relates to data retrieval).

In the scope of component view classes, if you're doing JFactory::getApplication()->input or most types of $this->get() (including $this->getModel()) in the layouts, you're probably doing something wrong and that is data that should be injected to the layout versus retrieved within the layout.

That is the benefit that the use of JLayout would provide. No, it can't stop someone from within a layout running a raw database query or direct reading data from some global service, but the only way to stop that would be moving to a full blown templating engine whose layouts are compiled back into PHP (so something like Twig, Laravel's Blade system would be out since it's a very thin layer on top of PHP).

In the end both are just files that get included into a class. Both have access to their class. In case of regular layouts it's the view class, in case of JLayouts it is the FileLayout class.

Right. Once though is in the scope of the MVC layer and inherently allows a layout to do a lot of things that it shouldn't with proper architectural separation of concerns. That's my gripe in the grand scheme of things. Sure, it's easier to just do things the way they're done now, but that doesn't necessarily make it "right".

A layout file on its own should NEVER be able to fetch data that it wasn't given for inclusion in the layout.

I don't agree with such a hard stance.
The layout file is still part of the view class and the view class is responsible for displaying the stuff.
I ended up myself in use cases where it made more sense to fetch the data in the layout than doing it in the view. Of course I could have built a big multi-array of data and pass that to a JLayout, but it would have become much less readable in the end.
So yes, ideally the layout should not fetch data, but I would not say "never". And I don't see it as an issue we have to solve just to do the "the right way".

Anyway, we've got offtopic here ?

one more for @HLeithner to decide how to go on with this Pull Request.

A similar PR has already been closed once, but I think it could be useful. Anyway this PR has to be rebased on j4.

@durubayram please rebase this PR on j4-dev