Why would you mark a formfield as required and at the same time don't show it to the user?
Sounds like a logical error in the code to me, not a particular issue with the showon feature.

Or do you require a "conditional required" attribute? Then the showon JavaScript would have to toggle the "requried" attribute, but I'm not sure that's really the behaviour we want.

In any case, it's likely not only the validation script that causes this issue. The browser itself may check the form as well and prevent sending the form if a required field has no value.

@Bakual Imagine I'm creating a unsubscribe form and the user has to pick the reason. If the user chooses "Other" a text field will appear and the user has to fill it with reason. I want that text field required but only if the user chooses "Other".

I think force to browsers to do that is not feasible, so Joomla! should provide some sort of mechanism to support this kind of behaviour as it's Joomla who is supporting this feature in first place.

I think force to browsers to do that is not feasible

Browsers already do check required attributes and prevent sending the form. That's the purpose of that attribute ?
So if that's not the behaviour you want, you need to toggle the required attribute using JavaScript. Should that be done by the showon feature or is that something you should do in your extension (using some custom JavaScript for your usecase)? Personally I'd say it should be done in the extension, but if others see it as a requirement I think it should be possible to add it to the showon JavaScript code.

I think this should be done by Joomla for the simple reason that it will now create unexpected behaviour and confusion.

If we stick to the example given by @vistiyos then setting the other field to be required would imply that it of course should only be required if it is shown. I think many developers will unfortunately forget to test this and release extensions that are broken and thus it will hurt Joomla overall.

Also, I do not think it should be terribly difficult to implement?

Also, I do not think it should be terribly difficult to implement?

If you find someone with JavaScript skills that is willing to do it, it should be simple. The file that handles it is https://github.com/joomla/joomla-cms/blob/staging/media/jui/js/cms-uncompressed.js

So here's the problem. If you declare it required in the XML manifest, even if you toggle the behavior in the UI, it's probably still going to run into issues with server side handling. This is where we get into a slippery slope, do we really want what is in essence a UI directive to be used for more than altering the UI? I say no.

If something is conditionally required you can't declare it as always required and nothing in the core supports this form of conditional requirements so it'd have to be done with extended handlers (i.e. a custom JFormRule class for server side validation and custom JavaScript for client side).

it's probably still going to run into issues with server side handling.

• yes , i run into it just now

I have just tested JS changes to find fields inner to the hidden containers and

• add / remove classes 'required' , and 'validate-*',
• do / undo attachForm action for required

and it works, but i run into the server side validation requiring the field

Then to just set a fake value, is dangerous, only option i see to overcome this is

• use the "default" defined in the XML file or a "hidden-default", but none JFormField* adds an attribute like:

data-defaultvalue=""

i use a similar in my forms

now if the above is added we can even reduce the extra JS overhead of this feature, by not doing class addition/removal/check, and attribute addition/removal/check,

and instead just set the default value, which besides of being a good option, since UI says that it is unused, the PHP code should never use it, so no problems right ?

If you have to set the default value to a data attribute and dynamically set that value to a form field to make it pass a required check, IMO you've screwed up badly. If a field is required, it's required and should rightfully throw a fit if it's missing data. If you want to conditionally require a field, IMO that's exactly why Joomla should be providing APIs to make it easy to hook into events so that you can easily detect the condition that makes something required, but it's not Joomla's responsibility to be doing all of this work itself.

Not having considered the server side aspect of this, I tend to agree that we should let everything stay the way they are. If people need a custom behavior like described in the original issue, they will have to implement it them selves.

thinking about my idea regarding the usage of default value, there is a contradiction

why add a default value if required ?

• instead just make it non-required

1. and PHP code will just use the default value,
2. and on form reload, the form will load the default value too

So we return to the possibility of setting a dummy value, which i think it is possible, because JS can detect it and clean on field becoming visible

• thus i could suggest, an attribute for XML form files: unused_default="..."

:facepalm:

why add a default value if required ?

Why define SQL fields with things like NOT NULL DEFAULT '' since the NOT NULL part is basically saying the field has to have some kind of data?

Quite frankly, I think this whole dummy value or exposing a default via JavaScript or data attributes is just someone defining their forms in a really stupid way and now it's being suggested that Joomla be more tolerant to people making bad design decisions. If you have a required field and you're using JavaScript to set a default value on submit to make it pass validation, is that field truly required or are you just marking it as such to hope the user pays attention and gives data?

why add a default value if required ?

@mbabker

lol , you have not read the rest of it ?
if you read the rest of it,
then you will see that i meant the reverse,

• i meant if field has a default value

then leave the default value then make it non-required just for the purpose of avoiding this bogus behaviour

i often mistype things in english and embarrass myself (((

2 cases in global config of hidden fields preventing form submit when empty but hidden:
ID: jform_cachetime
ID: jform_smtpport

about the required thing

• what UI "tells" to the user, should match what server validation does, and what the rest of the code does with the unused field, simple

Even core has cases where conditional requirements would be beneficial. But fact is they aren't supported. So either devise an API that makes it easy to do this (that doesn't mean core has to fully support conditional requirements; maybe a JFormRule subclass to help with simple checks in this scenario and JavaScript hooks in the showon script so listeners can react to changes and that'd be more than enough to build from) or either the fields are always required or never required. Either way I don't think exposing defaults in data attributes and setting values in JavaScript on submit before validation happens is a good idea by any means since as I said if you're doing that you've probably screwed up your form definition.

I am not sure about this,
will it hurt, if server side validation makes use of showon ?

Will it hurt? Not really. But why should server side validation be dependent on the state of the UI? showon is essentially a UI feature to hide options that don't apply based on the configuration, but the fields are still part of the form, just wrapped in a Bootstrap collapse element to show/hide them, so it's really not doing anything to alter the state of the overall form.

I am going to close this. Its not a bug but expected behaviour when you understand that shown is just a UI feature to hide options.

I had exactly the same problem, and this would be a nice feature - since the data is allready there :)

Solved it with a few slightly different xml forms, and then depending on users submit I load adequate xml form - for validation....

Ok these comments are a couple years old but i've been building forms like this for years a professional webdesigner and the whole internet is built with this kind of functionality.

The use case:
A field needs to be filled in by user when it is being displayed based on other settings. (almost all forms on internet have this use case).

Solution?
I would really like to know what is a proper solution to this use case. because in the replies i only read you're doing it wrong but no info on how it should be done instead.

Since all form builders for joomla have this functionality, and all the internet has this functionality. (where a required field is only shown when it is required).

How can this be done properly in Joomla? I haven't found the solution after an hour of searching online.

@brianteeman could you please give me some insight in my last post question?
Kind regards,
Tom

@TLWebdesign As written the showon feature is working as intended. Your use case isn't covered by the showon feature and would need more logic (eg also server side logic) anyway. So you need to do that in your extension yourself and add those functionality.

It's not only about UI, but logic. Some form conditions make different requirements necessary. Customer Class A may need to enter more data than customer class B. I agree that supporting the required option based on dynamic form behavior should be supported as it is common usability. This was not thought about when showon was initially done, but atm i see no other place to talk about this.

@stell It's clear for all people what the use case is. But showon isn't the solution for this usecase. You need custom logic in your own component to deal with that.

Also it's quite useless to comment on closed issues.

@Bakual Of course custom logic is needed. Custom fields started small and people were saying custom fields are not for CCK, but look where we are now. This should be a validation like behavior on client and server side. I don't think this is something every dev should solve in his own component because native logic already makes it possible to hide a required field.
Apart from this it is always important to know what requirements are asked for.