The showon feature is entirely client side (browser) logic, it works great for what it is.

A requireon feature would need to work in both the client and server, that makes this type of behavior rather complex for a core system and I would suggest if you need it you are best suited writing a custom FormRule implementation for the server side validation.

@babker Correct me if I'm wrong. If we already have FormRule why not build requiredOn both client-side and server-side. Where the rules would apply both? JavaScript based on showOn for a front-end and a back-end processor building FormRule based on the field rules? That would require less code to write from a developer. Just build a form, write the rules in the form and that's it. The markup would be known cause of showOn. The FormRule does provide a $form object so you should be able to check other fields values conditionally. I see only 2 difficult parts in here. One is the ability to use FormRule build programicaly, that would probably require adjusting Form object definition. The second difficulty is translating potential java script requireOn rules to PHP. Nothing looks impossible, too complex or a potential problems generator. Not to mention that nothing has to be changed for a backward compatibility.

@babker Correct me if I'm wrong. If we already have FormRule why not build requiredOn both client-side and server-side. Where the rules would apply both? JavaScript based on showOn for a front-end and a back-end processor building FormRule based on the field rules? That would require less code to write from a developer. Just build a form, write the rules in the form and that's it. The markup would be known cause of showOn. The FormRule does provide a $form object so you should be able to check other fields values conditionally. I see only 2 difficult parts in here. One is the ability to use FormRule build programicaly, that would probably require adjusting Form object definition. The second difficulty is translating potential java script requireOn rules to PHP. Nothing looks impossible, too complex or a potential problems generator. Not to mention that nothing has to be changed for a backward compatibility.

A feature to conditionally show fields in the UI is majorly different from a feature to conditionally require fields.

Conditionally showing fields is a lot less processing power as it is mostly JavaScript listening for change events then toggling display: block; or display: none; on a UI element (breaking it down to the simplest thing).

Conditionally requiring fields is a lot more effort. In the browser at the absolute minimum this should be toggling the required attribute of a <input> or <select> element, possibly changing classes on it and its related <label> element depending on the UI framework and designer's preferences, and requires extra conditional processing of fields and the form itself on both client side submission (any onsubmit event listener) and the server side submission (save action). This bit is highly complex and honestly not an easy thing to provide a high level abstraction for that will suitably work for everyone (especially because it is going to turn into a "I need this field to be conditionally required if one of these three fields has X value" type of requests), which is why I suggest it is best left to a developer to implement locally.

If you have a conditionally required field, this is a perfect case for using extended server side validation and rejecting the submission if it fails. Trying to make a behavior that works in both client and server is asking for trouble.

@mbabker You over-complicating that. I already modified showOn once to archive that functionality and it wasn't as problematic as you say. The argument that single field should be required if one of 3 has a certain value is missed as showOn already allows to hide/show field using such rule. And I was using it both for required and show rules on a 40-80 fields form. The only new part is the server-side. And as we already have FormRule it can be used. Form is already processed server-side when it is saved and validation is fired. Your'e just extending the validation. But building a whole new login.

If someone really thinks they can build such a mechanism that will work with some of these edge cases that people throw at things, then by all means go for it. Personally, I really think conditionally required rulesets belong to your server side validation logic and isn't something that should leak into the client (I'm also one of those who uses the client for only basic validation and doesn't try to have my form validation rules in both the client and server) and I don't think this needs to be a core CMS feature.

@artur-stepien can this be closed?

@franz-wohlkoenig There is the usual "no cause of reasons" so I assume it can be closed.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/23444

thanks @artur-stepien