Finally, I managed to write a server-side JavaScript (esp) in Sling that gave back a correct JSON structure of the node and its children. With a little massage it made a great input for a Dojo tree structure;
This is not available on the Bunkai PoC site, since it needs a backend which can provide an url that spouts JSON, but I'll think about lciensing Bunkai so that you can download it and make it run on your own backends.
The next step is to make it possible to change Sling url, path and to provide create, load, edit and save operations from the tree to the Sling backend, which, Sling being what it is, will be a breeze in comparison :)
This was the hard part.
Cheers,
PS
Comments
On a related note, I just found a GUI-builder for Ext.
http://tof2k.com/ext/formbuilder/
That's why I had the communicating windows src <-> render where changes goes both ways.
Have you seen WaveMaker?
http://www.wavemaker.com/products/demos.html
It is a bit like the ext gui builder, but can import MySQL databases (or WSDL) as services, with a live layout, with Dojo 1.0 as front-end. Pretty much like the Gui builder otherwise.
Now, take Swing and Matisse (in NetBeans) which is probably the most advanced GUI-builder for Swing. It never fails to completetly break down if I change as much as a single line of the generated code. The problem domain (Swing) simply offers too many permutations of code to be able to create a robust builder. Better then, I say, to hide as much of the generated source as possible.
Well, tastes are different, I even change my mind on this topic about once every week.
WaveMaker looks cool though.
I also feel that one of the largest problems the visual builders face is to generate good code, be it html, js, java or what have you.
And most probably the problem can be solved correctly in both approaches (visual only or src<->vis), if only we know what correct is :)
I did a horribly complicated stint which was fairly hard to use and looked ugly, last year. And when I tried to dig down to why it wasn't well received I realized that programmers (including myself) are very literal people. We know the magic words, and how to (hopefully) put them in a row to make things happen.
So a visual builder is in some ways an anathema tothe very core of a programmer, because it hides what is happening. That means that even though a visual build tool would be very helpful to a coder, it also makes him (me) nervous) by hiding what's going on.
By exposing changes done visually as immediate code changes as well, I think that you can achieve some kind of trust level with the programmer as he/she tries out the tool the first time.
Otherwise I feel that there's a risk that the tool, no matter how beautifully done (I have no experience with that, I'm just extemporizing :) will be given just a cursory glance, and then be left behind. I'm talking from a kind of marketing standpoint I guess, even if I'm leaning towards open sourcing things in the end.
But I think that the Ext gui builder (which I've fiddled some more with, and like the more for it, actually) could show source changes with so much effort, depending on how much of a metadata model they've build under the hood.
That was one of the first design choices with Bunkai, actually, to use just source as the 'metadata'. So that there's nothing there which isn't in source.
Of course, I'm lying a bit, because Google API's have to be preloaded, and there's a whole page for the widgets to live in, et.c. But that's the basic approach.
Cheers,
PS