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

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

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(; where 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 :)