If we need such feature then it should be in FileLayout calss, that should throws some LayoutNotFoundException when $options['required'] = true; and the layout file not found. So it can be also used in other places easily.

The field class looks as wrong place for it, to me

Isn't the already existing debug feature of JLayouts not sufficient? Instead of breaking the whole rendering of a form...

In the field class it is easier to override for your own handling.

If we need such feature then it should be in FileLayout calss, that should throws some LayoutNotFoundException when $options['required'] = true; and the layout file not found. So it can be also used in other places easily.

The field class looks as wrong place for it, to me

$options['required'] = true; fnot handled in FileLayout for fields, but in JForm when testing the field, unless a value is sent.

$options['required'] = true; fnot handled in FileLayout for fields, but in JForm when testing the field, unless a value is sent.

I meant, it should be in Layout class not in Form/Field

I meant, it should be in Layout class not in Form/Field

In the field class it is easier to override for your own handling.

field class = FormField / xxxField like RadioField.

In the field class it is easier to override for your own handling.

When you need in the field class, you do: $renderer->setOptions('required', true)

Easy

I was testing your suggestion.
In the FormField in the method getRenderer() I added $renderer->setOptions(array('required', true)); (by the way, array|Registry is expected).

The result is the same as described above.
A label without field and without error message.

Please test your suggestions before you make them. Otherwise this will only cause confusion. Thanks :-)

Sure, it does not work, because no one implemented it.
That what I have suggested, if it need then it should be implemented on Layout class instead of Field/Form: #30079 (comment)

The check, if a layout is set, is currently done in FormField->getInput() and throws an error if not.
This check has been extended by me to ensure that the layout used really exists. It will throw the same error message if not.

I have thought about why the check makes sense at this point.

There was also the option to throw an exception at a suitable place in the FileLayout->getPath(). Here the error handling for a field like the RadioField is not changeable.

Developers, who might have already solved this with an override, or want to solve it differently, could not do so now. B/C break.

My implementation in the FormField introduces this check without B/C break.

You are free to pursue this problem in a completely different approach and implement it in your own PR. I would be happy to bring in my knowledge of FormFields and FileLayout to test or improve your implementation. Otherwise I would appreciate it if you would contribute to constructively improve my proposal.

If you are responsible for FileLayout and FormFields in the core, and prefer to get an issue instead of a PR, so that you can think about the solution yourself, let me know, saves me a lot of time and work.

Thanks for your time and patience.

Hi @degobbis I'm sorry that this has never been merged into the J3 series. While I was involved in the initial thought process building up to this PR. I agree now that this PR should not be merged into J3. I understand and remember our thoughts but I'm not intending to change the behavior now with the last regular release of J3

Thanks for the PR and thanks for understanding