Roger Lee Whitcomb created PIVOT-1056:
-----------------------------------------
Summary: Reduce number of skin set style methods
Key: PIVOT-1056
URL: https://issues.apache.org/jira/browse/PIVOT-1056
Project: Pivot
Issue Type: Improvement
Components: wtk-terra
Reporter: Roger Lee Whitcomb
Assignee: Roger Lee Whitcomb
Fix For: 2.1.0
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
