Hi Cliff,

No problem.  And, of course, the spirit of my post was one of exchange, not debate.  To that end, I should respond so that lookers-on benefit from a refinement of this exchange.

I'd have to push back on this one.  (referring to covariance)

Actually, those of us who look for covariance think of it more in terms of return types, not arguments.  That's where we need it most (I'm afraid Wikipedia is incomplete here.  We would have to turn to Bertrand Myer's Object-Oriented Software Construction text for the complete definition).  Covariance over arguments isn't very interesting, albeit necessary.  When the conversation switches to arguments, well then I'm looking for contravariance.  Eiffel spoiled me with its robust support of both of these features.  In fact, I'm rather lost without covariance over return types.  I'm looking forward to .NET 4.0 for this, among other, reasons.  Incidentally, I see a few places in the codebase of PureMVC where covariance could be of benefit.

OK. I've managed to program since 1982 without needing lambda expressions. I see what they do, but I can't imagine how they'd change my life if I had them.

I felt the same way as you...until I went all in.  My goodness, why did it take so long for lambdas to work their way into mainstream?  It's quickly becoming the case for me that I wouldn't know how to program without them anymore.  I find myself using them naturally.  They're so powerful, so expressive, and so succinct.  They also tremendously improve the readability of the code.

Sure it is. The flash.* and mx.* classes are not part of ActionScript...

I missed this, then.  I stand corrected.  It wasn't a deal-breaker, though.

After years of doing it the other way round in Java, I've come to like the postfix syntax better.

Yes, Eiffel does it this way as well, and it drives me crazy there, too.  You're right: It's just a matter of what you get used to.  It wasn't a deal-breaker either, though.  But I have read where other die-hard ActionScript programmers don't care for the postfix approach too much, either.

Anyways, this is good stuff.  Thanks for your awesome reply.

Eric

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

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

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

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

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

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

Thanks, again.

Eric

Yes, I think this makes sense.  The Mediator is analagous to my ModuleStub.

Thank you for your guidance.

Eric

Directed to Cliff,

Hello, Cliff.

I was just reading a reply you made to a post concerning "fully encapsulated modules."  In it, you state the following:

You need another actor that is responsible for managing the modules. Much as the Model keeps a map of Proxies, this actor keeps a map of modules. This actor also needs to be able to take configuration from the other actor and use it to create factories for modules, create (or defer) loading of each module, as well as creating or deferring some configured number of instances of each module once loaded. It should keep the factory on hand to lazy load configured modules.

Who would that actor be?  In the .NET library I wrote, the 'ModuleLoader' resided in the shell.  That seemed to be the best place for it.  Would you agree?  Perhaps the loader should be its own module, except that, unlike other modules, it's not obtained from a file directory.  It's loaded in the same way that modules are loaded in your [wonderful] Modularity demo.

Thank you.

Eric

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