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: Will Fabrication be rolled into Multicore and Pipes as default?  (Read 14925 times)
arisco97
Jr. Member
**
Posts: 14


View Profile Email
« on: June 12, 2009, 02:21:43 »

I see Fabrication stream on Google. I am wondering why this is not in PureMVC home page?  Thank you.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: June 14, 2009, 08:28:55 »

Fabrication is a framework unto itself which utilizes PureMVC, but is managed by its own development team and grows at a pace that makes it difficult to fit into the way the rest of PureMVC.org is managed. In order to maintain a semblance of order on the site, (and because setting up all the permissions is a nightmare) I approve and tag releases and manage the wiki. This works for demos or utilities that rarely change, but makes me a bottleneck to progress on something as large as Fabrication.

And to answer your question; no, Fabrication will not be incorporated MultiCore and Pipes in the future. The goal with PureMVC in general is to have the framework be as small and simple as possible, bugfixed to maturity and left alone. It is extended with utilities (like Pipes). This keeps the framework from being a moving target under continuous development.

Don't you hate having to continuously upgrade software that already works because someone at the lab kept feeding the creepy feature creature? I know I do. Eventually software gets to a point where you're using 20% of the features and living with the 80% bloat that you're forced to accept to get those features.

Don't get me wrong, I'm not casting aspersions on Fabrication. It's just that there is an onion-skin hierarchy of developer needs to consider here:

MultiCore works. You can create a Flex Module (or Flash SWF) with its own Core, and just instantiate the thing in your application treating it like a custom view component. This just lets you have two PureMVC cores running without stepping on each other's toes. They don't even have to communicate with each other in any special way, you can just use events and expose methods.

You don't have to deal with Pipes unless you want them. Only once you find the need to communicate back and forth without having references and invoking methods or sending events do you even need to consider it.

MultiCore and Pipes work great together, (yes, I planned it that way :) and you can plumb them easily in a short Command. If you only have 2 or 3 modules, this may be the easiest, most lightweight way to go.

However, if you've got 50 modules, dynamically created and destroyed at runtime with complex communication networks to establish between them, then you might desire a framework on top of MultiCore and Pipes to help with the plumbing. That's where Fabrication comes in. It has loads of helpful functionality for helping you do this easily, but if you don't have this level of need, then it's 72k added to your app that you could easily do without.

-=Cliff>

Logged
Gilbi
Full Member
***
Posts: 22


View Profile Email
« Reply #2 on: June 14, 2009, 04:38:18 »

Where are you getting 72k from? In my experience fabrication is extremely light-weight. I'm working on a template which is a little heavier than the FlashDevelop template I recently posted to the Fabrication forum, and the compiled shell is only 33k. That 33k includes PureMVC MultiCore, Pipes, Fabrication, Asual's SWFAddress, and Digizex CMS.

I think that the fabrication flex-specific classes might import some heavy-duty stuff. But if you're working in Flex you've already opened that can of worms.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: June 15, 2009, 05:18:57 »

72k is the current size of the swc on Google code.

-=Cliff>
Logged
Gilbi
Full Member
***
Posts: 22


View Profile Email
« Reply #4 on: June 15, 2009, 08:10:15 »

Ok, that makes sense. Loading SWC's at runtime is a bad idea, so the size of the SWC shouldn't be a factor in deciding whether or not to use Fabrication.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: June 15, 2009, 10:06:53 »

I didn't say anything about loading the swc at runtime. And of course, the entire swc isn't necessarily baked into your app, only the classes you use from it. But that's just quibbling.

The whole point of my original response is: Fabrication is a layer that not everyone needs, and that's why it's not slated to become an integral part of MultiCore itself. In fact that's the reason Pipes is a separate utility and not just part of MultiCore. You don't actually need Pipes to use MultiCore, either.

-=Cliff>
Logged
Gilbi
Full Member
***
Posts: 22


View Profile Email
« Reply #6 on: June 15, 2009, 10:47:05 »

Ok, ok, I'm not trying to quibble, I swear. It just worried me that your comment would be misinterpreted by new users browsing these boards. They might come away with, "Cliff says that Fabrication will bloat your app". Of course you didn't say anything like that...

Also, I look it at it kinda differently than you. Even if you don't need to use modules, Fabrication is a lot easier to use than PureMVC on it's own. Furthermore, I believe there is a tipping point where NOT using fabrication will make your app file size bigger (even if you're not using modules). It cuts down on so much boiler-plate that it might actually decrease file size when you reach a certain level of complexity.

BTW -- I agree Fabrication absolutely should not become part of multicore.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: June 15, 2009, 06:39:05 »

True that. There is definitely a level when you need a framework like Fabrication as opposed to brute force workaday plumbing code.

But for those just learning, I suggest beginning with MultiCore alone (no Pipes, no Fabrication), using only Interfaces for communication between Cores. Learn when and how to allow modules to just know each other and communicate with references.

Then add the Pipes utility, learn how and why you'd want to send messages over pipes to begin with, and what pipe fittings are there and what they can do. Understand what is possible, and what it takes to implement it. Learn how to mix and match the two approaches of Pipes and Interfaces; they aren't mutually exclusive.

Then, you'll be ready to fully appreciate what Fabrication can do for you and why and when to use it.

This way when something goes wrong with your app, there aren't so many layers of 'magic' supporting your work that you can't properly use a debugger to figure out what's wrong with it and end up cursing both Darshan and myself for foisting all of our fancy abstractions on you! :)

-=Cliff>
Logged
arisco97
Jr. Member
**
Posts: 14


View Profile Email
« Reply #8 on: June 17, 2009, 10:50:27 »

Cliff, I am an ardent fan of singlecore, and I continuosly insist my team to go through the first pains of learning and I have to say it is a success story for me. I hope singlecore continuous to benefit from the focus on multicore. I feel singlecore appeals to small apps, and multicore w/pipes as it is now appeals to complex apps and is just harder to sell to developers for small apps.

I may be caused more grief than expected when I asked for accommodating Fabrication. My intention (poorly communicated) is to understand if key features such as reflection and the notion of notification would be extended to pipes to reduce the boiler plate without the need for using fabrication?

Thanks for your explanation and I understand and appreciate your clear direction on change management. PureMvc works.
Logged
Pages: [1]
Print