In that case, I'll pipe up one more time before piping out :) Probably it was too strong to say "any application"; more correctly, "any application designed by me," due to personal preference. I think there are better ways to design components than building in a dependancy on another object's property(ies), especially if those properties of the other object are never examined for expected values.
One thing I'm still not clear on is why you say binding is not working correctly. In your sample MyFirstObject component, the image's width is bound to variable innerWidth. The innerWidth variable is not bound to anything, it is just set to an object's property in the initialization handler, which is not the same as binding. I don't see how this breaks binding, since if innerWidth is set to undefined (which is how it starts out), the image's width is undefined, but if innerWidth is set to some value, the image's width properly changes. This is exactly what I would expect to happen, and in fact does happen. Unless I'm missing something here, the problem has nothing to do with "mistakenly breaking binding," and everything to do with incorrectly assuming an object's property has been initialized when it's entirely possible that it hasn't. Another thing I'm not clear on is why you would want to rely on order of component initialization in the first place. It just seems like a bad idea to me, and I'm not aware of any documentation that says you can reliably count on the framework to enforce a particular initialization order (please point it out to me if such docuemntation exists). Sure, most of the time components are initilized in the order they are declared, but not always - case in point would be a tab navigator control with creationPolicy set to "none". The children and their components would be created in an order determined by the user, and potentially never even created at all. Now maybe this case doesn't match the way your components are actually used, but I think you get my point. As far as constructObject2, createChildren, and the like, I would think the only time to use these would be when creating custom classes in actionscript. I've never had cause to use constructObject2, even in a custom class. In any case, I think relying on order of initialization is a recipe for disaster. Just one developer's opinion - FWIW, YMMV, and all that of course. --- In [email protected], G <[EMAIL PROTECTED]> wrote: > > Doug, please don't think you need anyone's permission > to pipe up! That's the point of the list, to > e-list-it conversation. The more opinions the better! > > I agree with what you said about establishing best > practices, but I'm not sure I agree that any > application with complicated initialization needs to > be redesigned. Those functions, constructObject2, > createChildren, etc., are there precisely to > accomodate complicated behavior in custom components. > The trick is to know how to use them well. (which I > don't) > > > Greg > > > --- Doug Lowder <[EMAIL PROTECTED]> wrote: > > > You're right, I didn't read carefully enough. It's > > a big thread :) > > I guess it boils down to best practices, and knowing > > which approaches > > will work and which are inherently flawed - not an > > easy thing > > sometimes. Seems we're in agreement on the > > programmer error point; if > > the purpose of the original code was to bind one > > object's property to > > another's, it certainly doesn't get the job done. > > Knowing why it > > doesn't, and how to fix it so it does, is part of > > the learning process > > everyone has to go through. > > > > I know none of this has anything to do with > > constructObject2, init, > > createChildren, and initialization order in general, > > but in my mind > > any application that depends on the order of > > initialization probably > > could stand to be redesigned. > > > > Thanks for letting me share my opinion! > > > > Doug > > > > --- In [email protected], G <greg556@> > > wrote: > > > > > > Doug, certainly I welcome you to join in the > > > conversation. The more heads and opinions the > > better. > > > But I'm afraid you didn't read my post carefully > > > enough--my entire point was that I believe our > > > problems are programmer error rather than a > > compiler > > > bug. That was the central question of my email, > > and > > > the code I included was to illustrate how easy it > > is > > > to make such errors! > > > > > > The purpose of this thread is to try to gain a > > better > > > understanding of the order of initialization in > > > Flex--the interactions between constructObject2, > > init, > > > createChildren, and how those interact with > > bindings. > > > > > > > > > Greg > > > > > > > > > --- Doug Lowder <douglowder@> wrote: > > > > > > > Sorry for butting into this thread, and no > > offense > > > > intended, but > > > > personally I would describe this as programmer > > error > > > > and not a > > > > compiler bug. You are building into > > MyFirstObject a > > > > dependancy on > > > > another object without taking into account the > > > > initialized state of > > > > the dependant object. I see two ways to correct > > > > this: > > > > > > > > 1. Check the state of the property of the > > dependant > > > > object when you > > > > access it. You can do this just by seeing if > > the > > > > property you are > > > > accessing has been defined, and taking > > appropriate > > > > action if not. > > > > > > > > <MyFirstObject initialize="handleInit()" > > > > > <mx:Script> > > > > public var innerWidth: Number; > > > > public function handleInit() { > > > > if (myOtherObject.outerWidth != undefined) > > { > > > > innerWidth=myOtherObject.otherWidth; > > > > } > > > > else { > > > > doLater(this, "handleInit"); > > > > } > > > > } > > > > </mx:Script> > > > > > > > > 2. The second, and in my opinion better, way is > > to > > > > create components > > > > and utilize binding from the parent rather than > > the > > > > component. > > > > > > > > // component MyFirstObject > > > > <MyFirstObject ... > > > > > <mx:Script> > > > > public var innerWidth: Number; > > > > </mx:Script> > > > > <mx:Image width="{innerWidth}" /> > > > > </MyFirstObject> > > > > > > > > // component MyOtherObject > > > > <MyOtherObject initialize="handleInit()" > > > > > <mx:Script> > > > > public var otherWidth: Number; > > > > public function handleInit() { > > > > otherWidth=55; > > > > } > > > > </mx:Script> > > > > </MyOtherObject> > > > > > > > > // application that uses the components > > > > ... > > > > <mx:HBox> > > > > <MyFirstObject id="myFirstObject" > > > > innerWidth="{myOtherObject.otherWidth}" /> > > > > <MyOtherObject id="myOtherObject" /> > > > > </mx:HBox> > > > > > > > > Either approach should take care of the > > > > initialization issues you are > > > > seeing. If you want to provide specific sample > > code > > > > showing the > > > > problem, I can try to give more details. > > > > > > > > > > > > Hoping that helps, > > > > Doug > > > > > > > > --- In [email protected], G <greg556@> > > > > wrote: > > > > > > > > > > If I haven't bored you yet, I would love to > > tell > > > > you > > > > > exactly what the issue is. For a long time > > now > > > > we've > > > > > occasionally seen very strange behavior. As I > > > > > described before, you'll write something, get > > > > > everything working perfectly, then do a clean > > > > build > > > > > before deploying and suddenly something > > > > disappears. > > > > > The problem is clearly that some properties > > are > > > > not > > > > > being initialized properly. I can make it > > happen > > > > > regularly and predictably right now. I do a > > clean > > > > > build, and one component's x & y are not set, > > so > > > > they > > > > > show up in the upper left. Then I "touch" > > that > > > > file > > > > > (I put the line "if (false) true;" in it), and > > now > > > > it > > > > > works. > > > > > > > > > > There are two theories here in the office. > > One is > > > > > that there is a compiler bug in flex so that > > > > bindings > > > > > are not always properly recognized. That's > > the > > > > old > > > > > pre-me theory. > > > > > > > > > > My theory is that there is no problem with > > flex, > > > > but > > > > > that we are not properly initializing > > variables, > > > > and > > > > > that certain changes get made during > > > > initialization > > > > > "under the radar" of the binding mechanism. > > > > > > > > > > First, it is easy to mistakenly break binding: > > > > > > > > > > <MyFirstObject initialize="handleInit()" > > > > > > <mx:Script> > > > > > public var innerWidth: Number; > > > > > public function handleInit() { > > > > > innerWidth=myOtherObject.otherWidth; > > > > > } > > > > > </mx:Script> > > > > > > > > > > <mx:Image width="{innerWidth}" /> > > > > > </MyFirstObject> > > > > > > > > > > <MyOtherObject initialize="handleInit()" > > > > > > <mx:Script> > > > > > public var otherWidth: Number; > > > > > public function handleInit() { > > > > > otherWidth=55; > > > > > } > > > > > </mx:Script> > > > > > </MyOtherObject> > > > > > > > > > > Width in the Image component is properly bound > > to > > > > > innerWidth--any time innerWidth changes, so > > should > > > > > width. The problem is, innerWidth only > > changes > > > > one > > > > > time, in handleInit, when it is set, not > > bound, > > > > > to MyOtherObject.otherWidth. If > > > > > MyFirstObject.handleInit() is called before > > > > > MyOtherObject.handleInit(), innerWidth will be > > > > > undefined, and never changed again. > > > > > > > > > > The second issue, I believe, is that the > > bindings > > > > are > > > > > only executed at a particular time during the > > > > > initialization process. (Specifically, in > > > > > constructObject2, after createChildren.) It > > is > > > > > possible, as I said, to get that out of order > > so > > > > that > > > > > the binding mechanism "fires" too soon, and > > not > > > > again. > > > > > > > > > > So anyway, those are the two competing > > theories > > > > around > > > > > here: compiler bug, or subtleties in > > > > initialization > > > > > order that we do not appreciate. > > > > > > > > > > Either way, I believe it is clear that binding > > is > > > > not > > > > > as robust as we'd wish, during initialization. > > > > > > And at > > > > > any rate, understanding better how something > > works > > > > is > > > > > always a good thing! > > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > > > > > > > > --- JesterXL <jesterxl@> wrote: > > > > > > > > > > > 2 things to do to ensure you're not nuts. > > > > > > > > > > > > 1. Add &recompile=true to the end of the URL > > > > string. > > > > > > Slows compiling, but > > > > > > it's worth the piece of mind. > > > > > > > > > > > > 2. Delete generated everytime you want to be > > > > sure > > > > > > your changes are in fact > > > > > > taking. Mine's here for Flex 1.5: > > > > > > > > > > > > > > > > > > > > > C:\JRun4\servers\starExhibits\cfusion-ear\cfusion-war\WEB-INF\flex\generated > > > > > > > > > > > > LOL!!!! Royal... AWESOME. Whew, that made > > my > > > > > > Thursday. Mmmm, tasty > > > > > > burger!!!! > > > > > > > > > > > > First off, bindings are supposed to free you > > > > from > > > > > > initialization worries. > > > > > > Here's how it was in Flash: > > > > > > - capture data in member var > > > > > > - create asset > > > > > > - wait a frame > > > > > > - set data > > > > > > - delete member var > > > > > > - repeat process in convulted way > > > > > > > > > > > > In Flex? Bind value in View and it'll > > "work" > > > > when > > > > > > she's created. Pimp! > > > > > > > > > > > > I'm sorry to hear it's not working that way > > for > > > > you. > > > > > > Here's the rundown. > > > > > > > > > > > > - init > > > > > > - createChildren > > > > > > - initial drawing > > > > > > * initialize is before everything is done > > > > drawing > > > > > > - createChildren is the last event fired > > when > > > > > > everyone and their mom is > > > > > > ready > > > > > > > > > > > > There is a good rundown of this on Adobe's > > > > DevNet > > > > > > site. If you want the > > > > > > link, I can go find; it's a pretty good > > > > explanation. > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Tired of spam? Yahoo! Mail has the best spam > > > > protection around > > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
