Everyone,
Last night we finally got all the pieces to the dojo.E release finished and it is now online. There is quite a few things new in this release of dojo.E. We are also now making it possible to get the dojo.E code with the IMB, EDS and Nexaweb Server right from the dojo.E site. This is exciting because you can get started with dojo.E and IMB by download a simple zip file.
Legacy applications have architectural limitations that prohibit their ability to support large scale deployments. They often necessitate servers and technicians at each location with continuous client software maintenance and service, all creating redundant headcounts, resources and costs.
Application modernization toward an open, web architecture can address these technology limitations as they relate to the demands of globalization and will create new opportunities in terms of people and delivery. First, regarding the architectural limitations of legacy technologies, modernization toward an open, web architecture supports centralized deployments and zero-client installation which significantly lessens the need for local technicians, eliminates client software maintenance needs, and supports a reduction in hardware and infrastructure –consequently lessening energy requirements. From a pure software development perspective, adopting a loosely coupled architectural Web approach can reduce the time to execute a change request by 90 percent.
Secondly, modernization with Internet-based technology creates new methods of delivery and new ways to carve the resources pie. In terms of people, transformation toward an open, standardized application platform allows better utilization of a global workforce, especially from countries such as China and India. In terms of delivery, the lack of skilled IT resources against the demand will drive innovation and investment in new delivery models such as SaaS, IT process automation, and Internet-based service offerings that lessen reliance on human resources to resolve issues that can be solved in other ways.
I just presented a tutorial on Friday on using Direct Web Remoting, Hibernate and dojo.E. It’s a very simple demo, but demonstrates the power of these three technologies combined to create simple, dynamic Java applications very quickly. The tutorial is available on SlideShare.
Note that there is a bug that obscures the URL for the SVN project. The URL is http://source.nexaweb.com/svn/repos/trunk/tutorials/ajax/DWRExample/.
You can check out the project via SVN using this URL.
Also, to copy and paste the code snippets, download the document and open directly in PowerPoint. When copying and pasting, watch out for “smart quotes”. Some of the quotation characters in the PPT have been replaced with “smart quotes”, which are not recognized by XML parsers.
This will get even more exciting with the new features of DWR 3.0, which will add a RESTful layer to DWR’s remoting. To learn more about DWR 3.0, I recommend Joe Walker’s presentation from The Ajax Experience last week. He’s the lead developer for DWR.
Joel Barciauskas
Over the weekend the dojo.E team spent some time at the Dojo Foundation’s Boston Dojo Developer Day and then at The Ajax Experience with some cool swag in tow. For those who missed these events, we’re giving away free stickers along with a limited number of t-shirts at the dojo.E website. Hurry up, though, as supplies are limited.
Google Chrome is only about three weeks old and is already an Internet phenomenon. To sum it up, Google Chrome is all about making web browsing safer, faster, and easier. While some might see a fierce competition between Google Chrome and Mozilla Firefox, I see harmony.
Here is some background to better understand this point of view. There has been a somewhat valid belief stating that the un-typed and interpreted nature of the JavaScript language was a major limitation for building demanding client applications. Consequently, to overcome this challenge, the browser technology providers had the following two options:
As you might have heard, harmony has been found in the ECMAScript working group ECMAScript Harmony (see also EJohn Resig’s post and thegreat Harmony podcast with Brendan Eich and Arun Ranganathan).
To sum it up, the ECMAScript, responsible for standardizing JavaScript, has had pretty intense discussions over the years about the future of the language. One side wanted to evolve JavaScript into a more typed and traditional compiled language (ECMAScript 4), while the other wanted to keep JavaScript’s dynamic nature a core feature of the language (ECMAScript 3+).
Theoretically, from a language perspective there are pros and cons for both sides. However, the bigger question was and is “what is the best direction for the web?”
To better answer this question, a quick look at the different application architecture designs would be helpful. There are two main architecture designs for client applications.
In the client centric approach, the benefits of having a typed and compiled language provides undeniable benefits as it facilitates client applications to fully take advantage of the local device’s resources. Platforms such as Java, .Net and others provide great versatility and client side capabilities.
For the web centric approach, dynamic languages and architecture such as html/css and JavaScript have proven to be robust and scalable design principles for internet based applications. These include consumer sites such as YouTube, Facebook and eBay as well as enterprise mission critical applications such as SAP, Oracle Ebusiness, and SalesForce.com.
So the real debate was “do we bring the ‘client/server’ application model back to the web, or do we continue to improve the current dynamic nature of the web which allows clients and servers to fully participate in all aspect of the application?”
Luckily, a conclusion has been reached and the decision has been to keep the Web dynamic and to abandon parts of the ECMAScript 4 concepts that could have had a negative or backward impact on the dynamic nature of the web.
Some might call harmony a victory for Microsoft, who despite their SilverLight effort were lobbying to keep JavaScript more incremental and dynamic, others might say that it dismisses Adobe’s ActionScript, which was paving the way for a more a traditional object oriented language for the Web. However, the real winner is the Web as we know it today as this event ratifies its design principles and consolidate its resources for building a better and brighter future. Harmony is a great milestone for the future of the web, and in many ways it has already reinvigorated the industry interest about the web technology discussions and directions. The ECMAScript team did a fabulous job at reaching consensus and articulating the decisions in an objective and informative way.
For enterprises, this is a huge step forward as it ratifies open Web technologies and design principles as the future-proof building blocks for creating the next generation of internet enterprise applications.
Now, the next two big milestones for the web are going to be how fast Microsoft will catch-up on its JavaScript implementation, and when the web will be able to leverage the next iteration of the web markup language (HTML 5).
Note: if you are getting confused with all these names and version, Alex Russell made a nice name soup.
Just finished checking in the last of the updates (minus bug fixes) for the new Ajax IMB Client, after a week of straight coding and little else. The new version has been completely rewritten from the ground up. This coincides with Nexaweb’s upcoming release (in a month or so) of an updated version of the Ajax Client. The Ajax Client codebase will be completely updated and run over dojo 1.2. All the coding for these updates follow six principles:
One of the goals of the dojo.E project has been to bring some of the standards created by the W3C and others to developers for building their Ajax applications. A couple of weeks ago, I saw on Ajaxian.com that Firefox and Webkit are going to support XBL. Simply defined, the XML Binding Language or XBL is a way to create reusable components.
The New Release: dojo.E 0.2.4
Last week the dojo.E team updated the code base of the dojo.E project. Many things in the code changed from the first release. The focus of the 0.2.x release was to create a well defined architecture around the core concept of adding XML to dojo. In this light, we created a flexible and well thought out XML processing engine that can take XML embedded in a script tag or external to the page and process the markup based on configured tag and namespace handlers.
Charting is one of the more advanced components that an application developer has at their disposal. It may not be used in every application but it probably could be and should be. Why? Charting makes the consumption of larges amounts of data easier and quicker than their tabular counterparts. In the Web world there are a couple of ways to bring charting to your Ajax application.
