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]> 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]>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]> 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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[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]
