Tuesday, December 4, 2007

New features and bugfixes for Backface / TLFKAP

Since last week, I've had issues with draggables suddenly 'freezing' on the facebook canvas page, for no apprent reason.

This was tracked back to improper z-indexing for certain elements. So there.

I have also had a request out from a developer who wanted a special kind of snap-back, so that if a draggable is dropped anywhere on the canvas, it will snap back to its original position - unless it's dropped one a specific dropzone. That works now, like a clockwork :)

And the off-by-two, works on sundays, et.c. fetaures of the snapback are gone too. Now you can snap back relatively positioned elements with no worries.

The zip-file with the sample facebook application included (and a README!! Gosh!) is here; http://supercodex.com/backface/backface.zip

And if you just want to good around with the demo, you can find it here; http://apps.facebook.com/backface

No need to add or anything, just go there, no worries :)


Monday, November 26, 2007

DragNDrop done - with snapback

OK, I have a slight off-by-2-px 'feature', but other than that I have easy-to use dropzones, with restrictions, that animates a snapback of the element not allowed.

Check it out at http://apps.facebook.com/backface


Thursday, November 22, 2007

The library formerly known as Prince

So, I didn't get to call my facebook widget library 'backface' after all, when I tried to submit it as an app to facebooks official application library.

Therefore the name of the library is now the subject line, or TLFKAP, Just so you know :)


Wednesday, November 21, 2007

Backface facebook javascript widget library now support drag AND drop :)

I had a request last night from Sam Dorman from theleague.com who needed not just dragging stuff around, but also being able to drop them on specific areas. Willing to support the development with a small donation, I felt I could not say no :)

At the moment, I am nearly there. What is supported, is to add any element in the page as a "dropzone", which will be called back on its onDrop function (if specified) when any draggable element is dropped on it, like this;

var pane = createPane(document.getElementById('bar'));

var zpane = createPane(document.getElementById('baz'));
var foo = 0;

zpane.onDrop = function(el)
document.getElementById('baz').setTextValue("drop "+foo);

This sample code (taken from the downloadable demo app) creates two panes (adding dropshadows) out of the elements with ids 'bar' and 'baz' defined in HTML on the page.

It then lets both be draggables, by the calls to Drag.init(element). The createPane function returns the resulting element which holds the content element which was the argument to the call, so it is just another 'div'.

Then we add the resulting div from the pane creation as a dropzone, by calling Drag.addDropZone().

At the bottom a function is tucked onto the zpane div element, which will be called whenever any draggable is dropped 'within' the dropzone element.

What is left to do is to support draggables which are not allowed in a specific dropzone, and then animate a "snap-back" of the draggable in such a case, to its previous strat-drag position.

This is not rocket science, but it will probably not be done today :)

Please comment on this to tell me what you would like to see next.

I'm planning to add resizing to panes, but maybe other stuff is more interesting. I'm almost done with a simple paging table with 'automatic' edit links for the current user, if the same as a defined field. Maybe next week.

Zipfile which include sample facebook app is here; http://supercodex.com/backface/backface.zip

Monday, November 19, 2007

backface update

I just added a feature to the backface demo, so that you can create your own divs for demoing purposes, and which also break up the process, so that it is easier to see in the demo source code how to create just a pane, just a draggable or just a fader, for instance.

Sunday, November 18, 2007

The coming frameworks; SOFEA, JDA, Squirrel and a taste of the future of web design

Yesterday, I saw that someone had created a full IoC container framework in Javascript, called squirrel. I have written (at length) previously about JDA (Javascript Dataflow Architecture) and its benefits for creating rich clients in Javascript, sometimes referring to it as "Spring for Javascript".

However, JDA is focusing more on being a pragmatic, easy-to-use (and understand) messaging kernel, for the web page where the rich client resides, rather than a full-out IoC implementation - which Squirrel certainly is!

The goal of both frameworks are of course to force the developer (Yes, that means you :) to modularize code, and not sprawl all over the page out of laziness (as usual). JDA is the more terse alternative, which defines functions called "Blueprints", with input and output "terminals", where each input terminal has a handler function inside the blueprint.

Blueprints can then be instantiated in the web page, and their terminals can be connected to each other (which makes it very easy to switch stuff out, if you change your mind about something) using properties in the HTML tags which JDA scans for after loading.

What I've seen in Squirrel so far (I must admit to just have read through parts of the code and examples), is that it very much resemble traditional Java containers like Spring or Hivemind. As in JDA, it uses the web page as a natural presentation layer, and pushes all functionality into separate Javascript files. One of these is a Mian defintion file, which takes the place of the same XML config file in (say) SPring. it looks like this;

var oCD={

var _oContainer = new IContainer();

It relies on the model, view and container obejcts to be defined separately, which enforces a very strict separation of concerns. What is good about this is that it makes the transition to Rich Client Javascript programing easier for a programmer used to code in Spring, for instance.

The downside is that Squirrel requires (or seem to) a lot more files and "framework objects" than JDA do, which might make it harder to code in.

My remaining impression of Squirrel, though, is; "Wow! They actually did it! :) ". One of my first posts on this blog was actually about a joke about creating a "real" IoC container for Javascript.

Moving on to a comment on the Squirrel posting, I found a link to something absolutely wonderful, which seem to have missed my attention when it came in October; SOFEA - standing for Service-Oriented Front-End Architecture.

SOFEA is an architectural style which in its definition criticizes (and manages to make a very good definition of) the current web frameworks, and (as they say) "none of them satisifes".

If I would summarize the SOFEA proposal (which I'm currently attempting) I would describe it as a clear analysis why generating the client out of the server, and forcing presentation to predefined pages and actions are inherently bad, and inefficient.

Incidentally, this ties very well into my own four principles of web application design : )

1. All functionality that possibly can be implemented on the client side shall be implemented on the client side.
2. All communication with the server middleware shall be constrained to service-interfaces; For instance REST.
3. No part of the client shall be evoked, generated or templated from the server-side. This rules out in-line conditional HTML in JSP, ASP, PHP, et.c.
4. The logic making up the server middleware will be implementing only the following functionality;
  1. Security
  2. Database access
  3. Cross-domain proxying for remote resources implementing only a) and b)
And just like the SOFEA proposal this scraps all major web application frameworks like JSF, Struts and the like (even tapestry, which i kind of like still ..)


Thursday, November 15, 2007

Introducing the Backface facebook widget library :)

So I was bored last night. Everyone in the family save the cats were asleep and I was frustrated that my facebook apps looked so criminally ugly. Here I sit writing fairly complex Javascript wizardry for common browsers, and yet I'm unable to stop the msot simple facebook app to look like something nasty.

I knew that FB allowed most Javascript functions, even if they rewrite all id references, and don't let you peek into the contents of elements, et.c.

I started to hunt for old framework-less Javascript samples for dragging and fading, and managed, despite what I would have thought from the beginning, to actually make it work. So now I have draggable "panes" with drop-shadows and everything, inside the canvas page of a facebook app. I don't think there's much to be done for the profile page, but I'll check it out..

Also, I managed to make a separate library of it, so if you're using PHP for you facebook app, you're free to download and use it. I'll probably put a LGPL sticker on it, but right now I just want to see if anyone finds it useful.

You can download a zipfile containing the library and a small demo page here;


A live demo of the [sic] demo is here (facebook login required);
Not that since the demo facebook app is part of the package, I have just copied code from another project that forces you to add it. I have no ads in it. You don't *have* to look at it, and you can almot jsut as easily d/l the zip and create you own demo project in two minutes flat :)



Thursday, November 8, 2007

Return to dojo revisited

Argh. I don't know how to say this, but.. I had an idea that I should check out jQuery and Ext and maybe spliff upp my interface *so that it looks nicer* to be able to lure people in and actually try things out.
After a week of that, coinciding with the release of dojo 1.0.0 (with the übercomplete Grid component), I felt that I had have enough of hunting about for non-documented css files or cryptic references.

The place where dojo really shines is that all components, widgets, what have you, are self-contained and auto-load their own resources. I had relied so much on that so I didn't realize how advance dojo's resource system really was.

In jQuery for instance, it's possibly to write a plugin (for a kind of cool-looking menu, say) which refers to half a dozen of css files, which have been released in various version.

In dojo, you cannot do so. If you write your own widget, dijjit, whatever, you define the html/css look and feel right there and then. More or less, bear with me here.

Anyway, the moral of this story is that in just a couple of hours I'm almost at the same point with dojo-1.0.0 as I was with jQuery for a week. OK, I know the API, but anyway. The new release looks way better as well :)


Friday, October 26, 2007

Feedback Frenzy

So.... let's recapitulate what happened a couple of days ago;

1) I got impatient with not getting my program "out there"
2) I decided to release early & often
3) I even did a small screencast (though I didn't realize how small until I saw the tiny windows in the blog :)

My idea was that it didn't matter that my design looked like being hit over the head with a live chicken greased in peyotl, as long as those who did the looking-around were programmers themselves and had the wits and tenaicty to dig around for features - especially if I wrote the features up beforehand.

It was, of course, a very silly idea. The end-result was that of the around 1400 people who took their time to load the composer, a whopping 74 did vote on ajaxian.com - and the result was 1.4 (out of 5). Not exactly glamorous, but that's show-biz, I guess.

The big reasons people thought it sucked was 1) It looked like crap and 2) They didn't understand what to do.

Note that in the ajaxian blurb I had bullet point that described the main features, in this very blog I described how to go about it, I put a link to the FAQ clearly visible on the page, and there was a new "System Menu" which labeled each subcategory.

This did not daunt more than a hardy few. It seems that *any* inconvenience is too much for most people - even supposedly battle-hardened programmers (who were my main audience for the alpha release).

But what was good was that I was able to try out the system under moderate load, with moer then one person at a time, since I really didn't know if it would hold water or not (it did, thankfully). So the expereince was not compeltely wasted. Also, I got to know some really interesting people who are doing similar thigns (and a troll, but who's counting? :)

The bottom line is now that I'll rewrite the entire system from more-or-less scratch. It's a wonderful feeling, and it will take *much* less time, since I know what I didn't like with my (architectural) design the last time around.

First of all, I decided to use a database - object layer. So today I managed to coach Propel (of phpdb fame) to generate schemas and classes from my initial phpmyadmin doodles, and during the weekend I'll set up a very basic and wonderfully designed dojo-1.0b frontend.

See you all then.

Wednesday, October 17, 2007

JDA Composer reaching alpha 0.80

JDA Composer is yet another web-based mashup IDE, in the same vein as Microsoft Popfly, openKapow, TIBCO GI and stuff like that. The focus is not so much to be complete one-stop shop but to let people quickly prototype mashups and export them as stand-alone archives when done.

The url, for the impatient is here; http://www.mashupstation.com/station/users/admin/jdacomposer_draw2d.html

Note that this is alpha-level software which might work, might not and will most probably crash and burn you machine so bad you'll think it's running Vista or something. Just so you know. Right now it's only tested in Firefox :)

Here's a screencast (without sound) that shows how to create a simple google maps Gadget;

You don't need to login to try it out, which is intentional. The focus is on first designing your UI properly, style elements, drag and drop them on each other, change background images, et.c. Then, add JavaScript Blueprints to selected elements. For those of you who recognize the term in this context; Yes, I'm using JDA (Javascript Dataflow Architecture) to wire things together. The composer is itself built using JDA, and it also generates pages adhering to the same standard.

A description of JDA is outside the scope of this document, but I just want to say a few things about Blueprints. They're the basic building-blocks of JDA, actually just JavaScript functions which tie in to the JDA runtime in the page and declare input and output terminals. each input terminal a Blueprint declares has a handler function inside the Blueprint, and each declared output terminal can be tied to send JavaScript objects to the input terminal of another Blueprint. I'm lying a little bit about how it works here :) , but I want to emphasize the LEGO-block functionality of JDA.

As you can see in the screenshot, the Composer has a window which draws the relations between the input and output terminals of the components. In the auto-loaded example page, there is a GenericForm blueprint, which wraps a form with any number of components, and overrides any submit button, so that a submit of the form instead sends a name-value pair list of all input elements ion the output terminal of the component. This is connected to an input terminal of the GoogleMap component, which scans for addresses, and shows them on the map. Not very complicated as an example, but it illustrates the possibilities.

If you want to define your own Blueprints, that's OK as well, just go to the System Menu "JS IDE", and you'll get a window which after a while lists the currently registered Blueprints in the system. Pick one up, if you want, and get a list of the functions inside it. If you choose a function, you'll get a very nice code editor (Which I've thankfully expropriated from Christofe Dolivet and his EditArea team. Thanks! :)

Right now I feel that the system is stable enough to handle a casual try out from people in the know. Please flame me heavily by mail or in the Google Group provided.



Sunday, October 14, 2007

Usability and Gaming

One good way to measure the usability of the tools you make is to observe whether you're using them yourself or not, and if so, how much. I had an idea to make a small javascript-based game, possibly using facebook as userbase, either as an app or from the outside...

So, I started to make a small blueprint in the composer and tried out the new editor, and it does work. However, I found one thing annoying, and that was that I haven't the foggiest idea how to *reload* a component, when I've added it to the framework. Possibly this might be easy, I haven't a clue, but at the moment I have to reload the entire composer each time I change the code after I've tried it. This is a bit annoying.

So I definitely have to make reloading of code a priority. Another weird thing is that for some reason, loading of scripts or images never gets done on the spot, but rather when the _onInit function returns. But only inside the composer. When I export the page, it works spotlessly, as seen below;

Finally - A code editor that works

Since last christmas I've been looking for off-the-shelf code editor. The kind that captures tab and insert four spaces, the kind that groks JavaScript syntax and highlights reserved words, etc.

I tried using dojo's editor and editor2, but wasn't satisfied with the code aspect of it all. I didn't need formatting so much as syntax highlighting.

Then I saw Marijn Haverbeke's in-browser javascript editor, which kind of blew me away. It looked to good to be true, which turned out to be the case. Not because Marijn isn't a truly good programmer (I dived quite deep into the code at times), but because he used mochikit (without the optional namespacing).

The resulted in the editor borking most of dojo (which takes great pains to namespace itself and not to collide with other stuff on the page), which I relied on heavily for windowing and diverse stuff. I tried to refactor in namespacing in Marijns codebase for about a week before I gave it up. It was really a shame, and so until today I had just a plain textarea to use as editor for my spanking new online Web IDE. :-P

But I checked Marijn's site a couple of days ago, and he had added a link to realted projects, one of which was editarea by Christofer Dolivet, which turned out to be very well-behaved indeed.

OK, I had to be creative when I created things dynamically all the time, and I couldn't use just one instance of the editor, but had to create new ones and remember them and so on, but on the whole I must say I'm greatly relieved. Not everything works perfectly, but it looks good and it works well enough. And it's LGPL as well! Thanks!!

Friday, October 5, 2007

Gadgets Ohoy!

This is so sweet!!! I was lamenting the sad state of my programming proficiency over a couple of beers with a couple of friends yesterday. I was especially bothered that I hadn't managed to translate absolute to relative positioning.

One of the guys told me that I didn't need to; Absolute works as relative coordinates within parent containers. I replied that it did not, but started to think about it. Then I started to experiment a bit more than I did the first time around. Then I discovered that it was actually true; As long as the parent element is relatively positioned. Whew!

And that was the final stopper. In only a couple of hours I managed to create an exported for Google gadgets. Prrof is in the pudding .. er .. pictures. Compare the gadget view with the editor view.

Tuesday, September 25, 2007


OK. I have top/left coordinates are off. All styling doesn't come along for the ride, and it like like a punch in the face, but I've finally managed to export the whole caboodle, php backend and everything. What this means is that I can whip up a form with named textfields, connect them to a yahoo image search, and connect the output of that to a JDA slideshow javascript blueprint.

Then I just choose export page from the page manager, and gets the stand-alone zipfile in my lap.

It still sounds stupid when I say it, especially since I have coded every inch of this, but I'm still perplexed that it really works!!!


Monday, September 17, 2007


Having a - mostly - stable platform is a pleasant surprise. One area where I'm sorely lacking right now is components. I'm supposed to show this thing up to potential customers and what can I show? Some google maps? Come on!

So today I revisited dojo's charting package and I saw that there existed some actually understandable code in the tests area, which I more or less copied, wrote some extra conversion code for the data I had slurped elsewhere and it just worked. Again. I mean I got that it just worked feeling again in quite a short while.

OK, so for some reason it's just grayscale, but is is financial data pulled from a table at a web page in kind of realtime, and poured over dojo charting goodness.

Monday, September 10, 2007

The last 80%

Yes, as always - again and again - after 80% is done, it's just the last 80% left to do; Layout bugs, missing buttons, various edge-cases, et.c.

rather than foucs on all small things left to do before I can feel comfortabel with showing the composer to investors or potential partners, is that it's actually workable as an IDE. Several times last month when having ideas on certain topics, I've used the composer, either creating blueprints, or fooling around with the WYSIWYG designer to try things out.

But the nicest thing I've done recently is so simple that I haven't really thought about it before, and it gives so much more to the overall impression of a page or a widget; Adding the possibility to define background-images for an element. I haven't finished the saving and loading part yet :) But it really does wonders for professional looks.

Tuesday, August 28, 2007

Good reads and the advent of facebook apps

Since being nearly there with the exporting to joomla business, I've of course been sidetracked by the sweet lure of making facebook applications.

I've done a couple of fairly simple, but quite workable ones. One interesting thing looking closer at facebook, is that they _do_ actually allow javascript in their pages. They just restrict it heavily.

One idea I have in May was to make facebook a target for the composer (or what I might end up calling it), but dropped it due to js being unsupported. Now, however, I might be able to.

Even though the composer needs shortsloads of js to get up and running, it doesn't necessarily mean that its output has to. I'll sleep on that a bit.

But then there's William Gibson's new "Spook Country" which is just brilliant. Must have. trust me.
I didn't like the earlier later ones, really. Only Pattern Recognition, and so-so at that. But Spook Country is very much just that :)

Tuesday, August 21, 2007

The "Life of Brian" definition of language choices

Here's the problem(s);

1) Most of the people trying out new shiny interesting programming languages and concepts are young and have relatively little experience writing code (at least, compared to (2)).

2) Most of the people with years of programming experience want to relive the last programming language five-year learning curve like they want a hot poker stuffed up their .. favorite gaming console.

Relatively few people have the relevant experience to compare between the new and the old. Mostly this is due to natural reasons, the new being, well.. new and everything. But the biggest problem in my opinion is that learning J2EE (as it was called back in the days :) was so staggeringly hard and complicated, especially since it didn't take you anywhere near where you wanted to go, forcing you to endure Struts piled upon JSF to get anything done. That experience scars, and makes people more wary of learning new things.

So when anything new comes around, they'll just stick to the beef they've already paid for, thank you very much. One person I've spoken to has actually declared that Java was and will be the last damn language he'll learn, and thats it.

On the other side we have mostly young, daring and early adopters who try, mostly in vain to define why Ruby (with or without Rails), PHP, Python or even NBL, sorry, Javascript, is a better choice for web development.

The reason they try in vain is because they do not have the experience to compare, they just feel that they can deliver quite a lot in a short amount of time, and having a fairly simple time maintaining what they develop as well.

But what is needed is senior coders with a solid experience of both sides. If you are one, please be seen. Blog, write articles, get involved in the projects you love and use. Do something new. Anything.

Why? To save the people around you from suffering technological blue-shift and be cut off from the very tools and languages which could save their projects.

Which brings out the question of my own expertise, of course :)

I've been teaching IP routing and general networking courses (firewall-1, Netware (Yes, I'm that old)), routing stuff during most of the nineties. I started fooling around with java 1998, founding my own company in 2000 as a programmer, and been involved in fairly high-profile J2EE things since then; Deep-down PKI CA coding, Distributed J2EE WPKI certificate enrollment and verification systems, Web-based (Tapestry) seling campaign systems, and a lot fo other stuff.

So I *know* J2EE.

During the first years of Java, the critique was very harsh; It was more than twice as slow as C/C++, it had a broken implementation of OO, it was unreliable due to GC, etc.

The people rallying for Java (myself being one of them) did so because they felt that they could be much more productive, and get a codebase which was easier to maintain, compared to, say, C++. Over the years the Java VM got smarter and quicker, up to the point that even Java's main derailer, Microsoft, decided to make it's own VM-based language(s).

Today, the new and upcoming scripting languages like Python, PHP, Ruby and Javascript (among others) gets ridiculed in *exactly the same way* that Java was - by the very people who defended Java from the same arguments, and for the very same reasons, ten years earlier.

That's really priceless :)

getting back to the title of this blog entry, I want you to remember a scene from the excellent Monthy Python movie "Life of Brian", where a Roman soldier manages a long line of people coming out from the courtroom, asking them if they're to be crucified or freed. Most answer "crucified" and the soldier prompts them to go to the left, and take one cross each. Please see http://www.mwscomp.com/movies/brian/brian-22.htm for reference :)

Today, I feel that the people who don't even try to look at the new tools available to them, is pretty much like these convicts. You actually do have a choice, you know.

Also, my own experience (starting with Javascript two years back, recently involving PHP) has been that the new languages and frameworks comes much cheaper, by orders of magnitude, than did J2EE.

I have done in dojo (javscript framework) and PHP combo some fairly simple things in two weeks, which would have taken months and months of development time if done in Struts or similar frameworks. Yes, Tapestry is better, but costs a lot of complexity.

Also, I am not tied in to any tools. I use no eclipse, no ant, no maven, I use VI, sometimes Kate or wordpad, depending on which machine I'm sitting. I know what I do, I _see_ what I do, and edit-to-tryout time is around 20 seconds. That's the time ti takes for me to copy the last versions of a couple of files to my web-hosting.

What do I do? Well.. I do This, for instance. It's very alpha and kind of hard to grok, so be gentle. The project has taken most of my spare time since january, but if I would have used any J2EE framework, I would still be fighting Hibernate over which Fetchtype to use for a certain class, and be two years off :)

Monday, August 13, 2007

I are Dunecat

Hee heee. I just wanted to share a lightyears short of production-quality image of the beginnings of my new user info page. The main reason of having this is to manage and edit developer keys that will be compiled to a config file for teh abckend, so that you don't have to put them up in the html page.

However, I couldn't resist adding the option of storing a mug shot as well. As you all can see, I am actually dunecat. Who knew?

Wednesday, August 8, 2007

At the bar, ordering a Beer

If it weren't for all the small, nonlethal things I've skipped over during tha last three months to get here, today would feel like a complete success.

As it is, is feels like having ordered the Beer, but not yet having it in close proximity, This is of course a huge leap forward from being able to see the bar further down the hill last week.

So what have happened to excuse such an unusual display of extreme exuberance, complete with potent inebriatic imagery? Well, glad you asked. I've finally managed to export the jda runtime, with assorted supporting files into an html-file which is itself generated directly from the database, converting general element and/or infotron definitions to html tags with correct top/left placement, correct jda initialization, connections between infotrons etc, etc,

What this really means is that I can now export pages made in the composer as true stand-alone artifacts. The only thing left now, is to create an archive of the generated html-file,and the backend php-scripts, as well as config file for devkeys replacemenet, and some extra UI components in the composer to handle development keys ... and some extra function in all blueprints that require devkeys to define them (and use them, instead of hardcoded values).

But other than that, it's as good as finished :) I don't have any inconceivable problems at the moment, just drumming my fingers until the barman gets back from the fridge.

Tuesday, July 31, 2007

You acquire a +6/+6 Two-handed Sword of bug-smiting

Some days are just incredible. This is one such day. Not only have I just started to feel normal (albeit weak) again from my recent pneumonia (Ugh!), but I've solved two serious problems and fixed half a dozen pesky bugs that I've known about but never really got round to. Also, I've added new functionality. Ah, the sweet feeling of success - almost a mythical beast :)

Some highlights include;

1) Added bezier connections hot off the shelf from AHerz latest batch of powerful draw2d magic.
2) Finally, finally, finally fixed the load/save cycle even if you only have html elements and is standing on one leg during a thunderstorm. Styles propagate. infotron properties gets saved. And loaded. The only words that come to mind are Sean connery's succinct "Schweeeet".
3) Fixed Google Maps so that markers gets shown properly again. Really don't know what I did, but it works :)
4) Re factored (OK, I didn't do all today :) infotron loading and connecting so that both manual fiddling and loading from server calls the same final functions, which makes it easier to give the same treatment to the visual manager.

Next up are of course (as always);
1) Fixing so that you can create and remove infotrons without leaving the "conceptual" visual manager, along with add/remove connections, et.c.
2) Really, really flush everything when loading a new page, so that things don't go bonkers somwhere.
3) Decide on a primary export target already! And git!

I'm actually grounded on doctors orders until 9/8, so with some luck I'll be done by then. Sort of :)

Thursday, July 5, 2007

Steve, Helma and the second coming of NBL

Quick update first: The draw2d figure connections routing now works. It was my fault as always ;) The save/load cycle is 90% done and only needs some quick touches to really swipe things everywhere when loading and really initialize everything while loading. I can finally start to work with it as a tool now, which is great.

Concerning Google, I cannot comment at the moment what is happening or not except to say that Zürich is a surprisingly nice and friendly city and Zooglers are a cool bunch of people.

Now for todays piece of information. Nobody in their right mind should have missed Steve Yegges announcement at Foocamp that he was basically porting ruby on rails to JavaScript - on the server side. Yikes! It seems that the server side language and framework I had been hoping for is already being made.

Today Joh Resig mentioned an exisiting js serverside framework called Helma.
I know that the Sun guys are already working hard on the Phobos project, which also is a java-contained js framework. The problem I have with Phobos is that it technically feels like going back seven years to JSP pages, including horribly mixing of code and presentation.

What's really, really cool with Helma is that it contains a js object-db abstraction layer. See above for a picture from their site.

Like a true coincidence I happen to be at the point where I'm starting to choose an export target for components generated in the composer. Also, one of my future musings include a visual editor for creating server-side objects, and for generating CRUD forms from them. Kind of makes you think. Hmmm :)

Tuesday, June 26, 2007

Der long and winding road

Augh! I've been battling like crazy with getting the load/save cycle to work together with the openjacob draw2d libraries. Actually, that's not really fair, because I hadn't touched the problem before I switched to draw2d, so most probably I would have had the same problems no matter with graphical library I would have used.

Also, there is still something that have changed between draw2d version so that my visual manager, which let you connect terminals to infotrons visually, now route not at all between nodes. I'll get to that when I can.

Right now the main target is to be able to save and load both position, size and style of elements, including hierarchical elements in a page, including any infotrons and their properties and connections, with no losses between serializations.

This has proven to be nontrivial, but at the moment I am saving things correctly, and I erase stuff when loading almost correctly, and I can load all visible artifacts, and also all infotrons. Only the connections are remaining. And that is a known problem. I just have to choose how to do it, which is very nice for a change :)

And after that ...... the actual generation of a stand-alone webpage directory with the correct html generated and the correct js and css files copied to it. This is a non-hard problem, compared to my battles with the load/save cycle. I _know_ how to do it.

And when I've done that all I have to do is copy that process, tweak it a bit, and have export functions for both joomla and Google widgets (or any other stuff I'd like) Google widgets are extremely cool, because google has their own (of course) proxying library, so I don't have to ship a PHP (or other) backend for the proxy stuff. Hmm. I probably have to drop support for wsdl things initially, since I use PHP for that, but what the hey, who uses that stuff nowadays anyway? :)

Friday, June 1, 2007

The truth and nothing but the truth

Jeff Atwood of Coding Horror fame is kind of hard to write about, because I agree so much with him it's almost silly.

Take todays blog, for instance; http://www.codinghorror.com/blog/archives/000878.html
Named "The best code is no code at all", he succinctly argues that the biggest enemy to writing good code is ourselves, as programmers.

I've felt for a couple for years or more that I'm getting more and more sick and tired of being slave to a host of things that has nothing to do with the problem whatsoever.

We're getting bogged down by ant (or gods help you - maven) scripts, we have to battle code versioning systems of various lethal potency, and when the day is done we still have to create seven new classes and interfaces - several quite obscure and weird - just to be able to use a single kind of functionality of a fine API. We're not even using it in an edge-case scenario, we're trying to use it for the most common purpose for which it was built!

And then we've never even started to write the actual logic of what we're trying to achieve yet.

These reasons, in a nutshell, along with LOC bloat is my main reasons for using javascript almost exclusively, after almost 10 years as a Java/J2EE and occasional .N0t programmer.

You can also be very certain that the next time I code server-side again, I will _SO_ use a scripting language, probably PHP.

Tuesday, May 29, 2007

Grinding away

Google sourcers are extremely nice over the phone as well. Even if I fail later on I must say that the very professional and, I can't find any other word for it, nice behavior I was greeted with when talking the the google representative. Now it can take ages until a recruting coordinator gets on my case, and I'm actually not certain I want to join google anyway - it might require relocation and so on. But still it's a nice feeling to be courted by the cutest chick on the block, so to speak :)

At the moment I'm grinding away the final part of the code that saves element and infotrons (if present) in the current page. And I know exactly how to manage loading as well, which if I'm lucky will be quite similar to how I render the final vanilla HTML page as well. Don't touch that dial.

Wednesday, May 23, 2007

I've been googled!

Last Friday a recruiter working for google sent me a very nice and friendly inMail on my LinkedIn account. It was a pretty surreal experience. To begin with I didn't know that google actively searched for people, but rather sifted through the tons of incoming applications.

Today we have a scheduled phone meeting, which will probably go OK. Now, if you're not up to speed with the way google works when recruiting this might seems like my big chance. Not so.

My research have confirmed the following points;

1) Google continually searches for potential candidates to various positions withing the company, Note the word 'potential'.
2) Even if you pass the first and second interview (which will be increasingly challenging), the next steps are a grueling two-day interview marathon, where up to 20 different people will challenge you on a variety of topics - not necessarily ones relevant to the position you think they want you for.
3) Every single one of these people will have to recommend you to a final decision-maker, who is not part of the actual interview process who can drop you for "cultural incompatibility" or some such reason.
4) The process can and will take several months to finish, with many irregular starts and stops between start and rejection.

On top of this, I'm not even actively seeking a new job. I'm trying to create my own company with the composer!

To google's defense, it seems that their recruitment process is intended to make pretty certain that they don't recruit any bad apples, even if that means that they'll skip a few good ones in the mean time.

My bet is that I'll pass the two first interview (by phone, since I'm in Sweden and the recruiter - sorry, technical sourcer - is in Denver, for some reason), and then fail miserably on the first day of face-to-face interviews when it is unearthed that I never found George R.R. Martin's books particularly good. Another possible end is that they finish two whole face-to-face ingterview thing, give thumbs up, hide for seven months, and finally send me a machine-generated rejection letter for the wrong position, citing provably false shortcomings.

Or, who know, me and my family might gets whisked out on a magic carpet and relocated - cats and all - near Mountain View.

And _then_ I can sell the composer to google (wringing hands)

Monday, May 21, 2007

Contain the container

I have been wrestling with using draw2d for over a month now (OK, having a vacation in between, but anyway), especially with hierarchic containers. I wanted to make it easy to create a small "group" of things, say; a label, a textfield and an image, and then drop the whole things inside a larger container which has lots of other form elements in it, and most importantly to resize and position the "group" inside the larger container in a simple way.

After losing my mind the third time I finally registered with the forum and wrote a short plea for help. I didn't expect much, after all draw2d is a on-person project (as are all other projects, for that matter), but the next day Andreas Herz had written a fix for hierarchical components just like that. And it worked and it was beautiful. I really hope he puts up the paypal donation button somewhere on his site, so I can thank him properly.

The only downside was that draw2d uses a separate hierarchy beside the actual DOM, so that all 'figures' sit flat beside each other, and move by draw2d logic depending on how draw2d thinks which one is inside the other. I have now learned to live with this, and written some extra logic to handle this, especially for the GenericForm blueprint.

So after some fairly minor amount of hacking I was able to get back to where I was a month ago, but now with a workable and intuitive GUI, with a toolbar and everything.

Next steps are to finally finish the load/save page stuff, so that the created pages can be serialized. And after that comes the holy grail of export as CMS module, with joomla and MAJ as the first CMS targets.

Thursday, April 26, 2007

Good looks isn't everything

However, GUI design is very geared towards surface values. The last week has been a not-so-dear reminder of the age-old adage that the GUI takes at least twice the time of the rest of the applications - regardless of its complexity.

I started out using Walter Zorns DHTML library, which works well even if it's a little low-level. I really wanted to constrain element placement to specific areas of the screen (The main canvas, for instance), and so I experimented with using dojo's DnD, which turned out to be much easier - at least to begin with.

Unfortunately, one major drawback with the current implementation of drag-n-drop in dojo 4.2 is that dragging also triggers moving, so you end up hauling your resizing element halfway across screen, when it should have stayed put.

Also, I have completely failed to understand how to use hierarchical and multiple drop targets simultaneously, so that you can nest elements, drag nested elements out on to the canvas again, or onto another element, properly.

So at the moment, I'm trying to shoehorn my ambition inside open jacobs draw2d library, which is built on top of WZDHTML, but with a lot of added functionality, especially the nice "green corner resizing blobs" and selection logic, as well as fairly simple drag and droppability, events, cross-browser brains, et.c.

But.... there is no explicit logic in draw2d for handling nested figures. So when doing the "obvious", i.e. adding one "Figure" objects html element as a child of one other, the highlighting, resizing blobs and stuff gets misplaced, but follows the movements symmetrically. Not good.

I'll probably hack around in draw2d to see if I can understand why it doesn't work, but if all else fails, I'll ironically move back to plain vanilla walter again, just to get things moving.

Thursday, April 19, 2007

Creeping functionality and some actual documentation

So, things have been busy as usual. Stuff I've finally dragged kicking and screaming into a usable state;

1) Datasource generation, which let you either search for and create blueprint out of a dappit dapp, a basic WSDL file or a simple table in a HTML page.
2) Menu choices to 'extract' HTML forms into the canvas from comments I've auto-generated in the datasource blueprints, mainly to get shorter test-cycles when coding but actually a nifty feature in itself
3) A workable simple wrapper for dojo's FilteringTable, which tries to use sensible defaults when just getting a heap of data.

Then I've begun fiddling with dojo's charting engine which, in good dojo tradition, have no documentation whatsoever. Truly and really. Isn't life great? :) I've managed to get it up and running in a blueprint, but I still can't understand quite how to map values. I'll get on it, promise.

Also, I've done a fairly working blueprint which takes dapp output from a dappit datasource and munges it so it can be digested by the SimpleTable (as I've called it). Eight now I might have broken that in favor of supporting the really usable simple table scraper. but any week now :)

Aaaaaand.... the docs! At http://www.mashupstation.com/Wikka/wikka.php?wakka=JDAComposerDocumentation is the first actual words apart from here which tells anyone how to use the composer. Please indulge, if you're so inclined.

I also seem to have reverted to an earlier error, in the visual manager, so I get wrong connections. I kind of remember how I tackled that, so as soon as I get the other stuff done...

Then I've finally made some real scaffolding for the page manager. That's a bit of a nut to crack, though, because I need to decide how to parse the canvas before storing it, but more importantly how to recreate a canvas page from storage. I.e. I'm not sure that my database model is sufficient. it might, but we'll see. Since it's nontrivial, I tend to drag it about.

Then there's the fairly simple login issue of supporting Yahoo, Google and openId id's. Really. It's not that hard, mainly some work on the serverside, but as I have nothing else to do :) ..

Then there's my daywork, involving shibboleth and GuanXi. Aeughhh!!

Wednesday, April 4, 2007

Fear the fork!

SO, having had moderate success on the data source department, I've realized that it's time to fork the composer into a "stable" and "development" branch, since people are testing. It has happened more than once that I've broken something just the day before a demo, for instance.

This also coincides with the need to switch over to JDA 0.96b. Unfortunately this will also lead to back-end changes, both to php and database. The reason for this is that o.96b changes the blueprint format to include a section which explicitly defines the properties a blueprint can take. I suppose I shouldn't whine about it since it was my idea :) But anyway, the works need to be done, and so I'll have to put the data source stuff on ice for now.

Sunday, April 1, 2007

Quick update on visuals

Here's a snapshot of how the visual manager looks. I've had some issues with regression testing when adding this and have spent most of the weekends coding hours to iron out the quirks in the canvas and connection managers, which are responsible for infotron creation and wiring respectively. I also changed the connection menu so that it now lists the given name of the target infotrons when you wire, instead of the more cryptic automatic ids.

As of now, I still haven't managed full communication to and from the visual manager for connectivity. The only thing working is that all created infotrons gets represented correctly in the visual manager as well, but connections doesn't get draw, and more importantly, you can connect yet from the vm. I have come so far on that road, though that I feel quite close.

The goal is to let blueprints declare themselves "invisible" or something similar, and then only render them in the visual manager. A good example of that would be the GoogleGeocoder which has not DOM interaction at all, or conversion blueprints, like xml2json, et.c.

I have finally come up with a metaphor for managing datasources. This has been a bit tricky, because I want to make it as easy as possible to "play" with different datasources and if possible avoid manual entry of long urls or other strings. The way I'm going to implement this is in the same kind of "wizard" way that you choose infotron instantiation from existing blueprints, with possible property specification - but instead of creating an infotron a datasource will be a full-blown blueprint, which is created after the wizard is done.

This way I can reuse a lot of code for the cases where you want two or three different infotrons that read the same data source - they just instantiate infotrons from the same blueprint.

So the datasource wizard will have to have static code snippets for blueprints which handle reading data from all supported types; Yahoo pipes, Dappit dapps, Web Services, WADL, et.c. but also with specialized selection logic for each edge case, such as using dapps search API when choosing a dapp, et.c.

We'll see how far I come this week :)

Saturday, March 31, 2007

Emergent quirks

Things are chugging along nicely. I've managed to integrate the jacob.draw2d package as diagrammatic (visual editor). I have to tweak it a little bit, since they don't have support of selecting connected lines between nodes in the workflow for some reason. But still, when an infotron is created it pops up in the visual diagram manager as well, along with properly positioned input and output terminals, which apply rules as to which things get connected to which, et.c.

Otherwise I've left too many dangling ends flapping about. I've still embedded html tags in function generation, even though I've ditched dojo's rich text editor, which requires some agility when relying on function generation when creating input terminal handlers.

Then I've _still_ not fixed the odd < problem, where the browser barfs on and less than or greater than signs (in for-loops for instance) . I'm pretty certain I just have to tweak the document type in the backend, but haven't got around to it.

And of course, I'm still itching to create the frontend logic for page management, especially since the backend and database tables are all done. The latest Internet Explorer debacle has really strained my schedule (as if I had one :).

But right now I feel that the most important thing to add is datasources, yahoo pipes, dapps, what have yous. It will be comparatively simply. I know, since I've done it once before, but on the earlier revision of the composer which didn't use JDA and as a result of that imploded under its own complexity. So whoever is peeking secretly at this at the moment - know that next week will see some real usability chucked in .

Monday, March 26, 2007

Internet Deplorer

I posted this to the dojo-list but I thought I'd blog about it as well, because ... well, because MS needs and deserves all the bad press the world can find, I guess ;)


I have been battling a problem when using Dialogs in both FF and IE for the last week. I'm using 4.1rc2 (IIRC).
The problem has been that I build dynamic content inside the dialog which is shown correctly in FF, but is invisible or hidden in IE.

I have tried a multitude of approaches for getting IE to show the content of the dialog. I have ,

1) Created the dialog almost entirely in the HTML page (dojoType="Dialog" ..etc..)
2) Created the dialog entirely programmatically
3) Skipped the form and only used a table which i append to the dialog
4) Created a dojo:Form instead of a plain form element and addChild that to the dialog
4) Numerous contortions of the above themes, sometimes in combination.

None have worked.

Today I got so frustrated that I just added a naked input type=text under the Dialog's div.... and that worked.

Now is that strange or what? So if anyone have had similar problems with Internet Explorer (6, in my case), just slam the elements up as they go, no fancy-footing with forms here, no.

Back to the labs :)

Thursday, March 15, 2007

Yiihaaa!! JDA rox0rz!!

After a lot of tweaking and fiddling, I finally got to my stable ground. My baseline for a workable system has been to be able to wire together more than two components, where one of them is a google or yahoo map, using nontrivial services in the meantime.

What I've done here is to create a form visually, by dragging the form tag out from the menu on the right, then dragging two text input fields and one submit input field on to that, not forgetting to name the input fields.

Step two was to configure the form HTML tag as a GenericForm JDA blueprint (part of the JDA 0.95b distro), which didn't change the looks, but added terminals and logic to the form tag.

Step three was to drag a div onto the canvas, and configure that as a GoolgeGeocoder blueprint (Which is one I created on the fly in just five minutes in the blueprint manager/code editor, which is the second button down on the left). That blueprint has one input terminal for an address array, and one output terminal which posts a GPoint object. It doesn't look like anything, so I'll hide that kind of component later, I think.

Step four was to create a div, which I configured as a SimpleGoogleMap. The only problem right now is that the google map blueprint eats my drag/move/resize logic, so I can't place it somewhere else, or resize it after I've designated the div as a GoogleMap. I think I know how to fix that by wrapping it inside another div (Like I do with the input elements)).

After that I right-clicked to get my nice dojo menu on every element, and choose connections, which pop up the connections dialog. From that I choose the correct endpoint for each of the two elements with outgoing connections.

It works beautifully!! My next two major steps are to add page management, so that you can save, load, delete the page you make, and to add openId, Yahoo, Google authentication so that everyone isn't 'anonymous'

I don't think that'll be particularly complicated. I've done the PHP/MySQL backend for page management already, and at least google auth API is very straightforward.

The final step (around the time I'll need nice and juicy VC :) is to implement generation of downloaded zipfiles containing the page you've made, including jda lib, infotron blueprints, css according to choosen styling, et.c.

My ultimate goal is to be able to produce downloads which are completely separate form the site, and which will work on any server and environment.

Tuesday, March 13, 2007

Return to the Dojo

It has been a thorn in my side for a while that I didn't manage to grok (or find info on) how to use dojo for both resizing and drag-move simultaneously. While the visual editor is now nominally up and running, can import and digest JDA blueprints and reconstruct them again, can pass messages et.c., I found yesterday that I really need a more visual way of showing what's avialable.

In short, I need a vertical toolbar where you can drag divs, forms and the like out on the canvas and then style them to you hearts content, before you add JDA blueprints to them. Specifically I needed to be able to choose in a simple way what kind of element should wrap the blueprint, especially in the case of forms.

In addition to this sudden, pressing need, I had issues with Walter Zorns DHTML library, which for some reason does not contain a restrict_to_parent funcitonality, so I hacked together something which didn't do the job particularly well. Things got added to parents for no reasons and couldn't be moved to certain parts of the canvas, et.c.

Since Dojo had that kind of restrictability out of the box I decided to just try for ten minutes or so to use dojo for all drag, move, resize, restrict et.c. things in stead of WZDHTML. Again.

And I did. Which is kind of amazing, since I very much did not just a couple of weeks ago :)

Anyway, the trick to get things done was the following;

el.innerHTML = " <div dojoType='ResizeHandle' targetElmId='"+el.id+"'> ";
var foo = new dojo.dnd.HtmlDragMoveSource(dojo.byId(el.id));

Where 'el' is the newly created element of some sort, and 'this' is the Canvas infotron whch handles all new elements.
I had problems wiht getting the resizing dog-ear to show up until I saw that you could create widgets out of an entire DOM hierarchy if you want, by passing _only_ the domid of the topmost element (Which can be an ordinary element, without a dojoType attribute as you see).

Talk about being effective! I know I sound like a silly-happy ten-year old kid all the while, but that's mainly because that's the way you feel when coding js, almost all the time. Now I'm looking for a language which makes you feel like drinking a couple of beers and snoggle up to someone :)

Saturday, March 10, 2007

A car building itself

Of course, that's not a very good analogy, and an extreme overstatement of how things go with the editor at the moment - but it's that kind of feeling. Once the core code stabilized I had a couple of idea;

1. Writing an importer for JDA blueprints, so that I can snarf the entire distro in a simple way. otherwise I'd have to enter each blueprints terminals and functions manually.
2. Finally get around to implement "droppability", so that you can make a form adn justd rop elements into it, such as in the OAT demo.
3. (again) finally just implement the possibility to add atomic HTML elements, which can be wrapped by infotrons, et.c.

What was odd that in just a couple of hours, I had managed to implement the wholesale downloading of blueprints from source files. I've made some ugly shortcuts here and there, but all in all I can now eat all official blueprints and make them available as configuration for every element in the visual editor. Rather nice, says me.

The droppability I had done before, in an earlier incarnation of the editor, so I just copied the code, barely touched it up and it worked (as long as you remember to not have postition:relative elements :)

The hardest part is oddly enough to let the user / developer choose from a selection of html elements. The reason this is hard is that many elements have spscific attributes which are unique to them and which without the element itself is useless . The src tag in img, comes to mind, as does the type in input. That means that I'll have to do a large hmmm on how to implement the choices in the most simple way.

But two out of three for a saturday evening can't count as bad. We had kids over at the house the whole day keeping _our_ kids busy, so under those conditions the code almost writes itself :)

Friday, March 9, 2007

Simplicity in code

Since I wrote my four rules, I've been looking for other people sharing the same sentiments. The rules were borm out of an increasing irritation of the complexity of todays software systems.

Today I see the following;

Sometimes what we are working on is complicated to understand, code and create. My argument is not to simplify the requirements for what we are doing but to find the simplest, most effective way to implement them
On the blog of Andrew Wulf / The codist. It's the most profound counter-argument when starting to talk about simplicity in softwared evelopment. It's not that we should do less, but to do it better. There is a difference in efficiency between a kitchen where yuo make your food with burning wood and hadn-drawn water, and a kitchen where you have an electric oven and running water - een if they "do the same thing". I fel that we don't use the technology we hav to reduce complexity enough.

Thursday, March 8, 2007

The quagmire of success

Augh! Another victory like this and I'm lost! I've foudn and removed some preconcieved notions in the stuff that manages connections between infotrons now, and also squashed a bug which swallowed the character '+'. Fairly bad for anone using string concats in js. Now I've finally connected my test button with my test textarea :-)=

Also, the styling (backgound color, font family & size, et.c.) is consitently changed all the way down the component hierarchy in the infotron you style, so that if you have a Form, and change the font, the font change will also affect all labels, et.c. Now, I jsut need to add a Form :)

Actually, now that things start to work in the framework I'll do a batch import function inthe blueprint manager which will let me drop all the existing blueprints from the distribution (Check the Wiki) in no time flat.

Sunday, March 4, 2007

Home at last!

Argh! What my left foot held was an empty reference to user identity in the PHP backend. After I got that nixed, things went forward pretty quickly after that and at the moment I have finally reached my first goal - to be able to first create and edit a blueprint in the blueprint manager, and then create an instance of that blueprint to a newly created element and make it run. It feels sooooo good :-)=

Friday, March 2, 2007

pit stop

It amazing how simple things expand when you get closer to them. It's very much like watching a road from a hill and imagining how simple a walk it will be compared to the trek you've just endured.

Once you get to the actual implementation of controlled infotron creation and the hidden specters in the PHP/MySQL relationship you tend to look back over the shoulder to the more simple times of yore, when you only had to contend with agressive colorpickers and the like.

Anyway, here I am - in the middle of something workable. I've nominally finished the element configuration part. The place where you can tie functionality (as in a datagrid) to an element, but more importantly, it's where you can tie together the output of the current elements infotron with the input of another. It seems to work :)

At the moment I follow that I can create, edit and save a function of an infotron blueprint, and as I save it I log in my PHP backend that the correct function body has indeed arrived.

Nontheless, inside MySQL, a syntactically correct function string resides (where one wasn't before), but void of logic.

It's not that some control-character have terminated the javascript function body string at some point and left a dangling end, or that nothing got through, but that just the lines containing information are lost. It's a puzzle, but as with most puzzles I expect left foot to hold the missing piece, when the mystery unravels.

And a very nice friday evening to you too.

Wednesday, February 28, 2007


One of the basic things I want to do with the visual editor/composer is instant easy-to-grok visual changes, for instance choosing _just_ the right sublime background color for an element.

Recently I had been using the rather plain colorpicker in the current dojo branch. Not incredibly simple to use (but OK, what the hey. It's no TreeV3, so who am I to complain?) but lacking in choices. After that I found a colorpicker with a larger variety of colors to choose from, but still it wasn't enough.

Then I saw what I knew I had wanted all along, a 'photoshop' style colorpicker. In Javascript.

The first one I found was NoFunc's DHTML ColorPicker, at http://www.nofunc.com/DHTML_Color_Picker/ which is lightning fast and the closest thing to assembler I've ever seen done in Javascript. I tried hard for over two days to make an infotron blueprint out of it, but it was just over my horizon. Go ahead. Check the source. make my day :)

The second stop was a completely wonderful article at webreference.com called "How to create a color picker in javascript". It's really well written and it produces the above result, and then some. Read it at its entirety at http://www.webreference.com/programming/javascript/mk/column3/index.html

I had to undo some rather advanced stuff that mark Kahn, the author, had done to speed up things a bit (a micro- templating engine which stored a cached copy of elements) to make it work. Maybe I'll redo it when I'm smart enough :)

Anyway, the point is that I know have a nearly-correct (I've broken the "minitoolbar" functionality somehow) Industrial strength colorpicker for all created elements in the editor, and that feels just great.

Friday, February 23, 2007

JDA is out!

finally, JDA 0.95 has been released to beta-testers! The current dox are nice, but a bit lightweight. I hope to alleviate that in the coming week (While Slim is having a well-earned vacation) with some more intermediate examples. ANyway, nice to finally look at the _real_ code. I'll compare it with my own during the weekend (drinks and wives permitting :)

Thursday, February 22, 2007

Four simple Rules

I've been thinking a long time about why most web development stinks so totally, and I usppose JDA is one answer to it, and a generic, scriptable middleware specification will be another. Toady it struck me that I needed to lay down the rules once and for all, so I don't forget them. They are the following;

1. All functionality that possibly can be implemented on the client side shall be implemented on the client side.
2. All communication with the server middleware shall be constrained to service-interfaces; For instance REST.
3. No part of the client shall be evoked, generated or templated from the server-side. This rules out in-line conditional HTML in JSP, ASP, PHP, et.c.
4. The logic making up the server middleware will be implementing only the following functionality;
  1. Security
  2. Database access
  3. Cross-domain proxying for remote resources implementing only a) and b).

That's all.

I realize that this flies if not in the face of common wisdom, at least up the panties of common practices.

Tuesday, February 20, 2007

The worlds quickest refactoring

..well, maybe not. But my quickest at the very least occured today. I was using a dojo FilteringTable to show all blueprints in the database, so that they could be sorted on each column properly. Now that I've switched back to the visual component view (the main view) again where you actually create and resize items on the page, I needed a similar view for choosing which blueprint to instantiate (create an infotron) in the component.

I thought that possibly I could just make another blueprint of the logic which hold the Filteringtable itself, and then pass JDA messages back and forth, but I wasn't clear on how to wire things up.

After maybe 30 minutes, I had broken out all the code which created and populated the FilteringTable in a separate blueprint; The logic which defined the columns and column types was passed as a property, as was the css classes for headers and body elements. The actual data in the table was consumed in an input terminal, and when any row is selected, the row (the whole object, skinny legs and all, since we're talking javascript function calls at the bottom of everything here) gets put to an output terminal.

So after just half an hour I had encapsulated the whole logic of using a dojo filteringtable. I also pass as property the DOM node which the table should replace when created.

Then I edited my component manager, so that it created a new instance of the FilteringTableWrapper (which I finally called it - not a very daring name, but that's life) dynamically, by calling __star.addInfotron, where properties and component wiring back to the anager itself was arguments, and as always... it just worked.

I really, really hope I never get used to that feeling. As soon as I can make a generic security and storage microkernal specification with J2EE and PHP implementations, I'll never code anything but js again, promise :)

Monday, February 19, 2007

Getting closer to real usability with JDA composer

I have been gaining real ground the last couple of days with the JDA composer. The basic idea is to have reasonable defaults, and to make it easy to let a newcomer keep to the road as much as possible. The goal right now is to make it pssobile to create full javascript blueprints and then define infotrons based on them in the visual page editor. Right now the following works in the blueprint editor;

1) You can create and delete blueprints, which are stored on the server
2) You can add or delete input terminals, output terminals and properties for each blueprint
3) When creating an input terminal whose handler functions deos not yet exist, a stub function will be created.
4) When attempting to load another blueprint when the current one has been modified, the bp editor will warn the user.
5) The same goes for removal of terminals and properties.
6) Function are edited inside small dojo Editor2 widgets

And it actually looks kind of good :) If you read this, please try it out and comment. The address is http://www.mashupstation.com/station/users/admin/jdacomposer.html

Friday, February 16, 2007

Goodbye slashdot

I've been having slashdot as homepage for my browsers since I don't know when. I've suffered through periods of creative stupidity regarding OO languages, I've survived the news-breakdown into different sections, but today I've finally had enough.

Two things;

1) They've now obviously been sponsored heavily by Intel. Intel is neutral evil, so that's kind of OK. But still .. as an advocate of open-source thinking and all.. it doesn't sit right to suddenly have an "Intel opinion center" - obiously a product of Intel PR people. Give it up allready!

2) Takin M$ money and showing Novell ads. I mean - really!!!! Novell ads! After what just happened - with a straight face!.

I'm taking my hat and leaving, Slashdot. I don't think I'm alone in doing that. Have fun in the opinion center.

Wednesday, February 14, 2007

Learning Dojo the hard way

The last days have let me come quite far on the blueprint manager. Since I finished the visual generics, so that you can crate, move and resize elements manually - as well as edit basic style attributes suchas abckground color, fint, fint-size, et.c, I've been moving on to creating and editing blueprints.

Blueprints - as you may not know yet :) - is stand-alone javascript "classes", which consist of a function call to BLUEPRINT(), which is defined by JDA for blueprint registration, and is composed of three parts;

1) Input and output 'terminals', which let the infotron based on the blueprint connect to other infotrons,
2) Properties, which are just named variables which can be filled when the infotron based on the blueprint is created adn wired.
3) A series of functions which handle startup, shutdown and incoming messages on each input terminal. Each input terminal specifies the name of the blueprint function which handles its messages.

And so far I've managed to implement named blueprint creation, which calls MAYAs UUID service from the php backend which gives the blueprint a unique identifier, and I'm also toying with typing each infotron (Service, wrapper, logic, et.c.) to make it easier for people to browse each others blueprints when crating services.

One controversial feature I'm working on is to create and manage each function in the blueprint more "wizard" based and to highlight and perhaps draw dotted lines between related items (properties when used, for instance), rather than allow complete free-form editing. We'll see what happens.

Friday, February 9, 2007

Pros and Cons of the Flu + return of the dojo

The last week has been filled with high-temp kids and several trips to the hospital due to eye infections. Things have calmed down reasonably now, but this years flu was really heavy, to say the least.

The upside of this is that I've had several days with babysitting very calm and mostly sleeping kids, which have given me more time to code over a short period of time for almost ten years!

This has resulted in getting a stable codebase for the JDA visual composer. I had a lot of problems writing my own pop-up component which attached to other components and showed edit, deltete, et.c. menus. Finally I saw that dojo had just the ticket, and by throwing away maybe three days prior work and copy-pasting for half an hour I got a far better result. Please check out the right-click popup menu examples at the dojo demo site .

And again the power of JDA shines through. I realize this sounds slightly silly if you haven't tried it yet, but while I've been up in the attic doing all sorts of silly stuff with my code, the html page itself is almost unchanged, and the only two components were ever affected (OK, three tops :), leaving the other provably sound. At other times, it's easy to resist trying something new because you feel you don't remember enough if all other small changes to be 100% sure you don't break anything.

Now I know. That's difference.

Thursday, February 1, 2007

Resizing woes and some gentle dojo-bashing

I've been busy trying to get simple moving and resizing of visual components to work in my new JDA editor , which if not a tour de force of JDA, at least will let people create composite infotrons fairly quickly, and to browse and share them with others.

However, I really didn't want to use any toolkit that messed my current codebase. Call me crazy, but I really dislike having written something fairly complex in plain vanilla javascript, and then have it break because I wan't a little eye-candy.

Anyway, my two prime candidates were dojo and jQuery. I've been using dojo on and off for some things before, but really wanted to try out jQuery and the incredibly beautiful Interface fx library, which had almost everything I wanted in form of widgets and effects.

At the end of the day (and a half), though, I just couldn't make Interface/jQuery work for me, and I think that part of the reason is the fact that jQuery feels a little like coding forth or something. You begin with a lookup function and then tag a lot of other functions on it. I've seen things like it in prototype as well, and it _looks_ powerfull but it works contrary to how I think.

So, disgruntled, I tried to get resizing and drag-move to work with dojo instead. This should have worked OK, since dojo is über-explicit about most things. But sadly dojo, rounded down, completely lacks documentation. Despite this, I managed to find some examples here and there and finally had components which I could move about and resize.

The bad part was that resizing also triggered moving, and I could not figure out why. I created a div, which I used in a call to new dojo.widget.ResizeHandle. I also separately created a new dojo.dnd.DragMoveSource with the same div, and despite the fact that dojo's own FloatingPane (for instance) managed to both be moved and resized correctly, I couldn't find any clues in the code to tell me how they did it.

I would have wished to find just one framework/toolkit which I could use for everything, and dojo looked the part, but slapped my hand when I tried to get comfy with it. I then turned to an old flame; Walter Zorn's DHTML drag and drop library.

Walter needed only two things (apart from including the script in the page);

1) Initialize the library by having SET_DHTML(); called in a script tag somwhere before getting to business.
2) Whenever you have any element you would like to move around (position:relative, for some reason), you just call ADD_DHTML(this.id+RESIZABLE); where this.id is the DOM id of the element, and RESIZABLE is a magic string Walter have defined which also lets you resize the element by holding donw SHIFT while mousing around.

Two steps. None of the particularly hard to follow. Now _that's_ usability.
(P.S. I still use Dojo for the fisheye menu. That widget is actually quite OK as well :)