topleft

PureMVC

larger smaller reset larger Futurescale, Inc.
  • fixed-width
  • fluid-width
  • Home
  • About
  • Code
  • Docs
  • FAQ
  • Forums
  • News
  • Showcase
  • Contact
  • Jobs
topright
Utility_AS3_MultiCore_Pipes
  • Login
  • Help/Guide
  • About Trac
  • Preferences
  • Wiki
  • Browse Source

Context Navigation

  • Start Page
  • Index
  • History
  • Last Change

TracNav

  •  PureMVC Manifold...

  •  Contributors
  •  Repositories
  • Ports...

  •  ActionScript 2
  •  ActionScript 3
  •  C #
  •  ColdFusion
  •  Haxe
  •  Java
  •  JavaScript
  •  Objective C
  •  PHP
  •  Python
  •  Ruby
  •  Propose a Port

TracNav

  • AS3 MultiCore : Pipes...

  • Downloads
  • Installation
  • Release Notes
  •  View Source
  •  API Docs
  •  Discussion
  •  Unit Tests
  • Project Owner...

  •  Cliff Hall
  • Tutorials...

  •  Understanding Pipes
  • Demos...

  • Flex...

  •  PipeWorks

Utility - AS3 / Pipes

This utility provides the capability for creating pipelines that pass messages between Cores in a PureMVC AS3 MultiCore-based application. Pipelines can contain filters, queues, splitting and merging tees, and more.

Changes in Version 1.1

  • Added disconnectFitting method to TeeSplit. This allows you to pass in a reference to the specific output fitting to be removed from the TeeSplit's outputs array.
  • Cosmetic change to constant values in FilterControlMessage.

Features in Version 1.0

Modular programming is a wonderful way to separate your code, even beyond the separation of concerns the MVC pattern lends. It allows extreme separation of code into discrete applications all running blissfully unaware of each others' presence in the same VM.

But in order for these discrete Modules to collaborate and act like a single application, they need to talk to each other somehow. The  Modularity demo shows two Flex Modules, instantiated by an application. The Modules are given a reference to a 'Shell' object in the application and are allowed to talk to the app through the interface it exposes. The Modules also implement an interface that the application Shell talks to. In the demo, the Modules and Shell communicate, but the Modules don't talk to each other at all. They could be given references to each other, and talk over an interface as well, but that is still more tightly coupled than many would like.

Sending Notifications between modules would require that they share a Facade, and or a methodology for keeping their Notification namespaces from colliding, which could be difficult if third-party vendors may be writing some of the modules.

No sub-classing is necessary at all to use the utility! All of the classes work completely out of box, just like the pipe fittings you'd buy at a hardware store :)

Essentially you connect fittings together into a pipeline and send messages down it. One nifty bit is that messages can be normal data messages or control messages. Control messages allow you to send control information to the more intelligent pipe fittings, Filter and Queue.

The Interfaces:

  • IPipeFitting - An IPipeFitting can be connected to other IPipeFittings, forming a Pipeline. IPipeMessages are written to one end of a Pipeline by some client code. The messages are then transfered in synchronous fashion from one fitting to the next.
  • IPipeMessage - IPipeMessages are objects written into a Pipeline, composed of IPipeFittings. The message is passed from one fitting to the next in syncrhonous fashion. Depending on type, messages may be handled differently by the fittings.

The Plumbing:

  • Pipe - This is the most basic IPipeFitting, simply allowing the connection of an output fitting and writing of a message to that output.
  • TeeSplit - Writes input messages to multiple output pipe fittings.
  • TeeMerge - Writes the messages from multiple input pipelines into a single output pipe fitting.
  • Filter - Filters may modify the contents of messages before writing them to their output pipe fitting. They may also have their parameters and filter function passed to them by control message, as well as having their Bypass/Filter operation mode toggled via control message.
  • Queue - The Queue always stores inbound messages until you send it a FLUSH control message, at which point it writes its buffer to the output pipe fitting. The Queue can be sent a SORT control message to go into sort-by-priority mode or a FIFO control message to cancel sort mode and return the default mode of operation, FIFO. NOTE: There can effectively be only one Queue on a given pipeline, since the first Queue acts on any queue control message. Multiple queues in one pipeline are of dubious use, and so having to name them would make their operation more complex than need be.
  • PipeListener - Allows a class that does not implement IPipeFitting to be the final recipient of the messages in a pipeline.
  • Junction - Manages Pipes for a Module. When you register a Pipe with a Junction, it is declared as being an INPUT pipe or an OUTPUT pipe. You can retrieve or remove a registered Pipe by name, check to see if a Pipe with a given name exists,or if it exists AND is an INPUT or an OUTPUT Pipe. You can send an IPipeMessage on a named INPUT Pipe or add a PipeListener to registered INPUT Pipe.

Download in other formats:

  • Plain Text

Trac Powered

Powered by Trac 0.11.6
By Edgewall Software.

Powered by the Subversion, Trac & Bugzilla Hosting Experts, Codesion.com

Copyright © 2006-2008 Futurescale, Inc.