Feature:Added a function in gui class to support dev callback #457

[Ujj1225]

Resolves: #457

So there was this issue where we thought of giving developer option to change unsupported data format to a supported type
For this I have made two functions in class Gui namely "on_invalid_data" and "set_on_invalid_data_callback"

The Second function "set_on_invalid_data_callback" accepts a callback as parameter and uses this function to transform data into supported format. If user doesn't provide a callback, it works as it used to. Nothing would change.

Besides in data_accessor, I have modified _InvalidDataAccessor. For all methods like get_data, get_col_types, etc. It calls the first function "on_invalid_data" to transform it into a valid data type. If no callback present it will work as it used to work.

[Ujj1225]

@quest-bot loot #457

[quest-bot]

Quest PR submitted!

@Ujj1225, you are attempting to solve the issue and loot this Quest. Will you be successful?

---

Questions? Check out the docs.

[FredLL-Avaiga]

Good work @Ujj1225
Please, move the invocation of the callback
we need tests

[Ujj1225]

hey, @FredLL-Avaiga
I am so sorry for this formatting issue (turns out my prettier mistakely formatted the code I'll make sure to get it reverted)
So i changed the function on_invalid_data's definition and assignment following the way on_action is defined and assigned.
Besides I also did run some tests. I havent pushed the file. Its called test_unsupported.py
What scenarios did I test?

• No callback
• Callback that returns None
• Callback that transforms data
• Callback that raises an exception
  Its results
  
  Do i need to push this file as well? I created it inside gui_specific tests

[Ujj1225]

hey i wrote a test case for the _get_instance as well

[FredLL-Avaiga]

I don't see your tests ?

[Ujj1225]

I don't see your tests ?

Hey i have pushed test featuring the method __get_instance of data_accessor. This is where we are actually using transformed value and getting the access type for the transformed value

[FredLL-Avaiga]

any news ?
please update your branch

[FredLL-Avaiga]

Are you still working on this PR @Ujj1225 ?
If you are, please resolve the conflicts, update your branch and answer the questions
If you are not, please close the PR

[Ujj1225]

yes @FredLL-Avaiga I am working on it I'll resolve the conflicts and update the branch soon!

[Ujj1225]

hey @FredLL-Avaiga I have now swtiched to use of public api _get_data to check for the method _get_instance but still I am struggling with the use of _get_accessor()._register()

[FredLL-Avaiga]

your branch still have conflicts

[FredLL-Avaiga]

I began some test implementation
Can you check it out and finish it ?

[FredLL-Avaiga]

are there still some linter issue ?

[FredLL-Avaiga]

why don't you use the _register method and the MyDataAccessor class ?

[RymMichaut]

Congratulations @Ujj1225 on this merged PR
Could you please contact me at [email protected] for the shipping?

[FabienLelaquais]

So I have a few remarks after I ultimately got the time to look at this.
First of all well done, @Ujj1225. What you propose does the job, and instructions were followed. And congrats for the tests!
We will integrate this into Taipy BUT only after I'm happy with the proposed API, which I'm not. But hey, nobody could have thought, since I never opened my mouth.

---

Here are the reasons why I'm reluctant to merge as-is:

• Really, this thing is not a callback. In all of Taipy's terminology, a callback invocation is the result of an event that reflects something happening on the front-end. A variable was changed (on_change), a button was pressed (on_action) and so on.
  This is really not the topic here. And again, the original wording of the issue made it confusing. I apologize for that.

• The proposal to create a method of Gui makes things clear... but wrong, in my opinion.
  The functionality is not related to any Gui. A Taipy GUI application with several Gui instances (although we're still wondering what the use case would be) would not really know what to do.

• The role of the user-defined function is to convert data with an unknown type into a typed value that Taipy supports.
  That could be seen as a "type converter," but the naming is confusing since what it does is really convert the data, with the type change being a (desired) side effect.
  So let's call this a "data converter". Actually, that's not so bad, since we can implement whatever we want, right?
  It's a shame there's so little context when the function is invoked (then the conversion could benefit from more information to do things differently), but we have what we have.
  And what we want is to handle values with unknown types. Not so much invalid. Now we get to "unknown data converter".
  And this would be exposed from the data module. Finally, "unknown converter" can do the job.
  I would certainly create a global function (taipy.gui.data.set_unknown_converter()) that can be invoked with any user-defined function expecting any value (knowing that its type was not recognized by Taipy for serialization) and returning any other value with a type that Taipy does supports.
  A single global variable (similar to current's Gui.on_invalid_data) will privately keep this from the user's eyes.

The bottom line is this exposed API:

# set_unknown_converter() would be defined in or imported by taipy/gui/data/__init__.py

def my_amazing_converter(value: any) -> Any:
    return ... # Whatever transforms value into something Taipy can use
  
taipy.gui.data.set_unknown_converter(my_amazing_converter)

It is implemented in a manner very similar to what you have proposed, and I volunteer to refactor all this.
Of course @Ujj1225 the 100 pts are yours.

@FredLL-Avaiga what say you?