We're not so off really, I hear what you're saying. Now we're getting a better idea of the use-case. In this case, all of the itemRenderers need to be controlled the same way; by changing their styles and/or labels. So let's go up a level. Extend the List, or whatever. Both the dataProvider and the collection of itemRenderers are there, so you could do it either way from the parent. For the styles, I'd still try the StyleDeclaration routes. For the labels, you have to ask, are the labels data related, like from a table somewhere?. Are they related to the parent object of the data in the dataProvider? Or, are they constants or persisted values? Each case could have a different solution. One way, is to create a public var in the itemRenderers, or a getter/setter, if you want to do something when the value changes. So, the itemRenderer's label.text is bound to the public var. In the extended list you create a method to update all of the public vars in the itemRenderers. It's a loop, but not so bad. Make your extended List's method public. Or, you can also use getter/setter vars, if you wanted to bind out further. When set, they could trigger the method that updates the itemRenderers.
Or, you can always use "owner as List," in the itemRenderer to check the value of a public var in the parent List during updateDisplayList(), and set your label's text value there. Like I said, it's usually all about the use-case. In general, I don't see a lot of itemRenderers that all display the same thing; unless the data happens to be identical. Common labels are often pulled up to the parent component. And the manipulation of an itemRenderer, for me, is usually based on data properties; that make sense to be included in every item. Interesting discussion. -TH --- In flexcoders@yahoogroups.com, Aaron Hardy <aaronius...@...> wrote: > > I think there might be a misunderstanding. If it's a transient property on > the data objects that come through the data provider, I would have to change > the property for all the objects in the data provider to be the same value > since I want all the renderers to change in the same way. For example, > let's say all my renderers say "Woot: " and then the data's text value. > Then at runtime, the user, in a different part of the app, enters "Niner" > into a text input and therefore I want all my renderers to now say "Niner: " > and then the data's text value. In my case, the word "Niner" really has > nothing to do with the data, it's almost more about the "style" of the > renderers--or what the renderers look like around the actual data. If I > were to use the transient property of the data provider objects, I'd have to > loop through all of them and set the property's value to "Niner". I'm not > sure if that's what you were suggesting, but that seems dirtier to me than > referencing a separate model from the renderers. > > I'm interested in understanding your analysis of this though even if we may > disagree in the end. > > Aaron > > On Thu, Jan 7, 2010 at 5:13 PM, turbo_vb <timh...@...> wrote: > > > > > > > Sure, but you don't necessarily need a model to use a VO; it can just be > > the strongly typed object that the dataProvider uses for its items. If you > > then change the transient properties of that VO, the set data method of the > > itemRenderer will work out of the box; and you can then adjust the renderer. > > You're right in feeling dirty having an itemRenderer reference a model. But > > reacting to changes in the data is fine. IMHO. > > > > > > -TH > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, Aaron > > Hardy <aaronius9er@> wrote: > > > > > > Yes, I suppose the line of what is or is not a style can be blurry at > > > times. In any case, using transient properties inside a VO is what I was > > > eluding in the first item of "things I've thought of", the downside being > > > that a model/VO of some type is needed in order to keep the renderer > > > notified of updates to the property. In other words, I don't see a viable > > > way of creating a "foobar" property inside the renderer and keeping it > > > updated from an external source. Instead, the renderer would need access > > to > > > a model that was set at instantiation through the renderer class factory. > > > The renderer would then watch the model for changes to its "foobar" > > > property. > > > > > > Aaron > > > > > > On Thu, Jan 7, 2010 at 2:58 PM, turbo_vb <TimHoff@> wrote: > > > > > > > > > > > > > > > If it's a pure style, then yes that is a viable approach. However, if > > it's > > > > something like changing text (characters, not styles), then you might > > want > > > > to use [Transient] properties in a VO and/or use states in the > > itemRenderer. > > > > > > > > > > > > -TH > > > > > > > > --- In flexcoders@yahoogroups.com > > > > <flexcoders%40yahoogroups.com><flexcoders% > > 40yahoogroups.com>, Aaron > > > > Hardy <aaronius9er@> wrote: > > > > > > > > > > Good point. So maybe I have to categorize everything as being data > > (in > > > > > which case it hangs out with the data object) or style (in which case > > it > > > > > would be applied to all the renderers and can be ran through the > > various > > > > > style mechanisms). To be clear, the changes (that aren't > > data-dependent) > > > > > being made to the renderers in my case can even be text and other > > such > > > > > things which may not normally be thought of as "styles" but in > > reality it > > > > > seems they actually are styles and could be treated as such. > > > > > > > > > > Thanks. > > > > > > > > > > Aaron > > > > > > > > > > On Thu, Jan 7, 2010 at 1:23 PM, turbo_vb <TimHoff@> wrote: > > > > > > > > > > > > > > > > > > > > > > > One thought, since you're taking about a style, is to assign a > > > > styleName to > > > > > > the itemRenderer and update the backgroundColor style of the > > > > > > StyleDeclaration when the user changes the color. You may need to > > > > override > > > > > > the styleChanged() method the itemRenderer, to handle the update. > > > > > > > > > > > > -TH > > > > > > > > > > > > > > > > > > --- In flexcoders@yahoogroups.com > > > > > > <flexcoders%40yahoogroups.com><flexcoders% > > 40yahoogroups.com><flexcoders% > > > > > > 40yahoogroups.com>, Aaron > > > > > > > > > > Hardy <aaronius9er@> wrote: > > > > > > > > > > > > > > Hey folks. I have a renderer that needs information that is not > > based > > > > on > > > > > > > the "data" object it's associated with. Essentially what I have > > is in > > > > > > View > > > > > > > A of the app is a color selector. In View B, I have a tilelist > > with a > > > > > > > custom renderer. All the renderers in the tile list display their > > > > data > > > > > > > using the color that was selected in Part A. The way I see it, > > the > > > > color > > > > > > > selected in Part A should be kept separate from the "data" object > > > > that > > > > > > gets > > > > > > > injected into the item renderers. The color is just to make the > > data > > > > > > pretty > > > > > > > in some way, it's not really "data" itself nor is it specific to > > an > > > > > > > individual data object--it applies to all renderers in the list. > > This > > > > > > leads > > > > > > > me to somehow keep the renderers updated with a separate "color" > > > > > > property. > > > > > > > What's your preferred way of handling this scenario? > > > > > > > > > > > > > > Things I've thought of so far: > > > > > > > > > > > > > > (1) If I have an application-wide model (like in Cairngorm) I can > > set > > > > a > > > > > > > color property there and either access it using the singleton > > accesor > > > > > > from > > > > > > > within the renderer (cringe) or pass the model into the renderer > > > > using a > > > > > > > class factory. Since the model instance shouldn't really ever > > change, > > > > I > > > > > > can > > > > > > > then watch the model for changes to the color property. > > > > > > > > > > > > > > (2) Whenever the color changes, I can grab all the renderers for > > the > > > > > > given > > > > > > > list and set their color property (cringe). > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > Aaron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
