[5.3] Allow adding additional layout base path to form fields

[bembelimen]

Summary of Changes

Currently the usage of form field layouts is very encapsulated in the FormField class, which means that it's not possible to change/add additional layout include paths via e.g. plugins.

There are three ways to add an alternative path

1. via XML attribute "layoutIncludePath"
2. via the ->addLayoutPath($path) method
3. via the $option attribute in the ->renderField(...) or ->renderFieldset(...) methods

Testing Instructions

There are several ways to test this PR, one would be to create a plugin and manipulate the form with the onContentPrepareForm event.

But to the test the raw functionality you can do the following:

• Create a folder "otherlayouts" in your Joomla! root
• Add the following folder structure joomla/form to the "otherlayouts" folder
• Copy the file layouts/joomla/form/renderfield.php to the new path
• Change this file somehow to see the difference when it's loaded (e.g. add some output like "Hello World" somewhere in the file)
• We will test now at the frontend registration, so open the form

Option 1:

• Open components/com_users/forms/registration.xml
• Add after line 17 the following attribute: layoutIncludePath="otherlayouts" (it should be in the "name" field)
• Refresh registration, now you should see the "Hello World" from above at the "name" field

Option 2:

• Open components/com_users/tmpl/registration/default.php
• Change line 44 to: <?php echo $this->form->renderFieldset($fieldset->name, ['layoutIncludePath' => JPATH_ROOT . '/otherlayouts/']); ?>
• Refresh registration, now you should see the "Hello World" from above at each field

Option 3:

• Open components/com_users/tmpl/registration/default.php
• Add the following code somewhere:

$field = $this->form->getField('name');
$field->addLayoutPath(JPATH_ROOT . '/otherlayouts');
echo $field->renderField();

• Refresh registration, now you should see the "Hello World" from above at a "name" field

Actual result BEFORE applying this Pull Request

• No alternative layout path possible

Expected result AFTER applying this Pull Request

• Alternative layout path possible

[brianteeman]

If I understand this correctly (and I'm not certain that I do) this will add a layout in a location that cannot be overriden by the template

[Fedik]

I am not sure what you trying to do, but when you need such thing you doing something wrong 😉

Developers already can set differemy layout per field with $field->layout = 'potato.input'
When you want custom renderLayout then it need something like I tried in past #42648 (can reopen), it is more inline with our general API.

[bembelimen]

If I understand this correctly (and I'm not certain that I do) this will add a layout in a location that cannot be overriden by the template

I guess the only missing area is the xml, so there a template call could be added. The other two options can be added by the plugin author.

I am not sure what you trying to do, but when you need such thing you doing something wrong 😉

Load a form via com_ajax and a plugin. There is no way to provide any layout via the plugin when you add a new field by your own, because Joomla looks into com_ajax and the template, that's it.

[brianteeman]

If I understand this correctly (and I'm not certain that I do) this will add a layout in a location that cannot be overriden by the template

I guess the only missing area is the xml, so there a template call could be added. The other two options can be added by the plugin author.

A plugin author should not need to do anything in order for a template to create and use an override. There should be no dependence in the relationship

[Fedik]

Load a form via com_ajax and a plugin. There is no way to provide any layout via the plugin when you add a new field by your own, because Joomla looks into com_ajax and the template, that's it.

For this case need to set Component and Client

joomla-cms/libraries/src/Layout/FileLayout.php

Line 431 in 4a5d4d5

public function setComponent($option)

However we cannot expose every possible options of the Layout Class to the Field class, it will be just bad.
For this we have FormField::getRenderer()

joomla-cms/libraries/src/Form/FormField.php

Line 1387 in 689cde9

protected function getRenderer($layoutId = 'default')

Which developer can overdie in its field class, and set required options.
So if you have your own custom field, you can do exactly this 😉

The approach suggested in the PR have other drawbacks and will not work in all cases, but that is to much to write :)

[LadySolveig]

To be honest, I have exactly this particular problem. It feels much cleaner to me personally to be able to insert my Web Component directly into renderField as a wrapper around the standard fields instead of having to inherit every single standard field and then just overwrite the layout path. I don't want to reinvent the wheel, but simply extend the existing one. But then I'm probably doing something wrong. @Fedik 😉

[Fedik]

To solve the issue with renderField it better that way #42648 (comment) , or override the field layout.

The Form Field class should only recieve the layout ID, nothing else. And how it going to be rendered is defined by renderer inside getRenderer method. (Would be nice to think a way to define a global renderer per form, but that another topic)

Addittionaly, the getField() method always return new field instance, and so if you do $field->getField()->potato = 1 in the plugin, then in the rendering proces in View layout this value still will be default one, not what you have set in plugin.