Current state of GeoBootstrap

It’s been a while since I decided I would build GeoBootstrap. And this while has extended for about 6 months now.

It's been a matter of choices. I wanted to overcome GeoExt self dependent components/ GeoExt awkwarkdness by which they don't build on any other popular library but OpenLayers and ExtJS. ExtJS's templating system, it's architecture for representing data models, its utility methods for handling the DOM, etc.

The thing is that what was going to be a seamless approach to extending Bootstrap with geo components, is taking me too long because of lack of consensus with other developers in the community. Not because I think one thing and the others do not agree, but because there was not others trying to compete with GeoExt.

That's why I decided to open the game to my friends (and coworkers) and we formed a team by the name MasAllaHayDragones, the expression for Here be dragons.

Our first goal is to build GeoBootstrap allowing us to build better geo webapps to our will-be customers or whatever project that involves building web apps for the geospatial realm.

GeoBootstrap Manifesto

• GeoBootstrap should attract current Leaflet and Bootstrap developers. We should not deviate too much from what we already like about those APIs/framework. Every part of GeoBootstrap should be intuitive to people that already make use of Leaflet and Bootstrap.
• GeoBootstrap's first users should be us. We should measure GeoBootstrap's user friendliness eating our own crap, i.e. creating mahsups that consume and show geographic services and refactoring the mashups generic parts into GeoBootstrap core methods and GeoBootstrap widgets.
• GeoBootstrap should be easy to understand by just copying and pasting HTML snippets that connect to underlying geospatial data already present in the web (WMS services, WFS services, CartoDB APIs, geoJSON files, KML/KMZ files, TopoJSON files, GPX Files, CSV files (i.e. a CSV with some latitude, longitude columns) and public Google Spreadsheets via the JSON list feed.
• GeoBootstrap should be HTML5, CSS3 compatible only. No backwards compatibility.
• GeoBootstrap should offer a Javascript API based on jQuery plugin/widgets and a library of core utilities methods.
• GeoBootstrap widgets should be loosely coupled to each other and to the core utilities methods.
• GeoBootstrap should offer nice templates to build upon.
• All GeoBootstrap widgets should offer a well documented HTML data attributes behavior like Bootstrap data attributes (also called Data API in their source code). With GeoBootstrap's data attributes, the user should be able to instantiate a widget with just basic functionality. Every complex action on a widget should be handled via the widget's jQuery interace methods.
• GeoBootstrap widgets should evolve well to HTML5 web components
• GeoBootstrap should handle Spatial Reference Systems elegantly. I mean SRSs other than EPSG:4326 and EPSG:3857 (A.K.A. EPSG:900913, the spherical mercator projection).
• GeoBootstrap should always be able to rely on a proxy that allows AJAX requests anywhere, providing Cross-origin headers to every request made by GeoBootstrap widgets and core methods. We will mantain a highly available proxy script that supports every GeoBootstrap Template by default. Let us resolve the Same-origin policy for the user.
• Every GeoBootstrap function or method should accept any parameters that involve Latitude and Longitude in the same way Leaflet does. i.e. accepting an [lat, lng] array or an L.LatLng.

Candidates for GeoBootstrap's javascript architecture

I've been injecting myself with high doses of javascript libraries recently just to improve my javascript tooling choices and these are some of the smoothest things I've found. I think that some of them will help me be consistent with the purpose of letting GeoBootstrap be maintainable by more than one coder.

Stuff that could help with the jQuery interface for GeoBootstrap Widgets

• jQuery UI Widget Factory. Create stateful jQuery plugins using the same abstraction as all jQuery UI widgets. Does not depend on jQuery UI. It’s just tha all jQuery UI widgets are created with this small library.

Stuff that could help with the concept of Modules — Loose coupling enforcement

• jQueryMediator. Typical mediators for dom libraries such as jQuery, tend to poorly abstract the underlying API, and lead to an inconvenient, verbose syntax that resonates throughout your code base. This project provides a jQuery API mediator that can be used in a manner that is indistinguishable from jQuery.
• Kernel.js. Kernel.js is an ultra lightweight (~4k) architecture for building scalable javascript applications. It provides a messaging system that allows you to build your apps in a decoupled and flexible fashion.

Stuff that could help with an MVP approach

• RIOT.js Riot is a standalone library that weighs 0.88kb when gzipped (1.6kb minified) and has only 3 public methods. Despite the tiny size all the building blocks are there: a template engine, router, event library and a strict MVP pattern to keep things organized. On a finished application the views are automatically updated when the underlying model changes.

Stuff that could help with live binding

• jQuery.my jQuery plugin that binds HTML with JS objects. In real-time.
• jtmpl Mustache syntax + automatic data-binding = Live templates.

Stuff that could help with all of the above

• CanJS. From the makers of JavascriptMVC (the framework, not the concept).
• JavascriptMVC. In addition to taking advantage of CanJS for the MVController approach, the whole JavascriptMVC framework offer tools for dependency injection, documenting, testing and jQuery useful extensions.

You can use JavaScriptMVC as a complete framework, or download only the parts you need. Read JavaScriptMVC’s features for more info.

Javascript MVC reading

About the concept of MVC in javascript, not the framework.

http://alistapart.com/article/javascript-mvc by Jonathan Snook, August 2009