What do you have in the "External" tab? Could just be a typo or something, but it is hard to say since the screenshot only shows the Internal tab.

As for JQuery, I prefer it especially for delegated event handling, but most things can be rewritten in vanilla JavaScript. My biggest hurdle is the sandboxing since that prevents about 75% or more of my custom implementations from transferring.

Thanks. It is hard to see, but I copied the url path from the help doc:



Yeah, if/when they kill the classic designer I'm going to need a solid 3-4 months to see if I can even have the same functionality as I did with the jQuery. It can get tricky pretty quick when dealing with collections and tables for sure.

The documentation seems to imply that this shouldn't be the case, but maybe the inline is executing before the external file is loaded?

I'd say to try running that same line of code from the console after the form is loaded. If it works, it could be a timing/sequence issue, if you get the same error then that would indicate a problem actually loading the external file.

The other problem for testing with the console may be the sandboxing since the new JavaScript approach adds iframes to the mix, and that adds cross origin hurdles which can limit what you can do with the browser console.

If that is the case and you can't really test in the console, then maybe test by adding a significant timeout delay or something like that to the inline.

As much as it pains me, if they decided to kill the classic designer with the current state of things, I'd have to move a lot of our processes out of Forms.

I've already started building more standalone web apps since we're very uneasy about starting new projects in what is now the "legacy" designer, and although the new designer is great in many ways, it just can't do what I need it to do to meet stakeholder requirements/expectations.

They have said several times that they have no plans to remove the Classic Designer.  But yeah, it makes me uneasy too.  I've got custom JQuery on 95% of the my processes.

I've got the external script working on Version 11.0.2212.30987 with the example you listed.  

I used some console.log commands to ensure that things were not loading out of order.  Like this:

External File: 

Code on the Form: 

And it did populate the field value, and the console looks like this:

That doesn't solve the issue, but may help identify what it's doing wrong.  If #1 doesn't show at all, it may not be loading the script.  And if #1 happens after #2 or #3, then it may be loading things out of order.

It looks like jQuery is not available in the new designer. Is that right? 

Not by default.

Via the "External" tab you can add the JQuery libraries, including the ones that are already installed for Forms.

But bear in mind that any Javascript you add to the new designer, including anything you add on the "External" tab, runs within a sandboxed iFrame, so it doesn't have direct access to the form, fields, window, or document.  Even if you add JQuery, you'll still be limited to changes on the form that are available through the LFForm interface.

What is Laserfiche's reasoning to using the iFrame and keeping us from direct access to the form, fields, window and document?

Why not have the same functionality as in the classic designer. Seems like that's going backward.

Would be nice to understand.

Hello,

There are 2 main reasons for putting custom scripts in sandbox iframes and limiting changes to what LFForm offers:

1. Allowing direct access to the DOM opens Forms up to security vulnerabilities. Having direct access to the DOM means you also have access to all cookies and local storage. If you are under an XSS attack or you open a form with malicious code, your credentials can be used to call APIs to do unwanted things, like deleting processes or updating security roles. 

2. Classic form uses the DOM as the source of truth, so you can directly modify things on the DOM and they will stick. New form uses Angular with an internal source of truth. So unless you modify this source of truth, Angular will overwrite any changes you make on the DOM. You can only modify this source of truth through the LFForm API.

We understand that these restrictions to scripting in new form make it harder to do what you did with scripting in classic form. We are constantly collecting information on scripting use cases and will expand the LFForm API to accomodate them. We will also update the documentation to help ease migration through more concrete examples. 
Last but not least, as a sneak peak, we are working on a new feature that lets you define your own field on the form. You will have full access to your custom field for scripting purpose.

Huong, if it helps your team the thing I most often have to use JavaScript for is date calculations, taking a date or set of dates from fields on the form, using the JavaScript Date objects to do things the Advanced Formula can't do, and then putting a value into a field or values into a drop down. 

The other thing I have to use JavaScript for is to create tables with a 'select row' checkbox. This is where the lack of jQuery hurts, because I need to use the jQuery element selectors to get at the 'Select Row' checkboxes in a table. 

Thank you @████████- I suspected that was the reasoning, but it is nice to have confirmation from Laserfiche regarding it.  I agree that it is a really good reason to restrict it - especially for publicly available forms.  Personally, I'm finding myself using the New Designer most with public facing forms that I want to look and feel nice on any browser, but don't need really complex functionality.  But there are definitely some areas where the LFForm interface needs to be expanded.  

Meanwhile, I continue to use the classic designer almost exclusively for internal forms for staff, which often need additional or more complex functionality.  Especially since I'm making use of API calls and other really complex stuff.

Also, I am really wishing the new Field Rule functionalities that came with 11 Update 3 were included in both designers instead of just the new one.  I can do all that stuff with Javascript in the classic designer, but it is so much easier to do with Field Rules.  

@████████

Unless I'm mistaken, this should be possible with the current LFForm API.

Based on my understanding, you can use the LFForm API to retrieve the field value(s), perform the necessary calculations, then use the LFForm API to set the appropriate field values.

Oh yes the date calculation thing is easy enough. Or at least as easy as date calculations get. 

Manipulating data in tables has been an exercise in frustration. At this time the LFForms object doesn't support setting values in tables or collections. 

Also, the classic trick of getting at HTML elements by going into the web dev tool and picking out specific items doesn't work any more, as everythig on a modern form is inside DIV or SPAN tags. 

It was super frustrating to discover a modern designer drop down field is done with SPAN and DIV tags with some kind of code in the backend. 

Hi @████████ can you talk a little more about what you are trying to do with dropdowns, and your "select row" checkbox option?

As for setting fields in tables, one thing to be weary of is adding rows to a table or collection returns a promise so you need to properly await it before setting. See this example below:


 

I'm trying to get a list of classes, and then a pulldown next to each with a pulldown for available times appended to 'Select a time to register' and use the set value to make 'Select a time to register' be the default value. 

I was only trying to do that because choosing that as the default value in the properties in form designer didn't work. 

This doesn't work in either the modern or classic designer to make the default value 'Select a date' 

So I have to use this in classic designer, because LFForms object can't set values in tables or collections. 

$(document).on("onloadlookupfinished", function(event) {
  $('.form-item-field').val('Select a date').attr("selected", "selected");
});

Thank you for the link.  Seems like a pretty important component to not have available at release.  

I have not upgraded yet, but I'm curious.  Is the choice for which designer to use something that is universal through the server or decided on a case-by-case basis for individual processes or forms?

@████████ it's case-by-case. When you add a new form (or a new business process with Form submission/approval selected) you can choose which designer to use, and you do seem to be able to mix-and-match within a process.