November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
I'm using Forms 4.8 and go to Admin mode change the Items property to localized. I tried to submit some different values from different languages, but do not got the error "Unexpected value is not accepted.". Could you please check again? If the issue is still there, could you describle steps to reproduce in details, so I can look at it deeper.
Thanks
We are running Forms 4.6
I was able to reproduce it in following way:
Hi, I created a bug AFORM-1445 for investigation to fix. To workaround, you can make Forms work in non-js mode, it will run valid validation process.
Hi,
I understand you were able to reproduce the issue as well right?
It seems that in non-js mode it is not giving an error, but anyway it looks as a bug.
We will be probably anyway forced to switch to non-js mode and the reason is that we would like to completely rewrite the views and also use Parsley js validation library to do all the client validations (to make it consistent with other static forms) and in js mode we were not able to trigger Parsley validator to validate page on form submit (it was validating when you have changed value in field).
So the question is if there is a way to replace epi forms client validation but still be able to submit form with Ajax (after switching to non-js it makes redirects which is sometimes a problem)
And one more thing in non-js mode is there a way to show validation summary with all errors without need to rewrite the FormContainerBlock view?
yes, I am able to reproduce the bug. The message "Unexpected value is not accepted." is from server side validation (SelfValidate method) when we submit form by ajax. So if you replace client validation, the error is still there. You also need to rewrite the FormContainerBlock view in case you want to display validation summary with all errors.
In order to have "Multiple or single choice" element with localized, I think the easiest way is to create a custom element which inherit from SelectionElementBlockBase<TModel>. Then you override the method SelfValidate to validate yourself with pre-defined localized items.
Hi, but is there a way to stay in JS mode still (Ajax submit) but only remove all Epi client-side validations? (we are utilizing Parsley validations)
We realized we have more customizations after submitting the form so switching to non-js mode is not perfect solution for us (also reloading the page and forcing user to scroll to form again is not so friendly solution)
Yes, the creating custom element which I mentioned above will keep you stay in JS mode, you just need to override SelfValidate method to vaildate your data with pre-defined values.
But you are talking about the server SelfValidate, let's forget for a moment about original problem with "Multiple or single choice" element and only concentrate on a target that for all the epi forms we have we don't want to have default client epi validation but instead use our own validation with Parsley, but still post the data with Ajax as it is in JS-mode. I have seen examples how to add custom validation method but is there a way to remove default epi client validation totally?
So in a short sentence target is: stay in JS-mode but turn off epi client validation (we use Parsley validators). Is there a way to achieve that?
If you do not choose validator for your elements, it will be skip validating data with our build-in validators. Is that what you want?
================================================================================
I mentioned about SelfValidate because when the data sent to server, it will be validated again in C#. And in your case, the "Multiple or single choice" get failed, that why you need to create your own custom element.
In short words example:
It should NOT validate anything in this case. Is that not working?
Well it looks that standard Epiforms client validation is triggered. I see that it is not called anymore when I remove surrounding wrapper element (e.g. based on extension of TextboxElementBlock)
@using (Html.BeginElement(Model, new { @class = "FormTextbox", data_f_type = "textbox" }))
But after that data is not collected properly when submitting.
Is there some other way to "turn off" epi client validation but still be sure that data is sent on submit?
Note: we are not customizing (yet) FormContainerBlock view
Forms does not collect your data because your element is lacking of css class or "data-f-datainput" attribute on the text box. Please see samples here: https://github.com/episerver/EPiServer.Forms.Samples to know how to create a custom element.
I did have already data-f-datainput="" on my input field, but now when I added additional attribute data-f-type="custom" data is submitted
Hello,
I have also experienced this issue today, after first localizing input strings and then inserting values in another language. I have not been able to resolve it with the above hacks and workarounds, and frankly I would expect something like this to work without this hassle.
Can I expect that this issue is worked on and hopefully resolved in a future update of Forms?
Regards,
/Marten
I have also noticed that the same error message appear when using the time picker on the DateTimeElementBlock, seemingly regardless of the language. If this element is part of the form it will not let you submit.
Hopefully the mentioned fix on Forms 4.9.1 will address this issue as well.
Hi,
Our customer when configuring Episerver Forms defined couple of form elements including "Multiple or single choice" element with list of options (Items property), after that he wanted to translate the form to another language and everything was fine except of the fact he was not able to define Items for "Multiple or single choice" (property not localized) so it was shown in language version in main language.
We have changed that property to be localized in admin mode but realized that when we started to use for Items different values in language version than in original one when submitting form user got error "Unexpected value is not accepted."
The solution (or rather workaround) was to use same values for the Items as in original language (just changing the Choice value for language specific) which was acceptable in that solution, but I can imagine that there might be cases when it is not acceptable (e.g. when you send chosen value via email with placeholders it adds the value to the email, so not localized text)
Another way how it could work I believe would be to create separate element for each language (I guess then there is no issue with different values), but then we lose all the benefits from language versioning.
I would like to know what is the recommended way of localizing Items for Multiple or single choice so we are not in risk that will be broken with some update later on.
P.S. The issue is also similar for Selection element I guess