Updating the list of entries in a RibbonComboBoxProjection?

[MichaelWDenney]

In our application, we have configured a RibbonComboBoxContentModel to contain a list of items, added it to a RibbonComboBoxProjection, and then added the projection to a JFlowRibbonBand. During runtime, we have a need to occasionally update/change the list of items. I realize the model is intended to be immutable. Short of removing the projection from the band and replacing it with an updated projection (or maybe removing the content model from the projection and replacing it), is there an elegant means to accomplish this? Replacing the projection/model seems very likely to cause visual, focus, and state side effects.

[kirill-grouchnikov]

How does this look like with a core JComboBox? I don't mind adding a couple more wrappers in https://github.com/kirill-grouchnikov/radiance/blob/sunshine/component/src/main/java/org/pushingpixels/radiance/component/api/ribbon/synapse/JRibbonComboBox.java or the projection.

[MichaelWDenney]

Do you mean what does it look like programmatically? DefaultComboBoxModel supports:

removeAllElements()
removeElementAt(index)
addElement(element)
insertElementAt(element, index)

I could see us using the brute force approach of removeAllElements() and then adding back the entire list one at a time with addElement(...). (Alternatively a single method that would allow us to re-initialize with a new list would be great but I don't believe DefaultComboBoxModel supports anything like that.)

But, I could also see us using removeElementAt(...) / insertElementAt(...) to be more precise when possible.

[kirill-grouchnikov]

With these wrappers, I'm not looking to replace the core Swing components. So if there's nothing "nice" in the default combobox model, I won't be reinventing that wheel here in Radiance.

[MichaelWDenney]

Hi. Just wanted to make sure I understood correctly that you are intending to add the wrappers to help address this concern. Any idea when they might be available? I'm not trying to be pushy but they would help us with a quickly approaching release.

[kirill-grouchnikov]

No, there is no intention here to add more wrappers for the core Swing JComboBox in Radiance. The intended replacement for the combobox is a popup command button.

[MichaelWDenney]

Oh. Have I misunderstood when you said above that you didn't mind adding a couple more wrappers to the JRibbonComboBox or the projection?

[kirill-grouchnikov]

What I meant was that everything under org.pushingpixels.radiance.component.api.ribbon.synapse is a skeleton blueprint that shows how existing Swing components might be wrapped so that they can participate in the content / presentation / projection worldview of Radiance components.

These blueprints do not aim to wrap all existing use cases of the more complex components such as comboboxes and spinners, but are more of a starting point for app-specific exploration.

[MichaelWDenney]

I see. If we add more wrappers in our Radiance branch for this purpose, would you be open to incorporating them into the main branch?

[kirill-grouchnikov]

Depends on the complexity of it. Long time ago I had a large code contribution for editable combobox auto-completion, and it was difficult to meaningfully maintain it over the years since I never got into the deeper details of it. I ended up removing it altogether a few years ago.

[MichaelWDenney]

Fair enough. We would be looking at adding some/all of the methods I mentioned above:

removeAllElements()
removeElementAt(index)
addElement(element)
insertElementAt(element, index)

Obviously, we would want to keep the complexity as low as possible. As long as you are not completely opposed, we will move forward and see about possible incorporation later.

[MichaelWDenney]

We were able to solve our problem without modification to the Radiance library. All that was needed was to switch from using the RibbonComboBoxContentModel interface to the RibbonDefaultComboBoxContentModel class as the class makes the add/remove methods accessible. We could instead modify the RibbonComboBoxContentModel interface to include custom mutator methods, but I don't see a need to mess with the library functionality. I'm just wondering whether any negative impact of the switch to RibbonDefaultComboBoxContentModel is foreseen.

[kirill-grouchnikov]

There's nothing negative or positive about RibbonDefaultComboBoxContentModel. It is one of those skeleton blueprints that shows how a core Swing component (such as combobox) can be adapted to the Radiance content/presentation/projection view of the world. If it works for your case, that's good.