Blogs

Merb to be Merged into Rails 3.0

Tagged:  

Yesterday the Ruby on Rails team broke the news: the alternative Ruby web application framework, Merb, will be merged into Ruby on Rails 3.0. Merb, which was already closely patterned after Rails, brings performance, modularity, and better integration with alternative JavaScript and ORM frameworks to the table. The default Rails configuration will still be the "full stack" framework, which uses ActiveRecord and Prototype, but there will also be a "Rails Core" with the ability to opt into specific other (e.g. JavaScript or ORM) frameworks as desired.

You can read the announcements by DHH here and Yahuda Katz here.

Migration of desktop applications to the web using Visual WebGui

The following is the first part of a 3 parts series of articles ppublished on VisualWebGui website describing the various available migration options of desktop/smart client applications to the web using Visual WebGui migration tool.

In order to discuss the migration process of legacy desktop applications to the web, we should first agree on 3 different types of desktop applications:

  1. WinForms based desktop application (C#/VB.NET). The UI layer is coded using .NET languages – the business can be .NET, COM+ or any other interop.
  2. VB 6.0 based applications. The UI layer is coded with VB 6.0.
  3. Other desktop or smart client technologies (C++ MFC/ATL, Delphi, Java etc). Any other smart client technology based applications.

WinForms based desktop applications to Web
Background
Normally, without Visual WebGui the migration process of a WinForms desktop application to the web will require a full re-engineering of the UI layer to fit the web architecture and capabilities.

If we take WinForms migration to ASP.NET for example using any AJAX 3rd party controls in order to provide a rich UI experience, we will have to consider:

  • Entirely new API.
  • Entirely new update approach.
  • Entirely new look & feel – or work hard to customize the UI to look the same.
  • Lighten the amount of data transferred to the client and presented at any given time to avoid severe latency.
  • Compromise on features list due to the web limitations.
  • Handling security holes created as a result of opening services consumed by client side AJAX and transferring business logics to the client.

Visual WebGui SDK is fully integrated with Visual Studio and provides the exact same API and set of tools/capabilities which are provided out-of-the-box with WinForms 1.0 and 2.0. This fact enables the native capability of simply copying any existing WinForms source code to a VWG project and providing a fully functional equivalent web application.

The Process
The basic 3 steps of migration (view a walkthrough tutorial):

  1. Open a new Visual WebGui application.
  2. Copy the code from your WinForms project into this new web application.
  3. Replace any reference to WinForms API namespace (“System.Windows.Forms”) within the code to Visual WebGui API reference (“Gizmox.WebGUI.Forms”).

Any standard WinForms application which is using the 58 WinForms out-of-the-box controls will then compile and execute as a plain web application.

The outcome of this short process is an ASP.NET based solution in terms of deployment and runtime and has the following properties:

  • Deployment is copy & paste equivalent to an ASP.NET web site.
  • Server infrastructure requires an IIS and .NET CLR only.
  • The application can be consumed from any plain browser - no installation is made on the client.
  • Minor static and cached footprint on the client ~200kb of plain JS and HTML code due to the Empty Client concept.
  • Support for multiple presentation layers with the same code base (DHTML/Silverlight or Smart Client).
  • Maintain a single layer of code – no need to write or maintain JavaScript, HTML and services.
  • Highly secured due to the Empty Client concept.

Considerations & Exceptions
There are 3 major setbacks you might have on the process which you can quantify in advance and estimate the amount of work that has to be done in order to migrate your application:

  1. Minor differences between the VWG API and WinForms which are mainly caused by architecture differences.
  2. The amount of 3rd party controls that are used in your application. This section describes a situation of using some non-WinForms out-of-the-box controls (for example Infragistics or DevExpress controls etc). In those cases you can select the most suitable solution from the following 3 options:
    • Choose a similar control from the WinForms out-of-the-box, adjust your code to use it and then perform the migration process.
    • Select an equivalent 3rd party ASP.NET control (Infragistics, Telerik, DevExpress etc.) which provides the same functionality, wrap it by a click of a button in VWG and adjust your code to use it.
    • Write your own VWG custom control which will perfectly suit your needs and then adjust your code after the migration process to use this control.
  3. Adjustments of a single user desktop application to a multiuser web environment. This section summarizes some of the major issues of transforming a single user application to a multiuser application sharing the same CPU, Memory space and other resources.
    • Thread safety – since a WinForms application can contain static members which are accessible to a single user, you should now consider one of the following:
      • Replacing those static members to a synchronized multi-thread safe data structures.
      • Lock critical read/write sections to protect concurrent multi user access.
      • Remove the statics and find instance or DB based solutions.
    • Memory load – in a desktop application, there might be places when the original consideration of the amount of memory in use was based on the assumption that the executing machine is local. therefore, many items are loaded to memory simultaneously without limitation.

Now, on a shared memory environment, when the server does the heavy lifting, the amount of memory consumed by each user will set the number of concurrent users that can be served by each server.

The following steps are recommended:

  • Consider loading items to memory on demand (keep only the headers and the identifiers in memory).
  • Remove any large objects read to memory – for example, don’t save binary objects to memory, instead write the binary to the response stream directly to the client.
  • Prefer DB based paging on entire prefaces and memory based paging. Visual WebGui provides mechanisms to enable it easily.

Summery
Migration of any WinForms application to the web using Visual WebGui has the following advantages:

  1. In 3 simple steps you will be able to get very close to a working web application.
  2. The effort you have to make in order to accomplish a fully functional web application is measurable.
  3. The application can keep using the existing BL and DL layers, and only the UI is either migrated automatically or adjusted.

Click to read the remaining articles:
VB 6.0 to Web
Smart Client and other Technologies to Web

or to view the tutorial:
How to Migrate WinForms to the Web

Ajax for the Lazy: Ajaxify

Tagged:  

From the "good to know" deptartment: a new jQuery plugin for converting existing links on a page to AJAX load and submit requests is available: Ajaxify.

Some examples:

//The easiest way: binds "click" event to existing "href" attribute
//and loads it into the portion of the page specified by the "target"
//attribute
$("#some_id").ajaxify();

//With options
$('#some_id').ajaxify({
        link:'example.php?action=options&ajax=true',
        target: '#container',
        loading_img:'images/orange_loading.gif',
        title:'Setting up options',
        method:'POST'
});

The Ajaxify plug-in also supports partial loads and forms. A demo page is available here.

jQuery 1.3 Beta 1

The first beta release of jQuery 1.3 is out.

Changes since 1.2.x:

  • New CSS selector engine (Sizzle)
  • Rewrite of DOM manipulation
  • Rewrite of namespaced event handling
  • Rewrite of .offset()
  • And more...

See earlier coverage here for more details.

Get jQuery 1.3 beta 1 here.

Opera 10 Alpha Released

Tagged:  

Opera Software has released the first alpha of its Opera 10 browser, the first public release to pass the Acid 3 test. The release marks the debut of version 2.2 of Opera's Presto rendering engine.

New and notable:

  • Up to 30% faster page rendering than previous releases.
  • Support for the web fonts CSS 3 module.
  • RGBA and HSLA opacity, e.g. background-color: rgba(255,0,0,0.5) or background-color: hsla(240, 100%, 50%, 0.5).
  • Support for the Selectors API.
  • Improved support for SVG, including frames-per-second on animations and ability to use SVG web fonts.
  • Improvements to the Opera Dragonfly set of developer tools, including the addition of a network tab (a la Firebug) and live DOM editing (nice!).
  • Built-in browser inline spell checking and auto-updates.

The Opera 10 alpha release can be downloaded here. The current stable release is version 9.6, and is available from the main page.

FireUnit

John Resig has just publicly announced a new extension/framework for unit testing JavaScript code with Firefox/Firebug called FireUnit. The framework provides a simple API for reporting test results within a new tab in Firebug. It also provides some methods for simulating browser events. Developers can use a local HTTP test server for running unit tests that need to simulate a network communication.

FireUnit requires Firefox 3+ and Firebug 1.2+. You can grab the extension and source code here.

There are some examples of how to write a test case here, and there is a blog entry on FireUnit by the other co-author here.

jQuery Patches for 1.3

Offering a sneak peak of what will be in the new version, John Resig has released the first in a series of patches to jQuery in preparation for the 1.3 beta release. They are:

  • A patch to the .domManip method to use DocumentFragments, resulting in manipulation code (append, prepend, etc.) that is about 15x faster.
  • Addition of a .closest(selector) method which starts with the current node and traverses the parents in the DOM tree to match the selector (think "first self or ancestor"):
    closest: function( selector ) {
              return this.map(function() {
                  var cur = this;
                  while ( cur && cur.ownerDocument ) {
                       if ( jQuery(cur).is(selector) )
                          return cur;
                       cur = cur.parentNode;
                  }
               });
    }
  • A patch to the seminal DOM ready() method that backs off attempting to detect the loading of stylesheets (apparently not possible according to Resig) to normal "document ready" functionality.
  • Addition of multiple-namespace support for events.
  • A new internal property that keeps track of the selector chain (mainly for use by plug-in authors).

The new jQuery 1.3 will also feature the Sizzle JavaScript CSS selector engine as well as revamped implementations of all the selector-based methods.

You can read all about the new patches in Resig's original post here.

Update: the new Sizzle engine has been added to the 1.3 trunk.

DWR version 3.0 Release Candidate 1

Tagged:  

DWR version 3.0 has reached release candidate 1. Here's what's new right from Joe Walker's Blog:

  • RPC Enhancements
    • Varargs support
    • Method overloading (DWR tries to copy Java's method matching rules)
    • Typed parameters (so you can say new Apple() in JavaScript and pass it to the addFruit() method and DWR will instantiate the correct type on the server)
    • Lightweight typed parameters (as above, but by adding $dwrClassName:"Apple", for when you are getting the objects from something else)
    • More natural synchronous XHR (so you can call var reply = Remote.getData() when doing 'Sjax')
  • Improved Marshalling
    • Binary file upload/download (byte[], java.awt.BufferedImage, InputStream etc and FileTransfer can be uploaded from an input type=file, offered for download, or sent to an img)
    • Functions (Store a reference to a JavaScript function on the server for later execution)
    • Objects by Reference (Store a reference to a JavaScript object, and then call methods on that)
    • Locale, Currency (DWR will marshal to and from java.util.Locale and java.util.Currency objects)
  • Reverse Ajax
    • JavaScript can now implement a Java interface (For simple integration with Java Events/Listeners)
    • More scalable Reverse Ajax APIs (See org.directwebremoting.Browser)
    • DOM Manipulation Library (Window and Document can now be manipulated from the server)
    • The server now runs in 3 modes: stateless (New - save memory with no page tracking), passiveReverseAjax (the default) and activeReverseAjax (comet enabled)
  • TIBCO GI Integration
    • Complete set of Reverse Ajax Proxy APIs (So you can manipulate your GI user interface from Java on the server)
  • Dojo Integration
    • Data Store (Keep a server side data store in sync with data in a client browser with both sides able to send updates. The data store also supports paging, sorting and filtering)
    • Packaging Integration (dojo.require all your DWR scripts)
  • Server Support
    • Asynchronous servlet support for Tomcat and Glassfish
    • Improved Spring and Guice support
  • Over the wire
    • JSONP support
    • JSON-RPC support
  • Tech Previews
    • JMS Integration (Publish to the browser directly from JMS)
    • Jaxer Integration (Zero configuration for trusted environments)
  • Infrastructure
    • SVN (We've moved from CVS to SVN)
    • Related Projects (Our repository contains a set of related projects including a number of demos)
    • CLA (We've been through a legal review and have signed CLAs for dwr.jar)
    • Dojo Foundation (We joined the Dojo Foundation and are now hosted by their servers)
    • Better Documentation (DWR version 1.x had great docs. Version 2.x let things slide a bit, but we've dropped Drupal, and have our own system now)
    • You can download it here.

      Read the full post

Tapestry 5 Released

Tagged:  

The 5.0.18 version of Apache Tapestry has been christened as the first release of Tapestry 5. The release is the capstone of long effort to re-write the web application framework from scratch, removing a lot of the complexity of previous releases toward a more POJO and annotations-driven approach (and making it non-backward compatible with version 4, a sore point for some current Tapestry users).

For those who don't know, Tapestry is a component-based web application framework (one of the original) for Java similar to JSF or Wicket.

New features:

  • POJO component classes: no interfaces or base classes required
  • Minimalized configuration via annotations and naming conventions
  • Live class reloading (think JavaRebel)
  • Its own dependency injection framework (Tapestry IoC)
  • Built-in AJAX support via Prototype/Scriptaculous
  • Tapestry template pages are now valid XHTML (with a custom namespace for Tapestry), making them easier to work with, especially when round-tripping between designers and programmers (an approach similar to Wicket's)
  • Automatic REST-style URLs
  • Automatic client-side form input validation
  • Built-in components such as BeanEditForm, BeanDisplay, and Grid
  • Really nice exception handling

You can download the release here, or (for Maven-style dependency management junkies like myself) reference the dependency: org.apache.tapestry:tapestry-core:5.0.18.

Google Chrome Out of Beta

Tagged:  

Google Chrome has just turned the big 1.0, as the browser has met Google's requirements for stability and performance.

Changes from the Beta

A short list of improvements includes:

Of course, the Chrome team isn't done yet. Future enhancements to the browser include form autofill, RSS support, and extensions.

You can download Chrome here.

Syndicate content