The JDA spceification is not very hard to grasp, due to the fact that it is small and does just a few things in an elegant fashion. Those thigns are by the way;
1) A standard way of wrapping generic components html, with clear references to unique id and implementation (javascript).
2) A standard way of setting properties which are read (again, in the most simple manner) by the components when they are intialized.
3) A standard way of passing messages between components, describing input and output terminals for the compoennts and allowing simple "wiring" of one compoennt to another in the html definition (1) above.
That's it! It's a small messaging microkernel for javascript (and possible for anything, since we can abstract Ajax calls in a truly Height-Ashbury kind of way) components.
Because of this elegance, I was truly stumbled when I tried to implement the is_proxy feature in JDA. If an element which defines an infotron has the attribute is_proxy="true", it means that it wraps an achor element (a which is a reference to the remote service which is being proxied (By an ajax call, most probably).
So, the whole shebang looks like this (example from the MAYA JDA foundry);
impl="~011A83EC1CBFAD4a3188344C9BA816DE73"
script="../extras.beta/JsonCallback.js"
properties="'encoding' : 'uri-form',
'uri_suffix':'&url=http://del.icio.us/rss/'"
is_proxy="true"
connections="'response_out' :[['rss_box1','list_in']]">
1) A standard way of wrapping generic components html, with clear references to unique id and implementation (javascript).
2) A standard way of setting properties which are read (again, in the most simple manner) by the components when they are intialized.
3) A standard way of passing messages between components, describing input and output terminals for the compoennts and allowing simple "wiring" of one compoennt to another in the html definition (1) above.
That's it! It's a small messaging microkernel for javascript (and possible for anything, since we can abstract Ajax calls in a truly Height-Ashbury kind of way) components.
Because of this elegance, I was truly stumbled when I tried to implement the is_proxy feature in JDA. If an element which defines an infotron has the attribute is_proxy="true", it means that it wraps an achor element (a which is a reference to the remote service which is being proxied (By an ajax call, most probably).
So, the whole shebang looks like this (example from the MAYA JDA foundry);
impl="~011A83EC1CBFAD4a3188344C9BA816DE73"
script="../extras.beta/JsonCallback.js"
properties="'encoding' : 'uri-form',
'uri_suffix':'&url=http://del.icio.us/rss/'"
is_proxy="true"
connections="'response_out' :[['rss_box1','list_in']]">
OK, so we have an infotron called "delicious", which in reality is an Ajax proxu (it's called JsonCallback). The proeprties given to it gives us hints that it can handle several types of encodings, and is flexible as to how to append arguments to the service it is calling.
So far so good, but I had a great headache when implementing my BaStar(d) implementation of JDA, because I tried to generate an infotrion in one pass, from scratch with information from both the is_proxy infotron and the enclosed anchor tag.
In reality, things were much more simple.
An infotron gets a reference to the DOM node wher it is defined. If declared in the Blueprint (the .js file implementaion of the infotron), the _onInit() function gets called whenthe infotron gets created (and the _onStartUp() gets called just before first message is passed).
That means that the most simple way to create a proxy is to not do anything at all. In teh microkernal code, that is. The JsonCallback.js of course searches for the first anchor tag childNode under its own node when initialized, and collects service url and other info from it. Case closed.
So, today lesson is to never, ever twist things around. Even if you manage getting both legs in one trouser-leg, it doesn't mean you've done the right thing :)
Comments