To get the nomenclature down, I think of "Objects" in Flex as a datatype, or a catch all phrase for classes and instances that do not have a visual component. Components to me are that visual component.
That said, I'm confused why order is an issue; could you elaborate? If you write all of your classes, the Flex compiler takes care of all depencencys and load order for you. Yeah, you can call methods on loaded SWF's, and they can call methods on the SWF that loaded them, assuming both are in the same domain, or the domain has a crossdomain.xml file that says otherwise. I've used the above to give my Flex 1.5 app the ability to utilize Flash Player 8 features; I load in a Flash Player 8 swf into a Flex panel, and the Flex panel makes method calls on it. If the user has Flash Player 7, they won't see anything for that 1 panel, but if they have Flash Player 8, it'll work fine. I've had no problems with large interfaces in Flex; those who have are loading thousands of forms, but I have yet to resolve how they are building things, and why they need soo many unique forms and why they couldn't reuse elements. In my opinion, I've always been successful if I build things, and re-factor as need be. Any performance issue I've had with Flex or Flash was something glaring, and easy to overcome. Therefore, I'd just build a pilot of what you want, and address the issues as they come up vs. theorizing over potential problems that don't even exist yet. ----- Original Message ----- From: "Courtney Couch" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, November 09, 2005 10:23 AM Subject: RE: [flexcoders] Lazy loading components Loading in the order of reference doesn't give me enough flexibility as the order of reference isn't necessarily the order in which the user will progress through the interface. The loading of the controls seems to be a bad solution as well. As you said eventually all the controls will exist. Also, are you familiar with how the object scope works for loaded swf's? Is it possible for callbacks from loaded swf's? If not then that wont work either. As they would be components in an event driven interface and would need to pass events to the calling swf. The SWF would potentially need to be able to callback to the loaded swf on events as well. The sections as individual SWF's also doesn't seem to work for large applications as it's you pointed out it's a management nightmare. It seems that perhaps it really isn't designed with large interfaces in mind yet? So perhaps some sort of lazy loading mechanism for parts of the application so its not compiled into a single SWF file should be on some sort of feature request list. If only that were built into it so one could simply develop that into the MXML and AS files and not have to worry about some sort of import/separate interface parts as a hack/workaround. -Courtney Couch www.courtneycouch.com -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL Sent: Wednesday, November 09, 2005 6:54 AM To: [email protected] Subject: Re: [flexcoders] Lazy loading components MXML & SWC's are compiled into a final SWF. Classes are compiled in the order in which they reference eachother. They are immediately available to you when your Flex application starts. Remote Shared Librarires (RSL's), allow multiple Flex applications (SWFs) to share the same components, both the internal Flex ones, and ones you make and plan to make available. They are loaded in order, like the above with the addition of having to download the SWF they are in first; from then on, this SWF is cached in your browser cache. You can treat them as normal components & classes that you can immediately access and call all methods on. You have 2 options for lazy instantiation; one is to utilize gregarious amounts of queued or none creationPolicies for your containers, and the other is load in dynamically loaded SWF's. While the former provides a lot more control over what is loaded, and when, as well as expediating the loading of your application, and improving start up time, eventually, in using all the app, all controls will eventually exist, just not be displayed. For Flex 2 this isn't that huge of a deal, but for 1.5, even if a visual element isn't shown, it still is rendered, albeit slightly. As such, things could slow down later on depending on what you are doing. The other option is to build in sections and/or components in SWF's. While this is the easiest way to load in multiple, unrelated sections with the ability to physically remove assets when you are done with them, thus clearing resources, this can become a management nightmare depending on how many SWF's you plan to use this way. Additionally, although both SWF's can use the same RSL's, they cannot share resources, and classes loaded between them is too confusing to write briefly in this email. Sometimes you have no choice to do this as it's the most efficient way, and utilizing interfaces, one can lessen the pain of having no compiler to help you connect things at runtime. I personally recommend against this. Hope that helps. -- 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 ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- 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/
