RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed

[Alessandro Parisi]

>
> OK, I think you've answered my first and third questions. The broader
> question then is whether this fills a general need, and if so, is
> allowing for a dynamic user agent style on a Control the best way to
> provide this feature? I'd like to hear from some of the other developers
> on this list.
>
> As for the second question, I don't think the API you propose for
> dynamic user agent style-sheets is feasible in a way that maintains
> compatibility. The current API model is that the control itself provides
> its userAgentStylesheet by overriding the get method, returning a String
> specific to that control (or possibly a specific instance of that
> control, if the designer of that control wants to add such logic for
> some reason). You can't compatibly turn this API into a standard
> property. Our properties have final set/get/property methods for a
> reason. Namely, to satisfy the invariant that calling the set or get
> method is identical to calling the property method (this is key to
> allowing bindings and listeners to work in a consistent and predictable
> manner). Also, since existing controls that override the getter, they
> will know nothing about the setter. Applications may wonder why
> setUserAgentStylesheet(sheet) does not imply
> sheet.equals(getUserAgentStyleSheet()).
>
> Off the top of my head I can think of three ways to resolve this
> depending on what app developers and custom controls developers would
> prefer to see:
>
> A. Provide a property with some other name (i.e., not
> userAgentStylesheet). If the value of this new property is non-null it
> takes precedence over the userAgentStylesheet. When it changes, it
> causes the necessary reevaluation to happen. This is the closest to what
> you propose, but preserves backward compatibility. This add some
> additional complexity, which may or may not be justified.
>
> B. Provide an "updateUserAgentStylesheet(String)" method that acts
> "like" a setter, but a control would be free to ignore (and a control
> that overrides the "getter" today would certainly ignore). This seems
> messy and has its own consistency issues. And it still doesn't solve the
> question of how the control indicates that it has change its user agent
> stylesheet.
>
> C. Leave it up to the control to decide when and how to change the value
> of its userAgentStylesheet. Provide a boolean
> "dynamicUserAgentStylesheet" property indicating whether the
> userAgentStylesheet is dynamic (most likely likely the control would set
> it for itself). There might also need to be a way for a control to
> indicate that its value has changed. Given your use cases, this seems
> like a good fit.
>
> There may be more options - e.g., a hybrid of B and C if setting this
> under app control is a thing many apps want to do (although in that
> case, why not just go with option A)? Maybe there something else I'm not
> thinking of right now that would work.
>
> A follow-up question is whether and how this would interact with the
> proposed theming API that is also under discussion (maybe that
> discussion could be revived)?
>
> Before we spend too much more time on the API discussion, I want to hear
> from other developers on the list as to the value proposition of doing
> this and how they would like to see it done.
>
> -- Kevin
>
>
I would exclude A and C solutions as they would add some
unnecessary complexity in my opinion. I kinda like solution B, I like the
idea of an update method, but I don't see how a control would be able to
ignore it. Also, let's say a control overrides the getter, why a call to
the "update" method should be ignored, it's up to the user to decide if the
userAgent should be changed right?

To be honest, these solutions, and particularly the B one, seem to be good
solution if you want to keep backwards compatibility but let's suppose
solution B is implemented, we end up having to methods for the userAgent a
"getter" and an "updater". At this point, without taking into account
backwards compatibility, I'd rather delete the "getter" and keep only the
"updater", apps/libraries that override the getter would just need to
remove the override and instead make a call to the "updater" in the
constructor or in an "initializer" method of some sort

As for the theming API there's one thing that I don't understand. If we
introduce a theming API then what's the point of the userAgentStylesheet
exactly?