Custom validator in Forms Builder based on another field

Hi all,

Could someone help me with the following. I want to write a custom validator SBO which has another field as an input. With a regular data source adaptor I can bind another field to a paramater field of the docbase configuration, but with a Validator I can't... is there some way to make this work?

This example shows what I need exactly:

Whenever the checkbox of field1 is checked, field2 should have a value between 1 and 10, if field1 isn't checked the value of field2 should be between 15 and 25.

Thanks in advance for your help!

Regards,

Kees.

Find more posts tagged with

Comments

Jeroen_Jansen

Hey mister Cayottes,

The manual states:

{Begin Manual statement}

Instead of specifying values and labels in the value-display table, you can use a data

source adaptor to populate the data values and their display labels at runtime from

an external data source, such as a database or a properties file. You can also use

the input from one enumerated-value input control to limit the values that another

enumerated-value input control displays. For example, you can ask users to choose a

region of the country, then to select the branch office from a dropdown list. You can limit

the branch office choices to those in the selected region.

{END Manual statement}

Creating a data validator that uses the checkbox as an input value should do the trick.

capatina

Hello,

I can see this is an old post, but since I have a similar problem, I wonder if you found a solution for this.

Thanks,

Ana

kees.vanbemmel

@Jeroen Jansen

Unfortunately, using data source adaptors does not do the trick. We want to be able to validate an input field instead of filling its initial values.

@Capatina

No we haven't been able to solve it.

Quick status update, since I wanted to validate individual fields with custom logic based on the input of other fields, I wrote a custom validator. Unfortunately there's no way to pass input parameters to a field validator... even though you can do that with a Data Source adaptor (As Jeroen Jansen points out).

We've had multiple discussions with EMC on this and, at least in version 6.5 SP1, it can't be done... sorry to kill your dreams... Anyway a workaround:

Document processors DO get all values of all fields so you can do your validation there.

Cons:

- You can't specify an error message specifically next to a field when validation fails, all validation failures will end up in error messages at the bottom of the screen.

- Document processors do NOT fire on all types of forms, I'm not sure which ones anymore but I thought Folder Information Templates for example do NOT fire them so there, this workaround is useless.

Hope this helps!

capatina

Thank you for your response. I tried the workaround you described, but since there's no way to customize the error messages I decided not to use it. For the moment I'll stay with my workaround which although it doesn't prevent the form submission, it writes red messages to the user. For this I used hidden labels with custom messages right next to every field which needed validation and a set of rules which made that label visible or not. This is neither a general solution, nor a good practice, but it's good for the user because seeing a red message makes him refill the field accordingly.

kees.vanbemmel

Hi Capatina,

You can, in fact, customize the error messages a user sees in the workaround I described. You can do this like this:

/**
* {@inheritDoc}
*/
public boolean validate(final Document document) throws XFormsProcessorException {
throw new XFormsProcessorException("YOUR CUSTOM ERROR MESSAGE HERE");
}

The only downfall is that EMC somehow manages to surround that custom error message with y's, don't know why that is.

Your workaround is also a good one, but we just had to many fields on one form to take that route.

Thanks for your insights!

Regards,

Kees.

capatina

Hello Kees,

Thank you again for your quick response.
Now, this post is strictly about search forms (TaskSpace Component). As you said in your previous post, Document Processors do NOT fire on all types of forms and apparently they don't fire on search forms. I also noticed that although Document Validators are fired, they are also useless in search forms because the result of the validation is not interpreted. If the result of the "validate" method is either true or false the search operation is not stopped and throwing an XFormsProcessorException is also useless because it does not appear on the interface (only in console) and again, the search operation is still working.
Do you know anything about this behaviour? Can the search operation be stopped in case a field is incorrectly filled and the user warned about this?

Regards,
Ana Capatina

kees.vanbemmel

Dear Ana (sorry for calling you Capatina earlier ),

We've done quite some forms building and were stumped that these kinds of functionality are so hard to implement. However with the workarounds described, we did come a long way.

Having said that, the search forms are in a league of their own... As far as we could find out, there is no way to stop the form from actually searching. So to answer your question: You can't validate a form field before the form goes out. I suspect that the submission of the search form works differently from other form types.

I know this doesn't help, but there's most probably no solution (in 6.5 SP1, perhaps this is fixed in SP2??)

Kind regards,

Kees van Bemmel

www.vlc.nl

capatina

Hello Kees,

Thank you for all information provided. I've searched on "Documentum 6.5 SP2 Forms Builder Release Notes.pdf" and I found on page 63 on "Additional information on using adaptors (FRM-414)" that Document Processor (Pre-submission and Post-submission) can't be used with search forms (among other forms) and Document Validator is not supported only on high fidelity templates. So, maybe on a future version this will be fixed

Regards,

Ana Capatina

kees.vanbemmel

Hi Ana,

I don't want to get your hopes down, but we've had extensive contact with EMC support and engineering about this. The note you see in the Release Notes is most probably a result of those contact moments.

We too requested this functionality, because it was supposed to work according to user guides... EMC response: This doesn't work by design and the fact that the user guide shows otherwise is a documentation bug.

So long story short, I wouldn't count on a fix soon since there's nothing to fix according to EMC.

Regards,

Kees.

capatina

Hello Kees,

Thanks for sharing this, it was very helpful. Now I can stop searching on documents and forums about this problem.

Regards,

Ana Capatina