I'm going to sound like a broken record here, but my organization needs more flexibility in JavaScript before we can even consider making the switch.

Currently, about 80-90% of our mission-critical forms cannot be reproduced in the new designer, even with all the truly great new features that address a lot of things that were commonly done via JavaScript.

It's gotten to a point where we don't start new projects in Forms nearly as much as we used to because we're uneasy about dependence on what is at this point a "legacy" designer.

While I understand the desire to improve performance and provide an easy-to-use API, and I do agree the new designer is in most ways far superior, the change to JavaScript has essentially put a "wall" around process development.

Even if that is expanded with new functionality, if/when we run into that wall we're just stuck and it's exceedingly rare that I can put a project on hold to wait for enhancements that may or may not come.

The biggest challenge is that it's not just about recreating what we've already done, which so far I haven't been able to do, it's about that unknown project down the road that needs something I can't provide out-of-the-box with Forms, especially when it is an uncommon use case that wouldn't have much traction as a feature request in the larger user community.

In the past, I could just get creative with JavaScript to bridge the gap, but with the recent changes I have few options/workarounds; our user base and stakeholders have become accustomed to a certain degree of functionality and customization in Forms that we just cannot provide in the new designer.

I totally understand your sentiment and appreciate the feedback. The "unknown" solution/feature aspect of project development makes our jobs incredibly difficult haha. I have used the classic designer for several years and have built many absolutely crazy custom forms essentially under the guise of you can do literally anything you want. I have a list of features from my own experience and some answers posts of must haves that will enable the new designer to handle as close to unlimited possibilities as I can. I also have another feature set in the works to handle additional use cases that don't quite fit in anywhere else.

The fundamental goal of the new designer is to build out of the box ways to do common things that were scripted in classic designers. My list continues with this strategy while also providing interfaces/documentation surrounding more advanced customization as those possibilities arise. My hope is that the features in the new designer begin to outweigh specific customer requests and lower development costs for building and maintaining forms (like only needing one form for most processes). Then you and your customers can meet a compromise between specific features and services costs. 

The main reason we stay with Classic Designer is because of using Google with the Address field.
If we could use Google in the Modern Designer address field, we'd move over completely.

@████████ can you give some examples of what you are doing using JavaScript in the 80-90% of your mission-critical forms that can't be reproduced with the modern designer? While Zac and his team might not be able to address the "unknown" projects, they might be able to review what you are currently doing and possibly work on built-in solutions for a future version.

Also based off of the post below from one of our Consultants and reply from @Zhiyong Deng, the process to use Topaz with Forms is not supported with the Modern Forms designer.

https://answers.laserfiche.com/questions/212856/Forms-11-and-Topaz-Signature-Pad-not-working#212860

Hi Blake,

There was a post a few years back where people were listing off some of the things they were doing via JavaScript, and there were some discussions during Empower that year as well.

New Forms Designer: Common Use Cases for Java - Laserfiche Answers

There's a good number of things that have since been addressed with out-of-the-box features (field rules, LFForm object, etc.), so the list is definitely a lot shorter now, just not quite where we would need it to be to switch.

We went pretty extreme on the customization in some cases so there are some things I wouldn't expect to be "common" use cases.

Some highlights,

One of our biggest processes is/was for public submission of documents; this process was responsible for about 27,000 submissions per month.

We started migrating that process to a different application so it's down to about 7,000 submissions per month now, but it relies heavily on JavaScript:

• We use a custom Authorize.Net implementation; we cannot use the out-of-the-box functionality because the payment amount is not determined until after internal review. We import Authorize.Net's JavaScript library and have a custom button which opens the Authorize.Net iframe/modal at the end of the process to collect payment information; this relies on a "callback" handler attached to the parent window to receive the tokenized values from Authorize.Net. The token is then used in workflow to create a payment profile so the card can be charged at a later date.
• The starting form also includes a "timeout" modal to warn submitters when they keep the form open too long, and other little things like setting placeholder attributes, enforcing a maximum total/cumulative file size for attachments/uploads, and handlers for various fee exemptions since they can get pretty complicated.
• On the internal side, JavaScript is used to load the submitted documents in "tabs" using WebLink in iframes; this enables a step-by-step review of the submitted documents in a sort of split-screen UI with fields/data in a left pane and the document/controls on the right. We use a modified/custom WebLink page with a callback method so the form can detect if/when a document doesn't load.
• This form/task also includes a modal to confirm the charge amount before actually processing the transaction, a custom parsley validator to apply min/max values on the various currency fields, functions to resize the parent window to fit the screen, hide things like the right pane and task page header, and display various other warning and confirmation modals in this and subsequent user tasks,
• This task also includes a "troubleshooting" function that modifies the value of the submit buttons so we can kick it back to a previous step without making that option easily accessible to our general users.

We have a process for document destruction orders:

• This has to load about 25,000 rows of data for each instance; it's a bit too much for lookup rules and we were running into other content limits, so I ended up pushing the data into repeatable multiline variables with Workflow to initiate the instance, then on the form side JavaScript is used to pull that data out and build/populate a table in a CustomHTML field.

We have a process for employee change requests (promotions, transfers, office moves, etc.):

• This includes JavaScript for things like displaying a building map so users can locate room numbers for office moves, and to handle checkboxes for building access that may be fixed, have required values, or be optional based on job/role and work location, and populating data on a summary/review page.
• Custom parsley validators are used to prevent phone number conflicts, ensure that an office move request actually includes a change in the room/building, check if the manager/supervisor enters the name of an employee who does not report to them, ensure each item listed in a system access table is unique, and other things along those lines.
• The final "stored" version also includes JavaScript that runs when the form is saved to the repository to map field values to the "display" version and remove the disabled attribute from checkbox and radio fields since they can be too lightly colored.

We have a process for updating document statuses (voiding and such):

• This process also displays the document in WebLink within an iframe and leverages the same custom WebLink page so we can detect if the document doesn't load and display an appropriate error message.
• For this process, the left pane contains a canvas which generates a stamp image based on user input; on submission, this image is converted to base64, the data is put into a multiline field, then on the Workflow side it is converted into an actual stamp and applied to the document. 

We have a process for document redactions:

• This form uses a similar multi-panel display but with a customized web client page embedded instead of WebLink, with methods to ensure the document is loaded, every page has been viewed at least once, and that all changes have been saved before proceeding.
• This one also includes confirmation, error, and warning modals that pop up based on various conditions.

An "availability" questionnaire for the public:

• This one uses JavaScript to show/hide a Help dialog, and a pseudo-login page that requires users to input certain non-sensitive information like zip code and a confirmation number before it loads data from a lookup and displays the rest of the form.

Some common elements I use in multiple forms:

• Updating the document.title value
• Parsley groups to enforce page-by-page validation for forms with steps (i.e., to prevent continuing to the next page).
• Custom parsley validators for various "uncommon" things like only accepting an email address from particular domains, enforcing uniqueness in table/collection inputs, or more complex validations that depend on multiple field values.
• Formatting methods to "mask" values, input filtering, etc.
• Sorting/reordering data in collections/tables
• Control behavior with multiple complex lookups (for example, showing/hiding certain fields until a lookup is complete so it doesn't present misleading information to the user, or manually triggering stored procedures only when specific fields have been filled).

I tried to focus on the more "extreme" stuff because more than a few things in my original post can now be done out-of-the-box with field rules, the LFForm object, etc., so things have come a long way for sure, but still not quite enough for us to transition our "big" processes, either because necessary functionality can't be reproduced, or because our users/stakeholders just refuse to let go of functionality that can't be reproduced.

This is a fantastic list, a lot of these are things I had in mind. Especially cross-window/frame communications either with the web client or another site. I will try to replicate some of these features and use missing items/qol stuff to add to my list.

I really appreciate the detail you put into this post so thank you!

Hi Zachary,

Thank you for all the work you and your team have done. I don't want to be too hard on the new designer because it really is great, and some big leaps have been made since the initial release so it has definitely reached a point where most things can probably be migrated.

My primary role is application development, so I totally understand that a lot of what we do is a bit "fringe" and falls under the ninety-ninety rule; I know all too well how addressing that uncommon stuff usually accounts for a severely disproportionate amount of development effort haha.