Greg,
The thing I don't like about
<PushButton>
<styles>
<bxml:value id="styles.red"/>
<bxml:value id="styles.bigFont"/>
</styles>
</PushButton>
is that it's about a bazillion more characters to type than
<PushButton class="red bigFont"/>
See what I mean?
Michael
On Sat, 3 Jul 2010, Greg Brown wrote:
Re: supporting multiple style classes, here is what I am thinking. I had suggested the
following in my earlier email - it would apply the styles by dereferencing the
page-scoped variable "styles.redButton", which contains a map of styles:
<PushButton styles="$styles.redButton"/>
Conceptually, this is no different than the way styles are currently applied -
it just gets the style data from a different source:
<PushButton styles="{backgroundColor:'#aa0000', color:'#ffffff'}"/>
<PushButton styles="@red_button.json"/>
In fact, this is already supported - if you have a page variable named "styles" that
contains a map named "redButton", it will work. The solution I am proposing will simply
make it easier to define such structures within the page (currently, you'd need to do it in code):
<bxml:include bxml:id="styles" src="styles.json"/>
To apply multiple style sets, we could support this:
<PushButton>
<styles>
<bxml:value id="styles.redButton"/>
<bxml:value id="styles.bigFont"/>
</styles>
</PushButton>
The <bxml:value> tags would behave the same as the "$" dereference operator.
They would resolve to the value of the page variable with the given ID. This is currently being
tracked in PIVOT-556.
However, you would also be able to do this:
<PushButton>
<styles>
<bxml:include src="red_button.json"/>
<bxml:include src="big_font.json"/>
</styles>
</PushButton>
which may also be convenient.
Not sure how useful it is, but you could even do this:
<PushButton>
<styles backgroundColor="$styles.redButton.backgroundColor"/>
</PushButton>
The beauty of this approach is that it addresses the primary use cases, is
extremely flexible, and relies entirely on existing functionality - we don't
need to create any new classes or concepts to support named styles,
inheritance, etc.
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
