|
Well, in theory, we've gone to
great lengths (and had long, heated, philisophical 'discussions' (read: knock
down drag out fights)) over what the relationship between MXML and actionscript
should be. Right now, we try as much as possible to follow a very strict
'no compiler magic' policy...specifically:
- there's are simple rules for how an
actionscript class's API dictates how it is used in MXML. a developer
should be able to look at a snippet of MXML and understand instantly how you
would achieve the same thing in Actionscript (and vice
versa).
- variable references and expressions in MXML
should be implemented using binding. That means a developer should be able to
look at the MXML and know that if there are curly braces, it's a bit of code,
and if there aren't, it's a literal value.
- Beyond three or four core language tags
(Script, Style, Repeater, Component, ??? ) the compiler should have no special
knowledge of MXML other than the simple mapping rules described above. if
it's all driven by rules and classes, then it improves the chances you the
developer will be able to learn the rules and figure out. What's more, if it's
driven by rules and classes, then you can extend the product by writing your own
classes that get access to all the same features and functionality our classes
do.
That's the theory. And the debate continues to this
day. As we add more functionality and features to the SDK, it gets very
tempting to try and customize the MXML Schema in ways that don't quite follow
the basic AS<-->MXML mapping rules. But so far we're still resisting
them.
Now one of the downsides of following these 'simple rules'
is that at times the MXML for a particular construct or feature becomes much
more verbose than we'd like it to be. In those cases, we've got three
choices:
1) change the AS API to generate a less
verbose MXML syntax. This works in some cases (i.e., the API for
constraints was changed between beta 1 and beta 2 for this reason). But
sometimes there's just a fundamental conflict between what dictates a good AS
API vs. a good MXML syntax.
2) Another option would be to just allow
custom syntax that breaks the mapping rules for that particular component.
We don't like doing that (see above).
3) A third option is to extend the rules
to allow for simplifying the syntax. If the use case your looking at it
general enough, and it can be tied to a generic set of inputs (i.e., a
particular interface, or base class, rather than a specific component), that can
be a generally useful solution. It also has a cost associated with it, and
can be abused, so we try and be judicious in how we use it. The more we
complexify (? nice word, huh ?) the mappping rules of MXML, the harder it gets
to do the translation in your head as you read some markup, and the less benefit
we get as described above.
So in this case, we decided that the situation was
generically useful enough to extend the language. For 'renderer' or
'template' use cases, where you write a component that can be passed another
component to instantiate for some sub-part of itself, we wanted to make the
markup simple.
So here the rule is that when the compiler sees a property
of type IFactory, MXML allows two ways of specifying it. The first is just by
providing a class name, like so:
<LineSeries
itemRenderer="mx.charts.renderers.DiamondItemRenderer" />
In which case the compiler automatically wraps the class in
a ClassFactory instance and assigns it.
The second is to specify an inline derived component, like
so:
<LineSeries>
<itemRenderer>
<Component>
<DiamondItemRenderer>
....
</>
</>
In which case the compiler reads the contents of the
Component tag as a separate MXML component, creates a new class for it, wraps
_it_ in a ClassFactory, and assigns that.
So...once you know that rule, it should in theory be
straightforward to recognize its use in some MXML or the API documentation and
know how you replicate it yourself in AS. In theory ;)
So to answer your original question, how are you supposed
to figure this out? Well, the answer is you're not. There should be
documentation...either showing the specific example of how to set an item
renderer on a series from AS, or, even better, describing the general MXML
rule so you can abstract the idea and apply it generally.
Having said that, I can attest to the vast amount of of
information the doc team has to communicate to the flex developer base, and the
heroic job they do and have done getting it out. It's an evolving process,
and they watch this list for feedback, so things like this that cause difficulty
should eventually make their way back into improvements to the
doc.
Ely.
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of j_sevlie Sent: Tuesday, August 29, 2006 11:51 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript Thank you very much! That worked as I had hoped. How are people like -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___ |
- RE: [flexcoders] Re: Specifying LineSeries itemRenderer wit... Ely Greenfield
