search

redcap-tools / redcap-tools.github.io

Public catalog of REDCap-related projects
https://redcap-tools.github.io/projects/
MIT License
11 stars 9 forks source link

Snippet table #14

Closed wibeasley closed 8 years ago

wibeasley commented 8 years ago

@sburns, @haozhu233, & whoever I split the "libraries" and the "samples" into different tables.

  1. Do you think this distinction is worth worrying about? I didn't feel the need for it until two REDCapCons ago, when I saw people repeatedly copy & pasting the same code into different places. You can imagine the versioning problems that are caused after a while. Not to mention that this type of code is much less likely to be verified thoroughly.

  2. If so, is this description ok? I don't want it to be too heavy-handed.

    The following libraries can assist communication with REDCap's API. They can help make your development quicker and more robust. Unlike the code samples in a subsequent list, these libraries are reusable components (and not loose code that's copied and pasted into each caller). Each library's readme will have instructions how the deployed instances can be updated after the developer releases a new version.

  3. I'm guessing that not all the entries fit the standard definition of a library. I'm wondering where/how the line should be drawn (assuming it's worth caring about).
sburns commented 8 years ago

@wibeasley merge master and your CI builds on this branch will fare better.

sburns commented 8 years ago
  1. I think it's worth worrying about. I think the packages should have more prominence than snippets. Ideally visitors look for packages in their language and fall back to snippets if there aren't any.
  2. That looks fine to me.
  3. They might not be but I'm not going to lose sleep over it. If authors submit PRs to add their repos to the site, we can have a quick discussion about the scope of their work.