Simply refresh new Record in background

[Chris Ju]

Hello,

i’m trying to refresh a new child record which i created with ‘record.addNewRecordToField’ in background.

I just don’t want to double click the new entry and press CMD-R. In the related child form there a some script and calculation fields. The problem is, that calculation 1 has an result for calculation 2 and these both has a result i use in a script field.

At the moment i have to open the new record and press three times CMD-R. This isn’t so funny that I want to do it 100 times a day…

I couldn’t find something in the javascript documentation to trigger the refresh with a script…

Had anyone had the same problem and have a solution?

Thanks a lot…

[Chris Ju]

I just resolved the automatic refresh of all required fields (with all their dependencies) just by changing the order of the fields and adding an if-loop to each of the calculation fields and the script field. Now i can click the “+>”-Button and all fields are refreshed without hitting CMD-R.

BTW: I had also the idea to merge the calculation fields to the script field, but i don’t know if this will do it (at the moment i haven’t the time to “translate” the formulas to javascript)…

@Brendan: Isn’t possible to add an function like << record.refreshRecord(recordID) >> which will do the same as CMD-R?

[Sam Moffatt]

Chained fields is going to be complicated because how many times does the refresh need to be called to resolve everything becomes a recursion problem. How do you know when to stop evaluating if someone adds say a time based script that mutates each execution.

A model I’ve used is having a single script that calculates everything and then stores the data in normal fields. There isn’t a read only option so they can be mutated by the end user but you can also work around that by using self referencing script fields that maintain their value set by an external script.

[Chris Ju]

Thanks, Sam, but what do mean exactly with

“you can also work around that by using self referencing script fields that maintain their value set by an external script”?

Do you have a short example?

[Sam Moffatt]

Most of the time you can have an empty script field and it seems to work. There was one situation where for what ever reason it didn’t work for me and my work around was to just have the script do record.getFieldValue(scriptFieldId); which returns the value for itself. Since the value for the field is set by your other script field (e.g. record.setFieldValue(scriptFieldId, desiredFieldValue)) this should work properly. This is at the limits of what a script field should do but it does seem to work properly and gives you a read only field.

[Chris Ju]

Ok, wouldn’t have thought it is possible to write into a script field via script. Thanks for the great hint. Will try to implement it in the near future…

[Brendan]

Hi Chris,

Yes, I could probably add a refresh function. form.refreshRecord(aRecord); would probably be a better API.

I’m not sure if this would help you but there is an alternative setFieldValue() function:

record.setFieldValue(movie_title_id, 'The Terminator', false);

From the manual:

Sets the value on the specified field and optionally executes scripts that would run by default when the field value changes.

It also evaluates formulas too, not just scripts.

[Sam Moffatt]

Wouldn’t the false disable executing the script? Isn’t the problem the chaining essentially means that if it’s executed out of order that the value isn’t available from the “earlier” calculations which means that it’ll not have the value required later to work. I think depending on correlated calc fields is probably an antipattern because you’re relying on TF ordering and if there is common code between fields to isolate that into a form script (which you can then include from form.runScriptNamed) so that there is one copy of it you can use elsewhere or setting the different values into empty script fields as noted above.

[Brendan]

Oh yes, the false does disable it. So just pass in true.

[Daniel Leu]

I was wondering about that as well. Brendan, could you please update the documentation as well? Thanks!

[Brendan]

Ugh… oops. Sorry about this misunderstanding. The default for that flag is already true, so subscripts already get run when you set a value, even without that parameter. Sorry for causing the confusion.

[Daniel Leu]

From the documentation: Sets the value on the specified field and optionally executes scripts that would run by default when the field value changes.

So it should say: …optionally _disables_ scripts that would run by default…?

Thanks!

[Brendan]

Well, optionally just means you don’t need that parameter, but setting it to true has no effect from the default and setting it to false disables. The sample code is set to false. I guess your wording is a bit better. Thanks.

[Author]

Posts