> 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: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Ely Greenfield > Sent: Wednesday, August 30, 2006 12:38 PM > To: [email protected] > 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="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: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of j_sevlie > Sent: Tuesday, August 29, 2006 11:51 AM > To: [email protected] > Subject: [flexcoders] Re: Specifying LineSeries itemRenderer > with Actionscript > > > > Thank you very much! That worked as I had hoped. How are > people like us supposed to ever figure that out on our own? I > would have never thought to create a new ClassFactory... > > --- In [email protected] > <mailto:flexcoders%40yahoogroups.com> , "Ely Greenfield" > <[EMAIL PROTECTED]> wrote: > > > > > > > > on charts, itemRenderers are styles, of type IFactory. so > you want to > > do this: > > > > import mx.charts.renderers.DiamondItemRenderer; > > > > ... > > columnSeries.setStyle("itemRenderer",new > ClassFactory(DiamondItemRenderer)); > > > > Ely. > > > > > > ________________________________ > > > > From: [email protected] > <mailto:flexcoders%40yahoogroups.com> > > [mailto:[email protected] > > <mailto:flexcoders%40yahoogroups.com> ] On Behalf Of j_sevlie > > Sent: Friday, August 25, 2006 1:00 PM > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] Specifying LineSeries itemRenderer with > > Actionscript > > > > > > > > I have some LineSeries charts that are generated all through > > ActionScript (because the number of lines I need is not know until > > run-time). > > > > --- CODE START --- > > var seriesArray:Array = new Array(); > > var i:int; > > var marketShareData:ArrayCollection = new ArrayCollection; > > > > marketShareData = wsData.getMarketShare.lastResult; > > > > for(i=0; i<marketShareData.length; i++) { // Line for > brand-specific > > data var columnSeries:ColumnSeries = new ColumnSeries(); > > columnSeries.xField = "fiscalyear"; columnSeries.yField = > > "sharepercentage"; columnSeries.dataProvider = > > marketShareData.getItemAt(i); columnSeries.displayName = > > marketShareData.getItemAt(i).getItemAt(0).series; > > seriesArray.push(columnSeries); > > } > > columnchartMarketShare.dataProvider = marketShareData; > > columnchartMarketShare.series = seriesArray; > > --- CODE END --- > > > > My question is: How in the world do I specify a custom itemRenderer > > through Actionscript? With MXML you can do it like this: > > > > <LineSeries yField="costs" > > itemRenderer="mx.charts.renderers.DiamondItemRenderer"/> > > > > But I'm not defining my LineSeries that way. I saw the demo of the > > charting stuff over at QuietlyScheming.com > > (http://demo.quietlyscheming.com/ChartSampler/app.html > > <http://demo.quietlyscheming.com/ChartSampler/app.html> > > <http://demo.quietlyscheming.com/ChartSampler/app.html > > <http://demo.quietlyscheming.com/ChartSampler/app.html> > ) > but he's also defining the series at design-time. > > > > Any thoughts? > > > > Thanks in advance for any help that somebody can provide. > > > > Cheers, > > Jacob > > > > > > > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
