> > 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?
