How to retrieve row data without submitting in inline mode?

How to retrieve row data without submitting in inline mode?

pisislerpisisler Posts: 6Questions: 2Answers: 0

Hi.

I am doing some kind of cross calculation and cross validation with a complex structure and it works fine. But there is a problem with retrieving the row data in inline mode.

In create mode, editor sends all the data as expected and no fancy things needed. On the other hand in inline mode, editor submits only the value of the cell that is being edited. For cross validation to work, I needed to set formOptions to send "allIfChanged".

While this lets the cross validation work, it also causes all fields' validation functions to be called (because it submits the data whether it's altered or not), although those cell values are not changed; which is a great performance issue.

Is is not possible to retrieve the row data without submitting it?

For example a renderer like function ($data, $row) is not receiving the row here, in inline mode. (Because the other values are not submitted)

If, it's technically not possible; then is it also not possible for the editor to check the actual "changed" data? I mean when submit option is set to "allIfChanged", would'nt the editor be able to submit all values but update the database only if the value is really altered?

Answers

  • allanallan Posts: 46,102Questions: 1Answers: 6,387 Site admin

    Is is not possible to retrieve the row data without submitting it?

    Where are your validation options? It sounds like they are on the server-side - if that is the case, then they would have to be submitted to the server in order for them to be available there.

    Perhaps one option would be to use ajax.data to get the data from the row being edited (table.row( editor.modifier().parentNode ).data() - depending on exactly how you trigger the editing!) and submit the data for the row in a custom parameter that the server-side libraries won't check for? Then you could use that data for your cross calculation.

    Allan

  • pisislerpisisler Posts: 6Questions: 2Answers: 0
    edited May 17

    Thanks Allan. Yes, I do the validation in server side script, adding a validator into the chain like;

            Field::inst( 'price' )
                ->validator( Validate::minNum(0) )
                ->setFormatter( Format::ifEmpty(0) )
                ->validator('update_price_soap'),
    

    I do this in here because if something goes wrong and the update_price_soap() cannot update the SOAP service, then it will return an error not letting the DataTables store the new value. That's why this function needs the row data to know which product's price is going to be updated in the SOAP service. But the problem is, this and all other similar functions repeatedly work with other cells also changed. I mean the price is not altered but my SOAP function is called nevertheless, because the price is submitted too.

    As for its nature, I know that they have to be submitted. What I mean is, submitting happens in two parts here. First, editor submits the data as an actual form to the server. Second, PHP part takes this submitted data and inserts/updates into the database. So I thought maybe the PHP part would give up updating the database for that cell if the cell value is not really altered. If that is possible, then the editor would have changed only the altered values, although all the values are submitted.

    Perhaps one option would be to use ajax.data to get the data from the row being edited

    With this method, I think I will have to move my validation functions to some custom file and do some extra coding; because this way I understand that I won't be able to use DataTables internal API.

    Maybe another workaround could be sending the edited cell name as a parameter; so that the custom validator would always return true if this is not the actual cell that was edited inline?

    Like this dirty code for example;

    function update_price_soap($data, $row, $current_cell) {
        if ($current_cell != 'price')
            return true; // We don't need to validate, because price hasn't changed.
        // Or you can do other cross validation, like "although the price hasn't changed
        // some other data might need to remain in a specific range in accordance with current price".
    
  • allanallan Posts: 46,102Questions: 1Answers: 6,387 Site admin

    So I thought maybe the PHP part would give up updating the database for that cell if the cell value is not really altered.

    No - if Editor submits it from the client-side, then the server-side libraries will act upon it. They don't currently read the data back from the database to check if anything has changed. A write is normally just as fast, or faster if you need to then also write after the read.

    Maybe another workaround could be sending the edited cell name as a parameter

    Agreed! That's what I was thinking while reading your follow up there.

    This recent thread I think will be useful here. You can store the values as they are when the editing is started, then get the values on submit and check to see if any have changed. If so, add those field names to the data being submitted so your custom validators can see that and act upon it.

    Allan

  • pisislerpisisler Posts: 6Questions: 2Answers: 0
    edited May 19

    No - if Editor submits it from the client-side, then the server-side libraries will act upon it. They don't currently read the data back from the database to check if anything has changed. A write is normally just as fast, or faster if you need to then also write after the read.

    What I ment was, the client side could have submitted both old and new values to the server side. So that it wouldn't need to read from database and compare if it has changed. Like maybe;

    function price_validator($data, $row, $old_values) {  }
    

    Also a quick note; there's no need to send the cell value as a seperate parameter ($data) in my opinion. Because no matter the option you set for "what to submit"; that cell's value will always be stored in $row array anyway. Like;

    price_validator($data = 3.45, $row = array('price' => 3.45))`
    

    So what's the point in sending one extra parameter?

    This recent thread I think will be useful here. You can store the values as they are when the editing is started, then get the values on submit and check to see if any have changed.

    I couldn't make use of it well; or maybe I couldn't figure out what was really pointed out in that thread :/

    As far as I see, he doesn't trigger a PHP script as he suggested and his method didn't seem to be compatible with DataTables API to me. In that method; I believe this is what's gonna happen;

    With this method, I think I will have to move my validation functions to some custom file and do some extra coding; because this way I understand that I won't be able to use DataTables internal API.

  • allanallan Posts: 46,102Questions: 1Answers: 6,387 Site admin

    So what's the point in sending one extra parameter?

    Simplification only. You are right it isn't required, but it means that you don't need to know the name of the field in the validator. That makes it much easier to write generic validators for simple scalar values.

    As far as I see, he doesn't trigger a PHP script as he suggested and his method didn't seem to be compatible with DataTables API to me.

    My point with linking to that thread was that you would be able to stored the values of the row when editing is triggered, and then check to see which ones have changed at submit time. That would be client-side checking.

    From your description it sounds like you want server-side checking. Which is fine - for that, use my suggestion above of ajax.data and table.row( editor.modifier().parentNode ).data() to get the original, unmodified data, for the row. Then you can add that to the object to be submitted and do whatever server-side check it is that you need.

    Allan

Sign In or Register to comment.