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:


 

const modernScript = async function() {
  const collection = { fieldId: 35 };
  const fieldInCollection = { fieldId: 38 };
  await LFForm.addRow(collection, 3);
  await LFForm.setFieldValues(fieldInCollection, [1,2,3])
  const newFields = LFForm.getFieldValues(fieldInCollection);
  await LFForm.setFieldValues({ fieldId: 47 }, newFields.join(', '));
}
// NOTE: no await here
 modernScript();

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.