[I-mobile-u] Making the MIT Mobile Web Framework More Generic

[Dave Olsen]

All-

In the interest of trying to move things forward and to try to
contribute to the original framework I wanted to share my
experiences/thoughts on some things that I feel could be addressed to
really make it more useful/friendlier for other institutions.

To me there are four basic changes that should happen to the MIT
Mobile Web framework to make it more flexible and generic. My fork has
gone part of the way to address this but it's definitely still lacking
(see Penn State wanting to use PostgreSQL). To me the current
framework is way too MIT specific which a) makes it annoying to
customize and b) makes me question how much work I'd have to do to
integrate future changes.

The issues are:

 - Ability to easily theme & customize
 - Proper database abstraction
 - Plug-in architecture
 - Documentation

Ability to Easily Theme & Customize
I've made headway on the customization... at least from the standpoint
of breaking out common text elements that appear throughout the system
(e.g. contact email address). jQTouch is forcing me to address
theming. Basically I want to let users have their own look but be able
to upgrade in the future and not worry about losing their changes to
styles. I'm currently looking at leaving the webkit, touch, and basic
folders at the root but creating a separate themes directory which
will include sub-folders for specific themes. Those theme folders
would contain images and styles specific to that institution.

Proper Database Abstraction
I didn't have access to MySQL when I started using the framework over
the summer so I chose SQLite. Others like MySQL or PostgreSQL. It'd be
nice to have a way to abstract the database enough so users don't have
to make changes to modules to get their own database preference
supported. I don't have experience with doing this in PHP so I'd be
curious to hear others' thoughts. Also, it could add the overhead of
some sort of XML config or model-like code. Obviously, there isn't
anything wrong with only supporting MySQL it just would be a nice
thing to have.

Plug-in Architecture
To me this is the key in making it easier to deploy the framework. In
my fork I've moved most of the module specific libraries from /lib to
module/lib (e.g. calendar). I've also started doing module/db for
database specific functions (e.g. create tables) and module/data for
hash-based data. Once there is a true plug-in architecture it would be
easier to have a core framework that people just plug-and-play with
their own modules. So you could have the ArcGIS-based map module or
the GMap-based map module. Two separate, clean code-bases. It also
would allow for easier "installation" of modules as well.

Documentation
A little documentation can go a long way. I haven't played with 2.0 so
I can't really contribute. Also, I think I've customized my version
enough that my docs (http://mobiweb.pbworks.com/) won't help much.

Let me know if people think these would be good changes to make to
core or not. I can work on the text customization stuff if the MIT
folks are willing to make me a branch to play in.

-- 

Proud supporter of DC United