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: Pipes vs. Notifications: I'm Confused  (Read 15915 times)
Jason Tuttle
Newbie
*
Posts: 4


View Profile Email
« on: March 24, 2009, 01:39:16 »

Hi All,

I'm working on an app right now that has multiple views. Each view handles the CRUD operations of a specific data type. The app is built using a structure based on the slacker demo. As a result, instantiation of each view is delayed until the view is requested by user input. I've been thinking about refactoring these views into modules to reduce the size of the initial download of the app. -- No need to even load the data for each view until the user requests it.

I've been going over the demos/docs/tutorials/forum posts concerning modules to try and wrap my head around the concept, and I'm having trouble figuring out how you would send notifications to all loaded modules.

Right now, after a view has been instantiated using the slacker structure, it registers its interest in certain notifications. Many views are interested in the same notifications, so each notification acts kind of like a message that is broadcast to the entire app. -- Great!

If I re-factor to modules, I assume I should use pipes for communication between modules (module to module and module to shell). What I don't get is wether or not a single pipe message can act like a message that is broadcast to all interested modules similar to the way notifications work. It seems like pipe messages are more rigid. It seems like they can only go in a straight line from one module to another. Is this right or am I thinking about the pipe metaphor too literally? In other words, can I send one pipe message and have several modules register their interest in receiving it like a notification?

Thanks in advance for your responses,

: )

Jason
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 24, 2009, 03:40:12 »

Jason,

The pipe metaphor is absolutely meant to be interpreted literally. So if you want water to all the sinks, bathtubs and toilets in your house, you have to plumb them, right? Pipes isn't like notifications at all. That'd be like sending the water to everything over WiFi or something. :)

Crack open the Pipeworks demo and study it a bit. Like an apprentice plumber, you need to have an idea of what plumbing looks like installed in a house.

But before plumbing your own house, it'd be a good idea to understand what all the pipe fittings are for and what they're capable of. So, next stop is the Pipe Utility Unit Tests and API docs where you'll see each thoroughly documented fitting tested in isolation with lots of assertions about expected behavior.

Also, don't assume that you need to use pipes. This is an asynchronous process where a message is pushed into a pipeline and that's it. Later another core may or may not send a response message; its entirely up to you and the Message protocol you devise for your app. Much like communicating with a service.

There are times when you want an immediate synchronous response. So the other method of inter-core communication is interfaces. This is well defined in the Adobe Flex docs on modules, and demonstrated in the Modularity demo.

You can mix and match the two approaches as needed in your app.

And finally, don't expect that modules are going to reduce your main program size. It would seem so, but it generally isn't the case. This is not due to PureMVC, but Flex. You see, if you use any Flex components in your modules, you don't compile Flex into every module, that would be silly. So you end up having to include all of Flex in your main app, in case any of the classes are used in your modules. And any shared libraries such as the domain classes (VOs, Enums, etc) you guessed it, need to be compiled into the main app or you end up loading them multiple times

In practice modules tend to be tiny and the main app large.

The value proposition for modules lies elswhere entirely.

First is the ability to reuse the module. Imagine self contained modules to talk to major web service APIs where the user simply drops in the module and talks to it.

And the real biggie is in being able to spec out your app as modules and the outsource the module development. The outsourcing team doesn't even have to understand how your app works, only what interfaces it should implement and/or what message protocol it should follow. On a really huge project this can pay off big time. Maybe you don't want thos people mucking around in you main program or even knowing about how it works for intellectual property reasons. You can severely limit what the know/have to understand and still see the results you want. Like when George Lucas shot the Star Wars sequals and did them out of order and with each actor only getting to show up and act in the scenes they were in. No one had the big picture but him, so no individual could spoil the release by giving away the plot. :)

-=Cliff>
Logged
Jason Tuttle
Newbie
*
Posts: 4


View Profile Email
« Reply #2 on: March 24, 2009, 04:02:54 »

Hi Cliff,

Thanks very much for the clarification! -- I'll have a closer look at both the Pipeworks demo and the Modularity demo. It sounds like pipes aren't what I'm looking for.

What about Fabrication? In a forum posting they mention:

"Instead of sending and receiving messages via the junction.sendMessage and handlePipeMessages, messages are routed as standard PureMVC notifications. To send messages to other modules you call routeNotification. And to receive messages from different modules you simply add the notification name in listNotificationInterests of your Mediator." (http://forums.puremvc.org/index.php?topic=681.msg3047#msg3047)

If you'd care to comment, I'd be very interested in hearing your thoughts on Fabrication. Also, I'm not sure if you know the answer to this question but, am I interpreting the above passage correctly: With Fabrication, do pipes start to behave kind of like notifications?

Last but not least, your comments about modules not reducing my main program size were an eye opener! I had assumed that modules would be a good way of breaking my app into smaller chunks, but it sounds like that is not the case which means I probably won't end up using them in this app. Nevertheless, I'm loving the PureMVC framework so much that I really want to learn it all, so I'll be diving back into both the Pipeworks demo and the Modularity demo for a closer look anyway!

Again many thanks for your replies. -- They've been invaluable!

: )

Jason
Logged
sksizer
Newbie
*
Posts: 1


View Profile Email
« Reply #3 on: April 03, 2009, 07:20:44 »

I am just getting into the PureMVC framework, starting from MultiCore up through pipes and then examining Fabrication on top of it.  I believe that Fabrication by default utilizes pipes in a 'star' fashion so that your shell app will typically receive all notifications from all modules in a TeeMerge and sends them back out over a TeeSplit to all other modules minus the sending module. 

So effectively Fabrication's routeNotification acts like a broadcast sendMessage.

I would love to see further elaboration on these points as well however. 

For the project I am working on, I would like to utilize Fabrication, but maintain a hierarchical module structure for some of my message passing so I can perform some injections and the like.  I am still working through understanding how to best do this.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: April 03, 2009, 09:24:24 »

There is a convenience board for Fabrication under Public Apps, demos, etc, manned by the author, Darshan. It is not officially supported here, however.

-=Cliff>
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #5 on: April 03, 2009, 10:40:31 »

Cliff,

I've been wondering this for a while now, do you disapprove of Fabrication? I ask because you seem to have a disdain for it in every thread you reply to that involves it.  It's also one of the oldest externally submitted utilities and yet has never been added to the repo.

Clearly there is a need to simplify the Pipes utility or people wouldn't be using Fabrication. I'd wager a guess that more people use Fabrication than are using Pipes simply because Pipes are incredibly confusing for new adopters. Not to mention cumbersome to write code for when using many external modules.

I personally feel something similar to Fabrications routing concept should be part of multi-core base. Of course that's just my opinion.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #6 on: April 04, 2009, 01:22:35 »

I do not have disdain for Fabrication, I just don't support it and I have to make that clear. Darshan has his own repo because the QC process here would not have allowed it to gestate as quickly. The repos here are for small utilities - Fabrication extends every framework class and adds it's own spin, this is an entirely different framework, and that is why it has its own site.

-=Cliff>
Logged
Justin
Full Member
***
Posts: 24


View Profile Email
« Reply #7 on: April 20, 2009, 02:17:44 »



...And finally, don't expect that modules are going to reduce your main program size. It would seem so, but it generally isn't the case. This is not due to PureMVC, but Flex....

Modules took our app from 2.6 megs to less than 1 with 5 modules.  Hands down, the trick was to use interfaces exclusively on the shell anytime the module was cast, referenced or declared.  It seems that Flex likes to 'promote' the module and any class contained within the module to the shell if it is cast or referenced directly, thus increasing the filesize of the shell and decreasing the filesize of the module.

do this: protected var myModule : IMyModule, not this: protected var myModule : MyModule.
do this: protected function getMyModule() : IMyModule, not this: protected function getMyModule() : MyModule.

Also, any child or class that is exposed to the shell in any way should not reference, cast or declare the module either, this goes for commands, proxies or mediators that may be registered to the ApplicationFacade on the shell.  Use interfaces instead.

You get the idea.  Modules, always reduce filesize of the shell when structured correctly.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: April 21, 2009, 05:59:39 »

I definitely use interfaces in this way. How big are your modules? And how much duplication exists between them? The problem is that if you have 2 modules, and they both use, say the DataGrid component, that component must either be duplicated between the modules, or reside in the shell.

-=Cliff>
Logged
Justin
Full Member
***
Posts: 24


View Profile Email
« Reply #9 on: April 21, 2009, 08:15:54 »

Very true.  Development planning usually involves some level of cost/benefit analysis for module candidates here. As a result, very little duplication will exist between modules and the shell.  If the candidate does not or will not reduce download or execution time significantly, I'd just assume promote it to the shell and call it good.

Since an empty module has a ~28k overhead by default, I use its compiled size as one way to gauge how much or how little the benefit is for module use.  If the module is 30k, I know the differential is ~2k and the shell will only increase by this amount if it were promoted.  This is probably not a good module candidate.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #10 on: April 21, 2009, 03:50:40 »

Ah, but you're not weighing in the maintainability factor. I agree that load times have a weight in the equation. However, the ability to wrap an entire PureMVC application into a single component walled off by itself from a development standpoint is very valuable.

I'm working on a large MultiCore app right now, where the main app would be way too complicated and cumbersome if all the code were in the same app. I've divided it all into modules, which I don't even load, I instantiate directly. But the beauty is I can put a developer on one of those modules, and their job is WAY simpler than if they had to understand (and possibly break) the big picture while trying to get their part to work. Right now they're all in the same Flex Project, but they can easily be refactored out into a separate project when and if needed.

Another nice part about this approach is that each of the modules can have its own StateMachine. This makes the FSM for the Shell much simpler, as is each Module's FSM. It gives us 'sub-states' without having to make a more complicated StateMachine apparatus.

Also, this is a government app, in the 'sensitive but unclassified' realm. However, some of the modules are innocuous enough that they could possibly be spec'd separately and outsourced. Otherwise developers have to be onsite because all the specs are 'For Official Use Only'.

Another sweet thing about the modular approach is that after doing a removeCore, I can literally null references to a module and it goes away without having to unregister the guts of it. As a property of the Application, I have a Shell Module that instantiates lots of other modules when the user logs in and does stuff. So potentially hundreds of classes are instantiated and in various states when the user logs out. To put them back into a 'fresh' state would require a tremendous amount of code as the project grows, and the possiblity of leaving a reference hanging or not resetting a value in a Proxy somewhere was unthinkable.

After doing a disconnect and logout on the service that uses the same channelset as all the other modules, I successfully wiped out and GC'd the entire works at the App level by doing an 'Indiana Jones/Bag of Sand for the Gold Idol switcharoo'. The Shell Module does a remove core on all the modules, then invokes a method on the App, which in turn wipes out the Shell and replaces it with a new one. And BANG, the entire hierarchy is replaced. The profiler shows complete reclamation of memory.

Modules have a LOT more going for them than just potential to reduce initial application load time.

-=Cliff>
« Last Edit: April 21, 2009, 03:55:34 by puremvc » Logged
Justin
Full Member
***
Posts: 24


View Profile Email
« Reply #11 on: April 21, 2009, 08:49:22 »

Truth be told, I started as a self taught hobbyist and have only been working professionally for less than a year.  I'd like to think I have a pretty good grasp on OOP and Flex for that matter but I love being reminded daily that there are people out there that can run circles around me. 

Just to clarify, by 'promote' I mean compiling them directly at the shell level versus loading them externally.  To me a true module is compiled separately, loaded externally and then instantiated.

 I like your idea of a command module that acts as a hub of sorts, hit the reset and the active connections are severed.  The delegation of tasks to dev's on a particular module is the moneyshot.  All they have to know is the UX/UI, the data it should consume and the data it should spit out, the rest is irrelevant. 

I'd like to get a download from you on this idea in a little greater detail sometime.  I have a project that is just starting that can benefit from your technique.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #12 on: April 22, 2009, 07:34:29 »

'...the moneyshot', that's it. Everyone wants to be able to outsource but when it comes right down to it if you can't modularize properly you're going to have a rough time pulling it off effectively.

-=Cliff> 
Logged
Pages: [1]
Print