Update on Migration to Django 1.7

[Easwar TR]

Hi,

Its been a while since I committed so this is to update on what's cooking.

Status of migration to Django 1.7

I am migrating <painfully> all the apps to Django1.7.

So far, most of the Au-core and Au-stock apps have been migrated except the 'visits' and 'admissions' app

Some changes in version 1.00 plan

For version 1 the announcement of which was `detoured` if not derailed by move to Django 1.7 and its difficulties, I am inclined to drop 'admissions' as an app. I plan to keep only 'visit' app with version 1. This would mean AuShadha at v1.00 would be essentially an EMR focussed on  OutPatient Visits notes, prescriptions etc..

This probably is as Richard wanted long back.

I think In-patient management, Progress Notes, Nursing Records should be bundled into 'admissions' app which would be in Au future versions.

Lessons from migrations

The difficulties faced with migrations are not without some satisfaction though. Right now Au functions well without the 'visit' or 'admissions' app.

This means that the existing apps are largely agnostic of what the 'pluggable' apps which deliver a particular feature gives. Django itself has included an 'AppRegistry' with this version that would probably aid better pluggability for future apps.

What would be ideal pluggability that I aim for ?

An ideal pluggability would be when an user can just download a package from internet and put it into a folder called 'apps' inside Au's root. All the config could be taken from that specific app.

Right now 'templates' , 'static' and 'INSTALLED_APPS' setting are still to be configured by hand on 'settings.py'. This is not user-friendly for a non technical user ( most Doctors would fit in here) who are the intented end users. Configuration os a particular 'app' like 'static' and 'template' directories can reside inside of the 'app' just like 'urls'.

This should not be difficult to achieve, but I dont know why Django does not have it already. Zope had this in version 2.x all those years ago. At the most just adding an entry to 'INSTALLED_APPS' would be acceptable; nothing more. Even this in my opinion would need to be abstracted to include 'roles' the app plays in the given project and not hard wired to a particular app.

I would work towards that goal to make Au as 'app-agnostic' as possible and as 'role-gnostic' as possible.

Your comments and criticisms are welcome :)

Easwar

--

 

Dr. Easwar T.R  MBBS, DNB(Orth.), MNAMS
   Fellowship Paediatric Orthopaedics & Deformity Correction( Sing., Kor.)
   Fellowship Spine & Scoliosis Surgery (Kor.),  
   Spinal Microsurgery (Ger.)

 Consultant Paediatric Orthopaedic & Spine Surgeon

     Ph:      91-98407-24924  

    Web:   www.dreaswar.com

    Email: drea...@gmail.com

[Derek O'Connell]

I think a lot of the difficulty around pluggability is due to the model-centric design of Django and activities impacted by changes to models (particularly start-up & migrations). That's beginning to change as of 1.7 but I doubt real pluggability is coming any time soon (I could be wrong, haven't checked). However, if Au was, partly, designed as a consumer/proxy for other Django app's running independently, ie, no direct access (therefore no cross-site issues either), then you could have pluggable-like appearance. Just a thought ;-)