Monday, August 27, 2007

missing table in IE

Help! I can't figure out why this table won't show up in Internet Explorer (v. 7, in Windows). The table (id="popsizelegendtable") is viewable in Firefox but totally disappears in IE. I have no idea what's going on. Here's the unprocessed source. Is it a CSS style issue? Or is some of my javascript overwriting some styles? The nodes and data are still there in the HTML tree, but it just isn't viewable. I feel like I've turned every display to block and zoom to 1 and am out of ideas.

Works in Firefox and IE (almost)

Version 2.3 is now up! Now it works in Firefox on Windows, Linux, and Mac, and has almost all functionality in IE in Windows and Mac. The only thing missing it not being able to draw the sample size legend in IE.

Aha! Getting google to return svg's instead of img's solved

So thanks to Mike William's post to the Google Maps API Google Group, I can get GPolygon to return svg's instead of img's in Firefox in Linux. Yay!

Basically, you have to set these two parameters, _mSvgEnabled and _mSvgForced to true in order to force Google to return SVG's. Here's the code snippet that made everything better:

function load() {
if (GBrowserIsCompatible()) {
// Initialize
if(document.implementation.hasFeature(
"http://www.w3.org/TR/SVG11/feature#SVG","1.1")){
_mSvgEnabled = true;
_mSvgForced = true;
}

Friday, August 24, 2007

VML - link to reference

A useful link to VML documentation:

w3 VML specifications

Conflicts between jQuery and Prototype objects in IE

I'm not sure that I have this problem correctly diagnosed, but I've been noticing a lot of errors in IE when I have lines of code that combine jQuery objects with Prototype functions. I guess this means that I've been sloppy with my JS and Firefox has been letting me get away with it! Here's an example of code that works in Firefox, but not IE:

var block = jQuery(".widgetBody", $(elementid))[0];
var blockstatus = block.getStyle('display');

It seems like the problem is mixing the jQuery object, block, with the prototype function, getStyle(). The error is removed when I replace the second line with a call to a jQuery function instead:

var blockstatus = jQuery(block).css("display");

I guess it makes sense that combining jQuery and Prototype code is a bad idea. I was using Prototype to begin with then started using more and more jQuery, and never went back to clean out all the Prototype. Heck there's even Prototype in the line with the jQuery search! Anyways...laziness is costing me now.

Addition of VML line critical to getting things working in IE

I can't believe I missed this until now. To get the polylines and, thus, polygons to render correctly in IE, you have to include a reference to the vml namespace. The top of your document should look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml">

See the documentation on XHTML for slightly more info.

Thursday, August 23, 2007

Internet Explorer -- pain in the ass

I've started debugging the program in Internet Explorer (v. 7.0.5730.11) on a Windows machine. I've been using Firebug Lite and the IE developer toolbar to help debug. Even put together, neither of these is remotely useful compared to the awesomeness of Firebug in Firefox. Anyone out there have a recommendation for anything better for IE development and debugging?

XRay is another interesting CSS viewer tool that works in any browser.

Fixing svg/img bugs

So I got a bug report that said that the site didn't work in Firefox in Linux. Only one wedge was being drawn. Turns out that for some reason the call to GPolygon that usually produces svg's produces 'img' elements instead. This caused a bunch of problems. Now I've fixed it so that I check if img's or svg's are produced, then modify the event handling of those objects. I suspect that this img/svg problem may be at the heart of the app's bad behavior in Internet Explorer and Safari as well. But there are more bugs to take care of there... Just a note: Gmaps in Firefox in Windows and Mac DOES produce svgs.

By producing img's instead of svg's certain features of the site become impractical to implement. The biggest problem is that the img's must be completely redrawn each time there's a change. With svg's I can easily change the style (fill color, stroke width, etc.) of the element without having to redraw the graphic. The drawing of the pies is time consuming, so with img's I've disabled the dynamic updating of the pie wedge colors. Now the user must click the 'ok' button to submit their new color requests.

Note: I'm not sure who's 'fault' it is for not being able to use svg's on Firefox in Linux. The documentation for Firefox states that svg support is now built in to the latest release, so maybe it's Google Map API's fault for returning the wrong img datatypes when it should return svg's. In any case, img's are what's being rendered on the page.

Development environment in Linux

So getting my development environment set up in linux was no small task. I'm using Fedora 6. Here were some of the obstacles:

1) The distribution's version of Firefox doesn't come compiled with the necessary debug flags for Firebug to work properly. I downloaded a new version of Firefox directly from the website and that seemed to have solved most of the debug problems. I've heard that you may need to download the source and compile it by hand with some special flags, but luckily the downloaded tarball worked for me.

2) The php-json package was missing from my installation of php. A simple yum install fixed that problem.

Monday, August 20, 2007

Last weekly update

I've just uploaded my code that I'll be evaluated for Summer of Code experience (version 2.2.2). Whew! I really enjoyed the summer and learned a lot. There still are many more features I'd like to add, but I feel pretty happy about the product at this stage.

Thanks, everyone!

Phyloinformatics Summer of Code Meetup at NESCent

At the end of last week the NESCent SoCoders all met up in Durham, NC for a wrap up conference. It was really neat to see what others had been doing all summer long. The diversity of projects was to be expected, though there were some common threads between us.

One message that was hammered home to me was the need for file standards in evolutionary biology. The amount of time spent massaging your data into different formats to interface with interesting programs is many times prohibitive to actually using the programs. I was struck by all the development going on with NEXUS (ex: Nexplorer, NEXML, and libraries for NEXUS) in particular, and I feel like I need to jump on this bandwagon too! I was quick to realize that I'm part of the problem in that PhyloGeoViz currently doesn't accept NEXUS (or anything else for that matter besides my own special format). Well, being able to work with NEXUS files is now on the top of my list of priorities.

Another common theme of the meeting was the visualization of tree data. Multiple projects were coming at this problem using different languages and in different contexts.

A great meeting! I had a lot of fun hearing other students' and mentors' experiences. Hope to run into you again soon!

Licensing

I decided to use the GNU GPL. It seemed the most broad.

I'm not sure if I did this correctly, but my Google SVN project repository contains other people's scripts (like Prototype, YUI Color Picker, jQuery, etc.) that have their own licenses, etc. All the scripts I used are open source libraries, but I'm not sure if including them in my own repository is ok. Should I have just told the user to download them themselves or is it ok to package everything together like I've done? In any case, I think it's ok to put everything in one place.

New features added

Last week I tried to code up as many of the features as possible prior to the meet-up at NESCent. Here are some I managed to add by the end of this past weekend:

Expandable/collapsible menu widgets for the legend.
Outline pie wedges option.
Enlarge/reduce map window size.

I also got all the pages prettied-up with the same css styles, which I think made a huge difference to the look and usability of the site. Thanks, Jack for helping me feel my way around CSS this week!

Newest version is up. Version 2.2.2.

Icons

Here's a nice icon set that I found. Very good looking. But it didn't have the +/- icons (for expand/collapse a tree) that I needed.

Silk icons

I did, however, use this nifty site that generates pretty ajax loading icons (animated gifs) for you.

ajaxload.info

Uploading to google repository

I finally got my local source code uploaded into Google's subversion repository. It was a bit of a chore to figure out how. And I couldn't figure out how to keep all my own repository history alive. Ah well.

Monday, August 13, 2007

Weekly update

I've spent most of the week tying my pages together. Now the user can input haplotype group data as well as the basic input data. Also, the edit data page now integrates with the rest of the site. The color picker that dynamically updates the pie wedge colors has been tested as well.

Things to do this week:
  • Clean up code for repository.
  • Include comments on the license, etc.
  • Get code into repository.
  • Write documentation and user instructions.
  • Edit CSS and make site look prettier.
  • Prepare presentation for NESCent meet-up at the end of the week.

Version 2.0 up and running

I've uploaded my latest version. Still need to fiddle with css to make it look nice, but the basic functionality is there. New features:
  • When changing color the pie wedges update with new colors in real time.
  • An edit data page, where the user can include/exclude populations or haplotypes and edit data fields.
  • Users can now group haplotypes by specifying haplotype groups.

Stuck on image creation

I'm trying to output the legend (of haplotype colors and of sample sizes) to some sort of image format (*.png for example). However, I'm quickly realizing that I'm in over my head. Anyone out there know of any javascript libraries that can help me?

So I'm putting this on the back-burner for now. I guess if you want to save the legend info, your simplest bet is to do a print-screen + crop.

Tuesday, August 7, 2007

How to auto-submit a form

Sometimes it's useful to pass data to a hidden page that processes the data then passes the new data to another page. To pass the data through forms, use javascript. Set a body onload function with $("form_name").submit() to submit the form when the page finishes loading.

Example:

<?php
....data processing code here
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"\n
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<script type="text/javascript" src="javascripts/prototype.js"></script>
</head>
<body onload="$('newdata').submit()">
<form id="newdata" name="newdata" method="post" action="newviewer.php">
<input type="hidden" id="data1" name="data1" value="x1">
</form>
</body>
</html>

JSON, php, and html forms

So I've been working on a data processing page that is hidden from the user, takes form data from an input page, processes the data, encodes the data using json in a new form, then auto submits the form to a new page. Here are a few helpful functions that got it working properly:

1. The json_encode() function in php doesn't escape some html special characters like quotes. It's helpful to wrap it with the function htmlspecialchars() so that it plays nice with your html.

2. php line breaks are '\r'. I had inadvertently included some line breaks in my string variables. To fix that problem use the trim() function.

Monday, August 6, 2007

Weekly update

This week I've spent hacking away at the data management page. I've got all (cross you fingers) the bugs smoothed out from transferring the changed data from the data management page to the viewer page. A new feature of note is that the program now sorts the haplotypes by groups and the user can color all haplotypes in a group at once. (Note, I haven't uploaded the newest version to the website yet, sorry).

Features added this week:
  • Can include/exclude haplotypes and populations.
  • Can edit data.
  • Can specify haplotype groups.
  • Can color by haplotype group.
  • Changing colors in the colorpicker now changes the associated pie wedge colors in real time.
Next week:
  • Meet with David about the remaining goals for the project, and project timeline.
  • Update the export function to allow grouping by haplotype groups, etc.
  • Tie the data management page to the input data page.
  • Update website with latest release.
  • Research copyright laws and permissions concerning the maps.

onChange handler for the colorpicker

Knallgrau's color picker has been a really useful library, but it took a bit to figure out syntax for the onchange handler. Each colorbox shares the same colorpicker, so I was having trouble deciphering which of the DOM elements was the calling element, so I set an 'onclick' handler on the 'ok' button then had a big loop through all the possible elements to see which one changed. Besides being ugly, the user doesn't have to click on the 'ok' button to exit the colorpicker, so this implementation fails to register a lot of events.

Turns out I was going about this all the wrong way. Knallgrau has an 'onUpdate' attribute that you can set. Here's the syntax when initializing the colorpicker:

new Control.ColorPicker("inputid", { IMAGE_BASE : "javascripts/colorpicker/img/", "swatch" : "buttonid", "onUpdate" : changeColor });

where 'inputid' is the id of the <input> element, 'buttonid' is the id of the <button> element, and 'changeColor' is the function called when the color is updated.

In the changeColor function, this.field gives you the input element. Example:

function changeColor ()
{
console.log (this.field); //prints <input type="hidden" id="hapcolor1" name="hapcolor1" value="B71919"/>

console.log (this.field.id); //prints "inputid"
}

jQuery!

So I've been trying to update all of the pie wedge colors in real time as the color picker runs. To do so I have to have a quick and efficient way of grabbing, traversing, and setting specific DOM elements. jQuery, this fabulous javascript library does all that and more! It's super fast. But the documentation is a little harder to understand than for prototype.

Wednesday, August 1, 2007

another bug to fix

Fart! If you click away from the default map type on the viewer screen (say go from 'satellite' to 'map') you lose the ability to drag the pies and color them. It's bizarre, but if you resize the pies you get back some of the draggability and can recolor them....