Tuesday, January 29, 2008

Sling tutorial online!

OK, so we have to wait just some more days for a downloadable Sling version with the simple Launchpad front-end, but while we're waiting, Bertrand Delacretaz has written an excellent tutorial here; http://cwiki.apache.org/confluence/display/SLING/Discover+Sling+in+15+minutes

Even if you're not willing or capable of using subversion to download the latest build (instructions after the link), it's a very easy to read article, which gives you the beef on why Sling is cool and how to get some quick stuff up and going, like inserting your own server-side javascript extension handler, or mounting sling as a WebDAV share.

Remember, Sling is as Jaxer as your get, but with WAR-file droppability and potential out-of-the-box groovish Java API integration. Watch this (or that space)! :)


Sunday, January 27, 2008

Web Måndag

Isn't it great when things happens at a quick pace? Just this week I got to know about Web Montag (Web Monday) which is a very web 2.0, grass-roots casual series of presentation & mingle events.

Anyone can host a Web Monday, and anyone can participate. It's built upon a "speakers corner" kind of ideal; You contact tho host of the event and get you ten minute presentation, and then there's some kind of main event from some company, or just some person who's got an interesting project.

I've been lucky enough to get my employer to sponsor Beer, Pizza and WiFi for the occasion, as well as somewhere to be, so I basically just have to host, meet nice people and have a great time. Yes, do some speaking and waving at screens as well, but that's just fun anyway.

Due to the fact that my wife rides on Mondays, I had to put the event the first _tuesday_ in every month instead. Web Monday on a Tuesday, no less :)

This first event, the 5th of February will focus on Dojo, Thin-server technology and the newly released Ajax server Jaxer, from Aptana, which I'll do an hour-long piece on.

If you live in, or know that you'll be in Sweden the 5th, and want to go to the event, add your name to the Wiki page; http://webmontag.de/doku.php?id=stockholm_sweden So I know how many beer to ask for.

Se you there,

Friday, January 18, 2008

Sling in the new year

After I had my first release of Bunkai up and running, I was contact by Lars Trieloff , of the Apache Sling project. We discussed whether Bunkai could be used as a resource editor for Sling.

I've mentioned Sling a bit in a previous post, but to sum it up (from my perspective :); Sling is the following;

1) Can be deployed as stand-alone or as Servlet (It includes Jetty - which is a nice, slim application server)
2) It's OSGi compliant, and can be configured with the OSGi Admin Service
3) It's a generic resource tree, stored in Jackrabbit, a JCR implementation.
4) All resources (web pages, pictures, scripts, et.c. are referenced using REST principles, leveraging HTTP GET, POST, DELE, et.c. to manage resources.
5) All resource stored in Sling can be scriptable *in JavaScript (or JRuby, et.c.)* on the server.
6) All resources can be accessed using standard WebDAV

So what Sling looks like to me, right now is the perfect thin-server. Sling can be a JSP/ish Server-side Web framework, if you want, but it also fits perfectly into a role where the server-side scripts only implement business logic, and format data, which is requested by the client.

So if you're experimenting with JavaScript RIA building, and are trying out different thin-server alternatives, do not miss Sling.

What I'm doing at the moment, is to modify my Bunkai Dojo Javascript widget editor to have an extra "Resource" tab, which list Sling resources on (currently) localhost. The idea is to store Bunkai inside Sling (I just copy files over WebDAV which I've mounted locally on my Kubuntu), let the user access a Bunkai url on localhost:8080/bunkai.. or something.

Then all HTML files or *server-side javascripts* you'll be making, will be saved at the place in the resource tree where you've created your node (add/deleet/modify of nodes is very simple in Sling as well, being RESTive). So you get a thin-server, REST-like database, and a simple client/server IDE in the same box! :)

Stay tuned. Further bulletins as events warrants.

Wednesday, January 16, 2008

Alternatives to Server-side Web Frameworks


Changing tack from previous posts, this article gives examples on how an application can be made without using Server-side Web Frameworks, thus reducing complexity and lowering costs.

I got many good replies to my recent post "The End Of Web Frameworks". In it I argued for the need to bypass all existing Web Frameworks on the server, to avoid their high complexity costs.

I realized the other day, on a related note, that Ajax in and of itself actually means not using Server-Side Web Frameworks. Think about it; Asynchronous JavaScript And XML which implements out-of-band channels where raw (XML) data is transferred between browser and server. Where in that proposal do you see the need to regenerate the client (again, and again) out of complex config files on the server?

Instead of just bashing though, I thought I should devote some time to explain what the alternative(s) are, and how one can go about designing an application without retorting to using Web Frameworks (WFs for short).


I have outlined fairly well the reasons for removing the web rendering from the server-side completely, and instead construct modular clients in JavaScript in my last post on this subject . The main points are the following:

1) Current server-side web framworks are very complex.
2) The reason that they are complex is because they try to generate a client out of the server.
3) If you remove the web client generation complexity from the server, the server becomes simpler.
4) If you program a client _on_ the client, using state of the art client frameworks, you get a simpler client (than the server-config-file client-in-parts, just add water, you had before).
5) This is a big win

The Client:

To begin with, on the client, nobody in his or hers right mind tries to reinvent the wheel and write hundreds of separate function supporting cross-browser oddities (read; IE) from scratch. Since several years ago there exists mature, well-tested cross-browser compatible "Ajax" libraries with copious documentation.

Good choices when coding your in-browser client;

1. Dojo 1.x
Url: http://dojotoolkit.org/
Reason: Dojo has a simple markup language, which the dojo 'runtime' will parse when loaded. It amounts to adding a tojoType="" tag to existing HTML markup, which make compact code.

Also, and more importantly, Dojo has very well designed data-binding structure, called dojo.data. Most high-end widgets such as Tree or Grid support reading their data (and sometimes writing as well) from a datastore, which can among other things be a csv file, an XML-generating service, or a custom component. This makes it easy to swap data sources, and presentations, without ever involving the server-side.

Dojo is also maybe the largest open "Ajax" framework in existence today, sporting encryption, Google Gears integration, cross-browser 2D and 3D graphics, charting, a powerful template-based, modularized and easily extensible widget system, complex Drag and Drop features (even in Trees), i18N support (currency, date, time, et.c.) for widgets and even support for widgets who have to display data right-to-left like Arabic, Japanese, et.c. Disclaimer: I'm a fanboy :).

2. Ext 2.0
Url: http://extjs.com/
Reason: Ext is perhaps the most polished "Ajax" framework, having very slick design and pixel-perfect looks. Ext also have powerful data bindings to its widgets, just like Dojo.

3. SmartClient.com (commercial but with LGPL client library).
Url; http://www.smartclient.com
Reason: The SmartClient guys have fairly covered all bases. They have about as much functionality as previously mentioned frameworks, but with the added twist of WSDL data bindings. This means that their widgets can read directly from a web service, or you can make a form which calls a web service directly. It is really quite a lot of stuff they're releasing as LGPL, so if you're missing anything from your current choice du jour, it might be a good idea to browse about the SDK. No, we're not affiliated, I just like what they're doing.

4. YUI (Yahoo User Interface)
Url: http://developer.yahoo.com/yui/
Reason: Very good data-binding widgets, such as their datatable (with good pagination examples), et.c.

Url: http://www.tibco.com/devnet/gi/
Reason: TIBCO has not only a very enterprise-y approach to building clients; Treetables (Matrices), extremely good support for WSDL Web services and a free visual GUI for creating browser-based clients.

The reason I'm not mentioning jQuery, Prototype or Mochikit and others is that I would like to emphasize the need for data binding and management as a key issue for a client-side framework, which is missing in the more basic ones, where the emphasis is more on design and effects.

The Server:

OK, we still need data from a server, of course. And if we place the client on the client, we don't need no client-code on the server, leaving us with a much more specific and "slim" server-side. Examples of servers which have well-defined interfaces to browser-based clients are;

1. DWR (Direct Web Remoting)
Url: http://getahead.org/dwr/overview/dwr
Reason: DWR is one of the slimmest offerings out there, which does the following, in their own words; "DWR is a RPC library which makes it easy to call Java functions from JavaScript and to call JavaScript functions from Java (a.k.a Reverse Ajax)". It is easy to get started with and fairly low on the configuration file department. It uses one XML file to map incoming queries to Java classes. It only returns data. Sweet. :)

2. Sling (RESTlike JCR implementation)
Url: http://incubator.apache.org/sling/site/project-information.html
Reason: Sling is a fairly young project which implements the Java Component API, which looks like a traditional web server, serving static pages from the outside, but where focus is on resource access and not page access. Each component can be implemented as a script (Rhino, Ruby, JSP or what have you). This means that Sling can be used as a stand-alone or servlet-droppable application which automatically maps requests for resources to specific scripts which generate data, thus making it more simple to focus on business-logic only on the server.

3. DIY (Because you're just serving yourself data anyway)
Url: http://localhost/yourapp
Reason: You get started in no time flat (if you're using scripting, like JSP or PHP). A little longer, perhaps, if you insist on compiling and bundling stuff up. You will not reinvent the wheel again and create yet another framework. Why? Because the client resides in a separate HTML file, which loads it's js libraries by itself. You will only implement security, business logic and serve data!


The SOFEA team has a very detailed description of why server-side web frameworks are complex, in an excellent PDF.

Bob Bufone at rockstar apps has a very succinct and insightful post on client vs. server-side frameworks, which is a must-read. He ha a webinar on the subject with a downloadable PDF as well.

Per Olesen has also done some research into which server framework to choose for the development of Rich Internet Application apps, which is an interesting read.


Monday, January 14, 2008

Bunkai 0.1 - Working Proof of concept

OK, I really wanted to have a drag-and-drop editor with resizable widgets for dojo. However, that is a non-elementary target, it seems.

Because I'm constrained by the absolute need for source code editing, I'd have to scrub the generated tags for DnD and resizing on the way over, which is a mess (I've tried it the whole last week).

So, I've decided to drop the fancy stuff and just release a hopefully simple to grok proof of concept thingamajig.

What Bunkai is now is the following;

1) A source code editor for Dojofied HTML markup, meaning normal HTML with extra tags that the dojo parser uses to instantiate widgets, et.c. when necessary.

2) When pressing the 'save' icon in the EditArea editor, the source will be dropped in the 'screen' portion of Bunkai, which will try to resolve any dojo library requirements, so that for instance the Calendar widget gets loaded before it's used, et.c. This works moderately well, since there's no 1:1 relation between loadable files and widgets. I'll have to write some extra meta-stuff for that I suppose.

3) When you drag (Yes, I still have _some_ DnD :) a dijit name from the rightmost list, you can drop it onto any existing widget, and it will be appended to it - also all changes here are communicated to the source code.

I haven't fixed widget properties yet, but my next to-do item is to have a general dialog for filling in properties (that are critical to provide for certain widgets), like how wide a bar should be, or what ratio of the parent container this container should take, et.c.

But anyway, as a first PoC, it's almost usable. My goal is to make a visual Dojo editor that can be used by a Dojo novice, and has a shallow learning curve. As it is, I think it's hard to use if you haven't done dojo markup before.

Please tell me what you'd like to see, and I'll put it on my to-do- list (Yes, I know. I'll try to find time to make a widget of Cristophe Dolivet's EditArea).

Ah yes, the Url is here; http://supercodex.com/bunkai/bunkai/bunkai.html

Sunday, January 6, 2008

Bunkai got widget list and drag n drop

This is why i like to code in JavaScript. Hard things are easy, just like that.

Having fooled around for a couple of more hours today, I've managed to get a list of draggable widget class names going. You can then drag one widget/dijit onto the main 'screen' area, and the widget in question will be instantiated. It really looks very nice, even if it's not rocket science.

Next step from here is to use the source code in HTML as the respository for all changes (even drops from the widget list), so that it's easy to see the skeleton code generated by Bunkai,a dn to add your own stuff and get it on the screen quickly.

Bunkai - A Dojo 1.x interactive workbench

If you've followed my blog for a while, you know I have a pendant for visual designers. My last project - JDA Composer - tried to do too many things at once, and so it was hard to understand at first glance. Now I'm trying another tack, restricting me to just one thing - Dojo.

My goal is to create a small, comprehensive editor which shows things from two mutually communicating perspectives; 1) the html/js code editor, 2) The 'scree' area where dojo widgets show up.

What this means is that you'll be able to write something in the editor, click save, and it will be rendered immediately. But it also means that the rendered widgets will be editable (according to what properties the widgets (OK, dijjits :) have defined, moved about (if not restricted to a layout container) and resized (again, if allowed by layout). All changes in the visual side will immediately be communicated back to html source code in the editor.

That way, I hope it will be simpler to understand, and as a programmer you'll feel that you're in control, even though there is an element of visual composition.

Right now, I have only completed a proof-of-conecpt implementing the first part, which works quite all right. It's just two days work, after all.

Wednesday, January 2, 2008

The End of Web Frameworks

Coming from a fairly serve-centric background (CA coding, wiring together stuff on the server-side, etc.) I abhorred doing any "web-work" for a long time. It felt cheap and not particularly interesting. Not that I checked it out, though.

I knew it was cheap, because I didn't work with it. If it would have been worth a second glance, of course I would have done it years ago, right? Since i worked in the field I felt I had a fairly bulletproof opinion on just about anything connected to the server-side, even if I had no direct experience working with it.

It felt safe and reasonable to shoot down stuff based on general assumptions and theoretical arguments, rather than giving things a decent spin with a 2-5KLoC actual project, so that I would have an actual idea of what I was commenting on.

Sadly, it seems I'm not alone in this endeavor. I recently did an informal poll at a LinkedIn forum, asking how many people had ample experience with both PHP and Java (say, at least a major project in each - major as you will) - and I came up with a lot of comments, but no one actually having had the dual experience I asked for. There were the usual comments that reduced one or the other side to smithereens based upon no real evidence at all, of course.

I think the reason is that there are very few programmers that do cross-train. We have corporate agendas, certifications, gazillions of reasons to not rock the boat (and get back home in time to dinner - a whole bunch of things that make you code in just one language.

The problem is that the world of programming is in constant change. New ideas pop up all the time, and looking in the rear view mirror, not all languages or frameworks were completely spot on in their 1.0 revisions.

So it is fairly safe to assume that the state-of-the-art way of doing things four years ago (for instance) might not be the most cost-effective way of spending time coding.

The last three years I have for various reasons done a number of web-related projects (for my day job), ranging from handmade Tomcat-based apps, distributed over a couple of machines, to fairly complex sales management systems done in Tapestry, to pure Javascript Ajax-works.

Then I've done a number of small to medium sized (~5KLoC) projects in my spare time in just JavaScript.

To try to round off this post, I've learned the following things;

1) It is _way_ easier to code in JavaScript, than in Java - doing precisely the same things (when you can).
2) The more logic I put on the client side (The browser again, natch), the easier my server-side components gets to write and maintain.
3) When writing JavaScript, I usually find myself doing it in just Vi, Kate or Wordpad, depending on which machine I'm using. There is no need for a big, fay, slow-starting IDE.
4) The whole point of web frameworks is to generate the client out of the server, making the server very complex to wrote and maintain, despite or because of that the whole point of the web frameworks are to reduce that very complexity.

Also, when I try to discuss my findings with people, I get invariably into long discussion where otherwise very smart people try to argue that I am wrong based on theoretical arguments - not having had the experience themselves.

At any rate, what I have found is that I am better off without any kind of server-side web framework at all - writing my clients old-school style, in JavaScript, making the server a 'thin server' which only doles out pure data.

And what does that mean? It means that the status quo has to go. No Tapestry, no JSF, no Wicket, Struts, Ruby on Rails or Symfony. Nothing at all. You can see why this is so very popular to talk about :)

In the end it is all about money. How much does it cost your company to build, a system and how much does it cost to maintain.