Modular applications, directory structure, and RSLs

[estaylorco]

Hello Forum:

I'm a certified .NET developer, but I'm new to the Flex/Flash world.  We are moving three of our applications into the cloud, and after two months of research, have decided on Flex (Flash Builder 4.0), MultiCore PureMVC (without Pipes for now), and ColdBox (on top of ColdFusion 9.0 ORM) as our technology stack of choice.  The architecture for each will following 'modularity' pattern.

Consider the following as you read on: Modules will be dynamically loaded.  The shell will have no foreknowledge of the modules that will be loaded into it, other than of the Administration Module.

I have a few questions concerning directory structure.  Following Joshua Ostrom's example, I'm thinking that I should have separate projects for the shell, for common, and for each module.  In the .NET world, we have the same problem with our AppDomains that you guys have with ApplicationDomains: Once a module ('assembly' in .NET) has been loaded into an AppDomain, it cannot be unloaded.  It's my understanding that the foregoing approach to separation facilitates mitigating, or eliminating altogether, GC issues and ApplicationDomain issues.

From what I've read around the forum, and in the Adobe documentation, it would be advisable to treat the framework SWC as an RSL, PureMVC MultiCore as external, and then place the two of them (along with another other common elements) into a separate Flex Library Project--perhaps called 'common'.

I've tried this, though, and even referencing 'common' from the main application project, the application can't find what are obviously framework classes (e.g. 'Object').  What am I doing wrong?  I can't quite seem to find the answer (even after reading chapter 30 of the Developer's Guide for Flex 3.0).

Also, there are a number of so-called 'framework' SWCs: the canonical, along with a number of ancillaries (playerglobal.swc, textlayout.swc, etc.).  What should the linkage type be of each?

Also, in the .NET WinForms application that I wrote (which we currently use), I took the approach of creating a ModuleStub for each Module.  While the Modules are loaded lazily, the very thin ModuleStubs are enumerated (from a file directory) and loaded all at once.  The stubs contain just enough information to set up the lattice: a small icon, a larger icon, the module name, the order of the module in the navigation pane, the facade, etc.  Communication between module and shell is done through interfaces (I did all of this before the advent of the .NET System.AddIn namespace in .NET 3.5).  From what I've read in another post on this forum, I will want to set up a similar scheme with PureMVC.  Is that correct?

Your help would be much appreciated.

By the way, PureMVC MultiCore is wonderful.  I spent about six months developing my own modularity scheme in .NET.  I'm quite relieved not to have to do it again, other than I'll have to develop a bootstrapping scheme for loading the modules.

Thank you.

Eric

[puremvc]

treat the framework SWC as an RSL, PureMVC MultiCore as external, and then place the two of them (along with another other common elements) into a separate Flex Library Project--perhaps called 'common'.

Your problem is likely trying to put Flex in a separate library. And for now, I wouldn't set Flex as an RSL, I'd compile it into the shell and call it external from the module projects. Until Flex 4 is real, you're likely to go through several versions and the rsl is different for each. Early optimization is the root of all evil.

But putting all your other utilities (MultiCore, StateMachine, etc.) into a separate library and referencing them as external in the modules and baking them into the client is the right way to go.

-=Cliff>

[estaylorco]

Will do.  Yes, I forgot that Flex 4 is still in beta.  It is remarkably stable.

Thanks, again.

Eric

[estaylorco]

Cliff,

I'm really wrestling with directory and library structure.  I've attached a screenshot to show how I've structured this application.  Even after reading 'Managing project resources' in the Flex 4 documentation, I'm still confused.  It seems that there are far too many degrees of freedom here.

From the documentation, it would seem that using Project References is not the way to go, that instead one should use source and library paths.

I moved PureMVC MultiCore into 'common' and set its linkage type to 'external'.  But it's unclear to me how I should reference this project from the main application project. In the main application, should I add the entire project to the library path or just the SWC?

Also, how do my modules gain access to the framework SWCs located in the main application project?  Do I have to add the framework to each project?  What about how the modules themselves should be referenced?  Am I referencing each module's project from the main application project, or vice versa?  I ask because it seems that I'm going to wind up with cyclic dependencies between the modules and the main application.  I want very much to move the framework into 'common' (to avoid ApplicationDomain issues), but that doesn't seem possible.

Even with Safari Books Online, I can't find much coverage on cross-project references.  The literature seems to be geared towards intra-project references.

Help would be much appreciated.

Thank you.

Eric

[jpwrunyan]

In the main application, should I add the entire project to the library path or just the SWC?

I know you'll get a better response from Cliff regarding the rest of your questions, but I might be able to at least answer this one. 

In general, I prefer adding library projects when I have the source to go with it (like with PureMVC).  The only time I add SWC (or SWC directories) is when that is precisely all I have: one or more pre-compiled .SWC's with the source files locked inside (like proprietary products, ILog Elixer, etc.).  I'm not using Flash Builder, though.  Just Flex Builder 3.

Finally, I rarely add source folders anymore since some bad experience with them in Flex Builder 2.  I just think taking the little bit of extra time to make Library Projects is worth the it.  With a library project I believe you get an SWC out of it automatically (cutting down on compile time if the source in the library doesn't change)... whereas with a source folder you compile the source code in that folder each time you compile your project--even if there is no change.  Anyway, my knowledge may be out-dated (Flex Builder 2), so please take that with a grain of salt.  I'm also going through the O'Reilly Flex 3 book to brush up.  Surely there's a discussion of the ins-and-outs of project settings there?

Finally, again from (out-dated) experience, I don't use RSL's very much.  Either I haven't had enough common classes between sub-apps to merit an RSL or else converting to Modules adequately addressed my issues.  Back in the day, RSL's were the only option for cutting down download times with very large Flash applications (I haven't used RSL-type behavior since Flash MX 2004).  Modules are great.

I know... not very PureMVC related, but there it is for what it's worth.

[estaylorco]

Thank you for the response.

Since I'm new to the Flex world (coming from .NET), everything's a grain of salt  .

With regards to adding SWC files vs. projects, I see what you're saying.  In .NET, we have the same thing: We can add an assembly or a project with source.  I have no choice if I'm using third-party components that don't come with source.  I liken SWC files to assemblies in .NET.

I found a pretty good article at this link: http://www.daveoncode.com/2009/04/07/deploy-and-work-with-flex-swc-library/.  You know, I have access to the O'Reilly book on Safari, but there's scant coverage of structure.

I have made progress, though.  I'm no longer getting framework errors.  I've attached a screenshot to show what I've reduced the problem to.  The link above explains part of the problem, but I'm too new to Flex to convert what he's saying there to a solution.

Perhaps this means something more to you?

Thank you.

Eric

[puremvc]

Hi folks,

Making the modular separation is the right thing for a lot of reasons in the long run but it does require careful planning.

When you reach the point of doing development with multiple modules, common library and shell projects, you are beyond the scope of what can be managed with Flex / Flash Builder and project references. For one thing, every developer has to go through the same hoops to set up the dependencies and you end up compiling this, that and the other thing individually, then copying the results to a location where you can run the shell and see your changes. You can set these dependencies up and check them into a repository so that all developers check out the project descriptor files with the dependencies, but that is a bad practice because when the IDE goes to a new version often times the descriptors change. Maybe they work, but if one person ventures ahead with a beta of a new version then checks in the file, now the rest of the team is using an IDE that may not be able to read that file and the whole project blows up. Bad news bears.

At this point, you must learn Ant and create a build script that has a targets for building all your modules, your library, your shell, moving the modules into position so that the shell can load them, etc. It allows you to encode all these dependencies clearly in an XML file fed by a properties file where you define all your variables.

Fortunately, the Flex Ant tasks are included with Flex nowadays, and Eclipse (which FB is built on) has an ant view that you can add to your development perspective which exposes your ant script targets, so you just run any of them with a click.

-=Cliff>

[jpwrunyan]

@cliff
Thanks for the advice Cliff, I know you've given it out before (re learn Ant!).
I went back and reviewed the modular class structure again yesterday and can now appreciate what you mean.  If the modules are in separate projects, then having to support Flex Builder settings across machines as well as across versions is really tedious.

If, like me, a person is in a situation where they anticipate resistance to adding yet another thing the developers have to learn (like Ant) or install (replace Stand-alone Flex Builder with Eclipse), then it's best to just keep modules in the same project and deal with it.  --  it seems to me.

@eric, cliff
For the record, I did try to install the adobe Eclipse plug-ins (in order to use Ant) into the stand-alone Flex Builder 3 at one point (last September) only get some meaningless error message ("pre-mature end of file"?!) and failure.  I assume this sort of problem can be circumnavigated by just installing Eclipse in the first place?  I can't believe I am unable to connect to the download server; I can see the website in the regular browser (http://update.eclipse.org/updates/3.3/).  The fault must be internal to Flex Builder 3 Stand-alone.  Or a gremlin.

@eric
Actually, I was wrong about O'Reilly.  I skipped to the index and then the table of contents.  There is no explanation of Modules in their Flex 3 book.  To paraphrase, they say "see chapter 9 for more about modules" and then in chapter 9 "we will cover components, but not modules here".  Huge disappointment (how could they miss that in editing?).  BTW their Flex/Flash Cookbooks are nearly useless, IMO, just in case you're wondering (I still buy them, but more for curiosity's sake than educational value).  Anyway I will definitely check the link you gave.  Also the regular Adobe livedocs are pretty instructive about Modules but probably don't have anything you don't already know at this point.

[estaylorco]

I have to agree with about adding yet another thing to learn.  I don't want to have to deal with Ant...in any programming context.

then it's best to just keep modules in the same project and deal with it.  --  it seems to me.

I think I will do that, although I'm waiting for a response from Joshua Ostrom, on his website, to see how he managed to pull off the separation I've illustrated here.  He seems to have a deep knowledge of PureMVC.

Concerning O'Reilly books, yes, over the years I've encountered uneven quality and consistency (unlike Manning and Wiley where every book I've purchased has been stellar).  I went to Safari Books Online specifically to keep the cost down and the risk to a minimum in acquiring technology literature.  I've never really been a fan of cookbooks.  They're great for n situations.  But what if you encounter n+1 situations?

Adobe does have excellent documentation, on the whole, but I must say that they come up a short a bit on the aspect of modularity.  Have you read Chapter 30 of the Flex 3.0 Developer's Guide from Adobe?  Covers modularity in depth...except cross-project modularity.

@cliff
Thank you for the insight.  I may ultimately fall back to a position of all modules in a well-ordered directory structure of one project, at least until my understanding of the Flex platform grows.

Thanks.

Eric

[jpwrunyan]

Have you read Chapter 30 of the Flex 3.0 Developer's Guide from Adobe?  Covers modularity in depth...except cross-project modularity.

Yes, that was the documentation I was referring to.  Sorry I didn't give the name.  They leave a lot to read between the lines, though, as far as implications of the Module, ModuleBase, ModuleLoader, and ModuleManager class.  For example, Module extends LayoutContainer, same as Application, but ModuleBase just extends EventDispatcher.  That's a pretty big difference.  But yeah, everything you *must* know is there.

On another note, I finally got Ant to work after many re-installs of Java (trying to get the environment variables right and chase down tools.jar).  I just wish I could run it from inside Flex Builder.  Right now I will have to make a desktop batch file.

[puremvc]

If, like me, a person is in a situation where they anticipate resistance to adding yet another thing the developers have to learn (like Ant) or install (replace Stand-alone Flex Builder with Eclipse), then it's best to just keep modules in the same project and deal with it.  --  it seems to me.

Developers on the project will not need to learn ant or understand the script, they merely click a run button in the Ant view and it does everything else. It's exactly the same as clicking run in Flex Builder now - you don't need to know how Flex Builder builds, it just does it, right?

And the person who creates and maintains the build script will basically do it once and make an  occasional tweak but that's about it.

It is a terrifically small price to pay for the result you get. You don't have the risk of loose cannons rolling around on the deck of your project who, if they're unable to learn something as simple as ant are pretty dangerous characters, IMHO. They can be contained in their own little sub-project dingys where they don't bother the Captain.

If you're going to develop large-scale enterprise software in Java or Flex there is no way to avoid learning Ant. Don't put it off, it's not that hard. 'Future-you' will thank you profusely for doing so.

-=Cliff>

[jpwrunyan]

Thanks for the advice Cliff.  I am trying to learn Ant a bit right now.  I didn't realize it could be so easily set up inside Flex Builder.

To which I have to say: I can't actually get it set up in Flex Builder (via Help -> Software Updates -> Find and Install...).  Don't know what the problem there is (see above).  I have to run Ant on the command prompt currently.  Anyway, that's neither here nor there...

Next is trying to put together a sort of concept demo that combines MultiCore PureMVC, Modules, and Ant.

[estaylorco]

I would like to thank you guys for your help, but, unfortunately, we have concluded that Flex is not a viable platform for the development of enterprise-grade business applications.  We are going to stay with the .NET platform.

Perhaps we will explore PureMVC more deeply in the context of C#.

Thanks, again.

Eric

[puremvc]

we have concluded that Flex is not a viable platform for the development of enterprise-grade business applications.

Wow. That's a pretty staggering conclusion.

It might be slightly off-topic, but I wonder if you might share some of the considerations that lead you to this decision?

-=Cliff>

[estaylorco]

Hi Cliff,

Sorry for taking so long to reply.  In looking back at my post, it seems rather curt.  I didn't mean it to be.  It was a genuine conclusion with no mal-intent towards Adobe (they're one of my favorite companies).

I overrode my team's decision to use Flex and/or Dreamweaver as our web platform going forward.  I decided to return to Silverlight and/or Expression, which I had been independently researching with one other team member.  Most of the weaknesses in the Flex platform revolve around ActionScript, which I would say is the Achilles' heel of Flex, in my opinion.  Here were my concerns:

• Lack of support for generics
• Lack of support for covariance
• Weak garbage collector (one has little control over it)
• No destructor or dispose pattern
• Doesn't solve the memory leak issues associated with event handlers*
• Implicit interface support only; no support for explicit interfaces
• Lack of support for lambda expressions
• Asynchronous, yes, but multithreaded, no**
• ActionScript is not a stand-alone language
• Declaring type after the variable is awkward

*Admittedly, both platforms address the issues with weak event listeners.
**I'm aware that multithreaded processing can be achieved with ColdFusion

Regarding Flex itself:

The Eclipse development environment is inadequate at best: Intellisense is substandard, the environment is slow when many tabs are open, no design-time incremental compilation, support for refactoring is weak.  In all, the Eclipse environment is utterly depressing compared to Visual Studio.  Perspectives, as they are currently implemented in Eclipse, are cute, but annoying.

Support for modularity is weak.  Take a look at Prism for Silverlight, which is put out by the Patterns and Practices team at Microsoft.  Silverlight, along with Prism, was designed for the level of modularity to which I was referring in this thread...without having to resort to Ant or its ilk.

I've noticed, too, that third-party Flex components are far more expensive than their .NET counterparts.

I was hoping that Flex solved at least some of the problems that we have on the .NET platform.  It doesn't solve any of them and, in fact, introduces a few of its own.  In the end, it's just another development platform, not a better one.

Two things I do like about Flex (and the Adobe stack), though, over Silverlight: CSS is directly supported in Flex.  Microsoft achieves styling through Expression Blend and XAML, but I thing CSS is more elegant.  Enough to keep me in the Flex camp? No.  The second would be ColdFusion.  Awesome product, far superior to anything we have on the .NET platform.  Almost enough to keep me in the Flex camp.  (I'm impressed with ColdBox, and I was excited about the prospect of Flex on top of PureMVC on top of ColdBox on top of ColdFusion.  Could have been great.)

I think that Silverlight is better suited for enterprise application development, but not necessarily for other types of websites.  In fact, I would probably resort to Flash for content-centric websites.

Anyways, that's just my opinion.

Eric