-
Notifications
You must be signed in to change notification settings - Fork 781
introduced "Default" widget type for sitemaps that is dynamically resolved #1535
Conversation
I am not familiar with that code, but why to the default widget be resolved all the time if the instance is already a default one? |
return result; | ||
} | ||
|
||
private Widget resolveDefault(Widget widget) { |
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.
Wouldn't the code be simpler (less if
s above) if we
return widget;
if it is not an instance of Default- change the method so you can give the fallback:
private Widget resolveDefault(Widget widget, Widget fallback)
andreturn fallback;
at the end (so you can use resolveDefault(widget, null) or resolveDefault(widget, widget)
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.
updated the code according to your suggestions. It looks only slightly better, though ;-)
The feature allows the SitemapProvider to simply say "use default widget type of this item" and the framework (uiregistry) then resolves the widget type dynamically (the uis then expect a concrete type). |
} catch (NumberFormatException e) { | ||
// no valid number, so the requested page id does not exist | ||
} | ||
} | ||
if (w instanceof Default) { |
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.
Can be removed now
…olved Signed-off-by: Kai Kreuzer <[email protected]>
Ok, new try - does this look better to you? |
👍 😉 |
Uff, thanks ;-) |
This partially addresses #635 as it is now possible to simply use a "Default" widget with a Player item, so that the switch buttons are rendered.
Signed-off-by: Kai Kreuzer [email protected]