Hi Rich, I thought, I give it (grouping/sorting/filtering items list by Thing, Tag, Semantic Class, class, hasLocation and editing items) a try but soon realized I need a kick start.
I need to get all items into an oh-repeater array. A straight forward way is to have a button which triggers a rule which calls the rest API (/rest/items) which writes the result into an item which then serves as an array for the oh-repeater.
I wonder if there is a more direct way?
I was also looking into oh-context and script component but didn’t see a way to make use of it.
The first thing I would try is to see if you can get all the Items using itemsWithTags with an itemTags left blank of set to *.
In the very likely event that that gives you no Items instead of all Items, the rule Idea is probably your best bet short of making a request to add the ability to get all Items added to the oh-repeater element.
But you don’t need to use the REST API for this. With JS Scripting you only need items.getItems() to get an array of all the Items. In Rules DSL you’ll first need to get the ItemRegistry but it has a getItems() method too. But you will probably want to expose some metadata here too and since metadata isn’t available in Rules DSL JS Scripting or jRuby might be a better choice.
The itemsWithTags approach works, but you have to use:
itemsWithTags: ","
This is a rather heavy handed application of the repeater and will be somewhat slow to respond if you have a large number of items.
I have a helper widget which I include in a few other of my widgets that uses this trick. When included in another widget this will present a list of items (possibly filtered depending on configuration) and selecting each item will trigger whatever action is set via the action parameter.
Hi Justin,
I have put together the first draft and I am struggling with the component redraw (this is related to the other question I had where you have already replied).
As you have already guessed the repeater cannot handle hundreds of items so I tried to rebuild a pagination as my goal is to keep a grid view on the items.
If I click on the pagination everything works as expected (if I manually refresh the page afterwards).
However, when adding a key to the f7-block in which the grid is defined the browser falls into an endless loop. S something must be wrong with this approach.
Could you please have a look?
If you see other areas which could be improved I’d appreciate feedback. I don’t need full code just some ideas so that I can start digging me through.
The problem here is that you are using the context constant for the items that are in the page. That doesn’t recalculate even it it is dependent on a variable that changes. The constants are only calculated when the oh-context is created (when the page load, or when you refresh the widget view). Instead of a constant, you want to use either of the other two context options a variable or a function. I’d probably use a function in this case. Something like:
Then each of your grid cell starting values look like this:
defaultValue: =fn.getRow().name
With that you won’t even need to have the key value on the block, the grid will update whenever the page variable changes.
The loop is happening because of some feedback between the key and the oh-context, for reasons I cannot quite figure out. I don’t know if this is a problem with the context in general or with this specific configuration you’ve got here. I will have to do some testing. Either way, the above approach should eliminate the need for the key so you don’t run into the problem anymore.
Thanks a lot Justin.
During “debugging” I found another potential problem with oh-context:
I double checked if the value of the two constants totalItems and page were correctly assigned when the widget is opened the first time (without the widget being redrawn).
It turns out the the values are not assigned and I get the following error message for both constants:
SyntaxError: No number after minus sign in JSON at position 1 (line 1 column 2)
It seems the consecutive parsing of one and the same item results in the value “-”.
When redrawing the widget the correct value is assigned.
This is also part of the problem, why thegrid within the widget does not get populated with items properties.
EDIT: Even the first constant (jsonItemList) is not working. Unfortunately I have also upgraded to 4.3 so I don’t know if the problem maybe comes from the new release
Here is the totally reworked widget in case you want to test it.
I see. Thanks for that. So I just need to add a button „Load data“ to overcome this bug. No problem. Would it make a difference if I loadad json data via rest API call? Not sure though if I can perform an http request within an oh-context.
That’s not quite the solution for two reasons. First there’s no way for you to capture the results of the “load” in the widget expression context, and second if that button is on the same page, that it still happening after the constant values have been set.
The workaround that I talk about in the issue is that some other page has to reference the item under normal conditions (not an oh-context constant). This causes the item to be added to the tracking list. Then if you go to your page after opening that other page everything works as intended.
Or, just be OK with opening the page, leaving it and opening it again, which also works because after the constants are evaluated the first time the the item is in the tracking list so the next time you open the page everything works as it should.
Also, the key value oh-context feedback loop that you encountered appears to be a general bug and not your code. It can be replicated with a very simple widget.
Is there a way to control, i.e. adding a prefix to the return value of an oh-input to an item?
I know there is a variable but I cannot trigger a rule or store its value in an item.
