Topic: Ajax Components

Informagen Echo2 Component Library

Dietrich Kappe, Thursday, July 19, 2007 @ 6:16 am

Will Gilbert has contributed a handful of validating form field components. Take RegExTextField, for instance. It will take a regex and, surprise, validate the input against it. Maybe not earth shattering, but handy nonetheless.

Technorati Tags: ajax, echo2, components

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

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

Dietrich Kappe, Thursday, March 29, 2007 @ 6:00 am

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

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Adding a Timer Component to Echo2

Dietrich Kappe, Friday, November 17, 2006 @ 3:19 pm

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

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Writing Echo2 Components

Dietrich Kappe, Monday, September 4, 2006 @ 8:00 am

As a prelude to trying to write some Echo2 components using GWT, I thought it would be wise to review the material on how to write Echo2 components in the first place. Why would you want to write a component when Echo2 gives you a nice level of abstraction with plenty of prebuilt components? Well, sometimes you need a special component that isn't provided by the framework or a new behavior in an existing component.

A word of warning: component development is like traditional web application development, i.e. you have to work with many different languages and it is much more expensive than developing in the single language context of Echo2. If you are going to do it, design your component to be as reusable and configurable as is practical.

The best place to start learning about writing components is Brad Baker's excellent three part tutorial over at the Echo2 Wiki.

• Part 1 covers the basics of creating a simple static <HR> widget. You'll learn how to create a Java project for a custom Echo2 component and how to write HTML using the org.w3c.dom package.
• Part 2 delves into how to create a component that can react to input, using some of the EchoPointNG components (of which Brad is the author) as examples. Here we see what Javascript needs to be written and how it is communicated to the client engine on the browser.
• Part 3 gets into what Brad calls "the productivity problem," i.e. the fact that it takes at least 50% of development time to debug the Javascript of a component. He demonstrates static prototyping -- using XHTML and Javascript local files -- as a solution to this problem.

If I have any criticism of Brad's excellent tutorial, it is that I'd like to see him deal with the Echo2 client engine in a little more detail. (Still, in the Echo2 development universe, that may not be his job, but rather that of Echo2 creator Tod Liebeck.) Also, the code samples should probably be color coded, depending on whether they are Java or Javascript. Given the similarity in syntax, it is sometime difficult to tell what your are looking at, especially as you scroll back and forth to understand the integration between different layers.

A different tutorial can be found in this Echo2 forum post, though it seems to be a little out of date in terms of the framework's API. I always like to get as many perspectives as I can when adopting a new technology, so on the reading list it goes.

I'll see you next Monday with my first cut at a vanilla widget. I'm still undecided as to what sort of component to write. Something simple yet useful and not present in the current collection of Echo2 core and contributed components. If you have a suggestion, please let me know.

Technorati : ajax, components, echo2, echopointng

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Using GWT to Create Widgets for Other Frameworks

Dietrich Kappe, Friday, July 28, 2006 @ 8:23 pm

Every AJAX framework developer I've spoken to has speculated that you could use GWT to write widgets and other Javascript logic for thier framework. But just how would you go about doing it? At runtime, GWT:

1. Loads the correct browser-specific generated Javascript file into the browser.
2. Calls the entry point of the module, which inserts various widgets into the DOM and initialized various objects.
3. Responds to user action via the various event handlers that have been registered by the module's entry point.

Now other people have hooked things like script.aculo.us into GWT, but the flow of control has been from GWT to the library. What about going the other way, from another framework to GWT? Can we simply create custum GWT widgets and register framework calls and callbacks within 'native' methods of the widget, or should we write static methods and register them in their name-mangled form from the entry point with the window object, there to be called by non-GWT javascript. We certainly want to leverage the browser independent DOM, event and other libraries of the GWT.

Once we've solved the problem of hooking into GWT, will this break our ability to debug in hosted mode? I aim to find out by writing a simple Echo2 widget, first in the usual way, next using GWT. Wish me luck.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Widget Watch – Echo2 Widget Panel

Dietrich Kappe, Wednesday, July 5, 2006 @ 9:00 am

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.

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

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

Dietrich Kappe, Monday, July 3, 2006 @ 11:05 am

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.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

An Interview with ZK Creator Tom Yeh

Dietrich Kappe, Wednesday, June 28, 2006 @ 9:00 am

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.

• Digg
• Reddit
• del.icio.us

Comments (5)

Software Development

ZK – Documentation & Tools

Dietrich Kappe, Tuesday, June 27, 2006 @ 9:00 am

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.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Grizzly – Infrastructure for COMET and AJAX

Dietrich Kappe, Monday, June 19, 2006 @ 9:00 am

Other than being the black hole into which the JavaMail API has disappeared, the Open Source Glassfish project -- a J2EE app server building on the Toplink and J2EE code donated by Oracle and Sun respectively -- has some interesting stuff under the hood. They have a new NIO-based HTTP Connector named Grizzly. See their Webtier page; down a little on the page, you'll see a heading entitled "HTTP Connector." Along with a nice high level diagram, the section describes Grizzly as

Grizzly is an HTTP Listener using Java's NIO technology and implemented entirely in Java. A re-usable NIO based framework that can be used for any HTTP related operations (HTTP Listener/Connector) as well as non-HTTP operations, thus allowing the creation of any type of scalable multi-threaded server.

With NIO, as anyone who has ever used the Unix select system call, you can have a single thread operating on a bunch of connections instead of one thread per connection. This can save tremendous overhead and can achieve a surprisingly high degree of performance. See the old single-threaded HTTP servers Boa and Tiny httpd for evidence that this is not a new concept.

To understand why Grizzly helps in one piece of the COMET puzzle, we look at Jean-Francois Arcand's blog entry, Can a Grizzly run faster than a Coyote. He ran ApacheBench against Tomcat and Glassfish and came up with the following result: Tomcat needs 500 threads where Grizzly needs only 10 to handle a large benchmark test.

The results are a little controversial -- nobody likes their app server trashed -- and I don't want to get into a discussion about the relative performance of Tomcat vs Glassfish, but the ability to handle the IO of an application server with a small number of threads bodes well for COMET. COMET, remember, keeps a connection open to the browser while the Servlet is performing some long running calculation or waiting on a message, and that means we'll have more connections open at one time. If we needed one thread per connections, we'd be hosed.

What NIO doesn't solve, however, is the that the waiting Servlet still chews up a thread. As we've mentioned previously, Jetty 6 has a continuation mechanism for Servlets that allows waiting Servlets to give up their threads. That's the other part of the puzzle for COMET. Jetty 6, BTW, also has an NIO HTTP Connector to go with its Servlet Continuations, so this may be the way to go for COMET early adopters.

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Example GWT App – Newsletter Signup

Dietrich Kappe, Thursday, June 15, 2006 @ 9:00 am

I decided to try out GWT on a simple project: providing a small newsletter signup box on a conference micro site. The idea was that after checking that a valid email had been submitted -- and complaining with a DHTML popup if it wasn't -- that email would be sent to a backend web service (asynchronously, of course). While the async XHR request was percolating, the newsletter box would display a thank you message, then fade away. A cookie would also be set, preventing the newsletter box from displaying during the lifetime of the browser session.

This just barely qualifies as AJAX, since I'm doing just one crummy little "Hello World!" communication with the backend. Still, it gets rid of the whole painful navigation to a signup screen, so that's a win in the AJAX column.

OK, so just 150 lines of code later (yeah, I know), I have my little box. The site is software500.pathf.com where you can see the newsletter box in the bottom right corner. Please be kind and don't sign up your goofy friends.

A few lessons from the excercise:

• GWT doesn't remove the need for Javascript. I found myself writing a few funky methods like this:
  

   public native void setCookie(String cookie, String value) /*-{    document.cookie = cookie + "=" + escape(value) + ";Path=/"; }-*/;         public static native String getLocationHref() /*-{    return $wnd.location.href; }-*/; 

• The GWT documentation is not complete. What is does talk about is pretty solid, but the fact that Google is not a shrinkwrap software company is pretty evident. Let's hope they hire some gifted technical writers and such for the general release of GWT.
• Debugging in the hosted mode is pretty handy. Not that an application of this simplicity needed a whole lot of debugging.
• One of the gaps in documentation is that it isn't very task based. Suppose you have a question like "How do I include a third party jar file?" You can dig through the documentation site and maybe come accross an explanation of the syntax of the MyApp.gwt.xml file and on another page the directory structure of a GWT project. Putting the two together takes a bit of noodling. That's definitely a steep start to the learning curve that doesn't need to be there.
• Spend some time with the more essoteric parts of the documentation, like how to write modules. Also, take a spin through the gwt.js file and see how it parses the gwt meta tags. This will ease your pain down the road when your GWT app and html page sit in different directories.

In my previous article on GWT Developments, I've pointed out several good resources for getting started, including the GWT newsgroup. Make liberal use of them.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Widget Watch – Echo2 ColorSelect Widget

Dietrich Kappe, Tuesday, June 6, 2006 @ 9:00 am

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

JWAX – A Little Raw

Dietrich Kappe, Wednesday, May 24, 2006 @ 9:00 am

Yet another client-side AJAX component GUI framework is JWAX. The class model resembles that of Swing somewhat and a seperate rendering layer realizes the components in the presentation medium of choice. Right now only DHTML is done, but XUL XAML and support for custom renderers are planned.

The demo is a bit raw, with most of the app not working in a recent version of Firefox and strange menu, tree, dragging and other behavior in IE 6. Since one of the main selling points of a framework is that you can implement cross browser support in a relatively compact rendering layer and client engine, this failing is unforgiveable. Let this one ripen for another 6 months and check back.

Update 1: I was incorrect in identifying this as a server-side framework (odd, since I tinkered with the client-side Javascript code a bit). I've corrected the information above. It is still is a bit raw, however. Thanks to the reader who caught the mistake.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Does Google Eat its Own Dogfood?

Dietrich Kappe, Tuesday, May 23, 2006 @ 9:00 am

Google recently released the Google Web Toolkit. The basic idea behind the toolkit is that you can write AJAX applications in Java:

public class Hello implements EntryPoint {

  public void onModuleLoad() {    Button b = new Button("Click me", new ClickListener() {      public void onClick(Widget sender) {        Window.alert("Hello, AJAX");      }    });

    RootPanel.get().add(b);  }

}

Then run it in a hosted mode for debugging:

Then compile it into Javascript for deployment:

[...]function lb(mb){cb(mb);return mb;}function xb(yb){return zb(this,yb);}function Ab(){return Bb(this);}function wb(Cb){if(Cb.toString) return Cb.toString();return '[object]';}function Db(Eb,Fb){return Eb === Fb;}function zb(ac,bc){if(!cc(bc,1)) return false;return Db(ac,dc(bc,1));}function Bb(ec){return r(ec);}[...]

The secret sauce here is that the GWT actually emulates a good portion of java.util and java.lang in Javascript. Can a full JVM implemented in Javascript be far behind?

A natural question is whether Google eats their own dogfood, i.e. do they write gmail, google maps and co. using GWT or something similar? Looking at the code from gmail and google maps, you certainly can see some similarity. Both GWT and the google application code contain lots of two letter identifiers. This points to either code generation, code obfuscation or both.

Still, none of the Java identifiers that show up in the GWT code (_.c = 'java.util.AbstractMap$4';) show up in the other code.

What does this mean? There are two main possibilities as I see it:

1. Google is making v2 of their own development environment available to the masses and will start developing their new apps using it.
2. Google is releasing a dumbed down version of their tools to the masses but will continue to use a different set of tools to develop their own apps.

Looking at Google Calendar, the most recent of google's releases seems to point to possibility #2, as it doesn't really resemble the GWT code in many respects. Also, the GWT doesn't include many of the cool widgets that google has in it's own apps, like the lazy loading, draggable grid in google maps.

What could google's motive be in releasing a tool they don't lose themselves? No idea.

If anyone can point me to a google app that actually appears to be built with GWT, I'm all ears.

Update 1: XML11 is a toolkit similar to GWT in that it allows you to write Java and codegen Javascript.

Update 2: Some thoughts by Dion Almaer over at Ajaxian on GWT and XML11 and whether they are at the right level of abstraction.

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

YAACGF – Yet Another AJAX Component GUI Framework

Dietrich Kappe, Friday, May 19, 2006 @ 9:00 am

I've been working hard on the next part in my Echo2 tutorial series and on my review for the ZK framework, but I'll take the time and point out another component GUI framework. WidgetServer has been around a while and hasn't gotten a whole lot of attention. You can write code once and have the make the decision on Swing, Swing Applet or AJAX at runtime. It is "self compiling," in the case of GUI frameworks that means that the GUI builder application that comes with WidgetServer is also built using the framework. From the description:

WidgetServer is a component based, server-side, Java/XML rich-client-framework which
enables an application to run as either

• a monolithic application with a Swing GUI
• a client/server application with a thin Swing client
• as an application with a rich Web client based on HTML, CSS and optional JavaScript
• or in future as a mobile application on different devices like PDAs (comes with Release 1.1)

without any change and without loss of functionality!
WidgetServer gives you the choice if you develop a GUI either using

• HTML markup
• a Java API like Swing
• or XML markup

 

WidgetServer provides a unified component-based, object-oriented
programming interface for Web and Swing GUIs to control and modify the
GUI and to process events. The framework prevents from struggling with
HTML, JavaScript and HTTP requests or from caring about the internals
of Swing (e.g. Drag and Drop implementation). For Swing client/server
applications the framework cares for the client/server split as well
as for the client/server communication including compression and
security layers. Web applications are completely AJAX enabled, while the use of this
feature remains fully configurable. The framework also supports a
mixed deployment mode, which enables one server to serve Swing clients
and Web clients at the same time. The functionality of the Swing
widget set is covered widely (and sometimes enhanced) in both (Swing
and Web/HTML) client channels. The project comes with a WYSIWYG
GUI-builder which is completely build on the WidgetServer framework
technology.

Breathless, I know. I like the idea of being able to write one app for both desktop and web. Still, how many times is that going to happen? My backend architecture is likely to be somewhat different for collaborative webapps than for desktop apps. Still, it's a good place to start, being able to make the decision on Swing vs AJAX at runtime.

This capability comes out of the component GUI design. If properly done, you are using the bridge pattern to retarget your abstract GUI model to a concrete GUI like Swing, Flash or AJAX.

The feature matrix gives an overview of what the framework offers. The LGPL version is a little crippled, i.e. it doesn't do a number of no-brainer AJAX things like partial page update and compression. I really don't like this business model for Open Source where you pay to avoid shortcomings. I much prefer the model that Nextapp has taken with Echo2 where they provide extra value -- an IDE plugin -- on top of a fully functional framework.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development