well big mouth has to say one more thing, Imagine commitProperties() committing property states :) , all of your properties have been committed. Children can be created at any time AFTER super().
What you fail to see is commitProperties() is a glorified createChildren(). This only thing "cool" about createChildren() is Container calls createComponentDescriptors() which is a heavy method. Other than the above, commitProperties() ALWAYS runs before measure() and updateDisplayList() so there is never a problem with creating children in commitProperties(). But subclassing a UIComponent, give me a break. I was under the impression from Eric's post that his "issue" was more than just create the children in create children, why the hell would I tell him to circumvent a template method!? Sorry, your post felt a little personal. Mike On Thu, Oct 30, 2008 at 6:40 AM, Michael Schmalle <[EMAIL PROTECTED]>wrote: > 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 > >> >> >> --- 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'. > -- 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'.
