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+"'> ";
dojo.widget.createWidget(el.id);
var foo = new dojo.dnd.HtmlDragMoveSource(dojo.byId(el.id));
foo.constrainTo(dojo.byId(this.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.