We are going to end up deprecating more than half of the methods in OrderService, i suggest that we deprecate the entire OrderService and introduce OrderEntryService. OrderService will delegate to it for backward compatibility purposes.
Wyclif On Fri, Apr 27, 2012 at 8:45 AM, Ben Wolfe <[email protected]> wrote: > Ok, that makes life simpler. The work on the "orderentry" module should be > stopped asap and the work moved to trunk (again). We must mark relevant > order calls/methods as deprecated in 1.9.x before the release. > > We don't want an "ordercompatiblity" module because we are modifying the > core order tables. So using "ordercompatibilty" with 1.10+ would cause the > exact same confusion as an "orderentry" module in 1.9 would! > > Ben > > > On Thu, Apr 26, 2012 at 8:34 PM, Burke Mamlin <[email protected]> wrote: > >> Mike/Darius/Ben/Wyclif/Daniel/Roger, >> >> From our recent design calls, I agree with Wyclif/Darius/Mike, that we >> are not being pressed for enhancements to order entry as much as the need >> for improved order sets & grouping, which, via a module, could be adapted >> to work with the existing order tables as well as the enhanced order tables >> in a future version (e.g., 1.10). >> >> -Burke >> >> >> On Thu, Apr 26, 2012 at 7:44 PM, Darius Jazayeri <[email protected]>wrote: >> >>> How about if we build and experiment with order groups and order sets in >>> a module, and we refactor order in core in 1.10, pulling in the order group >>> and set code from the module when it's ready. >>> >>> That lets us develop new end user functionality in a module usable with >>> 1.9, while saving the under the hood refactoring for core. >>> >>> So #1, basically. >>> >>> -Darius (by phone) >>> >>> On Thu, Apr 26, 2012 at 2:38 PM, Michael Seaton <[email protected]> wrote: >>> >>>> ** >>>> Option #1 is also conclusion I have arrived at. It likely means >>>> introducing backwards-incompatibilities that module developers will need to >>>> deal with (like we did with Provider in 1.9), which will be annoying, but >>>> at least everything is predictable. It is far worse, IMHO, than having the >>>> possibility that someone is unwittingly using a combination of modules that >>>> are storing / retrieving Orders from 2 different places. That is a recipe >>>> for disaster. >>>> >>>> A possible variation on this is to do something like we did with >>>> reporting back in the day: move all current Order functionality out of >>>> core and into an "ordercompatibility" module (not my proposed name). Then, >>>> develop a new "orderentry" module which does things the right way and can >>>> evolve at it's on pace. We would then add something to the module >>>> framework to allow modules to indicate which other modules it does not play >>>> nicely with, to ensure that no one ends up running both of these in >>>> parallel. >>>> >>>> But I still think that this isn't better than #1, because a key >>>> unwritten rule would be broken - that installing the module would change >>>> your _core_ data in a non-reversible way. I guess we could treat this >>>> module like sync - where once you install it, you are stuck with it unless >>>> you jump through hoops to get it off of your system... >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>> On 04/26/2012 04:42 PM, Wyclif Luyima wrote: >>>> >>>> Darius sent out an email yesterday, saying we should halt work on order >>>> entry module and that i should look at the 3 options again, and after >>>> carefully looking at all three today i have realized options 3 is most >>>> likely going to keep us going in circles and is going to be a pain both to >>>> us and the PIH guys. >>>> >>>> Wyclif >>>> >>>> On Thu, Apr 26, 2012 at 4:28 PM, Ben Wolfe <[email protected]> wrote: >>>> >>>>> I thought we already decided on option 3...multiple times. No? >>>>> >>>>> >>>>> On Thu, Apr 26, 2012 at 4:26 PM, Wyclif Luyima <[email protected]>wrote: >>>>> >>>>>> Hi Guys, >>>>>> >>>>>> I have spent some time today analysing the 3 possible solutions as >>>>>> to how we can rework order entry. >>>>>> Here is an etherpad <http://notes.openmrs.org/new-order-entry> that >>>>>> summarizes my views and my proposed solution. I have laid out what needs >>>>>> to >>>>>> be done, pros and cons of each solution and at the end proposed what i >>>>>> think the most convenient solution from my perspective taking into >>>>>> consideration what i think are the strong/key issues that Mike has been >>>>>> pointing out. If you are eager to know what it is, i have proposed that >>>>>> we >>>>>> just do this from core as part of 1.10 except for order groups/order >>>>>> sets. >>>>>> Of course your views are welcome. >>>>>> >>>>>> Wyclif >>>>>> >>>>>> On Wed, Apr 25, 2012 at 10:22 PM, Ben Wolfe <[email protected]> wrote: >>>>>> >>>>>>> Sounds fine except for the hacky part. >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 25, 2012 at 8:18 PM, Michael Seaton <[email protected]>wrote: >>>>>>> >>>>>>>> This sounds fine to me >>>>>>>> >>>>>>>> >>>>>>>> On 04/25/2012 07:00 PM, Darius Jazayeri wrote: >>>>>>>> >>>>>>>> I agree with that. >>>>>>>> >>>>>>>> I would further suggest that: >>>>>>>> >>>>>>>> * the API module (probably should be orderentryapi) should have >>>>>>>> high-quality code, and be written to support general and complex use >>>>>>>> cases >>>>>>>> >>>>>>>> * the UI module (probably orderentryui, or even >>>>>>>> simpleorderentryui) is allowed (expected!) to have hacky code, and >>>>>>>> should >>>>>>>> target the simple, common use case of recording mostly-standard >>>>>>>> regimens >>>>>>>> (e.g. for HIV and TB) in a low-resource setting, where it's equally >>>>>>>> likely >>>>>>>> to be the clinician entering the regimen order real-time, or a data >>>>>>>> clerk >>>>>>>> or secretary entering it later. >>>>>>>> >>>>>>>> -Darius >>>>>>>> >>>>>>>> On Wed, Apr 25, 2012 at 3:50 PM, Wyclif Luyima >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi Guys, >>>>>>>>> >>>>>>>>> Apparently, i forgot to bring up something that Burke commented >>>>>>>>> on a ticket, he suggested that the order entry module that Daniel and >>>>>>>>> I are >>>>>>>>> working is purely an API with no web layer, and that we will have to >>>>>>>>> author >>>>>>>>> another module to provide the UI, does everyone agree to this? >>>>>>>>> >>>>>>>>> Wyclif >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> ------------------------------ >> 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]
