

Dojo how to: publish / subscribe - naelshawwa
http://elshawwa.blogspot.com/2010/07/dojo-pubsub-geo-location-google-maps.html

======
kls
You know this is a simple but powerful feature. It breaks the mentality of
tight function binding and allows you to develop applications in a more
broadcast / listen for broadcast manner.

This is extremely powerful in the context of UI development because it breaks
the concepts of a controller in the MVC anti-pattern that is responsible for
so much spaghetti code. It promotes loose coupling among components so that
they can be dropped into a page and auto-wire themselves into the ecosystem
that is the page.

For example one can write a edit account widget that upon completion,
broadcasts an updated account object. Any widgets on the page that display
account information or that do processing on an account can subscribe to the
account updated publication and receive the new object or data set. Further a
web service service client can be wired to listen for it and publish the
information back to a server in which the server can syndicate it to other
clients.

The beauty of this style development is: yank out the edit account widget and
nothing happens. Due to the loose coupling components can be added and removed
with 100% certainty of no side effects to peripheral components.

Further, done correctly it eliminates the need for the concept of a
controller, widgets become self encapsulated entities, service calls become
self encapsulated routines, each and every routine has a clear entry and exit,
with no coupling to other code. Thereby making adding new features and
debugging drop deal simple.

~~~
BonoboBoner
I generally agree, but publish/subscribe can also lead to a spaghetti of
messages. In big apps you can get so many messages you start to lose the big
picture and can no longer tell "who calls what? what is the sequence of
control flow? etc" It is a great model, but as anything is, it is not a
silverbullet.

~~~
kls
Right, which is why I framed it in the context of UI development. A good deal
of UI apps are not a deep but broad problem set. Generally there is not great
depth of chaining to the point that you need deep stack logic or techniques.
For many web apps it is simple format/display and update data. Even deep apps
(for web apps) like mapping or trader applications are simply variations on
this theme. In that context it is the closest thing to a silver bullet we have
to building rapid and extensible UI's while maintaining quality controls.

~~~
naelshawwa
Exactly. This style suits the UI very well because of te nature of it. At the
end, the UI responds to events whether they are user driven or system driven
ex. Notifications. One of my favorites is the ability for the UI to degrade
gracefully even if a component has been removed because nothing calls it
directly, just publishes to it.

