I guess what it all boils down to for me is:
1. CSS is a standard for styling HTML, and WTKX is a ui markup like HTML.
2. CSS is well known and has been around forever.
3. CSS is powerful.
4. There are several CSS editors and parsers out there.
5. CSS+WTKX requires less typing (as in "fingers hitting the keyboard")
than the other proposals I've seen so far.
6. The behavior of CSS styles as applied to HTML is well-defined, and, if
implemented in close analogy, will work the same way as applied to WTKX.
That being said, if the Pivot styling API has hooks for plugging in other
implementations (like, say, a CSS approach), I don't see the need for one
implementation to "win" in a debate. There will be a default, but if devs
have a choice, they will choose what they want to use.
Cheers,
Michael
On Sat, 3 Jul 2010, Greg Brown wrote:
By the way, I don't mean to be needlessly dismissive about the CSS idea - I definitely see the
appeal. However, component styles are set via BeanDictionary, which maps dictionary keys (such as
"backgroundColor") to Java bean properties ("setBackGroundColor()"). JSON works
really well for this:
{ redButton: {
backgroundColor: "#ff0000"
}
)
CSS could certainly also work here:
redButton: {
background-color: #ff0000;
}
A CSSSerializer would simply need to output a Dictionary (or Map) that is equivalent to what
JSONSerializer would return. In other words, it would need to return a map of maps to the various
style definitions. It would also need to collapse "background-color" to
"backgroundColor".
One of the nice things about JSON is that the property types are embedded in the syntax.
For example, in the following JSON, "foo" refers to the number 10:
{ foo: 10 }
In CSS, "foo" would have to be treated as a string ("10"). This should be OK, because
BeanAdapter should coerce "10" to the appropriate type when invoking the setter, but it is
something to consider.
I'm not personally interested in investing time in this, because I am happy
with the JSON syntax. However, if you are willing to write (or port a
compatibly-licensed) CSS serializer, I could easily see a case for including it
in the platform. I don't know that we could support selectors based on
component type, but we could definitely support untyped selectors. Based on my
own experience writing Pivot apps, I would guess that this would be sufficient.
G
On Jul 3, 2010, at 7:46 PM, Greg Brown wrote:
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
