How about if, for the 1.9 release, we add "@deprecated this method will likely be removed in OpenMRS 1.10 as Orders are refactored" to every method in OrderService, and in 1.10 we may actually remove bad old methods?
That way we keep OrderService as the service name, and we actually clean out the stuff we don't want. This may cause compile errors for modules that use orders, but if the Order refactoring is going to be as fundamental as I think it is, better to introduce those compile errors than have things appear to keep working, but fail. -Darius On Fri, Apr 27, 2012 at 7:16 AM, Burke Mamlin <bmam...@regenstrief.org>wrote: > 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 >> > > ------------------------------ > 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]
