Agile Ajax

GWT Rolodex now at Google Code

Chris Jones was kind enough to move his GWT Rolodex widget over to Google Code. Looks like you no longer have to resize your own images.

Grab your stack of images (you'll get the best results from images that are roughly the same medium size) and place them in the same package space as your RolodexCardBundle.

That's it. Just drop them in a directory. Check out the RolodexImageBundleBuilder.java for the code that does the magic at compile time.

One enhancement planned already is to do a real perspective transform to "get rid of the jaggies."



Technorati Tags: ajax, gwt, rolodex

SMash - Something Useful from the OpenAjax Alliance?

In the announcement that the OpenAjax Alliance had released OpenAjax Hub 1.0, and would start to work toward 1.1, there was one thing that caught my interest: the news that 1.1 would support secure mashups. Given that proxies and JSONP are both pretty open to abuse by unscrupulous service providers, this was certainly welcome news? So, what exactly does this secure mashup support look like?

The nascent SVN repository at Sourceforge wasn't much help -- mostly just a placeholder for future work. A little digging reveals that the OpenAjax technology will be based on a technique known as 'SMash', developed at IBM for performing secure mashups. I was able to locate a copy of a research paper on SMash (not sure if this is meant to be public, so grab a copy).

 

GWT Widget: Rolodex

Chris Jones of YesMail has written a pretty slick rolodex widget (see the Google groups thread about it).

Right now the animation images are generated by hand, but with a little bit of Java 2D, this can happen at compile time. You can kind of see some of the issues here of Flash v.s. DHTML. Flash has all sorts of image transformation goodness, while DHTML is a little handicapped here. You could use something like Reflex instead of compile time image transformation, though I haven't tried out how well it performs when animating.

Anyhow, nice work Chris. It's nice to see folks pushing the boundaries of what one can do with DHTML widgets.

Technorati Tags: ajax, gwt, yesmail, widgets

A Spinner Widget

Update: I've added the controls to spin forward an backward, mouseover effects on the image and a simple onclick action.

I've been working on a spinner widget. "What is a spinner widget?" I heard you cry. If you've seen those flash widgets on Amazon that spin product images around in 3D, you know what I mean. I wanted to see if this could be done in pure DHTML. Well, it can, see image below and a demo here.

The widget uses projection geometry (a view point and calculating image size and position based on where lines pass through the z=0 plane) and a little bit of trigonometry for the circle. Also, zIndex is set based on an object's z coordinate. At this stage the implementation definitely performs differently based on machine horsepower and browser platform. It performs pretty well on IE7 and Safari 3, less well on Firefox.

The implementation is in GWT 1.5 (built from SVN), but could be done in pure JavaScript (obviously). Next steps include direct manipulation of the spinner (drag to spin the circle) and drag and drop, response to clicks on images, the ability to spin arbitrary DOM elements, etc. Also, I want to squeeze some better performance by using an image strip (clipped with CSS). Stay tuned.

Technorati Tags: ajax, gwt, widget, 3D

MyGWT Widget Library

I just came across the MyGWT widget library, a collection of good looking additions to the basic GWT widgets. From the site:

MyGWT is an open source Java library for the Google Web Toolkit. The library helps developers easily create compelling desktop like AJAX web applications. No messing around with HTML, CSS, or images, all MyGWT widgets look great out the box.

They look reasonable, and for those of us that want to avoid messing with CSS and icons, this is definitely an option. Just plug them in and your tree widgets can look like the ones below.

Beyond pretty widgets, the library includes an AsyncTree (i.e. it will show a spinning wheel and dynamically load the subtree just exposed via user action) and a small number of DHTML effects, such as DnD, fade, etc. The site goes on to say that MyGWT was heavily influenced by Ext JS, the slick Ajax JavaScript framework.

BTW, the link on the home page to the demo application is incorrect. You can find it here. In general, the www.mygwt.net host doesn't work. Just trim off the "www" and you should be good to go.

Technorati Tags: ajax, gwt, widgets

Cross-platform widgets: fact or fiction?

For such a simple idea, widgets (or "gadgets" or "modules" or - ugh - "badges") are ridiculously complicated. Take three basic web technologies (XHTML, CSS and JavaScript), wrap them in a fourth (XML), and you should have a really simple, powerful way of deploying a platform-independent UI for your remote data. Yet between Yahoo Widgets, OS X Dashboard, Google Gadgets, Vista Sidebar, Netvibes Widgets and the umpteen other flavors out there, broad deployment is time- and cost-prohibitive. Pretty much every major implementation is incompatible with the others. Often, a single vender offers multiple overlapping versions of its platform, such as Google Desktop vs. iGoogle and Windows Live vs. Vista Sidebar. I'm all for healthy competition and the innovation it produces, but couldn't each big player at least release a unified API for all of its properties?

Amid all of this chaos, what's a would-be widget author to do? Probably the same things as widget users: weigh the options and pick a side. True, the WC3 is beavering away on a standards spec, but we all know how long that's going to take. By the time anything gets signed off on, the fad will either have died out or, perhaps worse, have become a long-term part of the web ecosystem. Imagine hundreds of thousands of legacy widgets written in proprietary formats, a huge number of which will never get refactored to meet the standards. And that's assuming the various widget platform vendors even agree to sign on. It's easy to imagine Google jumping on board, but much harder to hope the folks in Redmond will follow suit. Who knows about the other players?

True, tools have sprung up to translate certain types of widgets into certain other types. But these are stopgap solutions with often unpredictable results. Even when the widgets work, they often don't look pretty in their new homes. And nobody yet has come close to a write-once, run-anywhere SDK for widgets. Translation is the best option the marketplace has produced.

That said, I'm keeping an eye on UWA, the new Netvibes "Universal Widget API." This is another translation methodology, but instead of a third-party application that performs a one-way port of an existing widget, it's an actual spec for authoring widgets once and then compiling them to the various platforms. Thus far it mainly supports Netvibes itself, iGoogle and Dashboard. But Vista support is on the roadmap, and Yahoo support has been discussed. Best of all, they're planning to open-source it. If this API ends up being halfway as useful as it promises, perhaps it will offer a good middle path while the official standard takes shape.

[Lest I end on a completely hopeful note, here's a somewhat related digression: I'm also often depressed by the way the aforementioned standard web technologies get used in widgets. To a certain extent, pretty much all of the widget platforms force you to develop kludgy code. iGoogle and other Web-based platforms scale their widgets based on the size of the browser window. Some developers spend the time to come up with intelligent liquid layouts, but the limitations of fixed-height iframe wrappers make design compromises inevitable. A lot of the third-party widget-assembly shops just slap together some fixed-width design based on the worst-case scenario and built the entire interface out of a sliced-up PSD file. Forget font-scaling and other basic accessibility considerations. It's like the 640x480 viewport all over again, but in miniature. The more things change...]

My Mash Note to Microsoft, Newest Member of the OpenAjax Alliance

It is easy to be cynical about Microsoft's recent entry into the OpenAjax Alliance. After all, the alliance is mostly a marketing vehicle for it's members. The "technology" portion of the OpenAjax Alliance revolves mostly around things like playing namespace cop -- more problems of the Javascript language and browser platform than real framework issues -- and is making very modest progress. Beyond the bitching of the odd developer about Prototype not playing nice with other frameworks, the real problem with Ajax frameworks is that they each reinvent the wheel, not that they don't work well together. This sort of ad-hoc interoperability -- making sure that different libraries and frameworks don't clobber one another -- reminds one of the legislative process: when the parties are divided, a weak compromise is often the best for which you can hope. (See John Reisig's take on why the OpenAjax Hub is in fact not a very good technical solution.)

Not that these efforts are useless; they are better than nothing. But both Ajax and the browser platform are still moving targets. Investing heavily in a standard that may evaporate once the next version of the browser comes out or if Ajax development moves away from direct browser programming to more abstracted models (Echo2, GWT, etc.), seems like something you would want to do quite slowly.

So, is Microsoft's entry a sign that it really wants to play nice, or is this part of its diabolical plan to "embrace, extend and extinguish?" I think the answer is more the former than the latter, and that has me feeling all warm and fuzzy towards my blue badge buddies in Redmond. I think Microsoft, by getting rid of its annoying compatibility layer, is trying to embrace open source Ajax libraries. Why? Because they realize that writing fancy eye-candy DHTML/Ajax wizardry is hard and expensive. Much better to treat this little browser ecosystem the way they treat custom WinForm controls -- a marketplace too fragmented for MS to efficiently play, but whose vitality and diversity needs to be encouraged in order to add value to the base platform, .NET in both cases.

I think this apparent willingness to foster third-party Ajax libraries is the real news, not their entry into a very corporate ("Member of the OpenAjax Alliance"), very marketing oriented, marginally technically useful organization.

    Technorati : .NET, ajax, editorial, microsoft, openajax alliance, openajax hub

Using GWT to Write Opera Widgets

I've been experimenting with GWT, seeing how it can be hacked into unusual applications -- bookmarklets, Greasemonkey, widgets -- without breaking. The answer is that there are a number of things about the GWT runtime that break in these scenarios (Each bit of code loads in a different HTML file, so each has its own sandbox, therefore, no cross site action). I'm still looking at ways to make it work, but in the meantime, GWT can be used without any problems to develop Opera widgets.

These widgets, once installed, sit on your desktop, have access to some permanent storage, and can access pretty much any site, so those cross domain Ajax doohickies you wanted to develop? Now there is a way of doing it that doesn't involve proxying through a web server.

I took a crack at developing a little "Hello World!" app, called AnswerWidget. It allows you to enter a search term and then cycles through all of the Yahoo! Answers entries that match that term (up to 50). It refreshes and starts recycling after that.

Now besides discovering that most of the Yahoo! Answers content isn't very good, I also found that writing a widget with GWT couldn't be simpler. Develop your app as you normally would (you may need to drop in a test object that generates content instead of trying to do a cross site JSON request). Once you've compiled into Javascript, just copy your app's html file to index.html and create a config.xml in the base dir that looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<widget>
  <widgetname>AnswerWidget</widgetname>
  <description>
    GWT widget for getting Yahoo! answers.
  </description>
  <width>495</width>
  <height>440</height>
  <author>
    <name>Dietrich Kappe</name>
    <link>labs.pathf.com</link>
    <organization>Pathfinder Associates, LLC</organization>
  </author>
  <id>
    <host>labs.pathf.com</host>
    <name>AnswerWidget</name>
    <revised>2007-01</revised>
  </id>
</widget>

Zip it up in a zip file (what else?) so that the index.html and config.xml files are in the base dir, then upload it to your favorite server. If you're using apache, you can create a .htaccess file in the dir where the zip file sits and add the following line:

AddType application/x-opera-widgets .zip

When you download this zip file with Opera, you will be prompted to install it. There is more on deploying Opera widgets here. I wasn't able to get the wdgt extension to work for me, BTW.

If you have Opera installed and feel in a trusting mood, you can install the widget here. Keep in mind that if I was a malicious person, I could mount all sorts of trojan horse attacks inside your firewall. That's one of the downsides to the GWT-based Opera Widget: without the Java source code, you will have a hard time inspecting and validating that the widget isn't malicious.

I do hope the guys at Google work on making the GWT runtime a little bit more flexible. I have some ideas on how to hack it to make it work cross site, but that won't be maintainable in the long run.

Technorati : ajax, google, gwt, java, opera, widget

Adding a Timer Component to Echo2

One of the things I really like about ZK is that it has a timer component that you can add or remove from a page in order to enable "async" Ajax events in the application. It's a useful abstraction that hides much of the messiness of async update.

<window title="Timer demo" border="normal">
   <label id="now"/><timer id="timer" delay="1000" repeats="true"
      onTimer="now.setValue(new Date().toString())"/>
   <separator bar="true"/>
   <button label="Stops timer" onClick="timer.stop()"/>
   <button label="Starts timer" onClick="timer.start()"/>
</window>

Echo2 also has a facility for performing async updates, but it's much more of a roll your own type of facility. I've been wrestling with how to add a timer component to Echo2.

The basic idea is to override the ApplicationInstance as detailed here to allow adding in periodic update tasks. Next, every time a component is registered or unregistered with the ApplicationInstance -- i.e. added or removed from the component heirarchy -- it is added or removed from the periodic update tasks. Fortunately, there are two Echo2 Component lifecycle methods which look like they will work: init() and dispose(). These get called when components get added or removed from a registered heirarchy.

It would be nice if, beyond these two methods, we had something like Swing's HeirarchyEvent and HeirarchyEventListener that allowed us to pass other kinds of events to a heirarchy. Well, the juices are starting to flow again for me on Echo2. I guess it's time to get back to part 2 of the tutorial series.

Technorati : ajax, echo2, timer

JQuery Widgets and the Widget Challenge

JQuery is rapidly becoming my favorite Javascript library. With it's ability to pack a complex operations into a single line, it sometimes feels a little bit more like Perl than Javascript.

JQuery allows for plugins, so you can build widgets and extensions on top of it that will work with one another. As of right now, there are already quite a few widgets and extensions built on top of JQuery:

• ThickBox - modal dialog widget built on top of JQuery.
• jCarousel - plugin for horizontal or vertical scrolling of items.
  
• 
• Interface - large collection of plugin effects for jQuery, including draggable, dropabble, etc. A must visit site. Also includes a list of plugins developed by other developers (some of which you will also find in this post).
• Date Picker - standard date picker.
• JQuery Portlets - based on the above Interface plugins, a draggable portlet interface. Very slick.
  
• 
• Dylan Verheul's autocomplete, editable, autohelp and google maps plugins.
• PanView - drag an image around in a little view port.
• YShout - a shoutbox (allows users to chat on your site or page).

I haven't seen a rich text editor yet, or the FishEye widget. The main jQuery site has an extensive list of plugins, including the above and more.

Feeling the pressure from Dojo, the JQuery guys have issued a challenge to the developer community to come up with new widgets based on JQuery:

Dojo released a new widget today: a spreadsheet widget. and it ocurred to me that while we don't quite have anything like that yet, there are scattered widgets throughout the jQuerysphere. I figured it'd be nice for us to put together a jQuery widget package that, to the extent possible, mirrors the Dojo widget set.

The challenge is this: where there is no existing widget, create it. The holy grail, at this point, would be a replication of their spreadsheet widget or their rich text editor widget.

I'd like to put together the widget pack at some point in the next month, and I'll be featuring the widget pack in next month's Magazine. Theere's nothing requiring an exact mirror of the Dojo widgets, so feel free to submit widgets that are not present in Dojo.

A little friendly competition is a good thing. I look forward to more JQuery based widgets being developed and Dojo following suit. While you're at it, check out the powered by JQuery button challenge. Winners get Ajax books. Cool beans. You can never have too many Ajax books.

Technorati : ajax, jquery, widgets

New ZK Google Maps Component

Integrating a third party mega widget like Google Maps into a server-side framework like ZK or Echo2 is not so straightforward. At best these widgets sit there on the page sending and reacting to events independent-of and invisible-to the Ajax app in which they are embedded. At worst they consume and generate conflicting events and confuse the heck out of themselves and the server-side framework's client engine.

The ZK team has taken up this challenge and has just released a ZK component that allows you to embed Google Maps in your application. With this component you can now both issue and respond to events from the server-side. For example, the following zul code allows you to use a ZK slider component to zoom a map:

<zk>
<gmaps id="map" width="500px" height="300px"/>
<slider maxpos="17" curpos="${map.zoom}" onScroll="map.setZoom(self.curpos)"/>
</zk>

Right now a limited set of events are supported, but more is on the horizon:

We have demonstrated how to use this new ZK gmaps component, the Google Maps component. The Google Maps API is a versatile API set. The ZK team will integrate more functions and events into the gmaps component so ZK application developers can control it easily.

We are going to discuss the "behind the scene" in another smalltalks about how this Google Maps API is integrated as a ZK gmaps component; especially how to route the Google Maps javascript event back to server as an ZK event. Sit tight.

Consider the possibilities: maps that zoom and pan in response to server-side events, such as election results coming in; maps that update realestate listings as a user types a query; listings that are updated based on where a users pans the map. I can hardly wait.

Technorati : ajax, google maps, zk

GWanTed - GWT Without Programming

Writing GWT apps and widgets is not the most difficult thing in the world for developers. But what about mere mortals who want to plug a GWT powered widget into a web page and go? Well, there is hope for these poor souls in the form of GWanTed. Right now it consists of this sparse sourceforge project and the following GWT developer forum post:

GWT is great for developing new rich interface components and with it you can develop your custom widgets easily.

On the other side, in pages already made, I think that GWT integration isn't so trivial. A small step is needed. Currently, you can't use GWT widgets directly in your pages, because you need to KNOW GWT (to build an integration module). So, in a way, we're working for people that don't need to learn java for create web pages, and like with HTML objects (inputs, by example), it's easy to think about "portal widgets". Web designers don't need to know intense javascript for cross-browser compatibility, and there is where we can help... We hope! ;-)

With GWanTed, we have different focuses. We've tried to create a base not only for creating web 2.0 apps with a bunch of out-of-box features that we think that will make easer the construction, as well as minimizing GWT's learning curve.

They promise to have more docs and explanations up shortly. In the meantime, the project page does contain some screenshots.

Technorati : ajax, gwt, widgets

OpenLayers - Google Maps for the Rest of Us

Google Maps was and is a good idea. In large part it is what caused people to say "Whoa! Cool." and first take notice of Ajax on a broad scale. The OpenLayers project aims to give that power to the rest of us. Built using OO Javascript, Prototype and the Rico library, it provides a similar UI and API to Google Maps. It's purpose, however, is not to be a google clone. To quote from the project page:

As a framework, OpenLayers is intended to separate map tools from map data so that all the tools can operate on all the data sources. This separation breaks the proprietary silos that earlier GIS revolutions have taught civilization to avoid. The mapping revolution on the public Web should benefit from the experience of history.

In essence, if you have a campus map or a detailed map of some other area, you can roll your own Google Maps like interface.

Technorati : ajax, mapping

Widget Watch - BeanView - Forms and Validation for Echo2

Echo2 has been described as Swing for Ajax, and its component model does have a passing similarity with the Java desktop GUI. So it's not surprising to see a component come out for both Echo2 and Swing at the same time: BeanView 1.1, which was released yesterday. What is BeanView?

BeanView is a Java library - a system for seamlessly rendering a JavaBean to a form and back.

In technical terms, it relies on the information obtained from reflection of the JavaBean to generate forms and update the beans from these forms - so, if you create a JavaBean with a method get/setFirstName(String in), BeanView will automatically generate the form with a textfield to enter a "First Name". Supported features include:

• Per visual widget error reporting
• Support for validation (both a variety of built-in validation types and an easy customization system)
• Support for a wide range of built-in data types
• Support for complex data models, such a mapping a collection to multiple selection list box
• Automatic configuration based on JavaBean meta-data (for example, if a JavaBean declares a get/setFoo(int input) method, will by default generate a text field with integer validation.

Invalid form data is indicated by a big red exclamation mark and a popup tooltip. Below you can see the Swing and Echo2 versions side-by-side.

The latest release of Echo2 also allows you to explicitly set the render id's used to identify components, i.e. the DOM id attribute. This means you can test your BeanView forms with an automated test tool like Selenium.

Technorati : ajax, echo2, swing, widgets

Which Echo2 Widget to Build?

In order to build an Echo2 component in the traditional way before converting it into GWT, I first need to pick a widget to build. I'd like to build one that hasn't been done yet. I have one in mind: and edit-in-place label. The basic idea is that you can click on a bit of static text and have it turn into an input field with submit and cancel buttons. You can see the idea and an example of how to do it with prototype.js described here. Nothing too earth shattering, but useful nonetheless.

To see if this has already been done in Echo2, we have to look at five sources of components:

1. Echo2 - the base set of components. Lots of interesting items that you can see at work in this demo app.
2. Echo2Extras - and extra set of components distributed by NextApp -- AccordionPane, BorderPane, ColorSelect, CalendarSelect, etc.
3. Echo2Chart - charting widgets based on JFreeChart.
4. EchopointNG - the definitive collection of third party Echo2 components, including a tree widget. The docs on this are a little iffy, so you have to piece it together from the NG demo app and the Javadoc. Trees, expanding boxes, RichTextArea. Good stuff, but no edit-in-place.
5. Echo2 Contrib - the mysterious set of components that lives as a set of zip files in the Echo2 developers forum. Home of drag-and-drop, etc. Hard to say if it's in there, but I can't find it. BTW, someone should take ownership of this. I'd be happy to, if noone else has.

No edit-in-place to be found.

So the edit-in-place component looks like a good candidate. Unfortunately, the power of Echo2 gets in the way here. There is a way of building an edit-in-place component just by composing existing Echo2 components. It didn't take me more than 10 minutes to put the following demo together (click on the name, edit, save or cancel). There is one drawback, however: clicking on the label initiaties a roundtrip to the server. Ideally we only want a roundtrip if there is a listener registered on the click. So a more efficient version of the edit-in-place widget is still a good idea.

OK, next week we take a shot at a first version of this component.

Technorati : ajax, echo2, gwt, widget

Widget Watch - Echo2 Widget Panel

Well it's happened. Down in the ferment that is the Echo2 Developer Forums, developers are contributing reusable components to the Echo2 framework. Beyond the EchopointNG components, lots of other developers have been throwing their hats in the ring. One fellow took a look at the new google home page and thought that a draggable, animated component panel like that would be a good thing for Echo2. He announced his component panel on the Echo2 development forum. Here's a screenshot of a demo in action:

I've put up the demo for those who want to test it out for themselves. (It's not my demo, i.e. I didn't write it, I'm just putting it up.)

A few words about the demo. To use it, click the "Add Widget" text at the top to add widgets, then drag them around. Use the other buttons to change the behaviour of the panel. OK, have at it.

GWT Libraries Released - XML, SOAP, Crypto, Amazon, etc.

Openfount has released a beta of a set of libraries and tools for use with GWT. The web services parts of these work in conjunction with their queued server. This queued server basically acts as a proxy for XMLHttpRequest's. So, if you want to access web services from Amazon but you're loading your Javascript from another server, you can proxy the request through your server. There's a bit more to it, but that's the jist of it.

Looking at their Open Source license, I'm not sure it smells that good, but IANAL.

Update 1: I've had a closer look and have even more second (or should I say third) thoughts on this package.

An Interview with ZK Creator Tom Yeh

Anyone who has been following the development of AJAX frameworks has heard of ZK, the server-side component GUI framework that allows you to write applications like you would a desktop app. It has become one of the most popular projects on sourceforge and has been nominated for a 2006 Sourceforge.net Community Choice Award.

Recently I talked with one of ZK's creators, Tom Yeh of Potix, about the Framework's popularity and future.

ZK Background

DK: How did you come up with the idea for ZK, i.e. an AJAX framework that allows you to write webapps like you would a desktop app?

TY: As I mentioned in http://zk1.sourceforge.net/faq.html#Why, it is the result of frustration.

I was a fan of thin-client computing since leading a wonderful team to develop Network Computer and Window Terminal in 1995. I truly believe in the so-called utility computing. Accessing applications should be as simple as using tap water.

It is crazy that someone should carry tons of water when traveling, since tap water is available everywhere. However, we still travel with notebooks, even though Internet connectivity is everywhere. Similarly, the Web edition of MS Outlook has been available for years, but we are still using the desktop version. Why? Frustrated user experiences and excessive development costs. In other words, it is too costly to develop a Web UI from scratch or add-on to 'legacy' apps, and people won't use the Web UI even if it is provided.

After trying different ways to apply Ajax in the projects on which we consulted, we found that applying Ajax at the client side, as most frameworks did, only solved the half of the problem -- though it did result in a lovely interface. That is why ZK was born.

DK: Who is Potix?

TY: Potix is a consulting firm providing expertise in Web development and project management. We also develop applications on an ODM-basis. ZK is the consequence of this work. However, due to strong demand, we mainly focus on ZK now.

Potix is also a house of old dogs. Most of us have more than 15 year of experience, ranging from developing Windows/Linux/Web applications, to embedded OS and GUI frameworks. ZK is my second OSS project; the first one, called OpenPam (GUI for embedded devices), was not very popular.

DK: How are you planning on making money with ZK? Nextapp, the makers of Echo2, sells an Eclipse plugin for around $400. Is that a business model you are examining?

TY: Dual license (as MySQL did). You might also take a look at one of my posts: http://sourceforge.net/forum/message.php?msg_id=3605162

Other Frameworks

DK: Echo2 seems to be the only other server-side AJAX framework out there. How would you compare yourself with Echo2?

TY: Echo2 assumes UI designers are Swing programmers, while ZK assumes many of them are not programmers.

Markup languages, like HTML, XUL and XAML, scripting languages, like PHP and Ruby, and the object oriented approach are the three most important developments since GUI was introduced. Unfortunately, Echo2, WebOnSwing and similar frameworks only focus on the object-oriented approach.

In addition to BeanShell, we are looking at the possibility of using Ruby and PHP in zscript. It looks to be, so far, quite feasible.

DK: There's lots of talk now about the Google Web Toolkit. Do you see it as a competitor to ZK or a complement?

TY: Both.

From a technological viewpoint, it is a complement. GWT is a client-side solution and quite good for developing Ajax components. On the other hand, it is never a good idea to replicate the business logic to the client, which eventually brings us back to the maintenance headache of fat clients. In addition, loading huge JavaScript files into the client and executing them there is not fun at all. At the end, you need a server-side solution to handle the business logic and presentation tier.

It would be great if we can leverage GWT's power to simplify the effort of component development (as we did with DOJO and FCKeditor).

From a perception level, users might see it as a competitor. Google is now at a sweet spot with plenty of resources and a good reputation, as Microsoft was in the 1980s. Developers love to explore any kit Google puts out there and exaggerate what it can do as if Google was the first to invent it.

DK: Do you envision developers writing ZK components using GWT?

TY: Sure, GWT does a good job for non-JavaScript programmers who want to develop Ajax components. I expect that some results of this will show up in next few months.

However, what makes Ajax programming difficult is not JavaScript itself. Rather, it is the incompatible and buggy API (to communicate with DOM). The ability to do Java-to-JavaScript is important, but I am also hoping for some benefits from the standards efforts of OpenAjax.

The true value of ZK is its architecture. We look forward to adapting components to ZK as decent (client-side) Ajax components become available.

DK: What other AJAX tools, frameworks or technologies do you think are noteworthy or interesting?

TY: DOJO has an amazing set of components, though it is too heavy (one of the reason we didn't build the ZK Client Engine upon it). Atlas has great integration with Visual Studio. Anyone who wants to provide an authoring tool should take it as an example. Google Spreadsheets is an excellent Ajax application. You should unplug the network connection and see how it reacts, though. It's cool nonetheless.

Strengths and Weaknesses

DK: What would you say are the strengths and weaknesses of the ZK framework?

TY: Strengths: boundless. But seriously, great richness and excellent productivity, if we can put in a sentence.

Many of ZK users appreciate that they can design a rich Web application without programming. Many have thanked us for the intuitive event model and feature rich components that have saved them countless hours. Many enjoy the power of prototyping so they can change the look and function right in front of their customers. For more information, you could take a look at the executive summary (http://zk1.sourceforge.net/wp/ZK-exesum.pdf).

Weaknesses:

1. Stops working if the connection is broken. It would be better if a subset of functions still worked (such as read only viewing).
2. Round-trip latency, though hardly observable. To minimize the effect of this, we plan to, in addition to Client Side Action, add visual effects that execute solely at the client and notify the server only when necessary.

One other weakness shared by all HTTP-based solutions is the lack of Server-side push. Though someone has implemented so-called "reverse Ajax", it introduces too much overhead on the server. This -- server-side push -- is the next important step beyond Ajax.

DK: There aren't any production applications out there using ZK. Do you see that as a problem and, if so, what are you doing to address it?

TY: According to the profile of our customers, adopting ZK is still in the development (and evaluation) phase. By and large, adopting Ajax for most companies is still in an early stage. It is just a matter of time. I'm not really that concerned about it as long as the growth of ZK's acceptance is strong.

DK: Right now, the framework doesn't seem to allow for easy customization of the look and feel (window color, font, etc.). First, is that correct and, if so, do you have any plans to address it?

TY: Not correct. The look and feel are well separated by CSS and molds. What prevents users from customizing the look is the lack of documentation and samples. Also, the customization of the sophisticated components is sometimes not intuitive. It forces users to look at DSP files (the templates used to generate HTML tags). We realize this is an issue and we will provide documentation in the Developer Reference guide.

DK: I've noticed in the code that you spawn another thread to handle events. Can you explain the design to me? Also, how does this fit in with the Servlet standard and doesn't this make it difficult to cluster a ZK application if the user session has non-serializable information and context?

TY: It is common that an application has to confirm with users about, say, whether to delete a file. It is unbelievably costly for Web developers to implement such functions. Why? Users get no response until the servlet has completed, while the servlet requires user's confirmation to decide whether to proceed further.

There are many solutions to this problem, but the most elegant one is modal dialogs. ZK is one of the first Web framework that really enables the server-side modal dialog. The magic is to process events in another thread. Then, users can suspend and resume the processing anytime they like -- including but not limited to modal dialogs.

It does make clustering difficult if there is a pending thread in a session. We are working on the serialization issue now. A basic idea is to send the application a notification, and it can decide how to handle pending threads. Of course, if there is no pending thread, there is no notification at all.

DK: What is your favorite ZK feature?

TY: Macro components, the threading models, and zscript.

DK: Are there some cases where you wouldn't use ZK to develop an AJAX-based web application?

TY: Hard to imagine unless clients want the application to be functional even if the connection is off. Oh, action games, but it might not be a good idea to use Ajax there at all.

DK: It doesn't appear that you are using JUnit in the ZK code. Is this true? And if so, why?

TY: Only common utilities are tested with JUnit (refer to pxcommonTest in SVN). I am still thinking about which is the best way to test ZK components. We will come out with something in the near future.

Future Plans

DK: What is the biggest feature enhancement request you are getting from the users of ZK?

TY: Safari support and design patterns. By design patterns I mean information on how to really write an application with ZK. An illustration with Pet Store is a common request.

DK: On your road map you mention plans to provide a mobile version of ZK. First, what is the time frame for this? Second, how are you planning to do this architecturally? Can users write one application and dynamically re-target their apps to a different front end?

TY: We originally planned to provide a J2ME-based client engine, but we are keen on developing a Flash-based solution now. Architecturally, we have to do three things to support a new client: client engine, server engine and components. Users have to do two things accordingly: use a different set of components and adjust their UI to fit into small screen. We will keep the component API very similar (and also provide common interfaces that make developer's code polymorphic).

It is possible to let users use the same set of components, where components would be smart enough to detect the client and behave differently. However, we're not considering this approach because it makes the development and maintenance of components too complicated. Of course, we can use the factory pattern to chose the correct implementation, but it makes the instantiation of a component too complex for most users.

DK: You've stated that ZK is at the interface layer. Do you plan to introduce components that punch through to the data layer, sort of like the .NET datagrid?

TY: Yes. We will add more data-layer utilities, such as zkplus's DelegatingVariableResolver, too. After all, most ZK applications will have to access a database. However, we may not do a similar deep integration as Ruby on Rails did -- I don't like to make so many assumptions about how applications might be built.

DK: What do you see as the major challenges facing the AJAX community today?

TY: There are too many frameworks, such that many users prefer to wait. There isn't even a well-recognized categorization for them (such as server vs. client). A comparison chart or something similar would be very useful.

A standard like OpenAjax will help (at the client side), but I've never seen an alliance really work.

DK: Care to share any other plans you have for ZK?

TY: We are interested in adding mega-components, such as spreadsheet, forum and wiki. Part of the success of PHP is because the availability of plenty of off-of-shelf stuff. We won't develop all of these components ourselves. Rather, we prefer to help other developers deliver them either as OSS or commercial components. We will have a ZK.forge website to promote such collaborations.

ZK - Documentation & Tools

Documentation

The quality of the ZK documentation is very high by Open Source standards. The documentation includes:

• A 13 page PDF Quickstart guide - shows how to set up the demo application and a hello world app.
• A 169 page PDF Developer's Guide - steps you through the ZK framework with lots of small examples illustrating components and concepts.
• A 43 page PDF Developer's Reference. Documents component properties and behaviors. This document is only about 40% complete.
• A 1 page PDF Executive Overview.
• A 16 page PDF Product Overview - gives information on the motivations behind ZK and the architecture of the product.

The reference guide will need to be completed, otherwise developers will be guessing at specifics of components and the ZUML. Also, the documentation on CSS and "molds," i.e. the templates for components, is spotty. This will make it difficult for developers to change the look and feel in any significant way.

Tutorials

While there is a ZK demo application that shows off various components, there appear to be no tutorials or example/reference applications available to the would-be ZK developer. There is a wiki with a how-to/cookbook page, but just like the developer's guide, it consists of short examples, not a substantial application. There is also a port of a struts application over to ZK, but it seems to make use of so little of the AJAX capability of the framework that it can't really be considered a tutorial or reference app. For now the forums are probably the best source of information and support. Also, there is a "small talks" section of the project site that has some bits of information on integrating ZK with things like the Spring Framework.

Usability

Overall the framework is a joy to use. The ZUML makes it easy to do quick iterations -- edit, test, edit, etc. -- without a long compilation step. The ZUML is also easy enough so that non-programmers can compose or modify a UI. Exposing effects such as drag-and-drop, async update, etc., as components or attributes further eases the development of complex user interfaces for non-programmers and programmers alike.

Tools

As of this writing there is no IDE integration for ZK. This is really a crying shame, since the ZUML makes a WYSIWYG UI layout tool a natural fit.

More GWT Developments

The ferment going on around the GWT is truly impressive. Whether this bubbling activity is caused by all the frustrated Java programmers that this framework has unleashed on Javascript and the browser, or by the Google name that draws people in to take a peek, I can't say. We've already look at the widget sets people have built on top of GWT, but now we're seeing people integrating it with other frameworks and libraries.

Robert Cooper over at O'Reilly's OnJava.com has a nice tutorial that shows how to develop with GWT. The source for the article includes a Maven module that allows you to produce a WAR from your GWT project. Very handy for those wanting to deploy the compiled Javascript and RPC services in one package. The tutorial covers a fair bit of stuff like history support and such. Definitely a must read given the terse and sometimes confusing documentation that comes with GWT.

Luca Masini has done the inevitable: he's integrated GWT with the Spring Framework. For those of you not familiar with Spring, it is the one framework I know of whose main objective is not to provide some functionality, but rather to improve the overall architecture and design of your application. Luca also has a nice article on integrating GWT with struts (and Hibernate, etc.). He's done some good work in making GWT more than just a client-side curiosity.

Ed Burnette over at zdnet has a short tutorial on getting GWT working with Eclipse, which IMHO isn't that hard, but it's always helpful to see how other people have done things. He does provide this valuable avoidance measure on a GWT documentation gotcha:

If you follow Google's Getting Started instructions it says to just click on the green "Run" button to get your project started in "hosted" mode, but that's not quite correct. Plus, you'll want to run the program in Debug mode most of the time anyway. So select Run > Debug…, and click on the launch configuration titled MyApplication (under Java Application). Then click on Debug. Two windows will appear: The GWT Development Shell (this is kind of like a console window) and the Wrapper HTML window (a special web browser).

For those brave souls wanting to use GWT with PHP (Java to Javascript and PHP with JSON? Yuck! Talk about language confusion.), you can try Juan Hurtado's tutorial (also available in Spanish), which demonstrates how to build an address and phone number database. Or you can try Robert Hanson's blog for useful GWT examples and insights. Or try this blog entry describing the development of a GWT widget.

Tod Liebeck, the lead developer of the Echo2 AJAX framework (server-side GUI component) has an informative article over at The Server Side comparing GWT and Echo2 and setting the record straight on some misconceptions. Specifically,

The most obvious difference between GWT and Echo2 is that all of your GWT code is executed on the client, whereas your Echo2 code is executed on the server. There are advantages and disadvantages to both of these approaches, which will be highlighted throughout the article.

OK, this post is getting kind of long for a simple GWT update, so I'll leave you with some insightful thoughts from Alex Russell over at Dojo:

From where I sit, GWT looks like the physical manifestation of hiring managers’ frustration when trying to hire for “ajax developer” or “UI engineer” positions. The truth of the matter is that there just aren’t very many of us in the world and interestingly, Google employs a fair number of them. That they did GWT smacks of recruiting desperation and the need to better leverage the Google SSFPU (super-smart fungible programming unit).

Turns out you can’t just drop a good hacker into UI programming and trust that it’ll work out. Not only does someone in the UI engineering role need to have a solid appreciation for the constraints of the web, they need to be multi-language clued, know when to defer to visual designers, have the balls to push back on stupid requirements, and empathize with users. And that’s the baseline. No wonder Ajax is sexy and hard to hire for. The great apps in the Ajax word are developed by great engineers and designers.

The "multi-language clued" issue is a major one, in my opinion. More on that later.

GWT Widget Library - Moving Fast

That didn't take long. Google just announced it's Google Web Toolkit (GWT) at JavaOne in mid May and a scant week later we already have the GWT Widget Library. This library wraps the Scriptaculous effects, adds image buttons (with support for PNG's in IE 5.5 and 6) and allows one to wrap existing HTML elements as widgets. There's a nice demo of using the effects with GWT here.

Also, if you haven't visited the GWT blog and the developer forums, you really should. Developer action is heating up and people are already starting to push the boundaries of the toolkit.

While writing Java to produce Javascript may offend purists, it is hard to argue with success. Google has delivered some of the most popular applications on the web using this technology. However, the two evaluation projects I've done so far with GWT have been somewhat disconcerting, with my guessing at exactly how the Javascript would be rendered. Also, 38k of Javascript for a simple little email submission widget seems obscene, but it and it's validation logic was a breeze to write and debug, though the equivalent raw DHTML and Javascript clocks in at under 1k.

Update 1: Here is another GWT-based widget library. Some overlap, but also some other things, like the rounded corners.

Widget Watch - Echo2 ColorSelect Widget

If a component GUI framework just gives you your basic text box, button and other vanilla HTML form controls, it's not very compelling. It should give you something that you didn't think a webapp could do. Draggable windows were one of the first components to raise eyebrows as were expandable sections, like accordion panes. It's good to see some frameworks moving beyond the basics.

The Echo2 framework has been sprouting new components at a furious rate. One of these is the ColorSelect widget.

This component gives you the well known direct manipulation way of choosing an RGB color: just point and click.

As the AJAX component GUI frameworks catch up with the desktop, you'll be able to free your mind further from the notion that your building a web application. I myself can't wait.