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