Classes

A Singleton IController implementation.

In PureMVC, the Controller class follows the ‘Command and Controller’ strategy, and assumes these responsibilities:

• Remembering which ICommands are intended to handle which INotifications.
• Registering itself as an IObserver with the View for each INotification that it has an ICommand mapping for.
• Creating a new instance of the proper ICommand to handle a given INotification when notified by the View.
• Calling the ICommand‘s execute method, passing in the INotification.

Your application must register ICommands with the Controller.

The simplest way is to subclass Facade, and use its initializeController method to add your registrations.

@see org.puremvc.swift.core.view.View View

@see org.puremvc.swift.patterns.observer.Observer Observer

@see org.puremvc.swift.patterns.observer.Notification Notification

@see org.puremvc.swift.patterns.command.SimpleCommand SimpleCommand

@see org.puremvc.swift.patterns.command.MacroCommand MacroCommand

See more

open class Controller : IController

A Singleton IModel implementation.

In PureMVC, the Model class provides access to model objects (Proxies) by named lookup.

The Model assumes these responsibilities:

• Maintain a cache of IProxy instances.
• Provide methods for registering, retrieving, and removing IProxy instances.

Your application must register IProxy instances with the Model. Typically, you use an ICommand to create and register IProxy instances once the Facade has initialized the Core actors.

@see org.puremvc.swift.patterns.proxy.Proxy Proxy

@see org.puremvc.swift.interfaces.IProxy IProxy

See more

open class Model : IModel

A Singleton IView implementation.

In PureMVC, the View class assumes these responsibilities:

• Maintain a cache of IMediator instances.
• Provide methods for registering, retrieving, and removing IMediators.
• Notifiying IMediators when they are registered or removed.
• Managing the observer lists for each INotification in the application.
• Providing a method for attaching IObservers to an INotification‘s observer list.
• Providing a method for broadcasting an INotification.
• Notifying the IObservers of a given INotification when it broadcast.

@see org.puremvc.swift.patterns.mediator.Mediator Mediator

@see org.puremvc.swift.patterns.observer.Observer Observer

@see org.puremvc.swift.patterns.observer.Notification Notification

See more

open class View : IView

A base ICommand implementation that executes other ICommands.

A MacroCommand maintains an list of ICommand Class references called SubCommands.

When execute is called, the MacroCommand retrieves ICommands by executing closures and then calls execute on each of its SubCommands turn. Each SubCommand will be passed a reference to the original INotification that was passed to the MacroCommand‘s execute method.

Unlike SimpleCommand, your subclass should not override execute, but instead, should override the initializeMacroCommand method, calling addSubCommand once for each SubCommand to be executed.

@see org.puremvc.swift.core.controller.Controller Controller

@see org.puremvc.swift.patterns.observer.Notification Notification

@see org.puremvc.swift.patterns.command.SimpleCommand SimpleCommand

See more

open class MacroCommand : Notifier, ICommand

A base ICommand implementation.

Your subclass should override the execute method where your business logic will handle the INotification.

@see org.puremvc.swift.core.controller.Controller Controller

@see org.puremvc.swift.patterns.observer.Notification Notification

@see org.puremvc.swift.patterns.command.MacroCommand MacroCommand

See more

open class SimpleCommand : Notifier, ICommand

A base Multiton IFacade implementation.

@see org.puremvc.swift.core.model.Model Model

@see org.puremvc.swift.core.view.View View

@see org.puremvc.swift.core.controller.Controller Controller

@see org.puremvc.swift.patterns.observer.Notification Notification

@see org.puremvc.swift.patterns.mediator.Mediator Mediator

@see org.puremvc.swift.patterns.proxy.Proxy Proxy

@see org.puremvc.swift.patterns.command.SimpleCommand SimpleCommand

@see org.puremvc.swift.patterns.command.MacroCommand MacroCommand

See more

open class Facade : IFacade

A base IMediator implementation.

`@see org.puremvc.swift.core.View View

See more

open class Mediator : Notifier, IMediator

A base INotification implementation.

PureMVC does not rely upon underlying event models such as the one provided with Flash, and ActionScript 3 does not have an inherent event model.

The Observer Pattern as implemented within PureMVC exists to support event-driven communication between the application and the actors of the MVC triad.

Notifications are not meant to be a replacement for Events in Flex/Flash/Apollo. Generally, IMediator implementors place event listeners on their view components, which they then handle in the usual way. This may lead to the broadcast of Notifications to trigger ICommands or to communicate with other IMediators. IProxy and ICommand instances communicate with each other and IMediators by broadcasting INotifications.

A key difference between Flash Events and PureMVC Notifications is that Events follow the ‘Chain of Responsibility’ pattern, ‘bubbling’ up the display hierarchy until some parent component handles the Event, while PureMVC Notifications follow a ‘Publish/Subscribe’ pattern. PureMVC classes need not be related to each other in a parent/child relationship in order to communicate with one another using Notifications.

@see org.puremvc.swift.patterns.observer.Observer Observer *

See more

open class Notification : INotification

A Base INotifier implementation.

MacroCommand, Command, Mediator and Proxy all have a need to send Notifications.

The INotifier interface provides a common method called sendNotification that relieves implementation code of the necessity to actually construct Notifications.

The Notifier class, which all of the above mentioned classes extend, provides an initialized reference to the Facade Singleton, which is required for the convienience method for sending Notifications, but also eases implementation as these classes have frequent Facade interactions and usually require access to the facade anyway.

@see org.puremvc.swift.patterns.facade.Facade Facade

@see org.puremvc.swift.patterns.mediator.Mediator Mediator

@see org.puremvc.swift.patterns.proxy.Proxy Proxy

@see org.puremvc.swift.patterns.command.SimpleCommand SimpleCommand

@see org.puremvc.swift.patterns.command.MacroCommand MacroCommand

See more

open class Notifier : INotifier

A base IObserver implementation.

An Observer is an object that encapsulates information about an interested object with a method that should be called when a particular INotification is broadcast.

In PureMVC, the Observer class assumes these responsibilities:

• Encapsulate the notification (callback) method of the interested object.
• Encapsulate the notification context (this) of the interested object.
• Provide methods for setting the notification method and context.
• Provide a method for notifying the interested object.

@see org.puremvc.swift.core.view.View View

@see org.puremvc.swift.patterns.observer.Notification Notification

See more

open class Observer : IObserver

A base IProxy implementation.

In PureMVC, Proxy classes are used to manage parts of the application’s data model.

A Proxy might simply manage a reference to a local data object, in which case interacting with it might involve setting and getting of its data in synchronous fashion.

Proxy classes are also used to encapsulate the application’s interaction with remote services to save or retrieve data, in which case, we adopt an asyncronous idiom; setting data (or calling a method) on the Proxy and listening for a Notification to be sent when the Proxy has retrieved the data from the service.

@see org.puremvc.swift.core.model.Model Model

See more

open class Proxy : Notifier, IProxy