I joked with a colleague a couple of months ago that one should create a microkernel for javascript. We had a laugh about that since the most of the problems that you solve by using a microkernel for Java simply doesn't exist in Javascript to begin with.
I made a coffee-stain vaugely shaped like Brendan Eich when I saw the news on Ajaxian that some guys over at MAYA Design Inc. had made just that, called JDA for Javascript Dataflow Acrhitecture.
One of the reasons for using, for instance, Spring when developing in Java, is that you use an external XML file which 'wires' together your various components, thereby forcing you to implement good separation of concerns and all that.
That's great, if you like XML which I really, really don't. I also doesn't like having yeat anotehr file outside of the source to massage and forget to modify properly.
JDA on the other hand wires together the javascript modules in the most natural file possible - the HTML page itself. OK, no big deal you might think. Think on this for a while;
This is an example of defining a small module inside a page. The name used for this is unfortunatly "Infotron". I've lived for it for over a week, and it's reluctantly beginning to sink in :).
Each infotron has an id, which is used both as DOM id for the element where the infotron resides and for the infotron itself. Then the impl tag defines which blueprint (javascript 'class') which handles messages to it. This means that you can define a blueprint once (not shown here) and reuse it several times in the page, by different infotrons.
Each infotron has a set of input terminals and a set of output terminals. They get defined in the blueprint, but are wired in the infotron definition, in the connections attribute. In the above example it conencts the output terminal 'state1_out' with the input terminal called 'city_in' in the other infotron with id 'rent_list_services
I made a coffee-stain vaugely shaped like Brendan Eich when I saw the news on Ajaxian that some guys over at MAYA Design Inc. had made just that, called JDA for Javascript Dataflow Acrhitecture.
One of the reasons for using, for instance, Spring when developing in Java, is that you use an external XML file which 'wires' together your various components, thereby forcing you to implement good separation of concerns and all that.
That's great, if you like XML which I really, really don't. I also doesn't like having yeat anotehr file outside of the source to massage and forget to modify properly.
JDA on the other hand wires together the javascript modules in the most natural file possible - the HTML page itself. OK, no big deal you might think. Think on this for a while;
less-than div id="state_machine"
impl="~01ac50bf2c623911dbaf41492c4db07a70"
connections="state1_out:[['rent_list_service', 'city_in']]"
script="_j/1/extras/StateMachine.js" greater-than
less-than /div greater-than
impl="~01ac50bf2c623911dbaf41492c4db07a70"
connections="state1_out:[['rent_list_service', 'city_in']]"
script="_j/1/extras/StateMachine.js" greater-than
less-than /div greater-than
This is an example of defining a small module inside a page. The name used for this is unfortunatly "Infotron". I've lived for it for over a week, and it's reluctantly beginning to sink in :).
Each infotron has an id, which is used both as DOM id for the element where the infotron resides and for the infotron itself. Then the impl tag defines which blueprint (javascript 'class') which handles messages to it. This means that you can define a blueprint once (not shown here) and reuse it several times in the page, by different infotrons.
Each infotron has a set of input terminals and a set of output terminals. They get defined in the blueprint, but are wired in the infotron definition, in the connections attribute. In the above example it conencts the output terminal 'state1_out' with the input terminal called 'city_in' in the other infotron with id 'rent_list_services
Comments