redcapAPI icon indicating copy to clipboard operation
redcapAPI copied to clipboard

Version 2.0.0

Open nutterb opened this issue 9 years ago • 5 comments

Most of the core code won't change, but I'm going through each of the functions and trying to tidy up the code, improve readability, add all of the currently available features (as of 6.5.0), optimize things as much as possible, and transition to using checkmate for as many error checks as possible.

API Functions

  • [x] exportRecords
  • [x] exportReports
  • [x] importRecords
  • [x] exportMetaData (still needs version logic)
  • [x] exportFieldNames
  • [x] exportFile
  • [x] importFile
  • [x] deleteFile
  • [x] exportInstruments (still needs version logic)
  • [x] exportPDF
  • [ ] exportSurveyLink
  • [ ] exportSurveyQueueLink (combine with exportSurveyLink with queue = TRUE?)
  • [ ] exportSurveyReturnCode
  • [x] exportEvents (still needs version logic)
  • [x] exportArms
  • [x] exportMappings
  • [x] exportUsers (still needs version logic)
  • [x] exportProjectInformation (still needs version logic)
  • [x] exportVersion

And since I tend to be sloppy about documenting as I go, I want to make sure I do a separate checklist of writing the documentation with each function. Things that should be included in the documentation for each function:

  1. @section REDCap Version: in which the API function was introduced
  2. @section Known limitations: of the API (such as fields and forms not active in exportMetaData; or arms forcing empty data frames in exportArms), if any
  3. @section REDCap Documentation: that gives, verbatim, the description of the action from the REDCap documentation page.

Documentation

  • [x] exportRecords
  • [x] exportRecords_offline
  • [x] exportReports
  • [x] importRecords
  • [x] exportMetaData
  • [x] exportFieldNames
  • [x] exportFile
  • [x] importFile
  • [x] deleteFile
  • [x] exportInstruments
  • [x] exportPDF
  • [ ] exportSurveyLink
  • [ ] exportSurveyQueueLink (combine with exportSurveyLink with queue = TRUE?)
  • [ ] exportSurveyReturnCode
  • [x] exportEvents
  • [x] exportArms
  • [x] exportMappings
  • [x] exportUsers
  • [x] exportProjectInformation
  • [x] exportVersion

Miscellaneous

  • [x] exportRecords_offline
  • [x] allocationTable
  • [x] allocationTable_offline
  • [x] parseBranchingLogic
  • [x] recodeCheck
  • [x] redcapFactorFlip
  • [x] Deprecate redcapDbConnection methods

Some more notes for myself:

  1. fieldToVar should be a big switch statement. It would make sense for there to be unexported methods for each variable type.
  2. The lapply that calls fieldToVar probably ought to be an mapply. Nope, changed my mind. This is begging for a for loop.
  3. Factors that are created by redcapAPI should have a new class that inherits factor. That would make it easier to find them and toggle between labels and levels with redcapFactorFlip.
  4. An additional option for how to handle errors would be good. For example, how to handle errors from exportEvents on classic projects, or any method that isn't supported by the version of REDCap. The options should be to return the error, or to return NULL
  5. For convenience, I'm going to assign anything that happens before REDCap 6.0.0 to REDCap 5.12.2. The only only inefficiency I can think of that this will create is in deciding when to run syncUnderscoreCodings, since those were fixed in 5.5.21. That's pretty low computational overhead, though, so I'm willing to live with it in order to have the benefit of exportVersion always returning something that can be compared.

nutterb avatar Feb 05 '16 17:02 nutterb