Provide for adding custom classes to web widgets

[jo47011]

I know I can easily create my own widgets. Still it in my eyes it would make sense to make the provided widgets as flexible as possible. We could add an attribute classes=list[str] to all widgets in python which would be added as additonal classes or data-tag in html. It would be a lot easier to customize, hide, etc. the widgets via css.

Example: I'm using a button group for my heating controls. I want to split the button group between the reset and the on/off button on the left and the up/down buttons on the right to improve usability. Without custom classes or alike it is kind of ugly to identify the correct button in css:

Furthermore it would also be nice to have the id (thus the data-idon js side) accessable on the python side. Then you could use it for some special triggers, for example I'm only showing the history graph of a room temperature when you click on it.

I know I can implement all this by myself writing my own widgets using the existing tool and framework. But I was wondering whether it wouldn't be a nice general feature for all users. What do you think?

[mhthies]

And again Sorry for the late response.

In my opinion, allowing to set HTML/CSS classes of widgets from the Python code would violate the current design principle of the SHC widgets: to hide all the web implementation details of the client-side rendering behind a simple Python-only interface. Thus, I'm rather opposed to the idea of adding such a generic attribute.

For the concrete use case, in my opinion, it would be more correct to create two button group elements (<div class="buttons">), maybe with some spacing in between, instead of adding spacing to one of the buttons. That should fix the border-radius of the two buttons in the middle. We can explicitly extend the ButtonGroup widget to (optionally) take a list of lists of buttons, which are then rendered as multiple button groups. If this would be sufficient for your use case, please create an issue for this new feature. (And, of course, feel free to implement it and create a PR, if you have the possibility to do so.)

[jo47011]

No worry about the delay, we are all doing this in our sparetime and I appreciate your support/feedback.

I implemented a 1st proposal in this PR #90. I have not rights to assign you as a reviewer and it seems like you need to approve the workflow to re-run tests after my commit of my mypy, flake, fixes.

Looks like a good starting point for a 1st contribution. Exciting 🚀

I will get back on your other feedback in the next few days. Thanks again.

[mhthies]

Considering the data-ids: Unfortuately, I didn't fully understand your usecase.

In general: Again, it's currently not intended to directly interact with the client-side implementation details of the web widgets, circumventing the Python API of the widgets. And, as I explained in the other discussion thread, in general, only connectable objects are expected to change or create events during runtime. So I don't really see, how one would need the widget data id in the Python code.¹

However, it may be easily possible to extend the existing widgets to provide a (connectable) API for your usecase or create a simple wrapper widget that allows to dynamically hide other widgets, based on dynamic events from the server.

¹ That said: It's quite easy to retrieve: It's just the Python object id of the WebUIConnector object (e.g. the button or chart object), which is returned by id(the_object).

[jo47011]

In general: Again, it's currently not intended to directly interact with the client-side implementation details of the web widgets, circumventing the Python API of the widgets.

Well my current use-cases are mainly for some click interaction. I want to show and hide some items, e.g. only show the graph when you click on the name.

After clicking on e.g. Schlafzimmer it looks like this:

Currently to achieve this I inherit from the according shc widget and add the following attributes:

<div
     {% if data_classes is not none %}
        class="{{data_classes}}"
     {% endif %}

     {% if on_click is not none %}
        data-on-click="{{on_click}}"
     {% endif %}
>
     {{ shc_template }}
</div>

Actually I'm no longer using the data-id but working w/ the classes.

With those attributes it is easy to add a javascript function to do whatever you want. Now having a little bit more in depth-knowledge I know how to implement it in pure python. But this was just quicker for me and seems to be more generic for some users who are firm in javascript. Thus providing a steeper learning curve. I understand your approach of encapsulating the shc python part. But still I'm not sure whether it not would make sense to open up for some javascript handling just for the convenience.

Another use case is I want to load another page when clicking on an item. E.g. I have this info about open windows on my overview page:

When you click on it the windows page with all window details is opened as easy as this:

index_page.add_item(
    ClickableTextDisplay(
        int,
        icon("window maximize outline", "{} Fenster"),
        "",
        on_click="window.open|Fenster",  # <= this line is new
    ).connect(open_windows_num)
)

Please see these examples as base for discussion about my use cases only. If we finally decide to move/add all this functionality to python is fine for me as well.

[mhthies]

Hm, I think, my approach to those use cases would still be to implement the respective functionality directly within the widgets. For hiding and dynamically showing the plots, I would imagine a Collapsable widget, that would wrap any other widget and display a dropdown-like button to show or hide the wrapped widget. Maybe even allowing to assign a "group" string to synchronize multiple Collapsable on the same page in an "accordeon"-style behaviour.

[jo47011]

Yep, I agree that would be an approach. I even thought about enhancing the HideRowBox to support any kind of widget. In any case we should implement the grouping option to support multiple widgets as you propose.

[mhthies]

I don't think, the current HideRowBox should be extended to support any kind of widget. Yes, a special HideRowLabel to display in the place of a button would be cool (simlar to the ImageMapLabel).

For dynamically showing/hiding of multiple widgets based on some state in the SHC server, I would suggest adding a new wrapper widget type. Of course, we could reuse the client-side Javascript code for the HideRow widget for this.

[mhthies]

I've created #95, #96 and #97 for these ideas.

[mhthies]

Buttons (or widgets in general) that work as a link to another page (as a simple navigation widget, or inside the HideRow widgets have been on my mental todo list for a long time, and I always have forgotten to actually implement this. I would suggest to add (at least) a new button descriptor type for this that is not a connectable object, but instead takes a WebPage (or a WebPage's name as astring) and renders as a link to that page. It could then be used in ButtonGroups, ImageMaps and HideRow widgets.

[jo47011]

I totally agree on your LinkButton proposal. But why not also allow the TextDisplay, HideRowBox and maybe some other widgets to be clickable? Would provide a greater flexibility and would save the additional space for the button wherever needed.

[mhthies]

Yes, I like that suggestion. For the TextDisplay, I would imagine a new widget type ("LinkTextDisplay" or similar) that will render the value text as an actual link.

HideRow could take an additional optional parameter that enables the linking functionality. This should also result in using the cursor: pointer CSS attribute to give the user a hint towards that functionality.

We should probably allow passing either a page name, or a WebPage object, or an absolute (external) URL to all those parameters.

[mhthies]

I created #92, #93 and #94 for these ideas.