Your core application, aka The "Shell" is a small application that is download first by the user, and responsible for loading/unloading your modules. You can also add some core functionality to this app that will get used by the modules.

ModuleLoader

ModuleLoader is a simplified hook into the ModuleManager class. It has some pros over ModuleManager in that you can use a MXML format to simply place the Module on the Stage. But of course it's ease of use also comes with some cons. First off when you load a module you need to get the child of the ModuleLoader element to get to the actual module. Also you need to create a new ModuleLoader for each instance of your modules. So if you want 3 instances of Account Module you would need to create a new instance of ModuleLoader for each.

Example

import mx.modules.Module;
import mx.events.ModuleEvent;
import mx.modules.ModuleLoader;
 
private function readyHandler(event:ModuleEvent):void {
	//Module Is Ready
	var loader:ModuleLoader = event.target as ModuleLoader;
 
	//You need to access the Child to get to the Module
	var module:Module = loader.child as Module;
}

 
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:ModuleLoader ready="readyHandler" url="MyModule.swf"
</mx:Application>
 

ModuleManager

ModuleManager is a more advanced way. Also my recommended method. You tie into the ModuleManager class to load the module. Once loaded you have access to a IFactory Interface to create as many Instance as you would like. Also when you create the Module and place it on the Stage you can avoid having to dip into any Children. The only con I've found with this method is you aren't allowed to directly place the Module without using actionscript. You could possible create a custom ModuleLoader of your own to set the Placement.

Example

import mx.modules.IModuleInfo;
import mx.modules.Module;
import mx.modules.ModuleManager;
import mx.events.ModuleEvent;
 
public var modInfo:IModuleInfo;
public var loaded:Boolean = false;
 
public function loadModule():void {
	if(!loaded) {
		modInfo = ModuleManager.getModule('MyModule.swf');
		modInfo.addEventListener(ModuleEvent.READY, readyHandler);
	}
}
 
private function readyHandler(event:ModuleEvent):void {
	//Module Is Ready
	var module:Module = modInfo.factory.create();
 
	//Place The Module on the Stage
	addChild(module);
}

The Module(s)

Modules can be anything really. Libraries, Components, or Pages. I prefer the later. I will create a module for each section of a large admin. So If I have Users, Bussiness, and Billing sections. I'll create 3 modules, one for each.

For the most part you can just create modules the same way you would create normal applications. I even start them out as a seperate app is some cases. That way you can debug/build them without having to load them thru the Shell. When you are done creating your module, you just switch the root tag from <mx:Application> to <mx:Module>. If you creating a actionscript Module, you just need to have your Class extend mx.modules.Module

 
<?xml version="1.0" encoding="utf-8"?>
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="400" height="300">
	<mx:Canvas width="400" height="250">
		<mx:Form width="100%" height="100%">
			<mx:FormItem label="Name:" width="100%" horizontalAlign="left" textAlign="left">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="Address:" width="100%">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="City:" width="100%">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="Region:" width="100%">
				<mx:ComboBox labelField=""/>
			</mx:FormItem>
			<mx:FormItem label="Country" width="100%">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="Zip Code:" width="100%">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="Phone #:" width="100%">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="Email:" width="100%">
				<mx:TextInput width="100%"/>
			</mx:FormItem>
		</mx:Form>
	</mx:Canvas>
</mx:Module>
 

Optimizing Module(s)

Their are a couple ways to optimize modules. The First way is to remove duplicate references. Basically you can tell Flex's Compiler not to reference anything that "The Shell" already does, so for instance if you have a actionscript class that handles all your HTTP Request and you use it in all/most of your Modules you can reference it in your "Shell" and add the compiler flags to not reference it and you'll save SWF size on the modules and the end-user won't be forced to download the same class over and over. Once and your done.

Their is 3 ways to do this, the third being my favorite for really large apps. It should be noted, that by optimizing the module in the first 2 ways, your making it only compatible with your "Shell". So don't expect your module to work with someone else's Shell Application.

Flex Builder's Way

This is probably the easiest way. I like to use it for medium size projects. The downside of it is that once you have say 100 modules. It's going to get pretty bloated in the "Flex Modules" section. And if your linking source for external project modules. Your source tree is going to go to hell. Because linked sources show up as folders in your project.

1. Right click the Shell's project
2. Choose Properties
3. Click the "Flex Modules" tab on the side.
4. Then click add.
5. The source is where the module is.
6. The application is the shell.

If you are using separate projects for your modules, you need to link the source in order to accomplish this method.

1. Right click the Shell's project
2. Choose Properties
3. Click the "Flex Build Path" tab on the side.
4. Click the "Source Path" tab.
5. Click "Add Folder..."
6. Enter your module's source path.

Flex Compiler / XML Linker Report

This way in some ways is a little more complex, but scales much better. This way also doesn't require Flex Builder. So it's a good solution for Open-Source Flex Developers. It works by generating a XML report from the "Shell" application with what Classes it references. Then the modules use this report to not duplicate it's references.

Shell's Project Settings

1. Right click the Shell's project
2. Choose Properties
3. Click the "Flex Compiler" tab on the side.
4. Add the following to "Additional compiler arguments"

   -link-report=report.xml MyApplication.mxml

5. Click "Apply"
6. Click "OK"

Module's Project Settings

1. Right click the Module's Project
2. Choose Properties
3. Click the "Flex Compiler" tab on the side.
4. Add the following to "Additional compiler arguments"

   -load-externs=report.xml MyModule.mxml

5. Click "Apply"
6. Click "OK"

RSLs (Runtime Shared Libraries)

Coming Soon: Information on Setting up RSLs

But their is a always pros and cons of using any programming language right? One of the biggest questions I had when learning Flex was how to make a large 300+ screen admin without having a 100MG SWF. So I began researching the internet finding very little. But the info I did find was very information.

Modules

Flexes modules were very well thought out in my mind. Basically allowing you to split up your application by pages, components. Allowing your users to quickly download a small "Shell" Flex application and then dynamically load your modules on demand. So if you have 300 sections of your flex app, and your user will only be using 10 pages, they aren't required to wait for the full 300 sections to be downloaded.

Modular Apps Are Easier Than You Think...

RSLs (Runtime Shared Libraries)

You can create shared libraries for anything from Flash components, the Flex Framework, or your custom Flex Library Projects. I like to have libraries containing my components. If I have a site that has custom components, I will split them up by category so I'll have one Flex Library Project for my Bussiness Accounts and one for my Users. So If I'm creating a admin interface module for the users, I'll add that library as a RSL. Then If I'm creating the user interface module for the user to update their information. I will link that module to the same RSL. What does this do? basically the components are not including in the modules SWFs. They are still registered which adds some size to the final SWF but it doesn't actually include the components. Adobe also has a new thing for Adobe Signed RSLs. also known as SWZ files. You can have your Flex framework linked in as a SWZ. What this does is, when the user starts your app it informs the player of which Flex framework version is required for your app to run. If the user has downloaded this Adobe Signed SWZ before they won't have to download it again, else it will download it for them and store it in a none browser specific cache. Meaning even if the user downloaded the framework for a yahoo website using IE, they can use it for your site using Firefox.

Coming Soon: Information on Setting up RSLs

First off, I'm a huge fan of frameworks, I love to tinker and explore through other frameworks, I think some of the best php code is often found in frameworks and their libraries. I also found that I really liked different things from different frameworks. So I set out on a mission to create a very Rapid Development Framework that was also expandable enough for major websites and applications. That's where Plex comes in I started with a similar directory structure as Codeignighter, which is one of my favorite frameworks. I then used a similar Yaml config setup as Symphony, another favorite of mine.  I then added my own logic from past projects I've created, which included my DB abstraction classes and my web services classes, Jax and Jaxson. When I was all done, I had create a very fast pace development server that was excellent for a web service server used in JS(Ajax) apps, Flash, and Flex Apps as well. The biggest key was the way the services are written, and the DB_Model_Generator.php file.

So to create a feed from the database server to say your flex app all you have to do is open the DB_Model_Generator.yml file and add these lines.

tableName:
  add:generate
  update:generate
  Web_Services:
    add:True
    update:True
    search:True

Then run the /bin/DB_Model_Generator.php file to create your Database Model file /model/tableName.php and create 3 web services

• /Handler/Web_Service/Add.php
• /Handler/Web_Service/Update.php
• /Handler/Web_Service/Search.php

To test out your Web Services go to http://www.yoursite.com/Jax/Service/tableName.Search and see if you get any errors, if not your good. Cool thing about how the web services work is that are agnostic to language meaning, you can access the same feed either in XML format(Jax) or JSON format(Jaxson), you could also create your own custom one, say to work with the Yaml format just by creating a new Classs similar to /lib/Jax.php or /lib/Jaxson.php

For you who don't know already, Plex Kicks Ass, It's a cool new PHP Framework that makes the busywork done, so you can get down to bussiness and do what you love, CODE!

The plan now is to to cache the thumbnails and cache the rss calls at least 1/minute, do to twitter's api restrictions which are 70 calls per Hour.

I'll post more info, link, screenshots when I'm a little further along with the app...

So if your looking for a lightweight editor, a multi-language editor, a windows version of the ever popular textmate, or just a kickass editor, you should really give E a look.

http://www.e-texteditor.com/

I would also suggest them in a large workgroup, where your always adding to the project, a good mvc framework will save you plenty down the road, doing everything completely custom for right now is IMHO not a good way to work, because it makes it much more difficult of a upgrade later. Even for a small, quick and dirty jobs I still like to use my framework, to save time, and ditch the learning curve of new objects. I can open any one of my projects and immediately know what's happening without having to remember how I created this wheel vs. my other ones. With a solid framework you can use the brawn of a 900 pound gorilla in your little mouse of a project. Which can help with anything from securing, optimizing, and simplifying your code. It's kinda like having a sudo development team. People spend hours on optimizing, testing, benchmarking, and securing every bit of code in frameworks. Its a valuable resource, why waste it...

Also, I've looked at many, many different frameworks, built my own, and contributed to others. And I can easily say that the code involved with frameworks is some of the most sophisticated, optimized, and cutting-edge stuff you will ever see in a php project these days. Good programmers can write up a site, but only Great programmers can create a framework they are willing to use more than once...

Just my 2 cents...

Yum - The Client

The great things about yum, is it's so easy. say you want to install php, just do something like this.

yum install php

Its that easy. Yum will then build a list of requirements (if any) and give you a list of what going to be installed, then you can say yes, or no. Now lets say you want to install multiple programs. Like for instance php, mysql, and apache's web server. Just added spaces in between the names like so.

yum install php mysql httpd php-mysql

And again it will throw together a list and the whole yes/no thing. Updating is just as easy you just replace the word install with update,

yum update php

And yum will go and try to find a newer version and build a list of dependencies for the new version if any. Now if you want to update your entire system just type

yum update

Yum will then try to update as much as possible.

http://www.fearyoucanhear.com

http://www.goodmonkeys.com

So now we have a huge pipe and unlimited bandwidth. Hopefully you can notice a difference.

Thanks Webpipe