Amy, > These functions are in place for very good reasons, and if you try to circumvent them you have a really good chance of running into problems. I will happily disagree with you on this and not say much else. I don't feel like getting into a pissing match with documentation, as I am sure this is what you are quoting. My information comes from 3 years of low level component development experience.
> circumvent Who ever said this? I don't think you quite understand what I am talking about. > you are probably going to fail miserably unless you put that logic in > _before_ the super.commitProperties(). This is just plain wrong. I don't have time to write an essay on why you don't understand what I said. Mike On Thu, Oct 30, 2008 at 1:53 AM, Eric Cooper <[EMAIL PROTECTED]> wrote: > Thanks, Amy. > > I have decided that my own model is more convoluted than is healthy. So, I > have reworked > things on my side and stuck with createChildren(). I was tempted to try > Mike's suggestion > - and, had I felt really good about my implementation, I might have. > > At this point, with more checks for null values than ideally there should > be, things are > working in various scenarios. > > Thanks again, > -Eric > > > --- In [email protected] <flexcoders%40yahoogroups.com>, "Amy" > <[EMAIL PROTECTED]> wrote: > > > > --- In [email protected] <flexcoders%40yahoogroups.com>, > "Michael Schmalle" > > <teoti.graphix@> wrote: > > > > > > Hi Eric, > > > > So, my question is does your approach address this by creating > > children > > > in > > > commitProperties() > > > Yes, > > > > > > This is basically what I do with all renderers in my commercial > > components. > > > I rarely use createChildren(). The only time I use createChilren() > > is when > > > the composite is 100% owned by it's parent containing the creation > > code. > > > > > > commitProperties() will solve all timing issues if implemented > > correctly. > > > > > > I'm not quite sure I get what you are asking in the second half > > but, all > > > item renderers use this algorithm which their state is entirely > > dependent on > > > the data being pushed into the component either through data or > > public > > > accessors. > > > > > > This means that children will not be instantiated until the data is > > present > > > for their instantiation. > > > > > > If this doesn't make sense, try to clarify a bit more. > > > > It's probably better practice to create children in createChildren, > > then use commitProperties to do whatever setting of properties needs > > to be done, and then use updateDisplayList() to do any layout, and > > measure() to resolve any sizing issues. These functions are in place > > for very good reasons, and if you try to circumvent them you have a > > really good chance of running into problems. > > > > For instance, if you put child creation logic in commitProperties(), > > you are probably going to fail miserably unless you put that logic in > > _before_ the super.commitProperties(). That's because any children > > should be created prior to commitProperties. And that's the reason > > there's a commitProperties() function that's separate from > > createChildren(). Oh, and if you do anything that edits layout, > > etc., in commitProperties, you better do it _after_ the super. Guess > > why? > > > > You should try and catch her state changes and defer them until the > > appropriate moment in the invalidation process. > > > > If what's going on is that her logic is affecting public properties > > or styles that you've exposed on your class, then you just need to > > make sure that they set a flag and call the right invalidation method > > so that you can execute at the correct place in the invalidation > > process. > > > > HTH; > > > > Amy > > > > > -- Teoti Graphix, LLC http://www.teotigraphix.com Teoti Graphix Blog http://www.blog.teotigraphix.com You can find more by solving the problem then by 'asking the question'.
