When I ported PureMVC over to Dojo I could not pass up the chance to port over the the Pipes utility as well. I initially created a Dojo-flavored version, but since the main Javascript distribution of PureMVC is framework independent, I figured that Pipes should be as well.
For those who are unfamiliar with Pipes, it is basically a way to create multiple PureMVC applications, each with its own core, so that they can be loaded and unloaded as modules within a main application or shell. It can get a little confusing and may appear to be overkill at first glance, but I think the end result proves to be worth the effort.
I posted the native version here. I also created a variation that uses the puremvc.define function to create a more clearly defined OO structure. I really like that approach better but the first version mimics the coding style found in the currently supported PureMVC Javascript implementation.
I also created a demo based on Tekool’s AS3 Pipes Demo:
- Demo [native version]
- Demo [puremvc.define version]
*they are identical in appearance and behavior
UPDATE: Here is a zip file containing the source for both demos. It is a tad large since it has a few binaries and dojo src libs (for the dojo version only of course).
If you are looking to learn more about Pipes, check out the following links which cover the conceptual use of Pipes, albeit in a Actionscript/Flex format.
- Tekool – Flex modules with PureMVC Pipes Simple Demo
- Joel Hooks – Piping the Machine
- Joshua Ostrom – Understanding PureMVC Pipes
- Jens Krause – A basic PureMVC MultiCore AS3 Example
(Update: I had to change the reference from Shell.js to Shelll.js because wordpress seems to think that any file named Shell.js is dangerous and blocks access to it which was breaking the demo. I updated both html pages with Shelll which points to Shelll.js to make it work)
Impressive job Bill! You not only ported the Pipes to JavaScript and mainly ported the demo which asks a good amount of work.
This is a good thing you made it, because, when the PureMVC port of choice changed from PureMVC+Objs to PureMVC+ObjectKit from David Foley everyone proposed to make it, but finally nobody did it.
I do not have time right now, but will have a look in what you did in your variation too this we-e.
Thanks a lot for this job, it’s possible I may need it soon.
Glad to help out. Let me know if there is anything you find that I can improve. I used your PureMVC Pipes demos a lot when I was doing the conversion so you really helped me out! 🙂
Hi Bill,
Great work. If you’re ok with it, I’ll put this in an official PureMVC repo.
-=Cliff>
Yes! I’m thrilled that you guys are able to make use of this.
BTW, our stuff there is now BSD 3-Clause. Does that work for you?
Absolutely. Whatever you need to do to get make use of it is fine by me.
Bill,
Hi again. Over the last few weeks I’ve been working to get a version of Pipes ready that will be the officially supported version. I’ve got a way to go, but thought it would be good to report some status here and heads up’s for anyone getting started now using the code in your repo.
First off, wow, I can’t believe you did three versions in all. An excellent exercise to be sure.
Between the two choices that don’t have dependencies, I started with the puremvc.define() version, but quickly discovered that jsDuck, the documentation generator, doesn’t follow PureMVC’s hierarchy. So for an app where you may only have docs for internal purposes as developers read the code, then using puremvc.define() is still totally fine. But in a library where you’re generating API docs that developers need in reference form, then we’re best sticking to pure JS prototype-style.
So, I moved to the native JS version and have been working to get the documentation completed, and fixing bugs along the way. With a library, it’s important to have unit tests, so I’ll be porting those over afterward.
Another thing I’ve been doing is refactoring the namespace. We decided to do this in the framework itself – instead of the standard org.puremvc.js.multicore.** namespace we flattened it to puremvc.* with all actors residing there.
This makes references to framework actors less obtuse and annoying. Since we’ve already staked our territory with a node in the global space, I think it makes sense to put all utilities into child nodes underneath puremvc.
So I’m moving org.puremvc.js.multicore.utilities.pipes.** to puremvc.pipes.*
That sounds great. I was not sure which way (puremvc.define/native) was best which is why I created all three versions in order to better understand all the different aspects involved. It was a bit of extra work, but it really helped me learn along the way. Also, it is good to know about the doc generation issue with using puremvc.define(). Let me know if there is anything else I can do to help.:)