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.
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.
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.
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.
4 comments
[ 3.1 ms ] story [ 19.2 ms ] threadThis 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.