Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Should I share PureMVC sub-classes in a .SWC?  (Read 4132 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« on: February 09, 2012, 07:51:40 »

This question is not: Should I put the PureMVC framework in an .swc to share among projects.  The answer to that question is yes, and I do.

The question is about my specific framework classes for my applications.  The situation has arisen that we need to make a "light" version of our horrible enterprisey PureMVC-abusing electron consumption CPU temperature elevation engine (aka, our application).  But the PM wants us to share code across these two projects as much as possible in a way such that if I make a change to one class it will affect both projects.  Nothing revolutionary here.  Ordinarily this is done with a library project.  I totally support this and have no problem putting our utils, view components, and service code into an .swc.

Where I am hesitant, however, is when it comes to also bundling the framework Mediators, Proxies, Commands, etc. selectively into an .swc so that the "light" application shares framework code with the "big" application. 
  • PureMVC.swc?  Yep. 
  • LoadupUtil.swc?  Absolutely. 
  • Some_common_mediators_commands_and_proxies_but_not_all.swc... uh.

Correct me if I am wrong, but isn't this a bad idea?  Shouldn't I keep the two code-bases for the framework classes (extending PureMVC classes) entirely separate even if they are redundant and even if updates might require that I copy changes into multiple locations?  What if later I am tasked with coming up with 50 "light" applications all using the same source but with only minor differences in content?  Does the same principle apply?

Finally, assume that the differences in these applications are significant enough that I can't use a configuration file or some other means to compile different versions of the application from one single project.  We tried that and it failed and now everyone here knows what inner-platform effect is.

Has anyone been in this situation?  And what did you do?
Logged
philipSe
Sr. Member
****
Posts: 139


View Profile Email
« Reply #1 on: February 10, 2012, 03:25:14 »

You need to have a set of classes that, individually, or as a group, are independent of the other more-application-specific classes.  That's obvious you might say. But it's often only when you set out to do it, that you come across dependencies that you hadn't expected.

So, then you might have to refactor the classess - if it makes sense.  This can involve introducing interfaces where there weren't any, and that is often sensible. It can also involve creating higher level classes that are extended at the application level.

In the end, having an swc that contains a set of reusable commands and mediators and proxies can be a good idea, but it is likely to involve some refactoring effort since the classes in question did not start out with that objective. The alternative of duplicate classes is not attractive.
----Philip
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: February 10, 2012, 09:09:11 »

I would not bundle PureMVC and Loadup inside yet another SWC, there's just no reason for that. It hides what's in there and makes it less obvious what is available to you in the project.

But bundling your PureMVC subclasses into a swc for sharing between project is a really common thing to do. For instance, my current client has a media creation tool done in Flex. Then they have a viewer that uses a subset of the components to make a lightweight app for viewing and sharing your creations on the web. Then they have an AIR version of that viewer that is the mostly same as the Flex viewer except it does local caching for offline operation. Then that lead to an iPad version of the viewer that has totally different view components and mediators (because you can't use MX controls on mobile, only spark).

So this has been challenging, but success is all about code separation.

First move your model to a separate library project with no dependencies back on the app. This will tell you if you've followed best practices and kept your Proxys and VOs ignorant of the application they are a part of. If you have difficulty making this separation, then refactor until you can. It should have PureMVC and possibly Loadup in its libs folder (set not to be merged into code). Call this, say LibModel

Next, move everything else but the application itself into a library. That library should have the model library project as a dependency, and PureMVC, LoadUp, etc, should all be swcs in the libs folder (set not to be merged into code). Call this, say LibFlex.

Now your application should have the model and the view/controller library as project dependencies and PureMVC, LoadUp, etc, should be swcs in the libs folder.

Now you should easily be able to create a second application just like the first, and it should run. But it's not the same app, of course. It's a different app. There will be code specific to that app and code specific to the other app. Over time you'll migrate just what is absolutely specific to each app, into those projects and out of the libraries, so that the libraries end up with just the shared code.

When you go from a Flex app to one or more AIR apps, you'll find that you have to create another library to house the code that references AIR stuff, call that, say LibAir. So your AIR apps will have LibFlex,  LibAir, and LibModel as dependencies. Your Flex apps will only depend on LibFlex and LibModel.

-=Cliff>
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #3 on: February 12, 2012, 06:49:13 »

Thank you guys, it sounds like you are telling me to go for it despite my reservations.  Admittedly, my reluctance is due to improper implementation of a lot of PureMVC classes that I know I can't extricate without a lot of work.  Nevertheless, there are some view/command classes that I could share.  And the model tier I have already made great efforts to separate already.  So, for my application projects, I am planning to have a lib folder with the following:

/libs
PureMVC.swc
Loadup.swc
AppCommonModel.swc
AppCommonViewCommand.swc
AppCommonComponents.swc

PureMVC and Loadup are just themselves, as .swc for convenience (Cliff, it sounded like you ultimately approve this, but let me know if I misread). 

AppCommonModel.swc holds the Proxies, VO, and whatever utils I might have exclusive to their function (eg: configuration .xml, enumeration constants, etc). 

AppCommonViewCommand.swc will have Mediators and Commands that go with view components I need in these different applications (regardless of whether their view components are implemented differently for different platforms--the public functions the Mediator calls on the view component will be the same).  Most of my Commands are used for deferred instantiation (I register Mediators, Proxies, and view components at run-time right now) and are easily shared as well, I believe.

Finally, AppCommonComponents.swc will be common view components written in .mxml or .as for these apps.  I might replace this .swc with a different one for mobile apps, Air, etc.

So each application will have its own ApplicationFacade, but apart from that, in theory, could have all its other framework classes in .swcs.

This is the approach I have come up with after reading your feedback.  If you have anything to add, or if you think I have strayed from your original advice, please let me know.

I also need to find out what happens when you set lib references to not be merged into code...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: February 12, 2012, 07:04:43 »

Sounds like you're headed down the right road.

So each application will have its own ApplicationFacade, but apart from that, in theory, could have all its other framework classes in .swcs.
Yes. Don't worry about trying get the sharing perfect the first time, you can refactor classes into and out of different library projects with each new app, as you go, and you can use inheritence to help avoid some duplication. For instance, our three viewer apps share a lot of the same stuff, but the web and desktop has one set of overlap, the desktop and mobile have another overlap and each has some of its own classes. So we ended up with an AbstractViewerFacade that all viewer apps extend for their ApplicationFacade. then they add what's unique to them or shared with only one of the others.

Good luck.
-=Cliff>
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #5 on: February 14, 2012, 01:59:11 »

Thank you!  I wish we'd had this conversation a long time ago.  We've already screwed this up with past applications by cowboy coding in a vacuum, but I've insisted that we do some design work before coding this time.  The design is hard (because I am not an application architect) but I can see now that the maintenance will be so much better!
Logged
Pages: [1]
Print