Based on discussions I have seen folks were also thinking about CSS-like styling. This uses JSON as the backing store for styling content. Currently, pivot supports styling form json files using a special @ notation, directly specified in strings through JSON, and now as proposed using inherited styling with style sheets as well as combining styles in a string-based DSL with classpath resources and URL implied notation.
I think simple was left behind awhile ago. There are two issues around styling discussed below: specifying styling and getting the right styling information to the right component at the right time. I am separating these two issues to understand how you are addressing each separately and together. Pluggable *could* mean changing the style property to a StyleProvider interface and making StyleProvider have one method that says Map<String, ?> getStyles(). The default implementation would accept a string that does everything you describe below so it would like transparent to clients. The audience for this would be developers not pure library clients. It would help you migrate styling in the future as your mechanism evolves. -----Original Message----- From: Noel Grandin [mailto:noelgran...@gmail.com] Sent: Wednesday, June 30, 2010 11:57 AM To: dev@pivot.apache.org Cc: aappddeevv Subject: Re: Named styles What use-case are you targeting here? I don't see a a clear need for having multiple styling mechanisms, and supporting such a mechanism would add unnecessary complexity. -- Noel Grandin aappddeevv wrote: > I think any step you take in this direction is good! > > However, what you propose can be accomplished in external code with a few > static methods. It would be good to understand what pivot's intentions are > around the evolution of the themeing/skin API and how styling features fit > into that in a seamless way. > > Also, the use of the approach embeds another DSL (for combining styles) into > an attribute's string values (which is not pluggable in the current pivot > code base) and I would think very carefully about doing that. If you are > going to make any changes, I would encourage making styling more pluggable > and make the approach you outline one instantiation of that pluggable > approach. > > > > > -----Original Message----- > From: Greg Brown [mailto:gkbr...@mac.com] > Sent: Wednesday, June 30, 2010 9:01 AM > To: dev@pivot.apache.org > Subject: Named styles > > Hi all, > > I have recently been giving some thought to how we might support a form of > style propagation. This has come up a few times and is clearly a feature > that developers would like the platform to provide. > > By design, Pivot does not currently support style inheritance. We decided up > front that there is not enough commonality between component and container > styles for such an inheritance mechanism to make sense. What does make > sense, however, is the concept of "named styles". These are similar in > concept to CSS classes - they would allow a caller to specify a set of > styles by name that should be applied to a component. For example, all > Labels associated with the "boldLabel" named style would be bold. > > Pivot currently supports a rudimentary form of named styles via the > URL-based styles setter: > > <Label styles="@my_label_styles.json"/> > > There are a couple of downsides to this approach, though: > > - It requires designers to split their style definitions into many small > files. > > - It only allows the designer to apply a single set of styles; style sets > cannot be combined (e.g. "apply both my_styles1.json and my_styles2.json"), > nor can they be overridden on a per-component basis by applying local styles > (e.g. "apply my_styles.json and {foo:'bar'}"). > > I have a proposed solution and I would like to hear your feedback on it. I > suggest that we add a "namedStyles" property at the Container level. This > property would be a read-only dictionary mapping style group names to maps > of style properties: > > Container { > NamedStyleDictionary : Dictionary<String, Map<String, ?>> > } > > These styles could be referred to by child components of the container. For > example, the following would create a "boldLabel" style at the Window level > and apply it to the window's content: > > <Window namedStyles="{boldLabel:{font:{bold:true}}}"> > <Label styles="boldLabel"/> > </Window> > > Named styles could be combined as well as augmented on a per-component basis > by local styles: > > <Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/> > > Additionally, nested container could override styles defined by an ancestor: > > <Window namedStyles="{myLabel:{color:'#ff0000'}}"> > <BoxPane namedStyles="{myLabel:{color:'#0000ff'}}"> > <!-- Label text will be blue --> > <Label styles="myLabel"/> > </BoxPane> > </Window> > > Finally, named styles could be stored externally and loaded via URL or > resource path: > > <Window namedStyles="@my_styles.json"> > ... > </Window> > > <Window namedStyles="com/foo/my_styles.json"> > ... > </Window> > > Overall, I think the approach works well. It addresses the major issues that > have been raised and does so in a manner that is consistent with other > aspects of BXML and WTK. There is only one aspect of the design that I am > not 100% happy with - supporting a simple "namedStyles" attribute would only > allow the developer to include a single named styles definition per > container. In practice, this is probably sufficient, but it would be nice to > support multiple style sheets if possible. My proposed solution to this is > as follows: > > <Window> > <namedStyles buttons="@button_styles.json" > labels="{color:'#ff0000'}"/> > ... > </Window> > > This would be the equivalent of the following style sheet applied via the > "namedStyles" attribute: > > { buttons: { > // content of button_styles.json > }, > > labels: { > color: "#ff0000" > } > } > > This syntax could be supported in addition to, or instead of, the attribute > syntax. > > Please let me know what you think of this possible approach. > > Thanks, > Greg >
