nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Form API and DCT Validation

alanhill

Hi,

We've just upgraded to TS6.5 and I'm looking at creating much more usable DCT forms. Part of this is showing/hiding fields based on the values of other fields.

An issue connected with this is that even if you hide a field, if you set it to be 'required="t"', then you can't save the DCT when the field is hidden (and empty). The only option seems to be to write the datacapture.cfg without the required attribute, but then deal with validation in Form API.

I get the feeling though that again Teamsite is missing something that seems a bit obvious - if you hide an item, then it's required attribute should be ignored, as should any validation-regex too.

Brings me to my main point - what do readers think is the best approach to validating items in a complex DCT like this:

1. Validate 'normal' fields as normal, using validation-regex and required, but handle other more complex fields' validation in Form API. Main advantage is that for the most fields, you're not re-inventing the wheel. Disadvantage being that as with normal validation you get horrible, non specific errors "either there are required fields or..." for the user to then work out exactly what was wrong.

2. Put all validation into the Form API - setting validation and required rules at initiation, then validating as part of the 'onSave' event. Main advantage is that this allows very specific errors - eg "field x contains an ampersand - please remove" or "if you select 'yes to field x, field y must be completed". Disadvantage is that you have to write every bit of validation, making dcrs much more complex (and in my view doing Teamsite's work for it - reinventing the wheel (albeit a better one!)).

I'm loath to write validation for every field, but I want to give my users a consistent approach.

Can anyone think of any other options or approaches?

Cheers

Alan

Teamsite Template Developer

Find more posts tagged with

Comments

alanhill

Hi,

As an addition to this, the main problem appears to be the fact that when an item is set to hidden using "setVisible(false)", it's required and validation-regex attributes are still actioned.

Does anyone know of a way to make Teamsite ignore the required and validation-regex attributes if an item is hidden when a dcr is being saved.

Many thanks

Alan

Teamsite Template Developer

Adam Stoller

If you're going to do item.setVisible(false); you should just follow (or precede) it with item.setRequired(false); - and that will solve part of the problem.
Of course, if/when you do an item.setVisible(true); you need to add conditional logic to determine if you should also do an item.setRequired(true) -- that's IFF you want to make use of any of the default safeguards against saving a form without having filled out all the required fields.

I tend not to bother using the hard-coded validation-regexs for most of the reasons mentioned (vague / generic error messages, too simplistic for compound field validation, etc.)

I try to create "global" or "general" FormAPI files for storing all basic validation pieces and then augment it with data-type-specific FormAPI files - and include both within the DCT. This way, even if I am reinventing a wheel - I only do it once.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

alanhill

Thanks Ghoti, wise words as always.

I'm with you on not using the standard validation, and ideally yes I want to create a generic set of DCT elements and corresponding Form API to set and test validation rules.

Apart form the problems with standard validation in DCTs, my problem was also that the object I was setting to be visible (or not) was not always the object I wanted to change the validation/required attributes. For example I can set a container full of a dozen items to be visible in one step (container.setVisibile(true), but I'd have to recurse through each item in that container to work out whether it was appropriate for it to be required or not - I can't just do a blanket recurse through the container's children. This is now making it much less generic than I'd hoped.

I'm finding it difficult though to separate these routines to make them truly generic - they get bogged down because the path to each item (from the root container) is always going to be specific. That's my next task.

Cheers

Alan

Teamsite Template Developer

jbonifaci

Alan,

If you say an item is required, hiding it should not make it no longer required. This would be a bug IMO. I told it to be required, it should stay required.

Anyway, back to your other question, I will go with Adam and say that all validation should be done using formapi. You have more control over the validation process and can give much friendlier error messages. Another option for your required fields is to control them all with formapi as well. When your form initializes, you set all of the fields that are required. This way your formapi controls everything about the items. I do this with all of my DCTs. All the DCT does is define the items, the formapi controls all rules around those items.

~Jeff

alanhill

Jeff,

In terms of an item being required when hidden, I think the opposite to be honest - if I hide an item, that means it's NOT required so shouldn't be validated. That's the problem I'm having basically.

I agree though that it would be better to have all validation done in Form API - a much better experience for the users (although a lot more work for developers). I can't set all fields to be required on initialisation though - there are some that need to stay optional due to the way they work.

Agreed with everyone though that the Holy Grail is to make the routines which set validation and then check it as generic as possible.

Cheers

Alan

Teamsite Template Developer

jbonifaci

You could have an array of items that are required in your container. When you initialize the form, you set all of those items to .setRequired(true). When you hide that container, you would then .setRequired(false) on all of those items.

~Jeff

Adam Stoller

I was going to suggest sommething like this too.
In my last project I did something very similar in which I defined a global routine for processing arrays of field definitions for hiding / required and such, and then in the DCT-specific FormAPI files I defined the arrays and passed them to the global routine when appropriate. It's generally a lot easier to maintain that way as it all becomes very table-driven.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com