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

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.

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

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

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()

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 :)

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 😉

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.

I have tested this item ✅ successfully on 4615028

Since I had the same use case and came up with a similar solution, I tested it with my code and this PR works as expected. thanks.

@bembelimen here still need few fixes.

Remove following

And replace it with:

$this->layoutIncludePaths = explode(',', (string) $value);

Also add a getter for this property.

Remove addLayoutPath method.
As we talked this not going to work reliable. The configuration should be done via attribute.

Then it should be workable solution and probably even will pass the tests 😉

@Fedik thanks!

Thanks, that looks better.
Few more things.

What is needed to achieve that User can do:

$layouts = $field->layoutPaths;
$layouts[] = 'path1';
$layouts[] = 'path2';
$field->layoutPaths = $layouts;

For this still need few more changes.
Do not use array_unshif and JPATH_ROOT in the setter

Just do:

$this->layoutPaths = is_array($value) ? $value : explode(',', (string) $value);

Add JPATH_ROOT in getLayoutPaths() where you actually add these paths to defaults.

$this->layoutPaths = is_array($value) ? $value : explode(',', (string) $value);

Now it makes sense for me :-) Changed + Thanks again

I have tested this item ✅ successfully on 5e52ced

I have tested this item ✅ successfully on 2a11f1e

I have successfully tested this! Thank @bembelimen @LadySolveig @softforge @Bodge-IT

RTC

Thanks @bembelimen for this work and thanks @LadySolveig and @exlemor for testing.

So this adheres to the override mechanism for layouts? I hope it does because if the dev should dictate the front end code then something is really wrong…