I’m happy with the progress my project is making. As previously posted, I am nearly done with the layer configuration framework – so, what follows, will be a fairly lengthy post detailing my thoughts on the process, and probably won’t provide very much useful information to experienced coders.
I was not sure how I would tackle the layer configuration problem when I first considered it, so last friday I dived into the code and hacked my way around until I came up with something I liked. Then I rewrote it. Then I examined it, and decided to rewrite. As it stands, I think the structure will remain. In the most basic sense, what I have created is a set of functions that allow me to pass in some stuff and get some html back. I decided this would be the best way to make the code flexible, and allow me to make changes later on if I need to. It works much better than hardcoding the html in any case.
Each layer in OpenLayers can have different options, so my first task was to figure out the best way to display different options for different layers. I’m using a pretty rough method right now that consists of just changing the innerHTML of an element based on the selected layer type, but I suspsect I’ll end up putting each seperate configuration in its own file and making an ajax request. The code won’t have to change much, the basic structure will fortunately remain in tact.
My next task, and current one, is to best figure out how to store the layer configurations. Creating a layer works by inputting a layer name and selecting a service from a dropdown list in the top toolbox. Once created, the second toolbox will display that layer’s properties. Accomplishing this is easy. I have a global “map” object that will store all the properties of the map – layers, controls, etc in JSON format. Later on, I will take this map object and, using OpenLayers / OLON, create a map from it. Layer configurations are therefore held in map.layers.
There are many ways to approach this problem, and while mine is likely not the best or most efficient, I think it’s pretty straightforward and does the job well enough. When trying to solve any problem, I try to break it down into manageable chunks. So, the basic parts of this problem involve:
* Once the layer name and service are chosen, and the create layer button is pressed, the layer itself has to be created
o The new layer’s ID is equal to map.layers.length. This ensures that each layer will be unique.
* We have to get this information to the second toolbox so the newly created layer can be edited
o Pass the layer name and selected layer service to some function that will update the second toolbox
This seems pretty straightforward. The second toolbox gets all the info and creates the appropriate html for the layer type requested. Upon second though, this seems pretty bloated. So, I reexamined the problem. What is the most important thing the second toolbox needs to know? The newly created layer ID. After realizing that, it became clear that the ID is the only thing that needs to be passed in – I can set the map.layers[layerID].name equal to the value of the text input box in the first toolbox, and I can retrieve it in a similar way. Although the solution should have been obvious to me at first, I overcomplicated it. This is one reason why I always look for a better way to code something – I know that these little mistakes are very easy to make. The new solution is a bit more elegant:
* When the create layer button is clicked, pass in new layer’s ID, and determine the layer based on the dropdown list’s value
One thing I learned from this short experience is that the first solution I come up with is likely not the best. But as the saying goes, code first. Optimize later.
