In form calculations

[envas]

I need to perform a calculation in a form. I think I selected the right way - I created field definitions with dependency

fields:
   a: ...
   b: ...
   c: ...
   x:
      dependsOn:
            - a
            - b
            - c

and the calculation is performed in the model function filterFields($fields, $context = null). Unfortunately, changes on a require database access, changes on b or c do not. To avoid a database roundtrip and improve performace I need to know, which field fired the event or, at least, the old field values. As I discovered, in the filterFields() function the model is filled with current form data, not, as I expected, with the original data fetched from the database or nulls in case of creation.

Is there any other way to perform these calculations in standard ways? Or do I have to use JavaScript?

[LukeTowers]

You should be able to use getOriginal('attribute_name') to get the original value of the field @envas

[LukeTowers]

In your specific case I would again recommend computed values through accessors on your Order model rather than trying to keep a database column up to date. It would be relatively simple to add a getTotalPriceAttribute() method to your Order model and generate that value dynamically based on the current state of the system (which is what I would recommend doing for consistency). Additionally, any part of the UI can be customized, so if you want the buttons to say something else that's totally doable.

[envas]

I work for a Swiss bank and for a banking company this way of accessing the data would be an absolute no go. Everything the customer gets on paper has to be reproducible. Here, if someone changes the program code, the historical data will be changed too! What if I print order after five years and someone has changed the function code in the meantime? Not even constructs like name = firstname.' '.lastname are not allowed. What if someone has changed the name in the meantime?

But come on, I guess I'll have to do it, even if I don't want to.

[LukeTowers]

Auditing requirements are a different ball of wax. If you need the values stored as part of an auditable trail of transactions, then that's totally doable, but you do need to make sure you cover off all of the places where the underlying values that make up the generated values are able to be changed.

@danielbidala's suggestion and your current implementation of calling a getTotal() method twice (once in filterFields() and once in beforeSave()) is a perfectly valid approach too. It sounds like it sort of comes down to the concept of client side vs server side validation. Client side validation (which filterFields is mostly for tbh) is purely for UX, server side validation (i.e. beforeSave() validation of data) is the key requirement to maintain data integrity. Does that align with your view points?

[envas]

Does that align with your view points?

From a functional point of view, yes, the results are as expected. Still not clear to me, why UX validation takes place in the Model class. I would expect it to be more in the Controller, but ok, accepted. I think the topic could be closed, we have a solution for 'in form calculations'.

[envas]

Here's a summary for those who don't want to read the whole discussion. We have the following Order - OrderItem form, the calculations marked with arrows are requested. There are dependencies:

• unit price depends on product and quantity (bulk prices)
• item price depends on unit price and quantity
• order price is sum of all item prices
• vat depends on delivery country
• total price depends on order sum price and vat

The requirement was to implement these calculations in the form without the need to refresh the browser page. To implement the requirement we had to:

• perform the identical OrderItem row calculation in the OrderItem model in filterFields() and beforeSave()
• perform the identical Order calculation in the Order controller in relationExtendRefreshResults() and in the Order model in filterFields() and beforeSave().

filterFields() works with form fields, beforeSave() works with the model and relationExtendRefreshResults() works with he HTML tags of the related form fields.

Even with this setup, you will get database inconsistencies unless you somehow disable the Cancel operation in the Order form after the relation record has been modified. The solution would be not to keep the order->itemsum, order->vat and order->total fields in the database but always just calculate them. For legal reasons this was not possible in our case and therefore we had to add the calculation of these data in the OrderItem in the functions afterSave and afterDelete, where after updating the Order values the Order save() is executed.

You can expect further code escalations if your Orders are not always entered directly, but can also be created as copies of quotations. Then you need to adopt the calculation logic that was used in the quotation and eliminate the logic when entering the Order directly. Locations in the code, where it is necessary to perform frequently repeated calculations everywhere (although these can of course be consolidated into static methods), will then begin to take on exponential value.

That's total crazy, tbh I'm glad I don't have to do this for a living.