You are viewing limited content. For full access, please sign in.

Question

Question

How do I force refresh on table pulling from database in Modern Form Designer?

asked on July 7, 2023 Show version history

I found this link that was helpful for Classic Designer, but not the new Modern Designer. 

https://answers.laserfiche.com/questions/107441/Getting-lookups-to-refresh-on-form-load

 

They recommend using this code for my issue, however it isn't working for Modern Designer. Does anyone know of the correct code that will do the same thing just in Modern Designer? 

1 
2 
4 
$(document) . { 
. attr( "vo", "e"), 
") . change(), 
//the lookup target field

 

2 0

Replies

replied on July 7, 2023

Unfortunately, any code written for the Classic Designer isn't going to work on the Layout Designer without serious modification, for several reasons:

  1. The Form structure on the Layout Designer is drastically different than the structure of form in the Classic Designer.  I don't think that the vo attribute is even used any more for example.
  2. The Javascript on the Layout Designer uses vanilla Javascript, not JQuery like the Classic Designer, so the shorthand ways to reference objects (like $('#Field1') for example) and the shorthand methods (like .attr() and .change() for example) are not going to work.
  3. Most importantly, the Javascript on the Layout Designer runs within a Sandboxed iFrame, and does not have direct access to the document, form, fields, attributes, etc.  The only parts of the form and fields that can be edited are those that have been made available via the LFForm Object (also known as the LFForm Interface) which you can read about in the help files (here's a link).  Unfortunately, that means we can't do things like edit attributes of a field, unless they are specifically set-up in the LFForm Object, and we cannot do things like trigger events (like the change event), unless they are specifically set-up in the LFForm Object.

 

That means that we have to completely re-think how these kinds of things are implemented, and possibly accept that they may not be possible in many cases.

In this case, I have an idea for how this might work (I have not fully tested this, so it might not work, but some brief testing seemed positive).  This code uses the LFForm object to work with the field that triggers the lookup (the source of the lookup, not the destination of it).  In this example, I'm using the field with ID # q1, so I'm referencing "fieldId: 1" in three places.  This code stores the current value of the field into a variable, then it clears the contents of the field, and then it reapplies the stored value back into the field.  Because the setFieldValues method is not only updating the value of the field but also triggering a change event, this should trigger the lookup to process again.

var triggerFieldValue = LFForm.getFieldValues({fieldId: 1});
LFForm.setFieldValues({fieldId: 1}, "");
LFForm.setFieldValues({fieldId: 1}, triggerFieldValue);

 

1 0
replied on July 20, 2023

@████████ I haven't been able to get it to work. My issue comes when we save a draft. It automatically is saving Lookup data in fields. Well this info is being changed constantly and causing an issue. Did you have any luck with that possibly?

0 0
replied on July 21, 2023

I just tested it on Version 11.0.2212.30987.

I filled in and saved a draft from a Message Start Event.

Then I changed the database values, and I re-opened the draft.

When I didn't have the code example I provided before, the draft did not get updated, and continued to list the old values from before I saved the draft and before I updated the database.

But when I included the code, it did force the fields to update from the database again when I opened the saved draft, and it populated the new database values.

0 0
replied on July 21, 2023

Thanks Matthew let me test again. I could have something missing on my form. Not feeling this new Java but hate to recreate forms in the old Forms. LOL! 

0 0
replied on July 21, 2023

Yeah, the Javascript in the new designer has been a struggle for a lot of us.  But there are some huge benefits with improvements to form structural security, field rules, and flexibility with different browsers/devices.

You've just got to balance pros and cons on each form you are developing. 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.