BUG-Setting an adapter for 1 control unexpectedly applies to other controls

[arcanaxion]

Description In the following example, using an adapter for my "fruit" selector to create uppercase labels unexpectedly also applies to my "flower" selector.

How to reproduce

import taipy as tp

fruit_list = ["apple", "banana", "cherry"]
selected_fruit = fruit_list[0]

flower_list = ["rose", "tulip", "daisy"]
selected_flower = flower_list[0]
md = """
# Select fruit

<|{selected_fruit}|selector|lov={fruit_list}|adapter={lambda s: s.upper()}|>

# Select flower

<|{selected_flower}|selector|lov={flower_list}|>

# Select flower

<|{selected_flower}|slider|lov={flower_list}|labels|>
"""

tp.Gui(md).run(run_browser=False, use_reloader=True)

Expected behavior Only the fruit selector should have labels that are in uppercase.

Screenshots

Runtime environment

• taipy-gui develop branch

[FredLL-Avaiga]

you need to specify a type type=fruit or type=flower If the type is not specified it is inferred from the data (here str)

[FredLL-Avaiga]

we might want to clarify the doc on that subject

[arcanaxion]

you need to specify a type type=fruit or type=flower If the type is not specified it is inferred from the data (here str)

Ah, I never knew about this property. I haven't experienced a situation where I used an adapter for a specific control and wanted it to apply to all other controls with the same lov type.

Take the following code:

import taipy as tp

fruit_list = ["apple", "banana", "cherry"]
selected_fruit = fruit_list[0]

flower_list = ["rose", "tulip", "daisy"]
selected_flower = flower_list[0]
md = """
# Select fruit

<|{selected_fruit}|selector|lov={fruit_list}|adapter={lambda s: s.upper()}|>

# Select fruit

<|{selected_fruit}|slider|lov={fruit_list}|labels|adapter={lambda s: s.capitalize()}|>

# Select flower

<|{selected_flower}|selector|lov={flower_list}|>

# Select flower

<|{selected_flower}|slider|lov={flower_list}|labels|>
"""

tp.Gui(md).run(run_browser=False, use_reloader=True)

Intuitively to me, the following code would have:

1. fruit selector: uppercase labels
2. fruit slider: capitalized labels
3. flower selector and slider: lowercase labels

But the actual output is:

[FredLL-Avaiga]

I suppose we can be a little more intelligent in the way we define the type when an adapter is present ...

[arcanaxion]

Intuitively to me, the following code would have:

1. fruit selector: uppercase labels

2. fruit slider: capitalized labels

3. flower selector and slider: lowercase labels

I tried to recreate my intended behavior like so:

"""
# Select fruit

<|{selected_fruit}|selector|lov={fruit_list}|adapter={lambda s: s.upper()}|type=fruit1|>

# Select fruit

<|{selected_fruit}|slider|lov={fruit_list}|labels|adapter={lambda s: s.capitalize()}|type=fruit2|>
"""

but this didn't work -- not sure I understand the type property properly.

[arcanaxion]

Sorry to reopen the issue. For the benefit of future readers of this issue (and myself), could I get some advice on how I can implement the intended behaviour in my comment above?

In my example above, the latter capitalize lambda is being applied to the upper control as well. I expected that the former would be upper and the latter capitalized.

[FredLL-Avaiga]

with the latest Taipy-Gui (develop), you would have nothing to do :-) in the meantime, you can use specific type as mentioned earlier

[FredLL-Avaiga]

Oh I see your point ! you're using the same variable but want different adapters ... I'll have a look at this

[FredLL-Avaiga]

The variable is associated to a type ... you'll need to use 2 variable names if you want to use different adapters for the same data

[FredLL-Avaiga]

@arcanaxion What do you think ?

[arcanaxion]

The variable is associated to a type ... you'll need to use 2 variable names if you want to use different adapters for the same data

Do you mean the variable of the value property (e.g. selected_fruit) should be different to use different adapters? There may be use cases where devs may specifically want the bound variable to be shared between two controls but have a different label.

I noticed that wrapping the lov in a list works, which could be a hack to achieve the above use case:

import taipy as tp

fruit_list = ["apple", "banana", "cherry"]
selected_fruit = fruit_list[0]

md = """
<|{selected_fruit}|selector|lov={fruit_list}|adapter={lambda s: s.upper()}|type=fruit1|>

<|{selected_fruit}|slider|lov={list(fruit_list)}|labels|adapter={lambda s: s.capitalize()}|type=fruit2|>

Fruit: <|{repr(selected_fruit)}|>
"""

tp.Gui(md).run()

Should I open a separate issue? I guess this is still related to the topic

[FredLL-Avaiga]

yes that's what I meant wrapping works because it's a new expression :-) good catch I suppose we'll have to improve the doc on this @FabienLelaquais What do you think ?

[FabienLelaquais]

I think the problem is legit but a fix would be overkill compared to potential use cases. It is true that this situation may happen, but I don't see that occurring so often as to avoid it completely: that would rely on the 'instance' of the visual element, which is something we don't control in the back-end.

As long as the expression for the 'selected' or 'lov' property is used to distinguish the case, we're good: create an 'identity' function, different for each control. This will need a paragraph in the doc.

@FredLL-Avaiga, @arcanaxion if you agree, let's create am issue in taipy-doc to clarify that.

[arcanaxion]

@FabienLelaquais

I think the problem is legit but a fix would be overkill compared to potential use cases.

I agree that this (sub)issue is minor. The larger issue was definitely when the adapter was being applied to all lovs with the same element type, which was quickly fixed (thanks!).

let's create am issue in taipy-doc to clarify that.

I don't think a line/paragraph in the docs is necessary because this issue should remain open and be "low priority" and not "not planned". I imagine that most people that encounter this unexpected behaviour would first look to the issue tracker, and find the workarounds here.

[FabienLelaquais]

At this point, in order to provide accurate additional documentation, this is blocked by #1159.