For the use cases I'm familiar with (HFE + MDS) I think we'll be able to write a few lines of code that inspect the XML definition of the form, find any concepts that are referenced by UUID, and replace those with a reference to the MVP/CIEL dictionary. (E.g. we'd need to replace <obs conceptId="aaba432432ba4b2a4"/> with <obs conceptId="MVP:123"/>)
I don't know XForms and Infopath well enough to know how you'd do this, so hopefully Jeremy and Daniel can comment. (How do you move forms from development to your forms server, or from the forms server to production?) -Darius On Thu, May 10, 2012 at 1:32 PM, Yeung, Ada K. <kye...@iupui.edu> wrote: > Darius,**** > > Can you explain what the form developers would need to do for #6 - > (Depending on the form entry technology) You edit your form to refer to the > new official versions of the concepts you proposed) under forms development > workflow? For example, if we use infopath and xforms? Anything needs to > be edited on the schema design in addition to edits on the forms?**** > > Thanks!**** > > -ada**** > > ** ** > > *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Darius > Jazayeri > *Sent:* Thursday, May 10, 2012 3:57 PM > > *To:* openmrs-deve...@listserv.iupui.edu > *Subject:* Re: [OPENMRS-DEV] Concept Proposals: a simpler workflow**** > > ** ** > > I figured that that "reset my dictionary" belongs somewhere other than the > concept proposal module. I don't know exactly where though. Currently the > MVP/CIEL dictionary is distributed as a big sql dump, and you would "reset" > by running that to overwrite your dictionary tables. Recent work on > Metadata Sharing is supposed to enable letting you pull in updates from a > server like MVP/CIEL, but I don't think this is complete.**** > > ** ** > > @Ada/Lauren/Jeremy, I'm really curious to hear whether something along > these lines would work for you. I think some parts of the workflow wouldn't > be quite the same, since Infopath doesn't work with MDS, but would that > minimal functionality for the proposal module solve a use case of yours?** > ** > > ** ** > > -Darius**** > > On Thu, May 10, 2012 at 12:11 PM, Burke Mamlin <bmam...@regenstrief.org> > wrote:**** > > Perhaps it's assumed or implied or I overlooked it, but consider adding a > method to "reset" your messy dev client to the latest-greatest version of > your dictionary from your production machine… so you can rinse & repeat.** > ** > > ** ** > > @Ada/Lauren/Jeremy – would Darius' solution meet AMPATH's needs?**** > > ** ** > > -Burke**** > > ** ** > > On Thu, May 10, 2012 at 2:32 PM, Michael Seaton <msea...@pih.org> wrote:** > ** > > Hi Darius, > > I think this is a great solution, and would meet our form development > needs very well. We can certainly talk about potential for developer > collaboration on this, though I can't promise anything... > > Thanks for thinking this through, > Mike**** > > > > > On 05/10/2012 02:01 PM, Darius Jazayeri wrote: **** > > Hi All, **** > > ** ** > > I'm working through a simpler approach to Concept Proposals that what has > been attempted several times before, and never finished, and I thought I'd > share my thoughts while they're fresh.**** > > ** ** > > I'm particularly interested in the scenario where:**** > > - In the cloud there's a concept authority (in my case MVP/CIEL) who > manages your dictionary, and you periodically pull updates from there** > ** > - You have one server that has your official concept dictionary (could > be your metadata, forms, or production server)**** > > > - No development work happens directly on this machine. Concept > dictionary and forms are developed elsewhere, and imported.**** > > > - You have one or more development machines where you do > (potentially-messy) development and testing of forms**** > > So, the forms development workflow would basically be:**** > > 1. On a development machine, starting with your master dictionary, you > work on a form. It is expected that you will create a bunch of new > concepts, revise them, and delete some of them that were mistakes.**** > 2. When your form is ready-to-go, you identify all concepts on your > form that do not come from the master dictionary (i.e. they were > newly-created)**** > > > - with HTML Form Entry this should be easy to automate, by checking > whether there are any concept references not in the form of MVP:###. > Maybe > XForms and Infopath could do something similar.**** > > > 1. You send that batch of new concepts up to a web service on the > concept authority in the cloud, as proposals. You get back tokens you can > use to check the status of your proposals.**** > 2. (Periodically you ping the concept authority, until all proposals > from that batch are resolved.)**** > 3. You hit the concept authority and download its official versions of > the concepts that you created locally, and these *replace* your > locally-created concepts.**** > > > - I hope we can leverage the Metadata Sharing module to do this > pretty easily.**** > > > 1. (Depending on the form entry technology) You edit your form to > refer to the new official versions of the concepts you proposed.**** > 2. At this point you export the form from your dev machine, and import > it into your metadata/forms/production server.**** > > I think the difference between this and prior work on Concept Proposal > is that I'm saying:**** > > 1. You should do forms development on a separate dev machine whose > dictionary is expected to get messy.**** > > 2. Instead of creating concept proposals, you create actual concepts, so > you can do real testing with them.**** > > ** ** > > All this leads me to think that we can produce a minimum viable > product<http://en.wikipedia.org/wiki/Minimum_viable_product> of > the Concept Proposal module with only these features:**** > > ** ** > > (client-side, for use on forms development machines)**** > > - every time you create a new concept, it is marked as "temporary"**** > - you can view a list of all temporary concepts, and delete ones you > don't like**** > - you can select some temporary concepts and "propose to master > dictionary"**** > - you can see a list of all your submitted proposals, along with their > current status**** > - when a proposal has been marked as complete by the server, it will > overwrite your local "temporary" concept with the new one officially > created, and clear the "temporary" flag.**** > > (server-side)**** > > - web service for proposing a batch of concepts**** > - web service for checking the status of a proposal**** > - UI showing a list of all open proposals**** > - UI for choosing the action for each item in the batch of proposals*** > * > > > - Created New Concept (specify the concept)**** > - Already Exists (specify the concept) **** > - Rejected (specify the free-text reason)**** > > > - Email notification when a new proposal comes in.**** > > It's possible that some ThoughtWorks developers-in-training might work > on this as a project. Or I might propose this as a sprint. What do people > think about the approach? In particular, is there anyone out there who > finds this approach consistent with their needs, and would contribute some > dev time to helping make it happen?**** > > ** ** > > -Darius**** > > ** ** > > ** ** > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
