[fusion-dev] Fusion Trunk Status Update

[Paul Spencer]

I thought I would give everyone a quick update on the status of my Jx  
update and a couple of other things.

There are four topics to address:

  * the build process update
  * the Jx update
  * the new imagestrip generator
  * overall improvements from the above

The Build Process
=================

The build process has been cleaned up a bit and the logic for building  
a single file build has been improved, now if you run ant compress it  
will produce a single file build for everything, unless you specify an  
appdef in which case it will include just what is required for that  
app (plus the json version of the appdef) - and compress the whole  
thing using YUI compressor.  It is now simpler to build a compiled  
version of everything, which is ultimately what we want the default  
distribution to use.

Jx
==

The Jx update is basically done except for some testing and a few  
minor quirks that I need to address.  I have merged my changes from  
fusion/sandbox/jx2 into trunk today.

Before you rush off to update, there are a couple of things to note:

1) the Jx API has changed, which means if you are using Jx in your  
template (index.html) to create tabs, panels, dialogs etc then some  
things will need to be updated.  I have updated the standard templates  
that ship with fusion in SVN (at least the mapserver one, I still have  
to check the mapguide one).  I will send a separate email describing  
the major API changes.

2) If you have created a custom skin for Jx (like the MapGuide  
templates), the CSS and images for those will need to be completely  
redone to match the new way we are doing things.  I seriously doubt  
anyone has done this except for DMSG otherwise would have heard about  
it ;) so the impact should be small (except for the mapguide templates).

A quick background on the Jx changes.  The Jx update has been  
undertaken to achieve several goals (not all directly related to  
Fusion per se):

1) reduce the size of the library by switching from Prototype/ 
Scriptaculous to MooTools
2) to standardize the Jx API and CSS files
3) to simplify the internal construction of various objects - now many  
things share a common base class that provides the basic structure
4) to simplify the process of creating a new visual skin for Jx
5) reduce CPU usage by relying as much as possible on CSS and the  
browser's layout engine rather than javascript
6) add some new features (such as menus that automatically adjust  
their position so they don't go off the page)
7) add more visual effects (drop shadows, animations etc)

We have largely achieved these goals, although we didn't get to adding  
any animation effects yet.

The end result is a slimmer library (almost 50% reduction), a much  
cleaner code base and CSS, reduced CPU load, better memory management,  
etc.

Bringing this code into Fusion, though, presented a couple of  
challenges.  The mechanics of updating to use the new Jx API was  
relatively straight forward, but it highlighted a few things that I  
felt were pretty broken in the core architecture of how widgets are  
created and represented.  I took the opportunity to revise this core  
architecture with the end result of simplifying widget creation and  
activation logic, simplifying the creation of new widgets (less to do  
for simple widgets), and completely removing four base classes  
(several hundred lines of code) that were just not necessary anymore.   
There is probably more that could be done with the core widget  
architecture but I am pretty satisfied with the work to date and don't  
plan to do any more at this time.

Image Strip Generator
=====================

I have also added a new image strip generator (php command line  
script) that can be used to generate a single image and a CSS file  
from a set of icon images.  These can be used by an application to cut  
out a large number of requests for individual icons in buttons and  
menu items.  Here is how I used it on the MapServer standard template  
that comes with Fusion:

1) in a command prompt, change directories to the images/icons  
directory in the application and run:

$ /path/to/php /path/to/fusion/utils/imagestrip.php -css ../../ 
icons.css -o ../icons.png *.png

This generates a CSS file in the root directory of the application (it  
can go wherever you want) and a single image in the images directory

2) edit the template index.html file and include the new CSS (after  
the jx skin CSS file)

<link rel="stylesheet" href="icons.css" type="text/css" media="screen"  
charset="utf-8">

3) edit the application definition and update all the widgets by  
changing the ImageUrl to point to the new icons.png file (yes all of  
them point to the same image) and setting the ImageClass to be the CSS  
class for that icon (which was taken from the file name)

So if you had:

       <ImageUrl>images/icons/zoom-in.png</ImageUrl>
       <ImageClass/>

you would end up with:

       <ImageUrl>images/icons.png</ImageUrl>
       <ImageClass>zoom-in</ImageClass>

my text editor has a regular expression search/replace feature that  
let me do it in one step:

search for:
       <ImageUrl>images/icons/(.*).png</ImageUrl>
       <ImageClass/>

replace with:
       <ImageUrl>images/icons.png</ImageUrl>
       <ImageClass>$1</ImageClass>

Combined Improvements
=====================

Old method, worst case: the default install, not compressed, load  
individual widget files:

128 requests, 648 kb, 6.45 seconds

New method (compressed, single file, image sprites for icons):

52 requests, 254 kb, 4.3 seconds

both methods are using gzip compression from the web server so the  
actual file sizes are larger in both cases, but I think this is a fair  
comparison.

Also, there was a compressed build option for 1.0/1.1 which would have  
reduced the number of requests and size somewhat, bringing it a bit  
closer to the new method in terms of requests and size, although it  
doesn't have the image sprite capability for icons which means more  
requests and the new Jx is quite a bit slimmer (almost half the size  
because of the underlying library change from prototype to mootools).

Overall, I am moderately happy that we have achieved the improvements  
we were looking for in this update (less HTTP requests, smaller  
overall file size, improved runtime performance) and have a few new  
features to play with.

There will be a few more things coming for the next version including  
an optimization to the LoadMap process to allow faster initialization  
- the goal is to get a map on the page as quickly as possible, after  
all - and possibly the ability to generate sprites for legend images  
(we have a tentative version for mapserver, not sure if we will have a  
mapguide equivalent or not).

Cheers

Paul

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/