I haven't been following this too closely, but keep me in the loop and I can help out with it... Mark
From: [email protected] [mailto:[email protected]] On Behalf Of Michael Seaton Sent: Tuesday, January 31, 2012 9:14 AM To: [email protected] Subject: Re: [OPENMRS-DEV] htmlformflowsheet and register module merge? I agree with this too and I like the way Dave has expressed this. @Dave, can you maybe schedule this into a design call and/or summarize on a wiki page the changes you recommend? I'm also happy to help with this. Mike On 01/30/2012 09:46 PM, Darius Jazayeri wrote: I approve of pulling the rendering mechanism into the core HTML Form Entry module. I.e. displaying a table of encounters with their obs exploded according to the underlying form schema. It still feels like other workflows (e.g. a row-per-encounter register for multiple patients by location and date, and a HFFS's many encounters for one patient) belong in their own modules. But if there's a way to make those modules thinner by pulling useful common functionality into HFE core, that's cool. -Darius On Mon, Jan 30, 2012 at 4:09 PM, Dave Thomas <[email protected]<mailto:[email protected]>> wrote: Well, i think the point is that the workflows are very similar, especially from a technical point of view. You're looking at renderings of 1-row-per-encounter tables where the columns are described by the htmlform schema, the obs matching is provided by the formentrysession, and the things you want to do with these tables are delete, add or edit a row. The only things that really differ between the modules (flowsheet vs register vs patient dashboard) are the encounter list that gets passed to the renderer, and the 'create patient' capability of the register module, which is handled by the htmlform tags anyway. That would be the rationale in merging htmlformflowsheet and the register module. The rationale for putting the rendering into htmlformentry is basically, if we stop thinking about htmlforms as just a form entry mechanism, and start thinking about them as schema descriptions of collections of OpenMRS objects in an Encounter, an object matching engine, and a renderer, then I think it would be valid to have a renderer for multiple encounters viewed through an htmlform schema as it is to have a renderer for a single encounter viewed through an htmlform schema. The stuff I added to the register module is off-mission from 'register'. But it uses the same jsp and controller -- the thoughtworks guys did a nice job with the DataTables stuff, so why do it again somewhere else (for the third time)? I've added a pic. d On Mon, Jan 30, 2012 at 2:42 PM, Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]>> wrote: Hi Dave, What would be the benefit of merging them? I'm having trouble thinking of a use case where having genericized rendering modes would help. (I'm sure there's one I'm not thinking of though...) There's definitely symmetry between HFFS rending multiple encounters for one patient in a single view, whereas Register renders encounters for multiple patients. But the workflows seem quite different. -Darius On Mon, Jan 30, 2012 at 1:46 PM, Dave Thomas <[email protected]<mailto:[email protected]>> wrote: Hey everyone. There are currently two htmlformentry add-on modules, register and htmlformflowsheet. These two modules essentially provide custom rendering of htmlforms for different circumstances -- register as a way to model paper registers using an htmlformentry schema (and i recently added the capability of using the register renderer to add htmlform-based tabs to the patient dashboard). And htmlformflowsheet for doing embedded htmlforms within htmlforms, and for building custom, easy-to-configure tabbed interfaces containing htmlforms. Register module has outgrown the name 'register', and at their core, htmlformflowsheet and register are basically just htmlform renderers for multiple encounters based on htmlform schemas. How would people feel about 1) merging these modules into a 'htmlformextension' (or similarly named module). Then we'd have a module that provided a couple of different renderer types for looking at data entered through htmlforms. And/or, keep these modules separate but merge renderers themselves into htmlformentry, to expose these for other modules? Any thoughts about where we want to go with this, if anywhere? Also, does anyone have any other general ideas around more ways in which to build htmlform-driven interfaces? Design ideas, etc... that could inform this discussion? Our needs at PIH rwanda in terms of workflows for getting data into the database have grown beyond the usual openmrs formentry model -- we've headed down the htmlform-based-interfaces road because we've got clinical charts, patient flowsheets, and MoH-issued registers that don't fit the one form per encounter model. And, we've taken our lumps in terms of trying to report on data entered through custom modules (i.e., schema-less encounters), and I'm of the opinion that NO observational data should ever be entered into openmrs without having some mechanism for saving the schema associated with that data. Hence the push into htmlformentry driven interfaces. d ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
