PureMVC Architects Lounge

Which is better?
Pipes or Fabrication?
or is the Fabrication utitility a manager of the pipes utility that is easier to use?
Is there any loss of functionality or downside of Fabrication vs straight Pipes?

nevermind, i found the information i was looking for, thanks.

Hey don't be greedy! Share what you found with the rest of us that don't really much about it! :)

Sorry.  I just found other posts on this forum regarding fabrication.

http://forums.puremvc.org/index.php?topic=681.0 (http://forums.puremvc.org/index.php?topic=681.0)

http://www.codedrunks.com/index.php/2008/09/12/fabrication-simplified-puremvc-multicore-modules/ (http://www.codedrunks.com/index.php/2008/09/12/fabrication-simplified-puremvc-multicore-modules/)

Fabrication does indeed look very attractive but it comes at a price. be aware that the whole utility is more than 500Kb. I guess that depending on what feature you use the size will differ but certainly some thing to keep in mind.

S

@quinrou, sorry to jump into this thread. I would like to clarify this, Not sure how you got to 500kb. The entire fabrication swc is around 70kb, the framework can't be bigger than that ;-). And depending on whether you are using flash or flex and which parts you use the footprint will be smaller. For instance this example (http://fabrication.googlecode.com/svn/examples/typing_undo/bin/index.html) is around 30 kb including 10kb of PureMVC itself.

peace,
darshan

Fabrication is a third party framework that builds on MultiCore and Pipes for solving the plumbing problem. That is, you have to plumb the cores together in some fashion so they can send messages to each other.

-=Cliff>

Hi Cliff and Darshan,

I use the presence of you both in this Thread to ask a question, that came in my mind today.

1. I'm I right, that there must be names for each pipe?
2. I'm I right, that the receiving part must know, what type of Message comes there, or what is in the NoteBody?
3. Isn't it much simpler to add an Interface to a SubClass of Facade like 'IGlobalBroadcaster', with something like this:

public function sendGlobalNotification(notificationName : String,
    body : Object = null, type : String = null) : void {

  for each(var facade : IFacade in instanceMap) {
    facade.sendNotification(notificationName, body, type);
  }
}

All cores would get the message, but the payload is much lower, because the observerMap in View has no such noteName and therefore nothing happens in a core, that does not know the noteName.

In both cases you need an API from the module, I think, but this would be much more efficient.

I searched the forum an the internet, but nothing could anwser this question.

Maybe you can.

Thanks for replying.

Marcy

Hey Marcy,

This sounds like a good idea to me. In my current implementation I am maintaining hash maps by module address and groups. So something like module-to-module notification with/out groups go directly to each other without loops.

Your idea is fairly clean way of doing things using existing information about cores. I will look into incorporating some of this into future versions once I get into optimization mode towards 1.0.

peace,
darshan

This is one of the reasons the Pipes was built. You should not send notifications to the other cores because they are merely strings.

The most limiting use case for intercore communication sets the best practice here and that is the case where you have one or more third party modules in your system.

You don't know what notification constants have been defined inside that module, and what's more you can't reference those constants so you must send in a string or a constant you've defined.

With PipeMessages its far easier to define and implement a protocol of what message classes will show up in a core and what data they will carry without stepping on any notification name constants or having to redefine them in every module.

-=Cliff>

Yes, i agree,

i thounght about this, this morning, and came up with the following thoughts:

- If the Notes are known, all notes could be send to a module. There is no filtering and internal notes, that where send from external, could damage the module at runtime.

-> So I would need another methond (receiveGlobalMessage) for filtering, and then use a mediator to listen to the wanted note. So I am back to JunctionMediators.

I wanted to keep it simple, but the mechanics of pipes should bring all the things I need.

Fabrication is a cool attempt, but far to big. Would be better, if single features would be seperated. Like the Pipes Handling. :)

Thanks for your input.

Greeting from Leipzig, Germany.

Marcy

I have built another framework that handles module configuation and plumbing and a ton of other stuff last year for a company called Lila (http://lila.io) they are building their flagship product on it and plan to release the framework in some form (at least as a library if not open source), but its not on their critical path at the moment.

-=Cliff>