RE: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript
For documentation on renderers, there are a few places you can go. To get you started, there is a general discussion of item renderers and editors, including using the Component tag, here: http://livedocs.macromedia.com/flex/2/docs/0820.html There is a description in that chapter of setting an item renderer or item editor in ActionScript here: http://livedocs.macromedia.com/flex/2/docs/0832.html These chapters are on general usage of renderers and editors,not specifically to charts. There is a section on creating charts in AS here: http://livedocs.macromedia.com/flex/2/docs/1217.html But it does not get into the details of renderers. That is something we can add in an upcoming release. Stephen Flex Doc Team From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ely GreenfieldSent: Wednesday, August 30, 2006 12:38 PMTo: flexcoders@yahoogroups.comSubject: RE: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript 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 kn
RE: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript
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_sevlieSent: Tuesday, August 29, 2006 11:51 AMTo: flexcoders@yahoogroups.comSubject: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript
RE: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript
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. LOL. Homer's doc was heroic. We're lucky if our stuff gets read. When deciding new doc topics to add, we get ideas from reading this list, the forums, blogs, LiveDocs comments, talking to support, mktg, prod mgmt, eng, qa, and little bit of intuition. You can bet that problems that come up time and again in these places will make their way into the docs. One of the big things that we look at, though, is how much of an edge case each issue might be. If one in a thousand users will encounter a problem with something, then we'll likely write about the issue that 1 in 10 users will encounter first. Doesn't mean we won't get to it, but it might be covered by a Tech Note or some other method before it gets put in the main product documentation. Now, if the doc were a wiki, this topic would already be documented. :) matt horn flex docs -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ely Greenfield Sent: Wednesday, August 30, 2006 12:38 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Specifying LineSeries itemRenderer with Actionscript 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
