[sitemap] Extend the number of widgets supported in a frame and any sub-page

[lolodomo]

The way how the widget id (unique identifier of any sitemap widget in a sitemap) is implemented in the core framework defines a constraint on the number of widgets that can be part of a frame or in a sub-page.
This is a coding on 2 characters (for each level of depth, so the limit is 100 items (00 - 99).
I propose to change this coding from 2 to 3 characters, this will allow 1000 items (000-999).

@openhab/android-maintainers @openhab/ios-maintainers Please first confirm that there is no dependency on how is coded this widget ID in the Android and iOS apps.

@Andi-Coder for information

[maniac103]

Android app takes this as an opaque identifier and does no attempts to parse it.

But wouldn't a redefinition from decimal to hexadecimal already yield a 2.5x increase?

[lolodomo]

Android app takes this as an opaque identifier and does no attempts to parse it.

It should be the same in Basic UI but I will check in detail.

But wouldn't a redefinition from decimal to hexadecimal already yield a 2.5x increase?

Yes that is another option. Certainly a little easier to change.
But as I have to go deep in the code where this id is built and used, I can certainly make a bigger change.
Do you think 256 items is enough ?

[maniac103]

I even think 100 items is enough :-D
I don't have a strong preference either way. You'll invalidate existing IDs (say in bookmarks, or NFC stickers in case of the Android app) either way. One option to be backwards compatible would be simply extending the counting, accepting the addition of additional digits (00, 01, ... 09, 10, ..., 98, 99, 100, ...).

[lolodomo]

I even think 100 items is enough :-D

At least one user encountered this limit.

I don't have a strong preference either way. You'll invalidate existing IDs (say in bookmarks, or NFC stickers in case of the Android app) either way. One option to be backwards compatible would be simply extending the counting, accepting the addition of additional digits (00, 01, ... 09, 10, ..., 98, 99, 100, ...).

It is not possible ... or I don't understand your point.
Maybe you mean having two different coding and using the new coding on 3 characters per level only when we encounter the case with more than 100 items. It probably adds a level of complexity but could allow having something unchanged with ID for 99.99% of users ;)

[maniac103]

Maybe you mean having two different coding and using the new coding on 3 characters per level only when we encounter the case with more than 100 items.

Yes, that's what I mean: 2 digits for up to 99 (00-99), 3 digits for 100-999, 4 digits for 1000-9999 ... you get the idea 😉

It probably adds a level of complexity

Is this more than a formatted string, where one could calculate the number of digits as (untested) Math.max(2, Math.ceil(Math.log10(numericId)))?

[lolodomo]

You probably missed that this ID is not just an index in the current page but a concatenation of indexes from the main page until the current page.