3

Do I need to create all objects which i will possible use with itemRenderer in createChildren function, even if the current item must not show some of them ?

Yordan Yanakiev
  • 2,546
  • 3
  • 39
  • 88

2 Answers2

3

createChildren() is for creating child components which lives along all host component's life-cycle. These children and their count are immutable like label of a button or border of a border container.

To create or remove dynamic children it is better to use commitProperies() or updateDisplayList(). The latter is more preferable because of you can create/remove dynamic children and perform their positioning in a single piece of code.

Constantiner
  • 14,231
  • 4
  • 27
  • 34
  • Thank you :) - I never tought that i should/could create the childs there. But which is the best practice overall ? – Yordan Yanakiev Jun 01 '11 at 16:21
  • 1
    I described the best practice above. `createChidren()` is for "constant" children like labels, borders, buttons etc. and `updateDisplayList()` is for dynamic children (a set of buttons from data provider etc). – Constantiner Jun 01 '11 at 16:26
  • -1 For recommending updateDisplayList() and commitProperties() as best practice. Using addChild in updateDisplayList is actually considered bad practice, mainly because addChild causes a call to invalidateDisplayList. It also causes a call to invalidateProperties, so using it in commitProperties is also discouraged. – bug-a-lot Jun 02 '11 at 08:09
  • @bug-a-lot: Hey man, did you red answer and comments carefully? Where did you red something about `addChild` somewhere in this discussion? And what is the best place to add/remove dynamic children (I mean some children which depends on data and we can't predict their quantity and life-cycle)? – Constantiner Jun 02 '11 at 08:15
  • @Constantiner When you say "create dynamic children", the assumption will be that after you instantiate a child, you'll also add it to your component, otherwise what would be the point? As for the best place to add/remove dynamic children, that's very situational, and not really what the OP is asking. I only know that updateDisplayList is not the best place by far, even though it's a very convenient one for the programmer. The same as it would be convenient to instantiate all the children, from the start, and just add them when we need them. But convenience is not what drives best practices. – bug-a-lot Jun 02 '11 at 09:14
  • @bug-a-lot: Did you read the code of Flex framework? For example `mx.controls.MenuBar` where children are added in `commitProperties()` or `mx.controls.DataGrid` where adding/removing children performed both in `updateDisplayList()` and `commitProperties()`. The point is that you should perform these operations smart way. If you're adding children in `updateDisplayList()` you should perform it only on data change (using some checks or flag) — this way `addChild()` won't cause recalculating and performing adding/removing children next frame. The best practice shouldn't except common sense. – Constantiner Jun 02 '11 at 09:38
  • @Constantiner Please don't get me started on the Flex framework. There's a lot of code there of questionable quality. And why would you compare a mammoth of a component like the DataGrid, which you'd have at most three at a time on the screen in a normal application, with an item renderer of which you can end up having thousands in an application? I understand your point with the checks, and in most cases the extra updateDisplayList and commitProperties calls are not important. But from there to being a best practice it's a long way. – bug-a-lot Jun 02 '11 at 14:26
  • @bug-a-lot: I really can't understand your point. As I noticed in my answer, the most common and best practice to use `createChildren()` for creating children. Agreed? But in case you need some advanced tasks such as creating children of variable count and type which can change across component life cycle there are only two options for that: `commitProperties()` and `updateDisplayList()`. Instead of abstract criticism can you suggest some other the best place for that? – Constantiner Jun 02 '11 at 14:34
  • @Constantiner As long as the component is initialized, the better option would be to add/remove children as soon as possible. That would mean even in your data change handler, or whatever other event your component is reacting to. – bug-a-lot Jun 02 '11 at 15:22
  • @bug-a-lot: Your answer has two problems: 1) You didn't give an answer where to perform it and answered something like "somewhere". 2) If you're talking about performing adding/removing children right in the place where you're noticed about changes your answer is a worst practice. Imagine you have collection change handler and iterate over children there and perform add/remove operation. The problem is client can perform update and add and remove collection elements in the same frame. And your handler will be called 3 times in the same frame. The invalidation in Flex was created to avoid that. – Constantiner Jun 02 '11 at 15:28
  • I mean you should call `invalidateProperties()` from your collection change handler and apply all the changes in the next frame in `commitProperties()`. And this is the best practice. – Constantiner Jun 02 '11 at 15:30
  • As I already said, it's very situational. That's the reason why I don't have a clear answer. One thing is for sure - updateDisplayList is not the best place. If you want to insist that it's best practice to add/remove children in updateDisplayList, that's you're own problem. – bug-a-lot Jun 03 '11 at 07:06
  • @bug-a-lot: The problem is your answer isn't answer at all. You have no recommendations and no arguments. You only have obstinacy in your opinion. – Constantiner Jun 03 '11 at 11:03
2

Short answer: no. You can create child objects whenever you'd like
Long answer: It is always best to work within the framework you're currently using. Flex has a method invalidateChildren (or something like that). You should consider calling that before you need to display your new objects and then build the new objects in the next call to createChildren.

Of course, sometimes situations call for deviation, but I have no way of knowing if this is one of those times.

cwallenpoole
  • 79,954
  • 26
  • 128
  • 166
  • thank you for the answer, can you please link me to some example to see how to use this methood ? – Yordan Yanakiev Jun 01 '11 at 16:12
  • @Yordan I suppose @cwallenpoole missed something because this method is absent both in `UIComponent` and `Container`. – Constantiner Jun 01 '11 at 16:19
  • 1
    Also, createChildren() is called only once in the component lifecycle. There will never be a "next call" (unless you do it yourself in your subclass, but I certainly wouldn't recommend that). Why this answer diserves 3 upvotes is beyond me. – RIAstar Jun 01 '11 at 22:29
  • It doesn't deserve 3 upvotes, although the short answer is to the point. Too bad the long answer craps all over it. And as a side note, just because you can create child objects whenever you like, doesn't mean you should. – bug-a-lot Jun 02 '11 at 08:13