@Roger, I think that JSS should manage the tickets however is most convenient for its development purposes. We'd love to get examples like the ones you gave committed to the core RESTWS module, but it's fine if those happen via by creating a ticket+patch for something JSS already did in its own issue tracker. Whatever works.
Regarding reporting, by the way there's a reportingrest module that lets you run reports via rest and get datasets as json. It's preliminary (might not support parameters yet, I forget), but that seems like the place to support running reports and getting back their rendered output. -Darius On Wed, May 2, 2012 at 7:34 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < r...@cdc.gov> wrote: > 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> 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<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]
