-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow ProfileTypeBuilder to pass its three filters list to both implementations of ProfileType #4325
base: main
Are you sure you want to change the base?
Allow ProfileTypeBuilder to pass its three filters list to both implementations of ProfileType #4325
Conversation
…o the ProfileType interface so that StateProfileType and TriggerProfileType can both take the three filter lists given by ProfileTypeBuilder Fixes openhab#4293 Signed-off-by: Olivier Sannier <[email protected]> (github: obones) Signed-off-by: OBones <[email protected]>
be1c40a
to
a3fea88
Compare
… all ProfileTypes Signed-off-by: OBones <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pleas also check why there are test failures in ProfileTypeResourceTest
.
...t.core/src/main/java/org/openhab/core/io/rest/core/internal/profile/ProfileTypeResource.java
Show resolved
Hide resolved
...main/java/org/openhab/core/thing/internal/link/ItemChannelLinkConfigDescriptionProvider.java
Show resolved
Hide resolved
bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/profiles/ProfileType.java
Show resolved
Hide resolved
I don't know if it's the same for everyone, but it takes a really long time to build the entire |
No need for squashing, I can do that during merge. In fact, if you squash and force-push usually the comment history is messed up, so better just push additional commits. |
…ile type can tell onto which channel kind it applies, if any Signed-off-by: OBones <[email protected]>
Signed-off-by: OBones <[email protected]>
Signed-off-by: OBones <[email protected]>
…ency Signed-off-by: OBones <[email protected]>
Signed-off-by: OBones <[email protected]>
I have just pushed some changes that I believe are addressing your fine remarks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for you work and sorry for being a PITA here.
if (!(profileType.getSupportedItemTypes().isEmpty() | ||
|| profileType.getSupportedItemTypes().contains(itemType)) | ||
|| !(((TriggerProfileType) profileType).getSupportedChannelTypeUIDs().isEmpty() | ||
|| ((TriggerProfileType) profileType).getSupportedChannelTypeUIDs() | ||
.contains(channel.getChannelTypeUID()))) { | ||
|| !(profileType.getSupportedChannelTypeUIDs().isEmpty() | ||
|| profileType.getSupportedChannelTypeUIDs().contains(channel.getChannelTypeUID())) | ||
|| !(profileType.getSupportedItemTypesOfChannel().isEmpty() | ||
|| profileType.getSupportedItemTypesOfChannel().contains(itemType))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks really horrible. It would probably be better to
Collection<String> supportedItemTypes = profileType.getSupportedItemTypes();
...
if ((!supportedItemType.isEmpty() && !supportedItemTypes.contains(itemType)) || ...) {
Why do you check profileType.getSupportedItemTypesOfChannel
? A profile can change the item-type:
- The timestamp update profile works with all channel-types (e.g. a humidity channel with supported item-type
Number:Dimensionless
) but can only be linked toDateTime
items. So a check would fail (in fact, currently the profile does not provide information about accepted channel types, so this will not cause an issue, but in principle it could). - A profile could map numeric values to strings, so the channel would support
Number
, but the profileString
. In this case you could never link them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that it looks horrible, but it was jut to "fit in" with the already existing code.
As to why I do the check, well it's because I did a global search for the interface methods and made sure both methods are called in all the places where one was called following an instanceof
call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, the style was not good before either and if you want to keep it: ok. But the getSupportedItemTypesOfChannel
is excluding valid combinations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm definitely in favor of changing the code style here, but as always when I'm submitting a pull request, I try to limit my changes to the code logic, adapting to the local style I encounter.
I'll try to come up with a more sensible way of writing this up.
return true; | ||
} | ||
private boolean profileTypeMatchesChannelType(ProfileType profileType, ChannelType channelType) { | ||
@Nullable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need @Nullable
annotation for local variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My IDE (VSCode) disagrees and outputs a warning saying that the value cannot be null. That's what I've been doing in my plugin bundles, but I can remove it if you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO it's wrong. The default locations for @NonNullByDefault
are PARAMETER, RETURN_TYPE, FIELD, TYPE_BOUND, TYPE_ARGUMENT
, so it does not apply to local variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I have removed them
...main/java/org/openhab/core/thing/internal/link/ItemChannelLinkConfigDescriptionProvider.java
Outdated
Show resolved
Hide resolved
....core.thing/src/main/java/org/openhab/core/thing/internal/profiles/StateProfileTypeImpl.java
Show resolved
Hide resolved
...ore.thing/src/main/java/org/openhab/core/thing/internal/profiles/TriggerProfileTypeImpl.java
Show resolved
Hide resolved
bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/profiles/ProfileType.java
Show resolved
Hide resolved
Signed-off-by: OBones <[email protected]>
…the two other locations where ProfileType are tested for applicability Signed-off-by: OBones <[email protected]>
The more I look at how things are going, the more I feel it would be beneficial to have a |
@J-N-K , sorry to ping you directly, but do you have an opinion on my last suggestion? |
This pull request moves getSupportedChannelTypeUIDs and getSupportedItemTypesOfChannel to the ProfileType interface so that StateProfileType and TriggerProfileType can both take the three filter lists given by ProfileTypeBuilder
It fixes #4293 and will allow bundle writers to limit their transformation profiles to just the channels/items that are related to their profiles.