August 21, 2008

New 0.2 (SoC) release, JUICE is born – aka the longest title and the longest post in history

Posted in GSoC tagged , , , , , , , , at 2:56 am by fadinlight

Relevant links:

“Dojoizing” OsmaFrontend

Following what I’ve said before, also this last week (while doing a MAJOR blog posts updating) has been full of interest for code developing, even if not so full of new features. What I’ve been doing is “Dojoizing” OsmaFrontend, to take the most advantage from Dojo toolkit and to have a cleaner code design (separating HTML code from Javascript, using Dojo’s xhrGet). Here the last days timeline:

August 11: TagTrunk

While “Dojoizing” Osmafrontend, I’ve started to separate the trunk code from the tags (thanks to TomH and spaetz that helped me in the #osm channel, also helping me not to do tens and tons of commits ๐Ÿ™‚ !)

August 12: Widgets and blog

A long day of studying to learn how to write Dojo widgets, and to write some of the past posts for the blog

August 13: Tags, Blog, Rule tree

Finally I’ve separated the tags from the trunk, while updating the blog with the new posts. A little interesting new Osmarender Frontend feature developed: a raw tree view of the rules. This is what is going to be, after the major refactoring I want to do for CMYK library.

August 14-15: Django template in Dojo (Dojox DTL)

I’ve started to learn how to use DTL in Dojo, but even after spending the whole day on various tries, I didn’t manage to have it do what I wanted to do to separate some HTML from the code. For example, I couldn’t manage to do a {% for key,value in store %}. Really don’t know why, because with other tags everything worked smoothly.

August 16: Widgets and i18n

After doing all the refactoring to separate HTML content from Javascript, I started to refactor all the code that concerned the CSS editing part of Osmarender Frontend. Then, I’ve started to learn how to do i18n with Dojo, while learning that Dojo’s i18n have some issues with Firefox 3.

August 17: Externalising CSS editor and publish/subscribe

This day I’ve finally externalised all CSS editor code from osmarender_frontend.js file, with some tricks to keep it really separate. As Osmarender Frontend takes the styles and handles them (add, modify, delete) only with the help of CMYK library, and as I wanted to keep the CSS editing widget and CMYK library really separate, I didn’t want to pass the CMYK instance to the CSS editor, nor I wanted to let Osmarender Frontend handle the CSS section of the rule file. This is where dojo publish/subscribe came to help! In this way, the CSS editor will publish a topic, which Osmarender Frontend have to subscribe to pass the parameters to CMYK library. That’s cool!

August 18: JUICE

I’ve spent the last GSoC days to do some minor changes to the code, and to definitely keep the CSS editor widget separate from the rest of the code, with its own i18n. This is how JUICE (Javascript User Interface CSS Editor) project was born!

Three projects in one!

At the end of my GSoC adventure, and at the beginning of a new adventure, I’m very happy to say that three projects have started at the same time:

  • CMYK library: When the refactoring will come to an end, the library will be completely independent from Osmarender Frontend, thus allowing every Javascript-speaking code to handle Osmarender’s rule file smoothly.
  • Osmarender Frontend: A Dojo-powered GUI interface for WYSIWYG handling of Osmarender’s great power.
  • JUICE dojox based widget: Without even knowing or wanting, the CSS editor has now its own life, so, sooner or later (at the end, when it will have more features and handling power), it will be a separate project, perhaps with some integration with Trevor McCauley’s great CSS parser… Who knows… Fantasy is the limit…!

August 10, 2008

Refactoring and UML models

Posted in GSoC tagged , , , at 11:46 pm by fadinlight

(This post has been published after the original date)

Now that all is ready, I know that probably the time is not enough for GSoC deadline to complete all that I would like to complete (even if I’ll try to do my best), that would be:

  • Externalise data model from cmyk.js
  • Create and package a better data model for rules handling (with some GUI hacking I could let it work in few time after creating it)
  • Refactor Osmarender Frontend (the GUI section) code
  • Externalise and dynamic loading some GUI resources (like the various panels)
  • Refactor some controls (mainly those that edit CSS properties) as Dojo widgets
  • If time permits, start using Dojo templating system for some GUI resources
  • Create all packages ready for release

The hardest thing to do would be to write and get to work the refined data model for rules handling. This is because, after a quick refresh of my Osmarender rules knowledge, I’ve produced the rough sort-of-UML model shown above (thank to argouml), which represents needed classes, inheritances, attributes and types. That explains clearly how difficult will be a proper refactoring, at least to get it to work for GSoC deadline without too much loose ends. Obviously I don’t want to risk to break something now. ๐Ÿ™‚

So, what I’m doing now? I’m using a mixed “top-down/bottom-up” stategy. I’ve already refactored some data models used by cmyk.js (1st point) and I’m just starting to externalise and dynamic loading GUI resources for Osmarender Frontend (4th point). This is going to be a step by step process, refactoring the code and re-testing the GUI any time, for every bit, to see if some regression bug appears. It would be quite slow, but, IMO, too much needed to have a maintainable and more flexible code for future improvements.

In the meantime, I’ll begin to prepare Osmarender Frontend’s directory in SVN for release.

August 6, 2008

Refactoring, refactoring… Documenting, documenting…

Posted in GSoC tagged , , at 4:12 pm by fadinlight

(This post has been published after the original date)

During the last week, I’ve managed to learn and beginning to use Dojo packaging features. So I’ve started splitting my cmyk.js file into model and controller chunks, exporting all functions that refers to models into different Dojo class files. After some little issues with relative paths, and after learning how variable and function scope works in Dojo classes, now it works!

I was starting to get worried, because JSDoc Toolkit seemed not to work in my PC at all, founding no suitable solution in the Net. Even switching from open-jdk to sun-jdk didn’t help. But, even in an unlucky period like this, sometimes a little bit of luck comes out… yesterday JSDoc Toolkit version 2.0.2 has been released… and all begun to work very very smoothly!

I’ve had some issues to let JSDoc Toolkit document properly Dojo classes, but, in the end, I’ve managed to let it work, even if it documents some functions as statics even if they’re not, and even if I needed to create some .js mock files just to document the various namespaces of the packages. Probably there could be a way to do all better, but I think I’ve to defer this research. ๐Ÿ™‚

July 30, 2008

The bus factor

Posted in GSoC tagged , , , , at 12:05 am by fadinlight

(This post has been published after the original date)

After talking with Frederik, also regarding what’s happened during the last days (and what’s happening now, and what will happen), we decided to change the scope of the project, aiming at a full refactoring and documenting of all that I’ve done. This has been chosen to reduce Osmarender frontend’s “bus factor” (in my case, the “sheep factor” ™! ๐Ÿ™‚ ). I’m agree on doing this, also because, to have a proper handling of the rule section (as it is very complicated), IMO a better data model is needed.

What’s Osmarender Frontend now

Now Osmarender Frontend is split into two JavaScript files: cmyk.js and osmarender_frontend.js. cmyk.js file is the osmarender’s rule handling library, while osmarender_frontend.js is the gui (sometimes they’re not really separate, to be honest). As I was a very newbie on using Dojo when I’ve started the project, I wasn’t using any Dojo feature at all. At the end, I was very reluctant on using it. Then, after I’ve done a total revision of the GUI, I’ve started to know Dojo better, and I see it would be a proper choice to use its features, beside for the GUI, also for the CMYK (“Customize Maps: Your Key”, or “Cmyk Maps Your Kingdom”) rules handling library itself, using only Dojo core features. Better, using Dojo’s scopeMap feature, I can distribute a fixed version of dojo with the library that doesn’t break anything if, sometimes in the future, another dojo version will be used when calling the library.

What Osmarender Frontend will be

Why Dojo is so attractive? Here I need to speak frankly: I don’t want to reinvent the wheel. If dojo can take care of browser quirks, class declaring/handling, package structuring (the thing I was missing the most!), i18n, querying the DOM, dynamic loading of panels, etc… well, why shouldn’t I use it? ๐Ÿ™‚

Beyond that, as Frederik asked, I’m going to start documenting the code, so I need to use JSDoc Toolkit. Furthermore, even if not really asked for, I want, at least, to refactor the library while using an unit test framework like JSUnit.

So, next steps:

  • Learn how to use Dojo packaging features
  • Learn JSDoc Toolkit
  • Learn how to use JSDoc Toolkit with Dojo
  • Start doing some documentation to test my knowledge of JSDoc Toolkit
  • Learn JSUnit
  • Learn how to use JSUnit
  • Start doing some unit testing to test my knowledge ofย  JSUnit
  • Start code refactoring

In the meantime, Simone Cortesi is coming to my summer house here in Montesilvano on August 4, while doing his sort of “Summer Italian OSM Tour“, to get in touch with the community all over Italy!

July 8, 2008

Weekly Report #5: The nextGen Osmarender Frontend

Posted in GSoC tagged , , , , at 7:42 pm by fadinlight

(This post has been published after the original date)

This week I’ve been doing an hard work to better integrate Dojo library with my code, thus enhancing the very very rough and provisional GUI of the last release.

New features:

  • There is now an option to transform right after loading data and rule files
  • New button to Save the SVG file
  • New panel for global map settings (like showLicense and showBorder)
  • Some CSS classes are now linked to general Osmarender settings (i.e. map-scale-core, map-grid-line, etc)

New GUI features:

  • Osmarender Frontend is now a floating resizable window, with the rendered map in the background. This solution will improve the overall usability when modifying the maps
  • When loading data and rule file, a progress bar of the nodes parsed will be shown. This is not so immediate to achieve in Javascript, because some inner knowledge of how intervals and timeouts work is required
  • Integration with some Dojo widgets, like the filtering select box for searching CSS classes, tooltips and tabbed panes

July 1, 2008

Weekly Report #4: First PrePrePrePreAlpha Release

Posted in GSoC tagged , , , , , , , , at 11:35 pm by fadinlight

Important: This version works only on Firefox browser (tested in version 2 and 3).

Relevant links:

SVN? Dev? What’s happened?

I’ve done many things in the past week (even if my last weekly report was 10 days old, I had an exam last Wednesday). Apart from idling in the irc channel (asking for help much of the time, I admit! Thank you to all OSMers that helped me), as you can see in the links, I have now accounts for SVN and DEV server (thanks to TomH and Spaetz, also for their patience on helping me in the first steps). I can’t explain with simple word how excited I’ve been when I made my very first commit in an open source project’s SVN. That’s cooooool…!

r8469 | merio | 2008-06-26 00:20:21 +0200 ( gio, 26 giu 2008 ) | 1 line

Directory for GSoC project code name osmarender-frontend created

Oh well.. just created the directory… I was doing my first steps… so please forgive me if this shouldn’t be a real “commit” ๐Ÿ™‚

New Features

So, what about new features?


  • The project can now be distributed in a online and in a offline version (rough shell scripts for distributing provided in the SVN).

General GUI

  • The screen has been divided in three “logical” sections to help a sort of rough usability for testing purposes. CSS styles are liquid. Upper left section is dynamic.


  • Create, modify, delete a CSS property, can transform automatically on those events, WYSIWYG style
  • View current color for fill and stroke properties in a little dynamic box (onkeyup event)
  • Show innermost key/value pairs associated to the selected CSS class
  • Modify color for fill and stroke properties via the DojoX Color Picker (I had to leave xhtml+xml for that ๐Ÿ˜ฆ )
  • Modify numbers via Dijit Number Spinner
  • Modify fixed choice properties with select box (like text-anchor,display etc)

Key/Value Pairs-related

List Key/Value pairs that are in the data file selected

  • List innermost CSS classes and symbols associated to selected key/value pairs


  • List of all SVG symbols in the rule file with preview
  • List of innermost key/value pairs that link to the symbol ID

Known Bugs

  • GUI and code are very messy, buggy, error prone ๐Ÿ™‚
  • Some GUI (and perhaps model) mess when dialing with styles edited via spinners (especially with “px” suffix in Firefox 3 and with “invalid number” warning if browser has not US locales, for this you can use Quick Locale Switcher Firefox Extension)
  • Symbols may be listed two or more times, something to deal with Firefox 3 compatibility
  • Only innermost rules between classes and key/value pairs are considered. I’ve to improve the rule data model before.
  • Key/Value pairs are parsed from the data file every time you click on “View Key/Value pairs” and not only once when loading at the beginning.

May 27, 2008

The least exciting screenshot ever :)

Posted in GSoC tagged , , , , , , , , at 3:23 am by fadinlight

Yes, I know… this is not what is expected to be a great “first day working” post, especially when talking about the great Google Summer of Code. But most of the time, what can be seen can play tricks on us. This is what I achieved today:

Not really astonishing, huh? ๐Ÿ™‚ Let’s see what’s behind that javascript alert.


Following my purpose of having a Object representation of Osmarender’s rules and/or css classes (to better manage and pointing to them in my code), I should make a relation that involves, for example, a rule with the features (key/value pairs) involved. Furthermore, I should be sure that a rule can be applied to the matching feature (for example “circle” can be applied only to nodes). Not enough, a feature can be applied to more than one type (for example, “highway=pedestrian” can be applied to ways and areas as well). So a model representation of standard features must be considered.

As you can see, in the alert is printed a linearized version of a tree. You can see “macrocategory”,”category”, and “key”,”value”. To improve the usability of the GUI, and to encourage templating for newbie users in the future, I’ve thought about giving a faceted approach on map features classification. What can’t be seen from this printing, is that all the features listed are in a single facet (which I called “wiki”), but multiple facets are allowed within the code. This was not a major overhead of coding time beside the original purpose of modeling key/value pairs, but can lead to a great end user usability feature when dealing with the GUI.


To achieve this goal, many Javascript tricks are involved, for example protecting the code itself to external overwriting. If I have a Javascript object to represent element types (node, way, area), I should be sure that the integer that represents internally those elements (and can be called, for example with a simple “elements.WAY”) will be not overwritten. This is not so simple to achieve in Javascript, because all objects can be overwritten at any time. I’m not sure this is the right way to go (but I’m sure is prone to bugs at the moment, for example a double check for arguments is needed), because I couldn’t test it so much (I’ll dig the Net for common patterns, if any), but it’s an handy solution at the moment, even if home-made. A simple example of Javascript function overloading is shown as well.

var elementTypes = function() {
	// if the object that calls the function is not already an instance return a new object. This example provide a rough overloading implementation of object constructors
	if (!(this instanceof arguments.callee)) {
		// if the function is not called with an argument (e.g. elements.WAY) then only a reference to the internal representation is wanted
		if (arguments.length==0) return new elementTypes();
		if (arguments.length == 1) {
			// if the function is called with an argument, which is an array of types (e.g. [elements.WAY,elements.NODE]), then an object that should be included in a Feature object is wanted. The object returned will call itself the section "if (arguments.length==1)" below
			if (!(arguments[0] instanceof Array)) throw new Error("not an array");
			return new elementTypes(arguments[0]);

	// Public variables that references names of functions that returns the integers
	this.WAY = "_WAY";
	this.NODE = "_NODE";
	this.AREA = "_AREA";

	// Private variable that will store the types compatible with the feature
	var _mytype=null;

	// Private functions that returns the integer that represent a type
	var _NODE = function() {
		return 0;
	var _WAY = function() {
		return 1;
	var _AREA = function() {
		return 2;

	// If this is an object that should be included in a feature
	if (arguments.length==1) {
		// Unnullify the _mytype private variable, it will be an array of types (for example highway=pedestrian can be applied to ways and areas as well)
		_mytype=new Array();
		// Iterate the array passed as the argument of the function
		for (type_defined in arguments[0]) {
			// Create a new object in the array
			_mytype[_mytype.length] = {
				// Assign the value of the object. This is achieved by eval() the type in the argument and adding "()" to call the desired function
				value: eval(arguments[0][type_defined] + "()"),
				// Create a value that remember the type requested
				toString: arguments[0][type_defined]

	// This is a public function that returns the types associated to the feature
	this.getTypes = function() {
		//returning a clone object to avoid accidental overwriting
		return clone(_mytype);

Beside any further testing, even if it’s easy to use, I don’t like the fact that I should call the function one time to retrieve the constants I want, and then apply the function to a public variable of that instance to achieve the goal. Perhaps, in the future, if I won’t have the time to search a better solution, I can hide this calling in the library in some way.

var elements = elementTypes();
var typeToIncludeInAFeature = elementTypes([elements.WAY,elements.NODE]);


The most interesting part of my community bonding period, beside happy talking with my mentor, Frederik, and OSM community in the irc channel and/or in the italian community and/or with Dieterdreist, was to explore and dig further in Javascript. As stated in the MDC, Javascript is the world’s most misunderstood programming language. And this is surprising what Javascript can do with its functional programming support. Studying more of it, let me realize that all that I’ve learnt and practised about object oriented programming (including design techniques, UML, etc.), even if greatly useful most of the time, was a lightly incomplete view of the world, and sometimes ineffectual for the scope of the project.

At this time, I’ve learnt a lot about Javascript programming and patterns, but I can’t say I achieved the right confidence to do a graceful design. Even if I’m traditionally a light supporter of BDUF development (“light” because I’m always open to intelligent compromises), I think that I would stay with some Agile influences. Furthermore, I would like to lower the technologies involved, thus embracing a little of KISS: I’ve seen that Dojo has lot of commodities for object orientation and such, but what about people who wants to extend my code in the future? They should learn my code, Dojo internals, Sarissa, etc… not so much inviting.