Results 1 to 6 of 6
  1. #1
    Member
    Join Date
    Dec 2008
    Location
    Karlsruhe
    Posts
    7

    Question Formatting of unchanged values in "DynaScrollTable"

    While searching through the forum to see if I could find some information regarding a problem with value-formatting while using a "DynaScrollTable" I came across this response by Dario Crivelli in a thread regarding the "addField" method:

    Quote Originally Posted by DarioCrivelli
    [...]
    However, in the onChangingValues callback (the place where formatting instructions can be given to the VisualTable), the previous values of the updated fields are not available.
    On the other hand, they are available in the onItemUpdate callback.
    [...]
    Out of curiosity, why did you chose to make the previous values available only in "onItemUpdate" and not in "onChangingValues"?

    We actually are dealing with this "problem" on one of our sites at the moment. We have a "DynaScrollTable" receiving updates containing a timestamp, an identifier (string) and two decimal numbers. We need to format the numbers before displaying them (rounding decimal places, insert thousands separator - e.g. original value is "12345.6" and should be displayed as "12.345,600"), and it normally works like it should..

    ..but sometimes only one of the two numbers changes, so when our "onChangingValues"-function gets called I can't access the value that the unchanged field previously had, as "updateInfo.getFormattedValue("number2")" is "null". As we don't know the previous value we're not able to format it, and the unformatted value is displayed in the table.

    Ideally I would write something like this in "onChangingValues":

    ..but I don't have access to the old value in "onChangingValues". At the moment the only way I see to get it to work would be to add some logic to the "onItemUpdate"-function, check if there are fields that did not change, and then add the old values of those fields via "UpdateItemInfo.addField(...)", so that I have the old value available in "onChangingValues" - I can't format the respective field in the "onItemUpdate"-function as I can read the value but not write it back into the field ("addField()" can only be used to add extra fields).

    I don't really like this "solution" as it looks to me to be quite inelegant, but I don't see any other solution - perhaps I'm missing something simple or obvious as I assume that this is not an unusual use-case, but looking through the online documentation didn't give me some better idea yet.

    Ideally, for an unchanged field, the table should just reuse the last set value of "setFormattedValue()" for the specific field, so my code could just ignore unchanged values, but the web client api doesn't seem to behave like this, at least on our site.

    I also looked through the Changelog for the Web Client SDK, to see if there was some change or bugfix that related to formatted values, but I did not find anything there, either.

    Any idea or comment is appreciated.

  2. #2
    Member
    Join Date
    Dec 2008
    Location
    Karlsruhe
    Posts
    7
    After tinkering around with our "onChangingValues"-function some more we managed to get it to work, with a tiny modification.

    Originally our code looked something like this:

    ..and when the value for "number2" didn't change "getFormattedValue" would return "null", so the formatting didn't work, and the unformatted value would be inserted in the "DynaScrollTable".

    Out of curiosity I changed the code to use "getServerValue()" instead of "getFormattedValue()", and all of a sudden it worked. The only thing I did was to change the line
    Code:
    var number2 = itemUpdate.getFormattedValue("number2");
    to
    Code:
    var number2 = itemUpdate.getServerValue("number2");
    After putting some debug output in our function to see the values for "getServerValue()" and "getFormattedValue()" it showed the following:
    • When the value for field "number2" changes in an update the new value is supplied identically via both functions (e.g. both functions return a value of "123.45")
    • When the value for field "number2" does not change in an update, "getFormattedValue()" returns "null" - but "getServerValue()" returns the last received value

    Even though our code now works correctly, and the problem we had before is explained after the debug output, I still find the behaviour of the web client somewhat strange.

    "getServerValue()" doesn't puzzle me, it returns the last known value, no matter if it was received with this update, or with a previous one - in effect it always returns the latest value the server sent/knows for the field, exactly what the name of the function implies.

    "getFormattedValue()" on the other hand doesn't really do what the name implies. When there is an update for the field, then the function intially returns the same value as "getServerValue()" does, which is the unformatted value sent by the server. Only if I manually call "setFormattedValue()" a subsequent call to "getFormattedValue()" will return something different - but as I already know what that value is (as I just set it before) I don't see the benefit of using "getFormattedValue()". And if there is no update for the field, then "getFormattedValue()" does not return the last known formatted value (which would make it behave similar to "getServerValue()"), but instead it returns "null" - and if I don't set it to something sensible (by accessing "getServerValue()" and setting the formatted value by calling "setFormattedValue()") the unformatted value will be displayed on the website.


    The way I see it, in order to make sure that everything is formatted correctly on the website, I always have to format each field by accessing "getServerValue()" and setting "setFormattedValue()", no matter if that field did actually change in the last update or not, because if I don't do so the web client library will display the wrong unformatted value instead of the correct formatted value of the previous update - even though the library ideally should still know the previously formatted value which would make the redundant formatting of unchanged values unnecessary.

  3. #3
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    Oooops! What follows was supposed to be the answer to your first post.


    It turns out that your problem is caused by a bug, which is specific for the DynaScrollTable case.
    With a DynaScrollTable, when a field value is unchanged with respect to the previous update, getFormattedValue is not supposed to return null.
    Thank you for the detailed notice.

    In fact, an update for a scroll table is meant to produce a new row, hence a value which is unchanged with respect to the previous update has not the same meaning as it has for an OverwriteTable, where it means "don't touch the cell in any way".
    The above cannot be used as the default behavior in a scroll table, where it cannot even be considered as a common case.
    As a consequence, computing and setting the formatted value of the fields is always needed on scroll tables.

    You can easily overcome the bug by always using getServerValue in place of getFormattedValue. The former returns the current field value in any case, that is, regardless that the value is new or unchanged.
    More generally, getServerValue is the intended way for getting the value to be formatted; hence, your use of getFormattedValue is improper (although getFormattedValue initially returns the "default formatting" for the value, which, in most cases, happens to be the same as the original value).
    Moreover, as your problem is related with an unchanged field, you don't really need to get the previous value, but rather the current value, as the base for formatting it; hence, getServerValue is all you need.
    To summarize, you can just forget getFormattedValue and always compute and set the formatted value of the fields, starting from the unformatted value returned by getServerValue.

    Actually, only when the formatting of a changed value also depends on the previous value is the separation of onItemUpdate and onChangingValues annoying.
    We considered such a case as infrequent (though it also occurs in our StockListDemo). If I understood right, this is not your case, either.
    Hence, we preferred providing two distinct callbacks for the value management pipeline, so that
    - the interface of each callback would be simpler and
    - onItemUpdate could be shared by all table types, whereas onChangingValues has to be different for each table type.

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    To clarify: for each value, we have a Server value and a Formatted value.
    In onChangingValues, the Server value is constant, while the Formatted value has a factory default at the method entrance (that you can query through getFormattedValue) and it has to be the desired one at method exit (so you can change it through setFormattedValue).

    Moreover, null as a Formatted value has a special meaning, which is "don't touch the cell at all" and, in some cases, it can be used as the factory default. We do that for Overwrite or Metapush tables in case of unchanged values.
    For Scroll tables we also do that, but, unfortunately, it's a bug. The fact that, with null, you eventually see the unformatted value in the cell is just a consequence of the same bug, which anyway you prevent by always setting the Formatted value.

  5. #5
    Member
    Join Date
    Dec 2008
    Location
    Karlsruhe
    Posts
    7
    Thanks a lot for your reply and clarification Dario. As you classify the "null" value as a bug for ScrollTables, does this mean that we'll see a bugfix for this specific case in one of the upcoming web client builds?

    After reading through your reply I think I better understand your reasons for splitting the processing in "onItemUpdate" and "onChangingValues", and even the need to format each update in a ScrollTable (even for unchanged fields) makes sense, as the relation between separate rows isn't necessary clear, so even if a field value doesn't change it doesn't have to mean that the formatting is identical for each row.


    Regarding your comment...
    Thank you for the detailed notice.
    ..I think my detailed way of writing shouldn't come as a big surprise for you, after all the support eMails we exchanged in the past already..

  6. #6
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    I confirm that getFormattedValue will be fixed (though you may not need to use it anymore) and aligned to the existing documentation (for setFormattedValue).

    Just consider that null is also an allowed field value. If it were used by the Data Adapter (or, more likely, if a field were left unassigned by the Data Adapter for an item in DISTINCT mode) then null would still be the default formatted value and it would keep the special meaning.
    However, for a Scroll table, the meaning would be to preserve the initial value of the cell, rather than to copy the value of the previous row.

    I also confirm that focused and detailed reports are appreciated. This especially holds for the forum, where no strict time commitments are involved.

 

 

Similar Threads

  1. Replies: 1
    Last Post: July 10th, 2012, 07:06 PM
  2. Replies: 2
    Last Post: March 1st, 2012, 02:53 PM
  3. Replies: 3
    Last Post: February 19th, 2010, 12:14 AM
  4. Are unchanged values broadcasted?
    By Otake in forum Client SDKs
    Replies: 2
    Last Post: December 17th, 2009, 03:13 PM
  5. Replies: 1
    Last Post: September 18th, 2009, 10:13 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 07:01 AM.