Monday, November 26, 2007

DragNDrop done - with snapback

OK, I have a slight off-by-2-px 'feature', but other than that I have easy-to use dropzones, with restrictions, that animates a snapback of the element not allowed.

Check it out at http://apps.facebook.com/backface

Cheers,
PS

Thursday, November 22, 2007

The library formerly known as Prince

So, I didn't get to call my facebook widget library 'backface' after all, when I tried to submit it as an app to facebooks official application library.

Therefore the name of the library is now the subject line, or TLFKAP, Just so you know :)

Cheers,
PS

Wednesday, November 21, 2007

Backface facebook javascript widget library now support drag AND drop :)

I had a request last night from Sam Dorman from theleague.com who needed not just dragging stuff around, but also being able to drop them on specific areas. Willing to support the development with a small donation, I felt I could not say no :)

At the moment, I am nearly there. What is supported, is to add any element in the page as a "dropzone", which will be called back on its onDrop function (if specified) when any draggable element is dropped on it, like this;


var pane = createPane(document.getElementById('bar'));
Drag.init(pane);

var zpane = createPane(document.getElementById('baz'));
var foo = 0;
Drag.addDropZone(zpane);

Drag.init(zpane);
zpane.onDrop = function(el)
{
document.getElementById('baz').setTextValue("drop "+foo);
foo++;
}

This sample code (taken from the downloadable demo app) creates two panes (adding dropshadows) out of the elements with ids 'bar' and 'baz' defined in HTML on the page.

It then lets both be draggables, by the calls to Drag.init(element). The createPane function returns the resulting element which holds the content element which was the argument to the call, so it is just another 'div'.

Then we add the resulting div from the pane creation as a dropzone, by calling Drag.addDropZone().

At the bottom a function is tucked onto the zpane div element, which will be called whenever any draggable is dropped 'within' the dropzone element.

What is left to do is to support draggables which are not allowed in a specific dropzone, and then animate a "snap-back" of the draggable in such a case, to its previous strat-drag position.

This is not rocket science, but it will probably not be done today :)

Please comment on this to tell me what you would like to see next.

I'm planning to add resizing to panes, but maybe other stuff is more interesting. I'm almost done with a simple paging table with 'automatic' edit links for the current user, if the same as a defined field. Maybe next week.

Zipfile which include sample facebook app is here; http://supercodex.com/backface/backface.zip

Monday, November 19, 2007

backface update


I just added a feature to the backface demo, so that you can create your own divs for demoing purposes, and which also break up the process, so that it is easier to see in the demo source code how to create just a pane, just a draggable or just a fader, for instance.

Sunday, November 18, 2007

The coming frameworks; SOFEA, JDA, Squirrel and a taste of the future of web design

Yesterday, I saw that someone had created a full IoC container framework in Javascript, called squirrel. I have written (at length) previously about JDA (Javascript Dataflow Architecture) and its benefits for creating rich clients in Javascript, sometimes referring to it as "Spring for Javascript".

However, JDA is focusing more on being a pragmatic, easy-to-use (and understand) messaging kernel, for the web page where the rich client resides, rather than a full-out IoC implementation - which Squirrel certainly is!

The goal of both frameworks are of course to force the developer (Yes, that means you :) to modularize code, and not sprawl all over the page out of laziness (as usual). JDA is the more terse alternative, which defines functions called "Blueprints", with input and output "terminals", where each input terminal has a handler function inside the blueprint.

Blueprints can then be instantiated in the web page, and their terminals can be connected to each other (which makes it very easy to switch stuff out, if you change your mind about something) using properties in the HTML tags which JDA scans for after loading.

What I've seen in Squirrel so far (I must admit to just have read through parts of the code and examples), is that it very much resemble traditional Java containers like Spring or Hivemind. As in JDA, it uses the web page as a natural presentation layer, and pushes all functionality into separate Javascript files. One of these is a Mian defintion file, which takes the place of the same XML config file in (say) SPring. it looks like this;

$(function(){
var oCD={
'model':{type:Model,props:[{name:'view',ref:'view'}]},
'view':{type:View,args:[{ref:'model'}]},
'controller':{type:Controller,args:[{ref:'model'},{ref:'view'}],props:[{name:'containerContext',ref:'containerContext'}]}
}

var _oContainer = new IContainer();
_oContainer.load(oCD);
});

It relies on the model, view and container obejcts to be defined separately, which enforces a very strict separation of concerns. What is good about this is that it makes the transition to Rich Client Javascript programing easier for a programmer used to code in Spring, for instance.

The downside is that Squirrel requires (or seem to) a lot more files and "framework objects" than JDA do, which might make it harder to code in.

My remaining impression of Squirrel, though, is; "Wow! They actually did it! :) ". One of my first posts on this blog was actually about a joke about creating a "real" IoC container for Javascript.

Moving on to a comment on the Squirrel posting, I found a link to something absolutely wonderful, which seem to have missed my attention when it came in October; SOFEA - standing for Service-Oriented Front-End Architecture.

SOFEA is an architectural style which in its definition criticizes (and manages to make a very good definition of) the current web frameworks, and (as they say) "none of them satisifes".

If I would summarize the SOFEA proposal (which I'm currently attempting) I would describe it as a clear analysis why generating the client out of the server, and forcing presentation to predefined pages and actions are inherently bad, and inefficient.

Incidentally, this ties very well into my own four principles of web application design : )


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)
And just like the SOFEA proposal this scraps all major web application frameworks like JSF, Struts and the like (even tapestry, which i kind of like still ..)

Cheers,
PS

Thursday, November 15, 2007

Introducing the Backface facebook widget library :)

So I was bored last night. Everyone in the family save the cats were asleep and I was frustrated that my facebook apps looked so criminally ugly. Here I sit writing fairly complex Javascript wizardry for common browsers, and yet I'm unable to stop the msot simple facebook app to look like something nasty.

I knew that FB allowed most Javascript functions, even if they rewrite all id references, and don't let you peek into the contents of elements, et.c.

I started to hunt for old framework-less Javascript samples for dragging and fading, and managed, despite what I would have thought from the beginning, to actually make it work. So now I have draggable "panes" with drop-shadows and everything, inside the canvas page of a facebook app. I don't think there's much to be done for the profile page, but I'll check it out..

Also, I managed to make a separate library of it, so if you're using PHP for you facebook app, you're free to download and use it. I'll probably put a LGPL sticker on it, but right now I just want to see if anyone finds it useful.

You can download a zipfile containing the library and a small demo page here;

http://supercodex.com/backface/backface.zip

A live demo of the [sic] demo is here (facebook login required);
Not that since the demo facebook app is part of the package, I have just copied code from another project that forces you to add it. I have no ads in it. You don't *have* to look at it, and you can almot jsut as easily d/l the zip and create you own demo project in two minutes flat :)


http://apps.facebook.com/backface/



Cheers!

Thursday, November 8, 2007

Return to dojo revisited

Argh. I don't know how to say this, but.. I had an idea that I should check out jQuery and Ext and maybe spliff upp my interface *so that it looks nicer* to be able to lure people in and actually try things out.
After a week of that, coinciding with the release of dojo 1.0.0 (with the ├╝bercomplete Grid component), I felt that I had have enough of hunting about for non-documented css files or cryptic references.

The place where dojo really shines is that all components, widgets, what have you, are self-contained and auto-load their own resources. I had relied so much on that so I didn't realize how advance dojo's resource system really was.

In jQuery for instance, it's possibly to write a plugin (for a kind of cool-looking menu, say) which refers to half a dozen of css files, which have been released in various version.

In dojo, you cannot do so. If you write your own widget, dijjit, whatever, you define the html/css look and feel right there and then. More or less, bear with me here.

Anyway, the moral of this story is that in just a couple of hours I'm almost at the same point with dojo-1.0.0 as I was with jQuery for a week. OK, I know the API, but anyway. The new release looks way better as well :)

Cheers.