Monday, May 19, 2008

Google Summer of Code Status Report

I haven't really blogged since I last announced that I was accepted into Google Summer of Code. I have a phone meeting with my mentor to bang out a project plan, I more or less have a general idea of how I want things to go, and he does too. Overall, it should be a very successful summer.

I've been enjoying the Community Bonding period. I have made a lot of friends. My fellow summer of coders are amazing. I planned a potential meet-up for google soc'ers from NY, NJ and CT (to be announced formally when it is more concrete).

Now, onto the fun part, telling you all about my project and how I plan on doing it. I'm gonna break this down. There's a lot of things that need to happen. A lot of data needs to be passed between the front and back ends.

Firstly, Direct Web Remoting (DWR) will be used to grab all the information the users enter into the form and forwards it to the backend whose job it is to generate the form, and then relay it back to the user showing them the result, then saving it to the system. DWR will also be used to provide some AJAX magic.

Then, after I have the data, I need to use reflection on the Form Model and based on the data type, using a templating engine, such as Velocity generate HTML form components.

String, etc: text field or text area; Using some Groovy ExpandoMetaClass magic will aid in deciding if we use a text field or text area.

List: drop-select select box

Boolean: radio or checkbox with some Groovy ExpandoMetaClass magic, i'll add a property which will help aid in deciding which one to use.

After the form is generated, a controller will be generated with default checks that the fields are not empty. This will also be done using Velocity for templating.

Once I have everything generated, it will be saved on the file system someplace with an associated XML file containing all metadata(title,version, description,etc) which will be read in by the system when showing which forms are in the system.

3 comments:

Unknown said...

nice , hope it goes well!

Unknown said...

Hi Robby,

Looking forward to seeing how this all goes.

What do you envision the end-to-end workflow to be?

I'm sort of assuming the following:
* Administrator picks a form in OpenMRS
* Your module generates a groovy + velocity template
* Administrator manually tweaks those to get the look right
* Administrator uploads those back to your module
* At that point any old user can fill out the form repeatedly

But is that right? Or are you thinking of a different workflow?

-Darius

Robby O'Connor said...

Darius,

No, I was actually thinking once the form is created in the system, it's stored some place where openmrs can read it on the file system (perhaps ~/.OpenMRS).

As far as tweaking goes, once the module generates the form, the user will be given an opportunity to tweak the html, create their controller etc. Basically, the directory for the forms will contain at most:
1) a controller (written in groovy)
2) an html file containing the form
3) metadata xml file.

Downloading and transferring the form is as easy as zipping up that forms folder. So moving these forms between systems should be cake!

Your last point: I may at one point plug into the Patient Dashboard (probably sooner rather than later).

Like i said, more details about how things should be done will be ironed out tomorrow with Burke.

--rob