Issue Number 2

Though we list down what we’re supposed to do in our wiki, these are all very general only listing features that should be implemented. But every feature is built with many steps, is made up of smaller sub features (components). I think by simply saying that we’ve finished a feature doesn’t justify the many other things that we’ve done to finish that feature.

It was staring me right in the face before but I wished I could have thought of using an issue tracker. It was taught during my internship and I always saw it on my way to our repository page @ unfuddle. We also need a list to track the many issues we encounter during development from difficulties to bugs. This gives more weight than simply saying, “we finished this feature this week, demo demo demo demo”. Hopefully things will be much smoother from now on.

I’ve already listed the issues related to developing our save a project feature in our wiki and today I’ve learned a lot of things by resolving issue number 2: laying out GWT panels in CSS!

1. Class and Id are different in CSS

<div id="content" style="font-size:8px">
    <!-- GWT widget placed here-->
</div>

We wanted to typeset our GWT widgets but didn’t know so I made a test GWT module and tried to find out how. At first I did it the normal way placing a widget and a pre encoded div with an id and gave styled the div in the html. But that didn’t work out.
Apparently id applies to only one element in HTML and class can span many elements. What was wrong with my code was that
I was applying the style to a certain id and not to a widget with an id. So I gave the widget an id in gwt and then used css to style it:

# get-widget-that-i-used-for-testing
{
font-size:8px;
}

2. There are two ways to style GWT widgets

<stylesheet src="__css-url__"/>

One is in plain old html and another using Automatic Resource Inclusion (ARI) also known as putting a reference in the gwt.xml file. What’s good about ARI is that a certain style goes where ever a widget is deployed. This is good if we want to reuse widgets which….I think we might be doing. But there’s a bit of a learning curve when using ARI. One is I don’t know how exactly I’d reference the styles in an xml file (see code above). The GWT tutorial does this by like it treats the stylesheet as a java file

<inherits name='com.google.gwt.user.theme.standard.Standard'/>

So for now I hope, we’ll go for plain old html. Now at least I know I can layout GWT widgets.

Intuition in Rubrics

For the rubric to be user-friendly, we’re going to manipulate the created spreadsheet to have a defined template. We’re thinking that criteria column goes to column A and the succeeding columns are for the points arranged from lowest to highest.

Something like this:

This way, users will be guided as to where the definitions should be placed.

Development-wise, since we’re already able to create rubrics, we just have to manipulate it. We’re looking at this API for help.

Will let you know what happens.

AR mode radar added

 

I added a radar that shows the user nearby points of interests within a range of 300km. It also shows the POI’s positions in relation to the user.

As for the marker position on the screen, I still have  to calculate this based on the altitude and pitch values.

Into the fray

In football, you know when a substitute is thrown into the fray when it’s extra time and his is team a goal behind. Although I can’t say that we’re a goal behind, we’re definitely a little bit behind schedule this week. Don’t ask me why. So I decided to wait a little bit and take a dip into web services.

So I guess I was wrong. There is a way to machine read dynamically generated pages. I met Miko, a WSG graduate student, last night and he told me that it’s definitely possible. It’s more or less like this: a crawling web agent will execute a script that will query the web service with parameters and then machine read the results.

All this time I’ve been assuming that the xml that will be machine read will be embedded in the jsp. Although I have seen somewhere that it’s possible, it’s probably not what is required. What is required is an rdf document that will contain information.

Pulling Google Spreadsheets data to Projectrix

I’ve been searching for existing implementations for this until I encountered David Burger’s post:

http://david-burger.blogspot.com/2009/03/display-google-docs-spreadsheet-data-on.html#comment-form

It made me hungry (okay, lame) but I’ll try it out in a bit. This might solve our problem of sending a request to Google Spreadsheets to return an ATOM feed. I also found another way, albeit more complex, using JSON (which I don’t yet have any idea about):

http://blog.uxebu.com/2009/04/30/jsonp-for-google-spreadsheets/

Another task pending is to try out the Jericho HTML parser (as suggested by Jeune).

Will update you if either works.