which would be a better option

[AEMnewbie]

I am trying to use some validation on a field which save a dialog box or i could also set a property while creating a page and remove that field from dialog box. which one is a preferred option .

[Ravi_Pampana]

Hi,

If you are adding a field in dialog where authors enters, it is good to validate on dialog submit instead of page

[Shashi_Mulugu]

It depends on the type of field ands it's usecase.  If you can set the field value while creating the page automatically then why to make author enter its value in dialog and add validation?

If it has to be controlled by author make it as a field in dialog, if it a backend driven value which is not author friendly then make it automatic.

Hope this helps.

[Ankur_Khare]

Better do it at dialog level.

[Shubham_borole]

Hi,

You  can choose based on use case. If the property is something that is must have for most pages, you can have it available during page creation (and as required probably) so that its value is set when a page is created. The authors don't need to worry about opening  dialog again. The equivalent to dialog submit validation might have to be found.

If the property is an optional one, and needs to reside in a component dialog it can be chosen too, but its an add extra step for authors.

[BrianKasingli · Accepted solution]

@AEMnewbie,

There are 2 tactics that I see that are common while validating Touch UI dialogues in AEM; a front-end way and a back-end way. I prefer the front-end way, as logic in the front-end will highlight the input field that is not valid, and also not allow the content authors to save the dialogue. 

Out of the box, AEM Granite UI (Touch UI)Dialogues are using the jQuery Validation plugin. You can create your own jQuery Validation.

Take a look at this tutorial, where it shows you how to implement your own jQuery Validation for adding AEM RichText Max Characters Length Validation - https://sourcedcode.com/blog/aem/touch-ui/aem-richtext-max-characters-length-validation

The back-end way will be you allowing the authors to save whatever value they choose, and the component in the editor mode page will display the component in RED (or some other indication) that there's a problem with the form dialogues. Sometimes you need to do this because you may want to validate the form data with your AEM backend... but you will be definitely introducing validation variables and code in your AEM component's sling model. 

As you can imagine, the front-end way of using jQuery Validation gives the author a much quicker and instant feedback on what is missing In the touch UI dialogue.

[AEMnewbie]

Thanks @BrianKasingli