Can you query the field's type value from the form in Javascript? Similar to the data you get in the type field of the getFormRateItemValues web service call?

[LCozzetto]

We're trying to write a JS function to reset multiple field values of multiple field types and need to be able to query the input field type so that we can call the appropriate function.

 

Ex. For a Select field we would need ca_fdUnselectOption() ,

       For a Checkbox we would need ca_fdUnselectCheckBox() ,

       etc.

 

Since the input to our custom function would only be the actual field id, we would need to be able to query the type of field that it references in order to call the appropriate function.

 

When using the web service getFormRateItemValues through PAM, we can see that the field types are defined numerically and are accessible however we do not know how to get these values via JavaScript on the form.

[Louis van Amelsfort]

Good Morning Louis.

 

Perhaps not a 100% scientific proved method, but is shows the info you ask for(I assume).

 

A form got designed with all components on it.
And then the following query shows the related type you are looking for.

SELECT form_entity_type, form_entity_name, is_system
FROM  usm_form_entities 
where is_system=1 and form_entity_parent_id = 4 order by form_entity_name
7  - Check Box
3  - Column Layout
14 - Date
19 - Dual List
16 - Field Set
15 - Image
10 - Label
17 - Lookup Field
24 - Page Layout
12 - Radio Group
9  - Select
23 - Slider
20 - Spinner Field
21 - Table
8  - Text Area
5  - Text Field

 

Unfortunately, I do not know how to retrieve this information from within a java script.

 

Thanks and kind regards, Louis van Amelsfort.

[LCozzetto]

Hi Louis,

 

Good morning.

 

The info provided above definitely helps move the needle in the direction we're looking to go.

 

We still would need to be able to query which field type we're working with.

 

Thank you for your contribution!

 

Kind Regards,

Louis Cozzetto

[Brett Zipkin]

Hey, I work with LC.   Ideally, we want to be able to inspect the field's type based on the field ID.  However, if that is not possible, is there a SQL query that could be run in a report object tied to some kind of hidden field on the form?  The query would run when the form first loads and populates the hidden field with the field names and types from the template that was used to build the form to begin with?  Then we could inspect that for comparison.

 

We're open to other options as well but being able to determine a field's type while the form is being filled out is important to streamlining the functions we will need to use.

[Lindsay_Estabrooks]

Can you not use the ca_fdResetFields function to do what you want to do?

[Brett Zipkin]

If I'm being honest....I didn't know that was there.  We'll have to test that and see if it does what it says.  So....maybe!  That would be much much much simpler if it does in fact clear the values regardless of field type.  We'll attempt to test tomorrow, if time permits.  Thanks Lindsay!

 

-Brett

[Brett Zipkin]

We began testing this late in the day and hit a few road blocks.  Road blocks were our own fault so we haven't fully tested this yet.  However, I did notice that when clearing a field with that function it doesn't trigger the onChange() event.   Can I leverage any of the events?  Ideally I'd like a cascading effect.  For instance.

 

An answer to Field 1 exposes Field 2 and Field 3

An answer to Field 3 exposes Field 4

 

If the Answer to Field 1 is changed, I'll clear the values of Field 2 and 3 with the function and hide them as well if they don't apply to the new selection.

 

In our current state of testing, it appears I have to pass fields 2, 3 and 4 into the array to clear them all.  I'd rather pass in 2 and 3 and have the fact that the value was cleared trigger a 2nd call to clear Field 4.  This way I can code dependencies explicitly and not have to worry about determining any other cascading effects manually.  On a large form, this can be cumbersome.

[System]

Hi Brett_Zipkin - Were you able to make any progress on this? Thanks!

[Brett Zipkin]

Chris,

  Yes and No.

 

The ca_fdResetFields function for the most part will work for us however, there are a couple things that we came across in testing.

 

1) it states "The fields will revert to their default values and any invalid data warnings will be removed."  In our testing, that was mostly accurate but not completely.  If the field being reset is a Label field, it actually wipes out the Label Text altogether making the label worthless.  Now you might say "Why would you reset a label field?" which sounds like a reasonable question.  Well the answer is that we're making a function that both hides and clears in 1 step the array of fields that apply.  If the label field is to be hidden, we wanted to put it in the same array as everything else.  If we do this, it'll actually break the label's purpose.   So either I'd still need a way to determine if the field being evaluated is a label field in order to only apply the hiding code or keep track of that separately and call different functions for labels than I do for everything else.

 

2) I also noticed that fieldsets have nothing to reset, which makes some sense but similar to the label, if I want to hide that, if I can't inspect it to tell me it's a fieldset object, I'd need to do that separately instead of using a common function.

 

3) We have not figured out a way to catch that a field was reset by the resetfields function which means we can't build a cascading trigger response as I had illustrated above.  This puts a heavier administrative load on the developers to pay attention to all possible cascading scenarios.

 

Any thoughts on this would be appreciated.