You're familiar with JPluginHelper::getLayoutPath(), right?

Yeah but that's the entire file. If argue that just being able to override the HTML to add custom classes etc must be significantly easier and easier to maintain

You could do the same layouts with the plugin you've chose using the existing method, and those template layouts would be in the scope of the plugin and have all the data automagically (same way component and module layouts are); whereas the JLayout based files need everything injected (and hopefully don't need things to change later). I just don't feel what you're proposing is right given how we're using JLayout and how the template system (and overrides) work (which includes that JPluginHelper method).

I think both methods have their own merits. I can see where your examples can be useful but I don't also see why whenever Joomla gets updated you have to check all the php etc is upto date for the latest version when all you want is a few small class changes - something you can get around with this method

I think I miss something here. But lets take the pagenavigation plugin because it actually uses a layout file (the one in the "tmpl" folder). It's a very simple file which contains almost only HTML output. That's very easy to override in the template and you don't have to take care of PHP changes here.

What we would need is that the other plugins (like pagebreak) also use this regular layout files for their output.

Personally I don't think we need JLayouts here. Those are best used for parts of a bigger layout which can be reused across extensions. Which is usually not the case for plugins. Their output is already small to begin with and isn't reused by other extensions.

I see your point @wilsonge but I think using layouts as you did it only makes sense to be able to override core layouts. I mean I have a plugin that shows a tag list and I want to override how is shown by core. But then imagine this situation:

I have a component and a common layout is displayed. The plugin will change the way that my component is shown and I cannot change that because plugins have higher priority. So it's complicated

If what you want is to make available layouts for plugins (which I think is a good idea to be able to reuse small parts of code) I think I'd do it differently. I'd create a new function getLayout() or getRenderer() that will get automatically a layout with the correct include paths to allow it to be overridable by templates. It's the same approach I'm using now for my fields (I hope to contribute it soon). The advantage of this is that a plugin can override the getLayout() function and inject there their own Layout class (the only requisite should be to implement JLayout) with their own include paths, suffixes (for j25 / j3) etc.

You would use it like:

// Load a JLayoutFile instance with our desired paths defined with addIncludePath()
$renderer = $this->getRenderer();
/* 
 * This checks for layouts in:
 * 1. templates/mytemplate/html/layouts/plugins/type/name/navigation.php
 * 2. plugins/type/name/layouts/navigation.php
 */
$renderer->render('navigation');

In my own plugin I can do this for example:

    /**
     * Get layout renderer
     *
     * @return  JLayoutFile
     */
    public function getRenderer()
    {
        $renderer = parent::getRenderer();
        $renderer->addIncludePath(JPATH_LIBRARIES . '/mylibrary/layouts');

        return $renderer;
    }

I think this gives developers a tool much more powerful than the JPluginHelper::getLayoutPath() (that I created :D ).

Also I think we should slow transitioning all to layouts to avoid people having to override layouts & views separatelly.

I forgot to mention that I'd add the funtion to JPlugin.

If we end going for twig we could just adjust the getRenderer() which would make it a very smooth transition because the $displayData will be passed anyway.

What's wrong with using JPluginHelper::getLayoutPath('content', 'pagebreak', 'layoutname')? You could create a layout for the content table and another one each for the tab / slider / prev / next / whatever, ending up with five or more layouts in the tmpl folder. That's already possible with the current code without the need to add yet another layout/override logic here

I tried to do something with the existing method JPluginHelper::getLayoutPath(), creating layouts in "tmpl" for the toc and the pages style (with some creative "sublayouts"). You can see it here: https://github.com/Bakual/joomla-cms/compare/PageBreak

I also cleaned up the plugin code a bit. There was stuff in there like if (!$this->params->get('enabled', 1)) which checks if the plugin is enabled. Umm, the plugin doesn't get executed at all if it's not enabled.
Or if (JText::_('JGLOBAL_LT') || JText::_('JGLOBAL_LT')) is very helpful as well: "if either the left string or the right identical string contains something".

I plan to also add layouts for sliders and tabs styles so they could be overriden and made bootstrappy (they still use JHtmlSlider and JHtmlTabs which uses MooTools).

Comments welcome.

I did a background check on the code the second of the JGLOBAL_LT strings
should be JGLOBAL_GT :) Although I see you've removed the full thing with
having a space or not a space - I guess that makes more sense now we're
loading English as a backup language.

I have to say though I think the benefits of having the variables already
in place vs. the benifits of having to load the file contents yourself is
pretty equal. I'd rather just standardize on using JLayouts for everything
rather than having half a dozen different ways of loading layouts..... But
that's just my opinion :)

We already have bootstrapped Tabs and Sliders in JHtml bootstrap (and the
tabs part has already been JLayout'd) so I don't really see the need for
this - the only thing we would need to do is move the rest of the functions
in there to use JLayouts.

Kind Regards,
George

On 25 February 2014 11:55, Thomas Hunziker notifications@github.com wrote:

I tried to do something with the existing method
JPluginHelper::getLayoutPath(), creating layouts in "tmpl" for the toc
and the pages style (with some creative "sublayouts"). You can see it here:
https://github.com/Bakual/joomla-cms/compare/PageBreak

I also cleaned up the plugin code a bit. There was stuff in there like if
(!$this->params->get('enabled', 1)) which checks if the plugin is
enabled. Umm, the plugin doesn't get executed at all if it's not enabled.
Or if (JText::('JGLOBALLT') || JText::('JGLOBALLT')) is very helpful
as well: "if either the left string or the right indentical string contains
something". [image: ]

I plan to also add layouts for sliders and tabs styles so they could be
overriden and made bootstrappy (they still use JHtmlSlider and JHtmlTabs
which uses MooTools).

Comments welcome.

Reply to this email directly or view it on GitHub#3163 (comment)
.

I did a background check on the code the second of the JGLOBAL_LT strings
should be JGLOBAL_GT :)

Yeah, I suspected something like that and removed it for the reasons you assumed :)

I have to say though I think the benefits of having the variables already
in place vs. the benifits of having to load the file contents yourself is
pretty equal. I'd rather just standardize on using JLayouts for everything
rather than having half a dozen different ways of loading layouts..... But
that's just my opinion :)

I find JLayouts are too complex and decoupled for simple things like what we need here. Also JLayouts only have access to the variables passed to it. So you loose some flexibility here.
But that's me

JLayouts make a lot of sense when we are talking about output which is shared across extensions. But imho it doesn't make sense when it's only used in a single extension. And honestly, our standard are the layout files in the "tmpl" folder. To my knowledge JLayouts isn't meant to replace those.

We already have bootstrapped Tabs and Sliders in JHtml bootstrap (and the
tabs part has already been JLayout'd) so I don't really see the need for
this - the only thing we would need to do is move the rest of the functions
in there to use JLayouts.

Ah nice, didn't remember that. JHtml is also a good place to use JLayouts btw. Because there is no other way.

Agreed. For another place. But I'd like to rip out the entire JHtmlBootstrap class, move the part that inserts the actual jQuery JS/CSS into the main JHtml class or maybe even a JHtmlFrameworks class (that will also deal with jQuery, Mootools and any other frameworks we use) and then move the entire of the rest of the class into JLayouts

JLayouts makes perfect sense everywhere. We have to change how we think. A layout should depend on the variables passed to it. See how all the template systems work (Twig, Smarty...). You always have to pass the variables that are going to be rendered. Templates are for designers and it's easier for them to dump the list of things they have available.

Benefits on using JLayouts are multiple:

1. Reusability

Imagine a layout to show an article on the frontend. It receives an item and maybe params and displayes the article. So it can be reused/overriden everywhere. Same for list of articles.

2. Evolution

We have to slowly move to a "standard template system" that we are going to end using. So creating the objects and using them in the layout is perfect to give the first step. The data generated will be passed to a different template system in the future without having to rewrite all the data generation system.

3. Standars

We need one way to render things. It's obvious that current views are not able to be reused everywhere so the solution is JLayout.

4. Powerful

With a layout system developers have the control to change the rendering class (to an extended/custom JLayoutFile for example). They can inject their includePaths, force client to frontend, force component....

In my opinion replace the way that plugin are rendered to then having to change it again makes no sense. We have to give o a definitive step in the right direction. George's proposal only had to get polished. Why duplicate efforts in solve the same issue?

I created the JPluginHelper::getLayoutPath() as a fast copy of what is used in modules but we need something better.

I actually don't like Smarty and Co because of the limitations they have. The same one JLayouts have: They can only work with the variables they got passed.
But then I'm a coder and not a designer, so my wishes may differ from designers.
However I will be the one who has to create the initial default layout for my extensions, and when I had to work with Smarty in a different project, I just hated it and prefered the way Joomla handles regular layouts.

I agree that the reusability of JLayouts is an awesome thing, and I can see the use of an "article" layout. It could become kind of a cheap UCM. However it needs a lot of work and standardising before it will work for non-core extensions, and with some of the current JLayouts being hardcoded to specific properties it will not work.
Imho we should first define a standard how to use JLayouts, or we end up with wild west usage of JLayouts all over the place.

It's obvious that current views are not able to be reused everywhere so the solution is JLayout.

Many of the current JLayouts suffer already the same problem and I can't use them in my extension.
We should only create JLayouts if they are indeed reusable (and make sense to be reused).

In my opinion replace the way that plugin are rendered to then having to change it again makes no sense. We have to give o a definitive step in the right direction. George's proposal only had to get polished. Why duplicate efforts in solve the same issue?

That's actually exactly my point. Before adding yet another way to render plugins, first define a standard. I did my branch to see if the problem could be solved with existing (and already used) methods. And it was easy so far.

But we may have to discuss this elsewhere and define a strategy where we want to go

Closing with @phproberto 's PR to come (the one that didn't quite make 3.3)