Uploaded image for project: 'Pivot'
  1. Pivot
  2. PIVOT-1056

Reduce number of skin set style methods



    • Improvement
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • None
    • 2.1.0
    • wtk-terra
    • None


      Especially for colors, but also for fonts, and other objects like Insets and CornerRadii, there are several (sometimes many) methods in the Terra skin classes used for setting these styles based on various kinds of objects (int, String, Dictionary). These leads to a proliferation of "setter" methods any time a new type of object is allowed (such as occurred for the introduction of CSSColor for setting colors). It also can lead to copy/paste errors that are hard to detect, and for missing conversions (such as when Dimensions were added as a source for Insets – most skins didn't have any such method). And since styles are set (mainly) through reflection using the "getStyles().put(....)" and now "putStyle(...)" methods, it is not necessary to have separate methods for each source type.

      So, I propose making a series of "fromObject" methods that take Object as source and do all the supported conversions in one place, so that if a new source type is introduced, it will be instantly available everywhere. Also, the error checking is consistent, potential for copy/paste errors is reduced, etc.

      Conveniently, if an object is used (such as Insets, or CornerRadii), the "fromObject" method can be placed in that object, so that all the conversion logic for that object is in one place. But, ComponentSkin can also be used for things like Color and Font, that are native Java objects and now our own.

      One thing I worry about is the performance impact, particularly since now we will be using JSON (and more reflection there) (see PIVOT-1014) to set the default styles, and not direct methods in the skin. It would probably be worthwhile to do some microbenchmarks of this, but I would be a bit surprised if the slowdown (if any) was noticeable unless a screen has 100s of widgets on it. Optimization in either JSONSerializer or BeanAdapter would probably be the best solution if there is a significant slowdown found, however.


        Issue Links



              rwhitcomb Roger Lee Whitcomb
              rwhitcomb Roger Lee Whitcomb
              0 Vote for this issue
              1 Start watching this issue