Custom JS or Rules to show/hide multiple fields

[Sebastian Ganson]

Hello Alexander and Forum,

I’m building functionality for “versioned” New/Edit/View on top of a large list (e.g. > 100 columns). The basic idea is to check the assigned version of the list item (1,2,3,etc.) against a separately maintained field/version list to identify which fields to hide on the main form.

At first blush, I don’t want to do this through rules because I’m concerned about the performance hit when the form goes to load and the rules run, and am thinking using the Custom JS route would be more efficient. The custom JS would execute when the form loads to run the comparison and set the relevant field(s) to Visible / Hidden.

Based on your experience, is the custom JS route possible and would you recommend it based on the list size and requirements I’ve described?

Thanks!
Sebastian

[Alexander Bautz]

Hi,
Sorry for the late reply. It sounds like you could use this approach: https://spjsblog.com/2015/05/09/dffs-multiple-variations-on-one-form/

This one has actually not been added to the user manual so no wonder you haven’t found it!

Please let me know how it works out.

Alexander

[Alexander Bautz]

Added it to the user manual

Alexander

[Sebastian Ganson]

Thanks, Alexander! It looks like this is exactly what we’re looking for.

One quick thing I noticed and wanted to bring to your attention is that in a certain circumstance DFFS does not properly create a “versioned” entry in the SPJS-DynamicFormsForSharePoint list. I believe you can recreate the scenario as follows

– go in to the DFFS Backend of a “versioned” form, e.g. Edit, and select to Switch to NewForm or DispForm
– if the Form configuration you select to switch to does not already exist, DFFS will prompt you to either create new or select from an existing list config
– selecting a “versioned” config to copy from (e.g. lists/listname/dispform.aspx?formType=3) creates a copy called (if switching to Edit) lists/listname/editform.aspx – ie. the version ?formType=3 is not included.

This may be by design, but it seems to me you’d want to (optionally?) include the version.

In either case, correcting the missing version details was as easy as editing the Title in the item in the SPJS-DynamicFormsForSharePoint list and appending the appropriate version information.

Thanks again!
Sebastian

[Alexander Bautz]

Thanks for the feedback. This in not by design, I just haven’t thought of testing it.

I’ll get it fixed in the next release.

Alexander

[Sebastian Ganson]

That’s great! If I can make one small enhancement suggestion / request, would it be easy to add a “default” function to the overall versioning routine? In other words, right now if a user opens a list item where the “versioning” field is a value which is not found in the list of available ?formType= values, it defaults to opening the view/edit form as though no DFFS backend has been configured (e.g. showing all fields, etc.). It would be helpful to be able to create and set a default form (for example the blank “?formType=” versions of the Add/Edit/View) from which we could prompt them that they have an unsupported version item and prevent them from taking further action.

[Sebastian Ganson]

One more quick thing I forgot to mention before – you may want to update the documentation to specify using the SharePoint Internal Field Name in the JavaScript code step when identifying the value for dffs_formTypeSwitch to handle non-pretty version field names 🙂

[Alexander Bautz]

Regarding the “?formType=[blank]” option: You should be able to enter setup without a formType switch to configure the default form – have you tested this?

I have added a note about using the internal name in the “dffs_formTypeSwitch”.

Alexander

[Author]

Posts