Calc element value changes to label in details view

[Bauer]

I have a calc element that gets the raw value from a databasejoin element in the same group then uses that in a query to return the result as the calc value.

The calc element is configured to 'Calc on load' and 'Use Ajax' (to check if/when the raw value in the databasejoin element changes in a new form).

What is happening is, in the details view the calc element is initially displayed (correctly), but then the ajax gets triggered (even though this is a details view and the dbj element never gets changed).

At that point, the raw placeholder value for that dbj element (referenced in the calc element) changes to the dbj label instead of the raw value - which explains why the element freezes with the ajax spinner spinning. (I know this is what is happening because I tried using that placeholder for the dbj raw value as the return value for the calc in order to debug this.)

Weird stuff, I know.
And I'm not sure if this is some new bug - just since updating from Github yesterday (1st update in maybe 3 weeks) - or an old issue that I just never noticed before.

So there's 2 mysteries here

1. I can understand 'Calc on load' if specified, even in details view - but why would/should the ajax get triggered in details view?
2. (And even if so) Why does the {fb_generate___custom_report_id_raw} value change from the correct raw value to the label once ajax is run?

 

[cheesegrits]

I think this is a Golden Oldie.

Raw values don't exist on the browser side in details views. So because the AJAX calc is going by the data submitted with the calc AJAX call (obtained from the current state of the "form"), in details, those are going to be the labels, not the values.

And the reason the AJAX kicks off is because that's what "Calc on Load" does, as per the tooltip:

"If using ajax calculations, then turning this option on will re-trigger the calculation as soon as the form loads. Useful if your calculation relies on data which may have been updated elsewhere"

So it triggers an AJAX update during element init on the browser.

I can't fix the whole "no raw values in details view" thing, as that would be a monumental task. But what I could probably do is make the binary yes/no for "Calc on Load" be a multiple choice, like "Yes (both) / Form Only / Details Only / No"

So if just not doing the Clac on Load in details view would fix your problem, keep reminding me, and I'll do it as soon as I get 10 minutes.

-- hugh

 

[Bauer]

Yeah, changing 'Calc on Load' to 'No' fixes the problem in details view.
Thanks for setting me straight on this - and refreshing my memory on 'how it works'.

And, come to think of it, there's no need for 'Calc on Load' in a new or edit record either - at least not in my situation where the dbj element if set to 0 ('Please Select') by default. The calc should still get updated in those circumstances via ajax when the dbj selection is made, right?

But that still doesn't mean that this quirk regarding 'raw' value placeholders being used in a calc element isn't causing some Fabrik users problems. (I'll need to check dozens of calc elements in my project to see where else this might be an issue.)

I'll make an agreement with you that if you take the time to make your proposed change, I'll take the time to fix the Wiki to explain the dangers of using raw values in a calc element that is being used in details view.

PS. Come to think of it, I've run into this before.
My "fix" was to add another calc element set to 'Only calc on save' that included a concatenated string of the raw values from any dbjs that were used by all calc elements in that group - whose raw value was needed by other calc elements.
E.g. ...
return CONCAT('{tablename___dbj1_raw}','_','{tablename___dbj2_raw}) ;

Then , in those other calc elements, I would just reference that added calc containing the concatenated values and use the php explode function to pull the correct raw value from that string.

That fixes the raw values problem in a details view - but then you might have that chicken or egg problem (which calc is getting updated first?) that comes with calc elements in edit view. So I think I added an if condition to the calcs so they would only rely on the concatenated calc value in details view - else just use the raw placeholder.

I wish there was an easier way - but this wouldn't be the first time in life I thought that. And now I can't decide if your fix would eliminate the need for that special code. (I'll leave that up to you to decide how important this fix would be. My brain hurts)

 

[cheesegrits]

Yeah, I had a vague memory of discussing this with you before.

I'll make an agreement with you that if you take the time to make your proposed change, I'll take the time to fix the Wiki to explain the dangers of using raw values in a calc element that is being used in details view.

Just to undermine your bargaining position, I added a warning under the Important Notes section.

-- hugh