OTOH, the beauty of the styling approach I'm currently proposing is that it would allow you (or anyone else) to author a CSS serializer that could be used instead of the JSON style descriptors that are currently supported. You'd just do this:
<bxml:include bxml:id="styles" src="styles.css"/> instead of: <bxml:include bxml:id="styles" src="styles.json"/> On Jul 3, 2010, at 7:43 PM, Greg Brown wrote: > I'm not sure that the license for that software is compatible with the ASL > (though it may be). In either case, my feeling is that CSS works quite well > for HTML and XML, but JSON works better here. JSON is also a powerful, > well-established language, and it maps directly to our use cases, whereas CSS > doesn't. > > > On Jul 3, 2010, at 6:23 PM, Michael Allman wrote: > >> Greg, >> >> There is already a standard programmatic API for parsing CSS stylesheets >> with several Java implementations. See >> >> http://www.w3.org/Style/CSS/SAC/ >> >> These parsers provide events like element selectors (which can map to >> component types), class condition selectors (like .example, which can map to >> the contents of "class" attributes) and ID condition selectors (like >> #exampleId, which can map to values of "id" or "wtkx:id" attributes). >> >> Is this hard to implement? The plus side is you get a very powerful, well >> established styling language with room to grow as needed. It simplifies the >> debate on implementation and requirements because we just pick which parts >> of CSS we want to do. Pivot does not need to claim full CSS support. We >> just need to document which parts it does. Adopting CSS also makes learning >> Pivot styling easier for web devs and designers. >> >> Cheers, >> >> Michael >> >> On Sat, 3 Jul 2010, Greg Brown wrote: >> >>> True, but it is also more complex than JSON, which so far has worked well >>> for us. JSON property names and value types map nicely to the Java bean >>> property names and values used by the skin classes. Also, we already have a >>> JSONSerializer - we'd have to write additional support for CSS, and I'm not >>> sure that is justified. >>> >>> On Jul 2, 2010, at 9:51 PM, Michael Allman wrote: >>> >>>> 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 >>>>>>>> >>>>>>> >>>>> >>> >
