Some thoughts...I suggest we write down requirements and the problem you are trying to solve and agree on those first. A simpler set of requirements proposed by GregB (named styles) could become something bigger (CSS-ish) but we should agree on it first then decide if its worth someone's time to implement:
Having said that, t turns out that you can implement all of this easily, without changes to core pivot, for all components in your application. The problem I was trying awhile ago was: OBJECTIVES/REQUIREMENTS: a) How can designers created named styles and add them to the application easily? The programmer gives them a name, the designer designs styles and places them into the toplevel of an application to pick up. I believe in the cause of trying (trying alittle at least) to separate the L&F design and component programming job as much as possible. b) How can I make styles automatically picked up if they are change? The named styles changes and the component must pick up the change instantly. Kind-of like magical theme changes. c) How can I apply styles without having the programmer do anything? Named styles need to be applied by having a programmer specify a name. A name is a key but even that is not ideal. I don't want to have to have programmers programming names at all but have them applied via "class" matching. d) How can named styles build on each other? The union of all applicable styles should be honored. If a named style exists, you must use that explicitly, but otherwise, how can we aggregate styles through the parent-child relationship? e) How can an individual component indicate they don't want automatic styling and turn everything off? f) How can I add a style "key" but not change any pivot code? g) Can I have a mechanism that I could change so that styles can be specified in another syntax besides JSON? Since JSON is easier XML, maybe I want a dynamic language data structure way of doing this. DESIGN APPROACH WITHOUT TOUCHING PIVOT CODE: a) Styles are named through a name and placed into the user data. There are no changes to properties anywhere. b) Styles are specified by name or class type (as a string name). If your component has a compatible class type, they are automatically applied. c) Named styles in user data are automatically change detected. If they change, they are reapplied before the next paint. d) The parent-child relationship is searched for styles. If styles, for example, are placed into the top level component with an include, and the include is in the user data, you have inserted "styles" into your parent-child tree. e) The user data can hold a key for the name style under the "key" of "namedStyle" or something like that. f) You can turn off automatic styling and everything else by putting a user data key called "turnItOff" and all of this styling mechanism is turned off. CONS: a) A named style does not get used in the "styles" property because that would change the JSON/DSL nature of the styles string syntax. b) It does not solve the problem of externalizing the injection of styles under different conditions. Sort-of like externalizing the styling "rules" engine, which is what CSS imposes on you (only one way I think) and WPF more flexibly enables? Can I move the multitude of small UI rules about what color is used under what component state into a vehicle that allows it to be changed so I can further change the L&F of pre-existing components...all without touching code? c) Does this produce a styles undo stack? Can a named style be removed or overridden then allow the previous style become the style again? Can I identify style properties so at least I can make a list of styles and work with them? Can I save styles as preferences more easily? d) Does this work with renderers which are not always in the parent-child tree? Does this matter? e) Named styles require specific programmer intention to use. Not so bad. But I think as a general rule we don't want programmers specifying styles explicitly but have them automatically applied. Sort of like style dependency injection...a programmer never knows its there except they do less work on styling. Regardless of my list prattlings, I have code that is *not* based on java partial classes so the requirements are met and it runs without changes to the compilation process. Recently, this went to the next level with partial classes (so I could make any change I want without touching code) to implement the fuller mechanism of triggers and actions, styles, sounds and animation--as an enhancement over WPF and CSS functionality. But I still have the earlier version. You can try the code today or tweak it with goofy changes such as using regexs to match styling names (funky) all without a change in pivot code. It turns out that a strategically valuable design of Pivot was to allow userData to exist and be listable (you can list all of the user data) and change detected. Its unlocks vast potential. Of course, you can also standardize this by building it into the pivot code base. -----Original Message----- From: Michael Allman [mailto:m...@allman.ms] Sent: Friday, July 02, 2010 9:51 PM To: dev@pivot.apache.org Subject: Re: Named styles It would be very premature for me to provide a good example. I've barely started my first Pivot app. Also, I can say that this can't be done with Flex apps either. So I never used it there. Doesn't mean it might not have come in handy once or twice... I dunno. It may be practically useless. Although I have seen it used many times in html. This comes back to my earlier post. Why not support a subset of CSS syntax itself? It's a very mature spec for styling declarative ui stuff. Cheers, Michael On Fri, 2 Jul 2010, Greg Brown wrote: > I have been thinking about that and I have some ideas. But I would like to understand how often that use case actually comes up. I know CSS supports it, but in practice (in Pivot specifically) I wonder how important it is? > > > On Jul 2, 2010, at 7:30 PM, Michael Allman wrote: > >> Hi Greg, >> >> How would one specify multiple named styles for a component element? Like >> >> <PushButton styles="redButton bigFont"/> >> >> Cheers, >> >> Michael >> >> On Fri, 2 Jul 2010, Greg Brown wrote: >> >>> Hi all, >>> >>> I have been thinking about this and I think I have a fairly elegant solution that will also significantly extend the capabilities of BXMLSerializer. I am thinking of extending the <bxml:include> tag to support loading of arbitrary content. Currently, it only supports includes of other BXML files, but there is no reason that it couldn't be modified to include other types, such as JSON, XML, or even images. All we'd have to do is determine an appropriate serializer to use for the include - this could be inferred based on file extension or could be specified explicitly via a "mimeType" attribute to the include tag. The MIME type-to-serializer mappings could be configurable such that an include could literally be used to load any type of object. >>> >>> One application of such an extension would be styling. <bxml:include> could be used to load a "stylesheet" - a JSON file containing a "map of maps". The format of this file would be identical to the format I had been considering for the "named styles" approach - each key/value pair in the file would essentially represent a "style class". For example, the following JSON file would define a "redButton" class: >>> >>> { redButton: { >>> backgroundColor: "#aa0000", >>> color: "#ffffff" >>> } >>> } >>> >>> In a BXML document, this file could be included as follows: >>> >>> <bxml:include bxml:id="styles" src="styles.json"/> >>> >>> The "redButton" style could then be applied to a button as follows: >>> >>> <PushButton styles="$styles.redButton"/> >>> >>> Unlike the previous solution I proposed, this approach would require no changes to the Component or Container classes whatsoever. With the exception of extending the <bxml:include> tag, it relies entirely on existing functionality (and existing BXML syntax, so developers will already be familiar with it). >>> >>> There are obviously other applications as well. Some simple examples: >>> >>> <TableView> >>> <tableData> >>> <bxml:include src="table_data.json"/> >>> </tableData> >>> </TableView> >>> >>> <TreeView> >>> <treeData> >>> <bxml:include src="tree_data.xml"/> >>> </treeData> >>> </TreeView> >>> >>> One challenge might be how to specify the MIME/serializer mapping for an include (we won't want BXMLSerializer to include all possible mappings by default). This could be inherited from the parent serializer, but I think that a BXML syntax for specifying it in markup is probably a good idea. >>> >>> Anyway, I think this would be an extremely flexible and useful addition to the serializer, and I think it also handles the styling case pretty well. Let me know what you think. >>> >>> G >>> >>> >>> On Jul 2, 2010, at 1:34 PM, Greg Brown wrote: >>> >>>> FYI, named styles are turning out to be a lot more challenging than I expected. The solution I proposed the other day doesn't work - elements in BXML aren't added to the parent element until the end tag is processed. So, given the following structure: >>>> >>>> <Window styleClasses="{foo:{...}}"> >>>> <BoxPane> >>>> <PushButton styleClass="foo"/> >>>> </BoxPane> >>>> </Window> >>>> >>>> when the styleClass attribute of the PushButton is processed, the BoxPane hasn't yet been added to the Window, so the "foo" style class name resolves to null. :-( >>>> >>>> I'll keep thinking about it, though. Suggestions are welcome. >>>> >>>> Thanks, >>>> G >>>> >>> >
