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 <[email protected]>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 <[email protected]> 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. >> 3. 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. >> 4. (Periodically you ping the concept authority, until all proposals >> from that batch are resolved.) >> 5. 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. >> 6. (Depending on the form entry technology) You edit your form to >> refer to the new official versions of the concepts you proposed. >> 7. 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<[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]
