[
https://issues.apache.org/jira/browse/PIVOT-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305208#comment-17305208
]
Roger Lee Whitcomb commented on PIVOT-1056:
-------------------------------------------
Looking through BeanAdapter, in particular: "getSetterMethod()" and "coerce" it
would appear that having a value of "Integer" (for instance), looking for a
compatible setting method, it will be faster, in that there will be fewer
checks, to find a method taking "Object" than to do the additional checks to
find the "int" method. At the expense of our generic method taking Object do
(essentially) those same checks to find the Integer method itself. So, I would
expect there to be negligible (if any) slowdown due to this change -- the same
amount of work will be done as before, just in a slightly different place.
> 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
> Priority: Minor
> 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)
