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]
Author Topic: Time for Pipes?  (Read 3664 times)
Full Member
Posts: 21

View Profile Email
« on: January 20, 2010, 01:29:17 »

I haven't delved much into the Pipes Utility for being afraid of being overwhelmed.  However, after a small refactor today, I think it may be time to make the plunge.  My application initially showed a data grid with summary data.  When the user clicked on an item the state would change sliding up the grid and showing a tab navigator with tabs showing the details of the selected grid item.  The change I made was to now show the details in a pop-up TitleWindow.  However, I now realize that I want to give the user the ability to work with more than one item at a time and still interact with the main application.  Would this be a scenario where the Pipes utility is relevant?

Thank you
Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #1 on: January 20, 2010, 02:23:23 »

It certainly could be, although it wouldn't be absolutely necessary. The mediator for the TitleWindow can certainly interact with the rest of the system while at the same time having the rest of the system be interactive as well, as long as the popup isn't modal.

But if you're getting to a state where the application is rather huge and it makes sense to put the stuff in that TitleWindow into a module unto itself, then certainly, you could make it a module, plumb it to the shell and set up a message protocol for interacting with it.

So you could go either way here. How to decide? Well, there are a few ways you could benefit from going modular and using pipes. See if any combination of them move you to look into it.

1) You achieve the maximum code-separation possible. To start, the module may still be part of the same project, and you just put it into its own branch of the package space with its own model/view/controller folders, etc. But if need be, you can easily refactor it into a stand-alone project.

2) As a separate project, you can now put an entirely separate team on the module project, or even outsource it. With a carefully spec'd message protocol and strategically shared libraries being the key to success.

3) You can learn from the whole business. Whether this project demands it or not, the learning will help you when you come to one that does. And you'll be more confident the second time around and able to take on more challenging projects.

Of course, separating the code into another project comes with the attendant overhead of multi-project management; you'll want an ant script that builds the modules and places the swfs into an area where the main project can load them.

On http://puremvc.tv there there is a short presentation about MultiCore and Pipes and and one called Getting in the Groove that describes an an actual implementation at http://seaofarrows.com Also, you can see the source code at http://seaofarrows.com/srcview

Pages: [1]