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 <[email protected]> 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 [email protected] <flexcoders%40yahoogroups.com>, Aaron > Hardy <aaronius...@...> 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 <timh...@...> 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 [email protected] > > > <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 > > > > > > > > > > > > > > > > > >
