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() ,
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.
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_name7 - Check Box3 - Column Layout14 - Date19 - Dual List16 - Field Set15 - Image10 - Label17 - Lookup Field24 - Page Layout12 - Radio Group9 - Select23 - Slider20 - Spinner Field21 - Table8 - Text Area5 - Text Field
Unfortunately, I do not know how to retrieve this information from within a java script.
Thanks and kind regards, Louis van Amelsfort.
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!
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.
Can you not use the ca_fdResetFields function to do what you want to do?
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!
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.
Hi Brett_Zipkin - Were you able to make any progress on this? Thanks!
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.