[#33415] [imp] layout improvements and base system for fields by phproberto · Pull Request #3231 · joomla/joomla-cms

phproberto · 2014-03-04T04:12:09Z

Feature tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33415

This also fixes this issue:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33618

This pull request introduces some new JLayout based features:

JLayout improvements

1. Chainable methods

I have added the option to chain methods when possible. Now you can do:

$renderer = new JLayoutFile('joomla.content.tags', null, array('debug' => true));

echo $renderer
    ->setClient(0)
    ->setComponent('com_categories')
    ->render($this->item->tags->itemTags);

2. Suffixes improvements

Version 3.2 already supported suffixes but I created some improvements.

2.1 Add suffixes dynamically

Now suffixes can be added dynamically with setSuffixes($suffixes) method. Example:

$renderer = new JLayoutFile('joomla.content.tags', null, array('debug' => true));

echo $renderer
    ->setComponent('com_content')
    ->setClient(1)
    ->setSuffixes(array('j25'))
    ->render($this->item->tags->itemTags);

2.2 Automatic version suffixes

Most extended suffixes use was for having different versions for Joomla 2.5 & Joomla 3.x. I've added an automatic mode that will load the default version suffixes:

$renderer = new JLayoutFile('joomla.content.tags', null, array('debug' => true));

echo $renderer
    ->setSuffixes('autoversion')
    ->render($this->item->tags->itemTags);

Will automatically load this suffixes when executed on Joomla 3.2.3:

Suffixes: Array
(
    [0] => j323
    [1] => j32
    [2] => j3
)

So it will search for a layout in this priority order:

Searching layout for: joomla/content/tags.j323.php
Searching layout for: joomla/content/tags.j32.php
Searching layout for: joomla/content/tags.j3.php
Searching layout for: joomla/content/tags.php

This is mainly intended to be used on classes that extend JLayoutFile because sadly layouts are not available on Joomla 2.5.x series (they are included on FOF now).

For example an extended class running the same code on Joomla 2.5.18 will search layouts on:

Searching layout for: joomla/content/tags.j2518.php
Searching layout for: joomla/content/tags.j25.php
Searching layout for: joomla/content/tags.j2.php
Searching layout for: joomla/content/tags.php

As you can see is useful to have layout specific for a Joomla version.

2.3 Automatic language suffixes

This is an automatic suffix mode language oriented. Example:

$renderer = new JLayoutFile('joomla.content.tags', null, array('debug' => true));

echo $renderer
    ->setSuffixes('autolanguage')
    ->render($this->item->tags->itemTags);

It will automatically add this suffixes when executed on a site with en-GB language active.

Suffixes: Array
(
    [0] => en-GB
    [1] => en
    [2] => ltr
)

So you can create a layout for:

This specific locale
This specific language
This specific language direction

Good examples would be addresses that are ordered differently on different languages or layouts specifics to RTL (Right To Left) languages

3. Prefixes support

Now JLayoutFile also supports prefixes. This is mainly to group different prefixes under the same prefix. In the practice a prefix is a main folder that stores all that layouts. Example:

$renderer = new JLayoutFile('joomla.content.tags', null, array('debug' => true));

echo $renderer
    ->setPrefixes('bootstrap3')
    ->render($this->item->tags->itemTags);

It will search layouts in this order when called from the article view:

Include Paths: Array
(
    [0] => templates/protostar/html/layouts/com_content/bootstrap3
    [1] => components/com_content/layouts/bootstrap3
    [2] => templates/protostar/html/layouts/bootstrap3
    [3] => layouts/bootstrap3
    [4] => templates/protostar/html/layouts/com_content
    [5] => components/com_content/layouts
    [6] => templates/protostar/html/layouts
    [7] => layouts
)

So for example if you are on a template that supports both bootstrap2 & bootstrap3 mode you can put in the layouts/bootstrap3 folder the specific layouts for bootstrap3.

4. Cached file searches

When a layout is already searched in a specific list of include paths the final path is saved on cache. Next time the layout is searched in that list of include paths the cached path will be returned.

5. Statistics

Now JLayoutFile stores statistics about its use. To get the stats you have to use:

$stats = JLayoutFile::getStats();

It will return something like:

Array
(
    [fileSearches] => 20
    [fileSearchesCached] => 11
    [fileSearchesSkipped] => 0
    [times] => Array
        (
            [fileSearching] => 0.0028524398803711
            [fileRendering] => 0.024386882781982
            [/var/www/jcms3x/layouts/plugins/content/vote/vote.php] => 0.0019118785858154
            [/var/www/jcms3x/layouts/joomla/content/blog_style_default_item_title.php] => 0.0065479278564453
            [/var/www/jcms3x/layouts/joomla/content/icons.php] => 0.005518913269043
            [/var/www/jcms3x/layouts/joomla/content/info_block/author.php] => 0.00033211708068848
            [/var/www/jcms3x/layouts/joomla/content/info_block/category.php] => 0.0012009143829346
            [/var/www/jcms3x/layouts/joomla/content/info_block/publish_date.php] => 0.00086474418640137
            [/var/www/jcms3x/layouts/joomla/content/info_block/hits.php] => 0.0002598762512207
            [/var/www/jcms3x/layouts/joomla/content/info_block/block.php] => 0.0072002410888672
            [/var/www/jcms3x/layouts/joomla/content/intro_image.php] => 0.00026798248291016
        )

    [layoutsRendered] => Array
        (
            [/var/www/jcms3x/layouts/plugins/content/vote/vote.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/blog_style_default_item_title.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/icons.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/info_block/block.php] => 4
            [/var/www/jcms3x/layouts/joomla/content/info_block/author.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/info_block/category.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/info_block/publish_date.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/info_block/hits.php] => 2
            [/var/www/jcms3x/layouts/joomla/content/intro_image.php] => 2
        )

)

All the stats in a single array.

5.1 Stats details

$stats['fileSearches'] : Number of layout searches performed
$stats['fileSearchesCached'] : Number of layout searches returning cached paths
$stats['fileSearchesSkipped'] : Number of layout searches skipped because they share same instance with same params
$stats['times']: Array containing different times tracked
$stats['times']['fileSearching']: Total time spent searching layouts on file system
$stats['times']['fileRendering']: Total time spent rendering layouts
$stats['times'][$path]: System stores also time spent rendering each layout. This includes the global rendering time of rendering all appearences of this layout.
$stats['layoutsRendered']: Array containing the list of layouts rendered (array key) and the times it has been rendered ( value).

6. Better includepaths handling

In the previous versions you could not specify a list of include paths. The layout paths were always calculated automatically. Now you have total control over them

6.1 setIncludePaths

$renderer = new JLayoutFile('joomla.content.tags', null, array('debug' => true));

$renderer->setIncludePaths(
    array(
        JPATH_COMPONENT . '/layouts',
        JPATH_SITE . '/layouts'
    )
);

echo $renderer->render($this->item->tags->itemTags);

Will search for layouts on:

Include Paths: Array
(
    [0] => /var/www/jcms3x/components/com_content/layouts
    [1] => /var/www/jcms3x/layouts
)

6.1 resetIncludePaths

Delete the include paths information

echo $renderer
    ->setIncludePaths(
        array(
            JPATH_COMPONENT . '/layouts',
            JPATH_SITE . '/layouts'
        )
    )
    ->resetIncludePaths()
    ->addIncludePaths(
        array(
            JPATH_COMPONENT . '/layouts-new',
            JPATH_SITE . '/layouts-new'
        )
    )
    ->render($this->item->tags->itemTags);

will search in this include paths:

Include Paths: Array
(
    [0] => /var/www/jcms3x/components/com_content/layouts-new
    [1] => /var/www/jcms3x/layouts-new
)

6.2 loadDefaultIncludePaths

It will load the automatically calculated paths.

JFormField improvements

1. Field requirements support

This adds the option for fields to specify requirements that will prevent the field from being loaded.

There are only 2 main requirements defined at this point:

multilanguage : Requires language filter is enabled
associations : Requires language associations enabled

Note: This adds the support but most of the fields will require to modify the geInput() method to add the $this->validateRequirements() call. So don't expect it works on all fields out of the box. It should only work on labels and on text field.

A sample field definition:

<field 
    name="title" 
    type="text" 
    label="JGLOBAL_TITLE"
    description="JFIELD_TITLE_DESC"
    requires="multilanguage"
    required="true" 
/>

You can specify more than one requirement:

<field 
    name="title" 
    type="text" 
    label="JGLOBAL_TITLE"
    description="JFIELD_TITLE_DESC"
    requires="multilanguage,associations"
    required="true" 
/>

You can easily extend requirements for your field like:

/**
 * Function to determine if field validates the requirements
 *
 * @return  boolean
 */
protected function validateRequirements()
{
    if (parent::validateRequirements())
    {
        $requires = explode(',', (string) $this->element['requires']);

        if (in_array('myrequirement', $requires) && !MyHelper::validateRequirement())
        {
            return false;
        }
    }

    return true;
}

2. Layouts support

This adds support to use JLayoutFile to render form fields. This is added in JFormField but it doesn't change most of the existing fields to ensure BC. So don't expect it to work out of the box on all the fields. Included fields are:

JFormFieldList
JFormFieldUser

Now layouts can be defined inside fields setting the property $layout:

    /**
     * Layout to render
     *
     * @var  string
     */
    protected $layout = 'joomla.form.field.list';

But they also can be overriden on form. Thanks to this we can save to create new fields when the logic to get the data is the same and only the logic to render it changes. Examples would be to load select2 on a field for example:

<field
    name="show_title"
    type="list"
    class="chzn-color"
    label="JGLOBAL_SHOW_TITLE_LABEL"
    description="JGLOBAL_SHOW_TITLE_DESC"
    layout="joomla.form.field.select2"
    >
    <option value="">JGLOBAL_USE_GLOBAL</option>
    <option value="1">JSHOW</option>
    <option value="0">JHIDE</option>
</field>

Or imagine that you have a layout to render a filed loading typeahead.js field:

<field 
    name="title" 
    type="list" 
    label="JGLOBAL_TITLE"
    description="JFIELD_TITLE_DESC"
    layout="form.field.typeahead"
    required="true" 
/>

You can also set a specific layout for the label and layout prefixes/suffixes on your field class:

/**
 * Layout to render the field label
 *
 * @var  string
 */
protected $labelLayout = 'joomla.form.field.label';

/**
 * Prefixes to use to render the field.
 *
 * @var  array
 */
protected $layoutPrefixes = array();

/**
 * Suffixes to use to render the field.
 *
 * @var  array
 */
protected $layoutSuffixes = array();

or in your form XML file:

<field
    name="show_title"
    type="list"
    class="chzn-color"
    label="JGLOBAL_SHOW_TITLE_LABEL"
    description="JGLOBAL_SHOW_TITLE_DESC"
    label-layout="joomla.form.field.label2"
    layout-prefixes="bootstrap3"
    layout-suffixes="j25"
    >
    <option value="">JGLOBAL_USE_GLOBAL</option>
    <option value="1">JSHOW</option>
    <option value="0">JHIDE</option>
</field>

3. Overridable getRenderer

If you want to change the default paths or load your extended class instead of JLayoutFile you can nor override the getRenderer method:

/**
 * Get the layout used to render the field.
 *
 * @param   string  $layoutId  Layout to render
 * @param   mixed   $options   Optional custom options to load. JRegistry or array format
 *
 * @return  JLayoutFile  The layout
 */
public function getRenderer($layoutId, $options = array())
{
    $prefixes = !empty($this->element['layout-prefixes']) ? explode(',', $this->element['layout-prefixes']) : $this->layoutPrefixes;
    $suffixes = !empty($this->element['layout-suffixes']) ? explode(',', $this->element['layout-suffixes']) : $this->layoutSuffixes;

    $options = array_merge(array('prefixes' => $prefixes, 'suffixes' => $suffixes), $options);

    return new JLayoutFile($layoutId, null, $options);
}

This gives a very flexible tool to developers.

Plugins improvements

1. Layout support

Now in your plugin you can do something like:

return $this->getRenderer('default')->render(
    array(
        'context' => $context,
        'row'     => $row,
        'params'  => $params,
        'page'    => $page
    )
);

It will search a default.php layout on:

Include Paths: Array
(
    [0] => /var/www/jcms3x/templates/protostar/html/layouts/plugins/content/vote
    [1] => /var/www/jcms3x/layouts/plugins/content/vote
)

Note: All the plugins are still using the old hardcoded method. Only the plugin content/vote has been converted for testing purposes.

2. Layouts information on debug

Now the debug console shows all the information of the layouts loaded in the current page:

Testing

Required tests include:

Check that all list fields are shown and work correctly (including tags and all other extending fields)
Check that user field works correctly
Check that when you enable the option to show votes on articles it's dispalyed correctly
Make performance tests with & without this patch to ensure that layouts doesn't overload system.
Common layout override tests with prefixes, suffixes, include paths....

wilsonge · 2014-03-04T04:17:13Z

I owe you so so so many beers :D :D

wilsonge · 2014-03-04T04:22:10Z

libraries/cms/form/field/user.php

Whilst it should be impossible to get here I think we should be returning an empty string here rather than null - as people often echo the contents of the input

You can echo a returned null.

For semantic reasons, wouldn't it make sense to return false? I do recall there being some discussion about this in the past and I think we currently have a mix of both.

phproberto · 2014-03-04T04:28:33Z

I'll review travis errors tomorrow 🎯

Bakual · 2014-03-04T07:35:48Z

I think you forgot to include the layout for the vote plugin? Vote doesn't show currently.

About the stats collecting. If I saw this correct you're doing that always? Wouldn't it make sense to only do that when debug is enabled? Otherwise we just generate overhead here for no reason.

About the prefix, I'm not sure I understand the intention here:

So for example if you are on a template that supports both bootstrap2 & bootstrap3 mode you can put in the layouts/bootstrap3 folder the specific layouts for bootstrap3.

As I understand it, the prefix (as well as suffixes, autolanguage and others) is set by the extension. How does that help a template? Or is that something a template could set globally?
Developers likely only add those if they provide different layouts themself. So most will not enable that. After all it's also a bit of a performance issue to look up ~15 override paths per layout (3 from autolanguage, 3 from autoversion, 7 from prefix plus the regular ones).
Writing this, I just wonder what exactly happens when we have both prefixes and suffixes set. Do they multiplicate? Then that would make the above ~42 (7 prefix * 6 suffix) include paths to look up... That's makes be a bit feared right now.

Generally speaking, while I like what you did here, I fear this PR got a bit big which makes it harder to test. Especially since there are so many places one would have to test things. If you could for example split it up into a part for the basic enhancement (maybe with the plugin) and another for the JForm part, that would help. If the JForm one does depend on the basic one, it may be better to do it incrementally.

wilsonge · 2014-03-04T10:03:00Z

Would we be able to integrate into the JForm class a method to add a prefix/suffix to the layouts for all form fields? So if I want to say load bootstrap 2/3 classes or even frameworky. I can load that for all fields in the form instead of having to override the layout path for each individual field?

Just to be an arse :D

phproberto · 2014-03-04T11:46:59Z

Sorry I forgot to answer before closing the PR. Thanks for checking it.

@Bakual :

I think you forgot to include the layout for the vote plugin? Vote doesn't show currently.

Yes. I forgot the vote layout. Thanks for pointing it. I added it before closing this to be sure I have all ready here.

About the stats collecting. If I saw this correct you're doing that always? Wouldn't it make sense to only do that when debug is enabled? Otherwise we just generate overhead here for no reason.
about the

It's not a overhead to store 10 vars (counters) in an array. There is no performance issue for having it enabled it just increases counters and get microtimes. Maybe in the future if the system ges complex it will make sense. I invite you to waste your time doing performance tests.

About prefixes, suffixes: they are there for anybody that wants to use them. Of course you have to use the tools in a good way. That's the main reason to have now the layouts debug. The caching system will also help. I'll appreciate that the next time I propose something (with the tools to test it) you waste your time testing it before suggesting issues.

Generally speaking, while I like what you did here, I fear this PR got a bit big which makes it harder to test. Especially since there are so many places one would have to test things. If you could for example split it up into a part for the basic enhancement (maybe with the plugin) and another for the JForm part, that would help. If the JForm one does depend on the basic one, it may be better to do it incrementally.

This is something that needed to go together. The system was done to be a first step into the right direction and to start using the tools in the right way at the same time. 3.3 release was next week and you knew it.

I know it's not something easy to test. It wasn't to code and double check it. That's why I closed the PR. I'm not ready to rush during a week to explain why I use !empty() or discuss what should go inside a layout or not. Not prepared for a full week like that to get this merged. It's quite unmotivating to talk about the finger when it's pointing to a bigger thing.

I have lost a lot of sleeping time to get this done. I won't lose more.

@wilsonge I faced that problem but I'm not sure modifying JForm is a good move. Probably the best move here would be to search the way to allow form XML overriding. This will solve this and many other issues.

Bakual · 2014-03-04T12:25:08Z

@phproberto I certainly didn't want to demotivate you and I am sorry if it came across like this.
It's hard to test something when you don't know the ins and outs of the code involved.
To test this I probably have to invest a whole evening. I'm happy to do that because I think it's a good move. But I would like to understand it prior to testing. That's why I asked the questions based on looking at your description (and briefly code) to get it right.

phproberto · 2014-03-04T12:49:48Z

I've sent a new commit to add layout support for views. It's intended to replace the old system (template folders are the same). So we cannot use it on core components for now because BC but we can start using it for new views and start encouraging extension developers to use it.

To switch to the new system you have to replace in your view display method:

parent::display($tpl);

with:

echo  $this->getRenderer('default')->render(
    array(
        'items'      => $this->items,
        'pagination' => $this->pagination,
        'state'      => $this->state,
        'user'       => $this->user
    )
);

phproberto · 2014-03-04T17:42:12Z

I removed the new mvc view path. For classes that use the view folder they can override the getRenderer method.

Branch rebased

Bakual · 2014-03-04T18:21:16Z

libraries/legacy/view/legacy.php

Just some small inconsistency which jumped me here: You first used "/" and second '/' on the same line.

hahahahaha are you kidding me?? OMFG

wilsonge · 2014-03-04T23:35:23Z

OK awesome :) I've been really busy today but I'll have this tested tomorrow (afternoon/evening) :D

phproberto · 2014-03-06T08:44:30Z

phproberto · 2014-03-06T10:38:16Z

I converted getRenderer view method to public to be able to render a view inside another view (pseudo-HMVC) 💃

wilsonge · 2014-03-06T10:41:52Z

👍

phproberto · 2014-03-07T02:23:39Z

Rebased vs latest staging to resolve conflicts

wilsonge · 2014-03-10T22:58:55Z

Roberto - somethings weird. I can't seem to use pagination in the article manager (it works in a clean 3.2.3 install so not sure what the hell is going on) - I don't understand at all why your changes would affect that specific pagination though :/

wilsonge · 2014-03-10T23:06:36Z

Further to the above it also appears in banners (and is related to the search tools - as these are the two components where search tools appears to be used) - it would appear that everytime to press anything in pagination for some reason unpublish is being selected in the search tools - even when it's not open - god knows why

wilsonge · 2014-03-10T23:38:57Z

libraries/joomla/form/field.php

Much more minor thing but shouldn't this return true if there are no requirements?

Definitely. Fixed it. Thanks!

phproberto · 2014-03-12T01:48:45Z

Thanks for testing @wilsonge

The problem with pagination was that it was identifying "" as 0. That's why unpublished was always selected

wilsonge · 2014-03-12T01:50:58Z

Ahh I see. I've just hit a PR into your branch that starts to deal with the unit test failures. Not sure how you want to deal with the layout changes - whether in the JLayout or in the unit tests themselves. Updates look good on a quick run through in localhost but will test more thoroughly tomorrow as pretty tired right now :)

phproberto · 2014-03-12T01:56:55Z

I'm not sure neither but maybe in the unit tests is better no? To compare field properties

wilsonge · 2014-03-12T02:11:09Z

Hmm probably. Not quite sure how we'd go about comparing the properties though other than doing some nasty preg_replace checks or something like that :/ Will have a ponder. At least the unit test failures now are just due to the spacings in the fields

In the meantime I've found an absolutely _critical_ bug. See my PR :P

… are present

adster101 · 2014-09-01T09:35:56Z

Does anyone know what's happening with this PR?

Also, does this work with all form fields or just lists?

wilsonge · 2014-09-01T10:05:25Z

Sorry been meaning to reply to you on the mailing list! Basically we decided to expand the scope a bit and to implement it for the majority of form fields here: https://github.com/joomla-projects/cms-naked

However as you can probably see it lost popularity pretty quick. Me and @phproberto need to chat about what we're gonna do with it!

adster101 · 2014-09-01T10:25:37Z

Oh okay, it's just that as it stands it's not possible to override the template (without a plugin) to accommodate any other CSS library that BS 2.3.

Would it be possible to just add layouts for the form fields? I can't see any b/c issues in doing this?

Can you point to any examples of where this has been done so that I can see the correct format / style for the overrides etc. I might be able to add them and put in a PR or two if I know what needs to be done.

wilsonge · 2014-09-01T12:11:59Z

Just use this PR as a base example with the rendering of the layouts. Or make a similar PR into the cms-naked branch and I have permissions there to merge that.

I completely agree by the way! I've hacked this into one of my sites to get integrations sorted in the frontend for the editing views.

phproberto · 2014-09-01T13:48:47Z

Sorry @adster101 I should also jump into the issue. I was waiting for v3.5 but I think we have to start making that naked CMS.

I'll update the PR against the naked repo tonight and link it here so @wilsonge and me can use it as a starting point to also receive feedback.

Thanks!

adster101 · 2014-09-03T08:37:33Z

What is 'naked' CMS? Is it just a place to add the layouts that will be merged into the staging branch at some point or something else?

@phproberto did you find time to update the repo?

Thanks.

wilsonge · 2014-09-03T09:47:58Z

Yeah so it's a place where we're gonna work on the next layer of making Joomla override-able. Firstly moving as much hardcoded stuff into JLayouts. But also thinking ahead a bit - adding in a getRenderer function (https://github.com/joomla-projects/cms-naked/blob/master/libraries/cms/plugin/plugin.php#L153 ) so that we can investigate not even being dependent on JLayouts.

The idea was that this would go into 3.5 (coming out ~now) but as you probably know 3.4 is being mega late so not quite sure where this is gonna fit in

adster101 · 2014-09-03T09:58:59Z

Can you elaborate a bit on how the renderer would break the JLayout dependency? I mean what would the other rendering options be?

Is there any reason why this PR can't be merged with 3.4, when it's ready?

Bakual · 2014-09-03T10:10:12Z

Can you elaborate a bit on how the renderer would break the JLayout dependency? I mean what would the other rendering options be?

Imho the longtime idea is that you could also use Twig or similar for rendering purposes. At least I understood it like this.

Is there any reason why this PR can't be merged with 3.4, when it's ready?

It could go into 3.4 in theory, but that would be something the release manager (currently for 3.4 that's David Hurley) has to decide. For 3.4, the main focus is a different one and since we're already delayed I wouldn't focus on this one. But if it gets ready in time, maybe it can be merged already.
On the other hand, the stuff in cms-naked is likely going to be a major focus for 3.5. So it would make sense to do this PR together with 3.5.

Fedik · 2014-09-20T12:42:20Z

I am a bit play with new JLayoutFile and it really cool thing 🎸

Have couple suggestions:

1 Posibility to get fullpath without rendering the layout file, something like:

    public function getFullPath()
    {
        if (!is_null($this->fullPath))
        {
            return $this->fullPath;
        }
        // Search
        return $this->getPath();
    }

2 Throw Exception in render() if no layout file found. Currently if no layout found user just get a blank page, that very confused. It not a problem when need to render 1-2 layouts, but when there 100 different layouts can be difficult to find out.

3 What about ability use the priority in addIncludePath()?

Example, I want add own fallback path, so I do

   $layout->addIncludePath('/root/path/my/fallback/path');

And got:

  'includePaths' =>
    array (
      0 => string '/root/path/my/fallback/path'
      1 => string '/root/path/templates/isis/html/layouts' 
      2 => string '/root/path/layouts'
   )

That not really what I want, because I want that my fallback work only when no layout found in the template (or component) folder.
I think something like $layout->addIncludePath('/root/path/my/fallback/path', $priority); would be cool, ~~but I have no idea how this can be done~~ 😄

added:
I think it can be as b/k solution, for the priority support:

public function addIncludePathToPosition($path, $position = 0)
{
    array_splice($this->includePaths, $position, 0, $path);
    return $this;
}

alex-filat · 2014-12-06T18:22:22Z

Hi,

please ckeck out review of the code of class JLayoutFile

Suggest don't run any debug function if debug not requested in options. I undestand that it makes a lot of "if ($this->debug)" but perfomance is more important then pretty code
In getPath method call "find" twice

$this->fullPath = JPath::find($this->includePaths, $rawPath);
if ($this->fullPath = JPath::find($this->includePaths, $rawPath))
{
   $this->addDebugMessage('<strong>Found layout:</strong> ' . $this->fullPath);
}
else
{
   $this->addDebugMessage('<strong>Unable to find layout: </strong> ' . $this->layoutId);
}

Method JLayoutFile::getPath() checks that file exists so you don't need to check it again in JLayoutFile ::render() method
Sugest also make cache on JLayoutHelper::render level from $options passed to render method and keep JLayout instances as value. It will work faster then JLayout cache. As a consequence JLayout's cache can store paths for LayoutId only , without md5 from all options. Some times it also very usefull when developer knows that state of JLayout whould not be changed, so we don't calculate every "render" md5 and json.

dgrammatiko · 2015-01-07T12:21:16Z

What is the decision on this one? If it is ready to commit I would like to bring the fields user, media and content history (versions) to layouts and use bootstrap modal (for protostar and isis) and thus drop completely the loading of mootools on joomla core...

wilsonge · 2015-01-07T12:48:27Z

The decision is that it is being held back for Joomla 3.5 - but the JLayout conversion will be centre feature of that release

dgrammatiko · 2015-01-07T12:51:33Z

Sounds good, thanks George

Fedik · 2015-02-14T13:05:07Z

one more note,
I will leave here before forget 😄
about Prefixes support

suggested search with prefixes is: template with prefix => component with prefix => template without prefix => component without prefix
it make possible case when template override will not work

so I think would be better make search like: template with prefix => template without prefix => component with prefix => component without prefix

dgrammatiko · 2015-05-16T12:30:58Z

@phproberto why did you close this one? There’s another approach/solution/code for this?

phproberto added Needs JoomlaCode Tracker Item labels Mar 4, 2014

phproberto added Has JoomlaCode Tracker Item and removed Needs JoomlaCode Tracker Item labels Mar 4, 2014

wilsonge reviewed Mar 4, 2014
View reviewed changes

phproberto closed this Mar 4, 2014

phproberto deleted the layouts-field branch March 4, 2014 10:00

phproberto restored the layouts-field branch March 4, 2014 12:14

phproberto reopened this Mar 4, 2014

Bakual reviewed Mar 4, 2014
View reviewed changes

wilsonge reviewed Mar 10, 2014
View reviewed changes

phproberto and others added 3 commits May 31, 2014 04:36

[fix] return true on validate field requirements when no requirements…

4a958b3

… are present

Use assertTag

879cbe1

[fix] duplicated function declaration

cb0f935

brianteeman added the New Feature label Aug 8, 2014

nicksavov removed the Has JoomlaCode Tracker Item label Aug 21, 2014

wilsonge mentioned this pull request Oct 18, 2014

Move user field to bs modal #4514

Closed

This was referenced Oct 19, 2014

Move media field to bs modal #4513

Closed

Move content history to bs modal #4561

Closed

dgrammatiko mentioned this pull request Nov 21, 2014

Why custom path taking highest priority in Layout #5157

Closed

dgrammatiko mentioned this pull request Dec 6, 2014

Layout engine has very bad perfomance #5334

Closed

dgrammatiko mentioned this pull request Jan 9, 2015

Move form field user to layouts and use Bootstrap modal #5655

Merged

dgrammatiko mentioned this pull request May 12, 2015

Layout for the field repeatable #6917

Closed

phproberto closed this May 16, 2015

joomla-cms-bot added the Language Change This is for Translators label May 16, 2015

Uh oh!

Conversation

phproberto commented Mar 4, 2014

JLayout improvements

1. Chainable methods

2. Suffixes improvements

2.1 Add suffixes dynamically

2.2 Automatic version suffixes

2.3 Automatic language suffixes

3. Prefixes support

4. Cached file searches

5. Statistics

5.1 Stats details

6. Better includepaths handling

6.1 setIncludePaths

6.1 resetIncludePaths

6.2 loadDefaultIncludePaths

JFormField improvements

1. Field requirements support

2. Layouts support

3. Overridable getRenderer

Plugins improvements

1. Layout support

2. Layouts information on debug

Testing

Uh oh!

wilsonge commented Mar 4, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phproberto commented Mar 4, 2014

Uh oh!

Bakual commented Mar 4, 2014

Uh oh!

wilsonge commented Mar 4, 2014

Uh oh!

phproberto commented Mar 4, 2014

Uh oh!

Bakual commented Mar 4, 2014

Uh oh!

phproberto commented Mar 4, 2014

Uh oh!

phproberto commented Mar 4, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilsonge commented Mar 4, 2014

Uh oh!

phproberto commented Mar 6, 2014

Review all extended JFormFieldList fields

Uh oh!

phproberto commented Mar 6, 2014

Uh oh!

wilsonge commented Mar 6, 2014

Uh oh!

phproberto commented Mar 7, 2014

Uh oh!

wilsonge commented Mar 10, 2014

Uh oh!

wilsonge commented Mar 10, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phproberto commented Mar 12, 2014

Uh oh!

wilsonge commented Mar 12, 2014

Uh oh!

phproberto commented Mar 12, 2014

Uh oh!

wilsonge commented Mar 12, 2014