Web interface Django refactor

Purpose of this enhancement, including design decisions:

The need for a more web-centered and web-enabling framework has driven the
want to refactor the web component of openIPAM from the CherryPy framework
( http://www.cherrypy.org ) to Django ( http://www.djangoproject.com ).

This would further enhance the internal modularity that we have fostered
between the backend and frontend components, and would likely offset the
initial cost of refactoring in the long run. Specifically, Django's
extensive capabilities with smart data models, dynamic form generation and
validation, and view-layer capabilities far exceed CherryPy's abstraction
of common web UI tasks (read as: CherryPy's non-existant abstraction of
common web UI tasks). "Beyond [request handler object-mapping and embedded
web server] functionality, CherryPy pretty much stays out of your way."
http://cherrypy.org/#QuickFacts ... very true, and helpful for backend
development in this project, but definitely not helpful for the web side.

Special factors to remember:

This could allow the frontend to have it's own set of tables (or, it's own
database if necessary) to hold user settings and user training information
(ie., displaying certain help messages or options based on what the user
has done before). If the extent of user training isn't feasible, user
settings is applicable.

This would require development of Django models that represent the
different aspects of networking, such as a DNS Record, a Host, a Domain, a
Network, and all of the associated validation that goes along with each of
the objects.

Since openIPAM itself is really one big admin interface, the Administration
app that can be enabled in Django may not be very useful to us.

Since we have already begun refactoring the old, terrible string-based view
creation into Cheetah templates, those sections would be fairly easily
transferred ... ie., many UI element wouldn't need to change, but would be
enhanced by Django's scaffolding abilities (is it blasphemy to use that
word in a non-Rails project?) If care is put into making the data of the
objects extremely smart, the whole Administration section could be finished
very quickly (trivial, repeatable tasks like, managing users, and managing
objects in groups, etc).

Overall, the UI would be much more intuitive than the current version. We
can get there with what we have now, it's just so much more painful, and
ultimately not maintainable.
Original issue reported on code.google.com by fotinaki...@gmail.com on 27 Jan 2009 at 1:16
dynogreg / openipam

Web interface Django refactor #2
