if you add the custom widget as the “default list item widget” in the metadata of the Item,
the correct properties of the custom widget appear and can be edited
if you then and add the Item (Add from model…) to a list on a page, the output of the page is showing the item title, icon, state properly properly and does not disappear from the page in visual editing mode.
Once it has been added to the page, the custom widget cannot be (visually) edited anymore (you cannot edit the widget properties, but only the settings of the underlying oh-list-item (same as above)
If you edit the Metadata of the item and change some of the widget properties (e.g. the battery name), this does not get updated on the page.
This means that basically, you can’t change the widget configuration, the only way is to remove it from the page and add it again (very annoying). The same is neccessary of course if you e.g. add another property to the widget later on. Only changes within the widget are propagated to all instances where it is being used.
Hi all, the custom widgets here looks great! Thank you.
I have a question though, about some syntax and weird behavior from OH.
I tried to import the list widget for light…
I created a new widget in the developer section, copied the code to the editor and saved.
I created my model and items through files so I added this line to the metadata: listWidget="light_list_widget"
so my item is defined as follow:
(instead of xxx there’s the appropriate channel string)
Now checked in the “Living Room” card- It didn’t work. The widget didn’t render at all.
I narrowed it down to the last two lines of the code:
title: =props.title
item: =props.item
Added a ‘tick’ to he expression (not sure what’s the correct name for this symbol in English):
title: '=props.title'
item: '=props.item'
Now it kind of works. I managed to render the widget correctly but, here comes the weird part, the widget kept reverting back to the original form without the ‘ticks’ I added.
I tried to remove the widget entirely and create it again, but when I saved it the ‘ticks’ were gone.
Thought maybe it’s a weird cache thing so I tried to create a new widget with a changed uid- again after hitting save those exact same ‘ticks’ were gone.
First question- what is the correct syntax?
Second- what could the reason for this weird behavior?
That widget defines two properties, title and item. In order for the widget to work you need to define those two properties on the Item. I don’t know how to do that with .items files (and I’m particularly interested in finding out). You probably need to define them as configuration parameters on the listWidget metadata.
Without setting the title and item properties, the widget doesn’t have anything to work with or display. They are undefined.
The single quotes and no quotes are irrelevant and not related to anything going on here.
I don’t know but the weird behavior isn’t what you think it is. The fact that it works at all without setting the properties is the weird behavior. It shouldn’t work at all.
Just found this post, which apperantly answer this exact question:
While it seems it’s not possible through .items files, it says that I can define the metadata through the UI and it should work. So this is my next “to do”.
Thanks!
EDIT:
On the other hand…
I noticed that the item property get populated correctly when set through the .items file. I wonder if it would be possible to define the widget to take to label value of the item as a title.
That way it might work because nothing needs to be defined in the .items except the uid of the widget, which apparently work.
I’d glad to hear your thoughts on the idea and how could be defined.
Thanks.
I don’t believe the widget is even getting the item from the file definition. The widget defines the item property with the context: item which, as I understand it, means that when this property is undefined (as it is in this case because it can’t get the definition from the .items file) the UI is capable of pulling a sensible property value from the usage, which is easy in the case of a widget that has been set as a default widget for an item.
Also, last I saw, there is no simple way of getting the label of an item from the item name in a custom widget. Right now the widget items object only defines state and displayState properties.
It absolutely is possible to do this through .items files. I just don’t know how. It’s probably something like listWidget="light_list_widget"[item="ItemName", title="Label for the widget"] (since this is Item metadata like any other Item metadata). But I don’t know if I have the properties labeled right or if there is something else that needs to be in there.
You can define the widget how ever you want. The above are just examples and I fully expect them to be customized. In fact, you could forego the use of a custom widget entirely if you wanted to and define everything on the Item’s metadata itself.
But, as JustinG indicates, you don’t really have access to all that an Item offers in a widget. You mainly have it’s state and displayState and you only get the latter if you defined State Description metadata. When using an oh-repeater widget you get a little more in that you can access an Item’s tags and group membership in creating the list of Items to create the widgets for. But that’s it.
Therefore, in a case like this you’ll need to hard code in the label for each individual widget, which is what the title property is there for.
I too use some of the widgets you published here (thanks for that). When trying them out I was wondering about how to define the properties, but it seems that it just works
Beside that no other metadata is defined for that item and it uses the widget (which is just the renamed widget from Rich). I just double checked, when removing the widget from the item definition the default widget is shown.
As JustinG mentioned, I would guess that if the property is not defined then it defaults to some reasonable value. But that won’t always be the case. For example, the door lock widget uses more than one Item in the widget. If you don’t define the properties the widget won’t have a reasonable default to fall back to.
I am not sure, if the control item has to be set too, if this item uses your lock widget, but this could be done accordingly with “control_item”. My assumption is, that you can use the name of the property, as defined in the widget, when tagging the metadata.
What is nor working is, that the badge in the widget changes when toggling the status item. But this behavior is the same whether I set the items in the items file or in the UI (tested this with a second test item). This is probably just me not using your widget correctly.
Am I correct that these widgets are used on the items itselves? I’ve setup a widget on an item (Default List Item widget). In the screen were I select the correct widget and properties, I see the widget how it should be, but when I save everything and go back to the item, I only see the state at the top of the screen, no widget. When I select a default widget, the same happens.
Refresh the page and navigate to your Overview page and look at the widget in one of the cards.
Note: these widgets only appear when the Item is presented in a list (hence the name “list widget”). It’s not going to change the widget you see at the top of the Item’s configuration page. That’s a standalone widget.
Thank you for this sharing, I have trouble understanding how to use the “.prefix” with my “items” on files, do we have to create a “prefix” item? could I have some clarification on this? thank you a thousand times
First of all, to my knowledge custom widgets cannot be defined in .items files or in any text based config file at this time.
A custom widget is the only way to define a widget with it’s own set of properties.
In the Chromecast widget above I’ve defined a property called prefix. That’s a property defined by me and which only exists in that one widget. There is no generic prefix property that exists for all widgets. In this one widget where I’ve defined it, the prefix is to contain the first part of a set of Item names that are all the same and which represent all the needed Items for that one Chromecast. In this case <prefix>_MediaTitle, <prefix>_MediaArtist, <prefix>_Idling and so on. Those are all separate Items that all start with the same thing. That’s how the widget knows which Items to use without explicitly defining each and every one individually.
I have no idea what the metadata would look like to use a custom widget in a .items file. probably something like { listWidget="chromecast_list[prefix=KitchenDisplay]" } but can’t say for sure. I frankly don’t see much point of doing MainUI related stuff in .items files. You can set metadata for Items that are defined in .items files without doing so in .items files.