[
https://issues.apache.org/jira/browse/PIVOT-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308171#comment-17308171
]
Roger Lee Whitcomb commented on PIVOT-1056:
-------------------------------------------
Do the conversion in TerraPromptSkin:
Sending
wtk-terra/src/org/apache/pivot/wtk/skin/terra/TerraPromptSkin.java
Transmitting file data .done
Committing transaction...
Committed revision 1888039.
Optimizations (I hope) in MacroReader that potentially could be used in reading
the default styles:
Sending core/src/org/apache/pivot/serialization/MacroReader.java
Transmitting file data .done
Committing transaction...
Committed revision 1888040.
> 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)
