HTML and CSS Reference
In-Depth Information
Figure 4.9. By using the same model (the plan held by the planner object) in the browser and on the server, the
business logic (the methods in the planner object) can be the same in both places.
Figure4.10 shows the architecture of the application on the server and in two identical con-
nected clients. As you can see, the structure on both client and server is similar. As each
user makes changes, the same methods get fired on their local copy of the planner object as
will be fired on the server planner object and on the planner objects used by other clients
as the messages are passed between them using WebSockets.
Figure 4.10. Planner application architecture following through from User events in Client A: Events are
generated by the client and update the local plan; an orchestrator monitors the plan and sends those updates
through a WebSocket to the server. An orchestrator on the server updates the server planner object; then those
updates are sent out via other WebSockets to the other connected clients, culminating in the UI of the other clients
being updated.
Your model (the object containing the plan) will make use of the events framework,
EventEmitter.js, as mentioned in the prerequisites. This is a browser-compatible version of
the events module that comes as standard with Node. As methods are called on the model
object, events will be fired. You'll then attach listeners to those events; when the model is
run in the browser, those events will update the UI and send the changes back to the server.
When the model is run on the server, those events will update all the other connected cli-
ents. The following listing shows the basic outline of the object you'll be using to store the
plan, including some types and some utility functions. Add it to a file called planner.js. In
the next listing you'll add some functionality.
Search WWH ::

Custom Search