Tuesday, January 30, 2007

OAT hangover and a new JDA demo

Hmm. It seems that OAT have some issues along the same lines as prototype has (i.e. breaks for in loops, et.c.), which makes it practically unusable in the things I'm bulding. Sad. But with some luck they'll fix it, and the compoennts are also a great inspiration. When checking out their tree component, for instance, I was impressed by how they used a lot of simple ul/li elements ina hierarchy instead of something more complex. I'll stay tuned.

Anyway, on the JDA side of the working table, I have a new working demo up and running at mashupstation, together with a lot of explanations. The ig issues with todays demo is that I've for the first time managed to wire two connections from one output terminal to the input terminals of two different ifotrons, like a T-junction.

So in a very simple step, I went from seeing my output as just debugging text to at the same time, also seeing it as a parsed tree structure. I'll never stop drinking this stuff :)

Monday, January 29, 2007

The OpenLink Ajax Toolkit

Yesterday Ajaxian posted a story about a new toolkit coming out of the open ajax alliance, and the first thing I thought was "Wow, are those guys actually _doing_ anything?" :) Since their website have had a very ... meeting kind of look to it for ages (at least when last I looked).

And then they drop something like OAT. It by far the most nice-looking, sexy and comprehensive ajax toolkit I've ever seen (Except for Dojo, in fair parts, but Dojo is also a bit bloated at the moment).

And they have a visual designer, which lets you drag, drop, resize and position html elements, widgets, tables, wahoos and whatnots.

They've got data binding to tables and whatnots (At the moment they seem completely tied to XMLA, which stands foe XML for discovery, has nothing to do with XML whatsoever, could have been done better in YAML and lets you query and manage a database about metadata, database, schema, tables and that sort of thing. Neat, but MS-centric, therefore uninterresting).

But if we survive that (which of course we somehow must) the've also got an Ajaxified visual database designer! It's shockfull of goodies and fairly well thought out, even if the architectural specifics is missing from the bundled docs.

What is really interesting is that they have/are working on (I'm waiting for incoming documents) standards for component messaging - just like JDA :) Also they're working on component publish/subscribe functionality so you can request components from a central repository, both from a web-page but also from an IDE, and then publish your finished widgets as well.

I'm interrested in finding out if there's common ground between JDA and the Open Ajax messaging specification, becasue .. they're the standard. It says so right there on the box :). Stay tuned for further developments.

Anyway, despite my mild griping here, it's relaly an incredible late christmas present. Thanks!

When things are just too easy

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']]">


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 :)

Friday, January 26, 2007

New Ajax-enabled JDA example at the station

Now that I've got a basic JsStar system set up (I'm calling mine JsBaStard at the moment, don't hold your breath for filee name update :), the beauty of JDA starts to shine. It'll probably take another couple of weeks to rewrite my dappit frontend visual editor in JDA but in the meantime I've thrown togehter a quick three-piece with some explanations along the way.

I'll try to add some more basic examples and more explanations as soon as I can. Please mail me, comment this blog or bother the main site if you have any questions.

Thursday, January 25, 2007

Clarification concerning JDA/JsStar license

Hmm. When I approached Maya Design a couple of weeks ago and asked about getting hold of any old version of the Javascript implementation of JDA (called JsStar). I then got the impression that if I wanted to get it I had to sign something, so it didn't feel as free as I thought it should be.

I jumped wrongfully to the conclusion that JsStar was closed and couldn't be used commercially. I must admit to being a bit rusty on anything legally attached to software which isn't GPL or LGPL :) However, I received the following confirmation Seung Chan Lim of Maya Desing this morning;

"The distribution is not GPL, but it is still free for use (commercially or non-commercially). The GPL or other open source option is being discussed, but we just haven't come to a conclusion yet."

So, as soon as they have the 0.95 version ready, it will be freely available and usable, maybe even as open-source. So ther. Sorry if I was abit unclear before :)

Wednesday, January 24, 2007

First alpha of the LGPL JDA

I had some real problems knotting my head in the right konfigurations required to implement the JDA standard correctly. There's only one thing certain about prototypes in javascript, and that's that when you think you understand them, you're normally way wrong.

Nontheless, the present humble results can be downloaded from Mashup station here.
I've skipped a lot of stuff in the present release just to get it working at all. So at the moment it is only possible to wire together infotrons residing in the same page, with no fancy proxying or domain-stuff. With some luck I'll get that in in a couple of weeks, RL work admitting.

If you haven't read the specification yet, please do so. It's a good read and a warm, fuzzy wow-feeling inducer. you can find it Here.

Monday, January 22, 2007

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;

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


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