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