Constructor.
+This Controller
implementation is a Multiton,
+so you should not call the constructor
+directly, but instead call the static Factory method,
+passing the unique key for this instance
+Controller.getInstance(multitonKey)
Protected
commandMapping of Notification names to Command factories
+Protected
multitonThe Multiton Key for this Core
+Protected
Optional
viewLocal reference to View
+Protected
Static
MULTITON_Message Constants
+Protected
Static
instanceMultiton Instances
+If a Command
has previously been registered
+to handle the given Notification
, then it is executed.
The notification containing the data or command details needed for execution.
+Protected
initializeInitialize the Multiton Controller
instance.
Called automatically by the constructor.
+Note that if you are using a subclass of View
+in your application, you should also subclass Controller
+and override the initializeController
method in the
+following way:
// ensure that the Controller is talking to my View implementation
initializeController() {
this.view = MyView.getInstance("ViewTestKey1", (key: string) => new View(key));
}
+
+
+Register a particular Command
class as the handler
+for a particular Notification
.
If an Command
has already been registered to
+handle Notification
s with this name, it is no longer
+used, the new Command
is used instead.
The Observer for the new Command is only created if this the +first time a Command has been registered for this Notification name.
+Static
getController
Multiton Factory method.
The key used to identify the controller instance.
+A factory function that creates a new instance of the controller if one does not already exist for the specified key.
+The controller instance associated with the given key.
+Static
removeA base Multiton Facade
implementation.
Protected
Optional
controllerReference to Controller
+Protected
Optional
modelReference to Model
+Protected
multitonThe Multiton Key for this Core
+Protected
Optional
viewReference to View
+Protected
Static
MULTITON_Message Constants
+Protected
Static
instanceMultiton Instances
+Protected
initializeInitialize the Controller
.
Called by the initializeFacade
method.
+Override this method in your subclass of Facade
+if one or both of the following are true:
Controller
.Commands
to register with the Controller
at startup.`.If you don't want to initialize a different Controller
,
+call super.initializeController()
at the beginning of your
+method, then register Command
s.
Protected
initializeProtected
initializeInitialize the Model
.
Called by the initializeFacade
method.
+Override this method in your subclass of Facade
+if one or both of the following are true:
Model
.Proxy
s to register with the Model that do not
+retrieve a reference to the Facade at construction time.`If you don't want to initialize a different Model
,
+call super.initializeModel()
at the beginning of your
+method, then register Proxy
s.
Note: This method is rarely overridden; in practice you are more
+likely to use a Command
to create and register Proxy
s
+with the Model
, since Proxy
s with mutable data will likely
+need to send Notification
s and thus will likely want to fetch a reference to
+the Facade
during their construction.
Set the Multiton key for this facade instance.
+Not called directly, but instead from the +constructor when getInstance is invoked. +It is necessary to be public in order to +implement Notifier.
+The unique key to identify this instance of the notifier.
+Protected
initializeInitialize the View
.
Called by the initializeFacade
method.
+Override this method in your subclass of Facade
+if one or both of the following are true:
View
.Observers
to register with the View
If you don't want to initialize a different View
,
+call super.initializeView()
at the beginning of your
+method, then register Mediator
instances.
Note: This method is rarely overridden; in practice you are more
+likely to use a Command
to create and register Mediator
s
+with the View
, since Mediator
instances will need to send
+Notification
s and thus will likely want to fetch a reference
+to the Facade
during their construction.
Notify Observer
s.
This method is left public mostly for backward +compatibility, and to allow you to send custom +notification classes using the facade.
+Usually you should just call sendNotification
+and pass the parameters, never having to
+construct the notification yourself.
The notification to be sent to observers.
+Register a Mediator
with the View
.
The mediator instance to be registered.
+Register a Proxy
with the Model
by name.
The proxy instance to be registered.
+Create and send an Notification
.
Keeps us from having to construct new notification +instances in our implementation code.
+The name of the notification to be sent.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+Static
getStatic
hasStatic
removeA base Command
implementation that executes other Command
s.
A MacroCommand
maintains a list of
+Command
Class references called SubCommands
.
When execute
is called, the MacroCommand
+instantiates and calls execute
on each of its SubCommands
turn.
+Each SubCommand
will be passed a reference to the original
+Notification
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.
Constructor.
+You should not need to define a constructor,
+instead, override the initializeMacroCommand
+method.
If your subclass does define a constructor, be
+sure to call super()
.
Protected
multitonThe Multiton Key for this app
+Protected
Static
MULTITON_Message Constants
+Protected
addExecute this MacroCommand
's SubCommands
.
The SubCommands
will be called in First In/First Out (FIFO)
+order.
The notification containing the data or command details to be processed.
+Initialize the MacroCommand
.
In your subclass, override this method to
+initialize the MacroCommand
's SubCommand
+list with Command
class references like
+this:
// Initialize MyMacroCommand
initializeMacroCommand() {
this.addSubCommand(() => new app.FirstCommand());
this.addSubCommand(() => new app.SecondCommand());
this.addSubCommand(() => new app.ThirdCommand());
}
+
+
+Note that SubCommand
s may be any Command
implementor,
+MacroCommand
s or SimpleCommands
are both acceptable.
Initialize this Notifier instance.
+This is how a Notifier gets its multitonKey. +Calls to sendNotification or to access the +facade will fail until after this method +has been called.
+Mediators, Commands or Proxies may override +this method in order to send notifications +or access the Multiton Facade instance as +soon as possible. They CANNOT access the facade +in their constructors, since this method will not +yet have been called.
+the multitonKey for this Notifier to use
+Create and send an Notification
.
Keeps us from having to construct new Notification +instances in our implementation code.
+The name of the notification to be sent.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+A base Mediator
implementation.
Protected
Readonly
_namethe mediator name
+Protected
Optional
_viewThe view component
+Protected
multitonThe Multiton Key for this app
+Protected
Static
MULTITON_Message Constants
+Static
NAMEThe default name for the mediator.
+the mediator name
+The name of the mediator.
+Get the Mediator
's view component.
Additionally, an implicit getter will usually +be defined in the subclass that casts the view +object to a type, like this:
+The view component.
+Set the Mediator
's view component.
The new view component.
+Handle Notification
s.
Typically, this will be handled in a switch statement,
+with one 'case' entry per Notification
+the Mediator
is interested in.
The notification to handle.
+Initialize this Notifier instance.
+This is how a Notifier gets its multitonKey. +Calls to sendNotification or to access the +facade will fail until after this method +has been called.
+Mediators, Commands or Proxies may override +this method in order to send notifications +or access the Multiton Facade instance as +soon as possible. They CANNOT access the facade +in their constructors, since this method will not +yet have been called.
+the multitonKey for this Notifier to use
+Create and send an Notification
.
Keeps us from having to construct new Notification +instances in our implementation code.
+The name of the notification to be sent.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+A Multiton Model
implementation.
In PureMVC, the Model
class provides
+access to model objects (Proxies) by named lookup.
The Model
assumes these responsibilities:
Proxy
instances.Proxy
instances.Your application must register Proxy
instances
+with the Model
. Typically, you use an
+Command
to create and register Proxy
+instances once the Facade
has initialized the Core
+actors.
Protected
multitonThe Multiton Key for this Core
+Protected
proxyMapping of proxyNames to IProxy instances
+Protected
Static
MULTITON_Message Constants
+Protected
Static
instanceMultiton Instances
+Protected
initializeRegister a Proxy
with the Model
.
The proxy instance to be registered.
+Static
getStatic
removeA base Notification
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, Mediator
implementors
+place event listeners on their view components, which they
+then handle in the usual way. This may lead to the broadcast of Notification
s to
+trigger Command
s or to communicate with other Mediators
. Proxy
and Command
+instances communicate with each other and Mediator
s
+by broadcasting Notification
s.
A key difference between Flash Event
s and PureMVC
+Notification
s is that Event
s follow the
+'Chain of Responsibility' pattern, 'bubbling' up the display hierarchy
+until some parent component handles the Event
, while
+PureMVC Notification
s 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 Notification
s.
Notification
+Constructor.
+The name of the notification.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+Get the body of the Notification
instance.
The body of the notification.
+Set the body of the Notification
instance.
The new body to be set for the notification.
+Get the name of the Notification
instance.
The name of the notification.
+Get the type of the Notification
instance.
The type of the notification, or undefined
if not set.
Set the type of the Notification
instance.
The new type to be set for the notification.
+A Base Notifier
implementation.
MacroCommand, Command, Mediator
and Proxy
+all have a need to send Notifications
.
The Notifier
interface provides a common method called
+sendNotification
that relieves implementation code of
+the necessity to actually construct Notifications
.
The Notifier
class, which all the above-mentioned classes
+extend, provides an initialized reference to the Facade
+Multiton, which is required for the convenience method
+for sending Notifications
, but also eases implementation as these
+classes have frequent Facade
interactions and usually require
+access to the facade anyway.
NOTE: In the MultiCore version of the framework, there is one caveat to +notifiers, they cannot send notifications or reach the facade until they +have a valid multitonKey.
+The multitonKey is set:
+Protected
multitonThe Multiton Key for this app
+Protected
Static
MULTITON_Message Constants
+Initialize this Notifier instance.
+This is how a Notifier gets its multitonKey. +Calls to sendNotification or to access the +facade will fail until after this method +has been called.
+Mediators, Commands or Proxies may override +this method in order to send notifications +or access the Multiton Facade instance as +soon as possible. They CANNOT access the facade +in their constructors, since this method will not +yet have been called.
+the multitonKey for this Notifier to use
+Create and send an Notification
.
Keeps us from having to construct new Notification +instances in our implementation code.
+The name of the notification to be sent.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+A base Observer
implementation.
An Observer
is an object that encapsulates information
+about an interested object with a method that should
+be called when a particular Notification
is broadcast.
In PureMVC, the Observer
class assumes these responsibilities:
Observer
+Constructor.
+The notification method on the interested object should take
+one parameter of type Notification
Optional
notify: null | ((notification: INotification) => void)The method to be called when a notification is received. Can be null
.
Optional
context: anyThe context in which to call the notifyMethod
. Can be null
.
Get the notifyContext
+The current context or null
if no context is set.
Set the notification context.
+The context to set. Can be null
.
Get the notification method.
+The current method or null
if no method is set.
Set the notification method.
+The notification method should take one parameter of type Notification
.
The method to set for handling notifications. Can be null
.
Notify the interested object.
+The notification to send to the observer.
+A base Proxy
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 asynchronous 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.
Protected
Optional
_datathe data object
+Protected
Readonly
_namethe proxy name
+Protected
multitonThe Multiton Key for this app
+Protected
Static
MULTITON_Message Constants
+Static
NAMEThe default name for the Proxy.
+Get the data object
+The current data or undefined
if no data is set.
Set the data object
+The data to set. Can be null
.
Get the proxy name
+The name of the proxy.
+Initialize this Notifier instance.
+This is how a Notifier gets its multitonKey. +Calls to sendNotification or to access the +facade will fail until after this method +has been called.
+Mediators, Commands or Proxies may override +this method in order to send notifications +or access the Multiton Facade instance as +soon as possible. They CANNOT access the facade +in their constructors, since this method will not +yet have been called.
+the multitonKey for this Notifier to use
+Create and send an Notification
.
Keeps us from having to construct new Notification +instances in our implementation code.
+The name of the notification to be sent.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+A base Command
implementation.
Your subclass should override the execute
+method where your business logic will handle the Notification
.
Protected
multitonThe Multiton Key for this app
+Protected
Static
MULTITON_Message Constants
+Fulfill the use-case initiated by the given Notification
.
In the Command Pattern, an application use-case typically
+begins with some user action, which results in a Notification
being broadcast, which
+is handled by business logic in the execute
method of an
+Command
.
The notification containing the data or command details to be processed.
+Initialize this Notifier instance.
+This is how a Notifier gets its multitonKey. +Calls to sendNotification or to access the +facade will fail until after this method +has been called.
+Mediators, Commands or Proxies may override +this method in order to send notifications +or access the Multiton Facade instance as +soon as possible. They CANNOT access the facade +in their constructors, since this method will not +yet have been called.
+the multitonKey for this Notifier to use
+Create and send an Notification
.
Keeps us from having to construct new Notification +instances in our implementation code.
+The name of the notification to be sent.
+Optional
body: anyOptional data to be included with the notification.
+Optional
type: stringOptional type of the notification.
+A Multiton View
implementation.
In PureMVC, the View
class assumes these responsibilities:
Mediator
instances.Mediators
.Mediators
when they are registered or removed.Notification
in the application.Observers
to a Notification
's observer list.Notification
.Observers
of a given Notification
when it broadcast.Protected
mediatorMapping of Mediator names to Mediator instances
+Protected
multitonThe Multiton Key for this Core
+Protected
observerMapping of Notification names to Observer lists
+Protected
Static
MULTITON_Message Constants
+Protected
Static
instanceMultiton Instances
+Notify the Observers
for a particular Notification
.
All previously attached Observers
for this Notification
's
+list are notified and are passed a reference to the Notification
in
+the order in which they were registered.
The notification containing the data or command details to be sent to observers.
+Register a Mediator
instance with the View
.
Registers the Mediator
so that it can be retrieved by name,
+and further interrogates the Mediator
for its
+Notification
interests.
If the Mediator
returns any Notification
+names to be notified about, an Observer
is created encapsulating
+the Mediator
instance's handleNotification
method
+and registering it as an Observer
for all Notifications
the
+Mediator
is interested in.
The mediator instance to be registered.
+Register an Observer
to be notified
+of Notifications
with a given name.
The name of the notification to which the observer should be registered.
+The observer instance to be registered.
+Remove the observer for a given notifyContext from an observer list for a given Notification name.
+The name of the notification for which the observer should be removed.
+The context of the observer to be removed.
+Static
getStatic
removePureMVC is a lightweight framework for creating applications based upon the classic Model-View-Controller design meta-pattern. It supports modular programming through the use of Multiton Core actors instead of the Singletons.
+ +npm install @puremvc/puremvc-typescript-multicore-framework
+
+
+Production - Version 2.0.0
+PureMVC MultiCore Framework for TypeScript - Copyright © 2024 Saad Shams
+PureMVC - Copyright © 2024 Futurescale, Inc.
+All rights reserved.
+Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+The interface definition for a PureMVC Command.
+Execute the ICommand
's logic to handle a given INotification
.
The notification carrying the data and type necessary for executing the command.
+Send a INotification
.
Convenience method to prevent having to construct new +notification instances in our implementation code.
+The name of the notification to send.
+Optional
body: anyOptional data associated with the notification.
+Optional
type: stringOptional type of the notification.
+IController
The interface definition for a PureMVC Controller
.
In PureMVC, an IController
implementor
+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
.
IController
+Execute the ICommand
previously registered as the
+handler for INotifications
with the given notification name.
the INotification
to execute the associated ICommand
for
IFacade
The interface definition for a PureMVC Facade
.
The Facade
Pattern suggests providing a single
+class to act as a central point of communication
+for a subsystem.
In PureMVC, the Facade
acts as an interface between
+the core MVC actors (Model
, View
, Controller
) and
+the rest of your application.
IFacade
+Set the Multiton key for this facade instance.
+Not called directly, but instead from the
+constructor when getInstance
is invoked.
+It is necessary to be public in order to
+implement Notifier.
The unique key to initialize the notifier with.
+Notify Observers.
+This method is left public mostly for backward +compatibility, and to allow you to send custom +notification classes using the facade.
+Usually you should just call sendNotification
+and pass the parameters, never having to
+construct the notification yourself.
the INotification
to have the View
notify Observers
of.
Register an IMediator
instance with the View
.
a reference to the IMediator
instance
Register an IProxy
with the Model
by name.
the IProxy to be registered with the Model.
+Create and send an Notification
.
Keeps us from having to construct new notification +instances in our implementation code.
+the INotification
to have the View
notify Observers
of.
Optional
body: anyOptional data to be included in the notification.
+Optional
type: stringOptional type of the notification.
+IMediator
The interface definition for a PureMVC Mediator
.
In PureMVC, IMediator
implementors assume these responsibilities:
Implement a common method which returns a list of all INotifications
the IMediator
has interest in.
Implement a notification callback method.
+Implement methods that are called when the IMediator
is registered or removed from the View.
Additionally, IMediators
typically:
Act as an intermediary between one or more view components such as text boxes or list controls, maintaining references and coordinating their behavior.
+In Flash-based apps, this is often the place where event listeners are added to view components, and their handlers implemented.
+Respond to and generate INotifications
, interacting with of the rest of the PureMVC app.
When an IMediator
is registered with the IView
,
+the IView
will call the IMediator
's
+listNotificationInterests
method. The IMediator
will
+return an Array of INotification
names which
+it wishes to be notified about.
The IView
will then create an Observer
object
+encapsulating that IMediator
's (handleNotification
) method
+and register it as an Observer
for each INotification
name returned by
+listNotificationInterests
.
IMediator
+Readonly
nameThe name of the mediator.
+The view component associated with the mediator.
+Handle an INotification
.
the INotification
to be handled
Send a INotification
.
Convenience method to prevent having to construct new +notification instances in our implementation code.
+The name of the notification to send.
+Optional
body: anyOptional data associated with the notification.
+Optional
type: stringOptional type of the notification.
+IModel
The interface definition for a PureMVC Model
.
In PureMVC, IModel
implementors provide
+access to IProxy
objects by named lookup.
An IModel
assumes these responsibilities:
Maintain a cache of IProxy
instances
Provide methods for registering, retrieving, and removing IProxy
instances
IModel
+Register an IProxy
instance with the Model
.
an object reference to be held by the Model
.
INotification
The interface definition for a PureMVC Notification
.
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/AIR. 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
.
INotification
+INotifier
The interface definition for a PureMVC Notifier
.
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 the above-mentioned classes
+extend, also provides an initialized reference to the Facade
+Multiton, which is required for the convenience method
+for sending Notifications
, but also eases implementation as these
+classes have frequent Facade
interactions and usually require
+access to the facade anyway.
INotifier
+Send a INotification
.
Convenience method to prevent having to construct new +notification instances in our implementation code.
+The name of the notification to send.
+Optional
body: anyOptional data associated with the notification.
+Optional
type: stringOptional type of the notification.
+IObserver
The interface definition for a PureMVC Observer
.
In PureMVC, IObserver
implementors assume these responsibilities:
Encapsulate the notification (callback) method of the interested object.
+Encapsulate the notification context (self) of the interested object.
+Provide methods for setting the interested object notification method and context.
+Provide a method for notifying the interested object.
+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.
An Observer
is an object that encapsulates information
+about an interested object with a notification method that
+should be called when an INotification
is broadcast.
+The Observer then acts as a proxy for notifying the interested object.
Observers can receive Notifications by having their
+notifyObserver
method invoked, passing
+in an object implementing the INotification
interface, such
+as a subclass of Notification
.
IObserver
+Optional
notifyThe context in which the notification method should be called.
+Optional
notifyThe method to be called when a notification is received.
+Notify the interested object.
+the INotification
to pass to the interested object's notification method
IProxy
The interface definition for a PureMVC Proxy
.
In PureMVC, IProxy
implementors assume these responsibilities:
Implement a common method which returns the name of the Proxy.
+Provide methods for setting and getting the data object.
+Additionally, IProxy
ies typically:
Maintain references to one or more pieces of model data.
+Provide methods for manipulating that data.
+Generate INotifications
when their model data changes.
Expose their name as a public static const called NAME
, if they are not instantiated multiple times.
Encapsulate interaction with local or remote services used to fetch and persist model data.
+IProxy
+Optional
dataThe data associated with the proxy.
+Readonly
nameThe name of the proxy.
+Send a INotification
.
Convenience method to prevent having to construct new +notification instances in our implementation code.
+The name of the notification to send.
+Optional
body: anyOptional data associated with the notification.
+Optional
type: stringOptional type of the notification.
+IView
The interface definition for a PureMVC View
.
In PureMVC, the View class assumes these responsibilities:
+Maintain a cache of IMediator
instances.
Provide methods for registering, retrieving, and removing IMediators
.
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 is broadcast.
IView
+Notify the IObservers
for a particular INotification
.
All previously attached IObservers
for this INotification
's
+list are notified and are passed a reference to the INotification
in
+the order in which they were registered.
the INotification
to notify IObservers
of.
Register an IMediator
instance with the View.
Registers the IMediator
so that it can be retrieved by name,
+and further interrogates the IMediator
for its
+INotification
interests.
If the IMediator
returns any INotification
+names to be notified about, an Observer
is created encapsulating
+the IMediator
instance's handleNotification
method
+and registering it as an Observer
for all INotifications
the
+IMediator
is interested in.
The IMediator
to be registered.
Register an IObserver
to be notified
+of INotifications
with a given name.
The name of the notification to register the observer for.
+The observer to be registered.
+
A Multiton
+Controller
implementation.In PureMVC, the
+Controller
class follows the +'Command and Controller' strategy, and assumes these +responsibilities:+- Remembering which
+- Registering itself as an
+- Creating a new instance of the proper
+- Calling the
+
+Command
s +are intended to handle whichNotifications
.Observer
with +theView
for eachNotification
+that it has aCommand
mapping for.Command
+to handle a givenNotification
when notified by theView
.Command
'sexecute
+method, passing in theNotification
.Your application must register
+Commands
with the +Controller.The simplest way is to subclass
+Facade
, +and use itsinitializeController
method to add your +registrations.See
+- View
+- Observer
+- Notification
+- SimpleCommand
+- MacroCommand
+
+Controller
+