Ugh. Can we introduce the OrderEntryService and all of its methods as deprecated as well and then replace OrderService in 1.10? :-/
-Burke On Fri, Apr 27, 2012 at 9:29 AM, Wyclif Luyima <wyc...@openmrs.org> wrote: > 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 <b...@openmrs.org> 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 <bu...@openmrs.org> 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 <dar...@openmrs.org>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 <msea...@pih.org>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 <b...@openmrs.org> wrote: >>>>> >>>>>> I thought we already decided on option 3...multiple times. No? >>>>>> >>>>>> >>>>>> On Thu, Apr 26, 2012 at 4:26 PM, Wyclif Luyima >>>>>> <wyc...@openmrs.org>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 <b...@openmrs.org> wrote: >>>>>>> >>>>>>>> Sounds fine except for the hacky part. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 25, 2012 at 8:18 PM, Michael Seaton <msea...@pih.org>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 <wyc...@openmrs.org >>>>>>>>> > 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<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]
