So I was thinking about enriching/AJAX-ifying my current JSF UI. The data displayed is very complex; the code is getting big and cumbersome, and the size of each page is reaching 100kb. Actions feel very un-responsive and slow, since it takes 2-3 seconds just to download the HTML itself!

One option is to not even do HTML+JS, and use a Swing-based downloadable client UI. Another is to use partial page replacement and keep existing JSF code. Also, I could just use bare-bones DWR and jQuery.

Common things to think about are:

• I have a good POJO model of what the UI is managing, and I want to re-use it
  
• Wherever the POJO model lives, it has to be able to talk to J2EE service beans

A Swing UI would let the model live on client-side JVM, and would require an RPC channel to the J2EE side directly. Promises to be clunky...

I did some quick Googling on DWR and direct JavaScript <-> server-side session POJO interfacing. Looks very cool because of its simplicity. I am comfortable with using jQuery, and its one-liner minimalism could mesh very well with making simple get/set calls to Java model beans. However, as the UI itself gets complex, one-liners get hairy.

JSF with PPR could be nice and easy to add to existing code. But since it will still generate huge amounts of HTML, I wonder if it will stay just as slow. The only way it wouldn't be the case is if JSF only rendered the affected parts of HTML.

Something to ponder...

Nano HTTP server

A tiny utility that provides a super-minimalist HTTP server, serving up contents of just one file. I mocked it up in Perl a while back, I think it was supposed to provide a WAR file for remote deployment to Tomcat, or some such.

Not really that great, but may be useful for quick-and-dirty file transfer or for testing HTTP stuff. The source code follows:

##
#       listens for HTTP connections and, regardless of request,
#       always returns contents of given file, with given content-type
#       header value
#       useful to serve up some test data as though it was from a real
#       HTTP server
##

use IO::Socket;

my($port, $file, $contentType) = @ARGV;

$port = int($port);

defined $contentType or die "must supply content type";

open(FILE, $file) or die "cannot open file";
local $/ = undef;
my $data = <FILE>;
close(FILE);

my $socket = new IO::Socket::INET('LocalPort' => $port, 'Proto' => 'tcp', 'Listen' => 1, 'Reuse' => 1);
$socket or die "cannot create listener socket";

while(1)
{
        my $clientSocket = $socket->accept();

        # read a token amount of data, just for appearance's sake
        my $buf;
        $clientSocket->recv($buf, 5);

        # print our response
        print $clientSocket "HTTP/1.0 200 OK\r\n";
        print $clientSocket "Content-Type: ", $contentType, "\r\n";
        print $clientSocket "Content-Length: ", length($data), "\r\n";
        print $clientSocket "\r\n";
        print $clientSocket $data;

        $clientSocket->close();
}

Unicode Sparklines

The concept of Sparklines (http://sparkline.org for examples) has been around for a while. I was reminded of it when browsing the Unicode character map the other day, and coming across the "block shapes" characters. There is a set of 8 characters that are essentially vertical bars with heights ranging from 1/8th to full character height. That allows to create crude but image-less quick spark-lines directly in text.

I mocked up a quick script that pulls stock data from Yahoo! Finance and converts it into a bar-graph using those Unicode characters. My Debian machine's fonts display those codes, so I assume most browsers out there will, too. Here is an example: ▇█▆▄▄▃▂▁. Link: http://sigmaxis.com/misc/quote-unicode.php

By the way, it was pleasantly surprising to see Unicode support for a lot of other "pragmatic" characters, such as ASCII box-drawing, etc. Heh, reminds me of good old DOS pseudo-GUIs and spreadsheets.

Script source:

<?php

$ticker = 'JAVA';

$handle = fopen("http://ichart.finance.yahoo.com/table.csv?s=$ticker&g=m", "r");
$csvdata = fread($handle, 4000);
$lines = explode("\n", $csvdata);
fclose($handle);

$prices = array();
$max = 0;
$min = 1000000;
$skipped = 0;
foreach($lines as $line) {
        if(!$skipped) { $skipped = 1; continue; }

        $values = explode(",", $line);
        $price = $values[4];

        if($price > $max) { $max = $price; }
        if($price < $min) { $min = $price; }
        $prices[] = $price;
        if(sizeof($prices) >= 8) { break; }
}

$prices = array_reverse($prices);

header("Content-Type: text/html");

echo "Monthly closing price for $ticker: ";
echo '<span style="background: #cdb">';

foreach($prices as $price) {
        $adj = intval(1 + 7 * ($price - $min) / ($max - $min));
        echo "&#960$adj;";
}

echo '</span>';

?>

JSF MyFaces tree2 Practice

I have tried using the MyFaces Tomahawk custom tree2 component in a UI project of mine. I had to show a hierarchy of beans; in addition, each bean had several list properties which also had to be editable and shown as part of one big heterogeneous tree structure.

Here are my observations:

• not nearly as simple and quick to get going as JSF sets the standard for
• does not seem to work inside the h:dataTable element!
• out-of-the-box, client-side node expand/collapse state does not react cleanly to tree modifications

Bean model implementation took a couple of tries to get decent, since node objects must implement the TreeNode interface. The cleanest result was to just roll a usual bean model, implement a TreeNodeBase subclass with a generic Object "data" field and then have a "getTreeRoot" method on the top-level element that would walk the model and build a corresponding tree of nodes. That way, I could have JSF tags get directly at the original model bean via the "data" field with no extra fuss.

The alternative included making model beans directly subclass TreeNodeBase, but that got messy fast.

I don't know if someone implemented that already, but I was aching to have a JSF tree component that would not impose a custom tree node interface model. The cleanest implementation would just take an arbitrary root node bean value and then recursively invoke a special "get child nodes" EL expression on it and its children. For example, assume that you have an "Account" model bean class, and it has a "getChildAccounts" method that returns an array or list. Here is what I'd expect the tag to look like:

<x:myAwesomeTree nodeVar="acct" value="#{blahblah.rootAccount}" children="#{acct.childAccounts}">
... usual JSF tags referencing the acct variable ...
</x:myAwesomeTree>


I should mention that I ended up ditching the tree2 tag after all. I just made a special tree-walker method that returns a list of all nodes in my tree structure in traversal order. That list is shown directly as a bunch of divs via t:dataList tag. Then, each node tells how many ancestors it has, which sets the CSS left-margin attribute. Yep, that's right. Cheap and dirty won the day.

In fact, even after that I ran into performance and usability issues... I think that I should have made a Swing-based UI delivered via Java WebStart. For my need - a complex, rarely-accessed administrative interface - it fits the bill best. But oh well, that is a task for another day.