Burke, I envision few if any changes to the basic paradigm. I think the JSS-motivated tickets will go into the JSS JIRA, likewise the code into the JSS repo. But suppose we're going to do a custom search with general utility, such as search for locations with a specified location tag (ws/location?tag=foobar), or a search for patients with addresses in a certain geography (ws/patient?address=province:Indiana); do we put this in the OpenMRS JIRA when we envision it as a marker to the world, or wait until after we've implemented it and add it along with a patch?
The most off-paradigm thing I see coming down the pike has to do with reporting. Like the old BIRT and Jasper report modules (I need to review and coordinate with the new GSOC project around this), there will probably be report and parameter tables. These tables need to be extended to the REST API for report selection and parameter entry. Then we will need some sort of function to receive the report name and parameter values and return the path of the generated pdf file (or error status). Maybe this becomes a PUT function, I haven't given it much thought. From: dev@openmrs.org [mailto:dev@openmrs.org] On Behalf Of Burke Mamlin Sent: Wednesday, May 02, 2012 9:41 AM To: openmrs-deve...@listserv.iupui.edu Subject: Re: [OPENMRS-DEV] How to extend web services Tickets for changes/bugs around RESTWS would go into that project. If they are working on a module in our repo and have a project for it in JIRA, then tickets relevant to that module would go into that JIRA project. If there are tickets that are for an application that is separate from OpenMRS, then those should go into the ticketing tool for that application. Ideally, any needs for extending existing functionality using the same pattern would go into RESTWS. Those features require some design discussion (e.g., add features that break the pattern or start new conventions) can still go into RESTWS when vetted and, if we decide against them or the timing isn't fast enough for your needs, can be managed within your own module. You can create methods temporarily in your own module and then turn them into pass-throughs or eliminate them when/if that functionality is added to RESTWS. In the end, the more we can converge on getting basic functionality robust within RESTWS, the better for all (and the less code you'll be left maintaining on your own). -Burke On Wed, May 2, 2012 at 8:36 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <r...@cdc.gov<mailto:r...@cdc.gov>> wrote: JSS Raxa is about to go into a big front-end development phase. During this time, it is liable to need REST interfaces with some tables which have not yet been carried forward in the REST module or in the module which defines them, and certainly some custom queries and/or representations. It will need these on a schedule which fits into its front-end development pace. I anticipate that JSS Raxa will build a helper module to contain those elements which don't exist in OpenMRS. What I'd like to discuss is how this work should be coordinated with OpenMRS. Should we create OpenMRS tickets for all this work? for work that we think should be incorporated into OpenMRS? for none of this work? Is there a release schedule with which we can coordinate? Would you rather that the helper module have its own pseudo-resource or that it extend and override resources using the @Handler order parameter? Any thoughts or suggestions would be appreciated. @Jeremy, did you encounter any similar issues using REST? ________________________________ Click here to unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
