search

reichlab / zoltr

http://reichlab.io/zoltr/
GNU General Public License v3.0
2 stars 4 forks source link

change structure of calls to API to return data.frame objects instead of environments/lists #2

Closed nickreich closed 5 years ago

nickreich commented 5 years ago

The way the functions operate currently, it seems like there is this added layer of programmatic bureaucracy to access the data from the API. E.g. when I run

the_projects <- projects(conn)

I expect the_projects to be a data.frame object that I can print and access individual elements of. But instead it's an environment that I have to have a specific piece of lapply() code to access the specific elements of. Same applies to the models(project) line of code. I'd prefer just to be able to pass a character string like models("sandbox project") rather than having to worry about passing the right project object to the models() function. I recognize that maybe my instinct in how I want to interact with the API might be violating all kinds of good programming practice.

nickreich commented 5 years ago

@matthewcornell I'd be happy to discuss this more. I don't want my caveman coding habits to disrupt an otherwise nice object-oriented package. But I am really not a fan of a user having to run this code every time they want to isolate one project:

lapply(the_projects, function(project) {c(project$url, name(project))})
cond <- sapply(the_projects, function(project) name(project) == Sys.getenv("PROJECT_NAME"))
project <- if (any(cond)) the_projects[cond][[1]] else NULL

We need a simpler way to isolate/access/reference one project, one model, one forecast, etc...

nickreich commented 5 years ago 
## use case 1: retrieving/editing forecasts from known model/project
get_forecasts(project_str, model_str)
get_forecast(project_str, model_str, timezero)
upload_forecast(project_str, model_str, timezero, filename)
delete_forecast(project_str, model_str, timezero)