Join GitHub today
excel_sheets does not work with *.xltx/*.xltm #411
Possible fix would be to change
There are of course other Excel formats which may deserve to be handled too, Excel 97-2003 templates for instance (
If you are wondering, why somebody wants to read in templates, let me give you my use case: in a Shiny app I want the user to upload a file containing some data. In order to make sure that the data is compliant with my Shiny app, I do some checks.
Basically, I compare the structure of the user data with the structure of a template stored in my app folder. This approach avoids hardcoding all the checks. As I am providing an Excel template anyways to the users of my tool, I gain quite some flexibility. I could of course fall back to a
But I guess I was too late to test it?
@thothal I'm interested to learn more about your workflow. Especially this part:
I have vague aspirations, along with Aaron Berg at RStudio, to provide some workflow-level guidance when a keen R user needs to work with people more comfortable in a spreadsheet application. It sounds like you might have some interesting insights.
What sort of checks do you on the uploaded user file? I'm curious to hear more.
For the Shiny tools we are developing, the user (mostly non stats scientists) is typically asked to upload their data. For this task, we provide them with an Excel template where they can fill the data and sometimes these templates also includes some VBA checks to ensure data consistency.
For the Shiny app it is of course important that the required data is where it supposed to be. That is, we would like to have the right columns available. Thus, the approach we have pursued in the past is the following:
Idea behind this approach is that if the template changes slightly, the Shiny app ideally does not need to be changed - all what is needed that the new template is also in the relevant sub folder. The code is modular and does not require any hard coding on the Shiny side (unless the column headers do not start in the default row). If we start a new project, all we have to do is to provide an Excel template and the testing procedure. With this set up we ensure
For future iterations we thought about providing a template template, from which project specific templates derive and which has one ".SYSTEM" sheet (say), where all the project specific settings (e.g. which sheets not to check, what are the cell boundaries for comparing etc.) are stored. In this way we should be able to eliminate the last bit of Shiny hard coding completely.
Does that make sense to you?
Interesting! Thanks for providing more details. The hidden row of "true" column names is interesting.
I also want to make named ranges more of a "first class" addressable object in future. I'm baking this in to the reboot of googlesheets. Because I think that is another tool for this sort of workflow, where you can mark off an area in the spreadsheet that needs to be managed your way (and possibly force certain practices there, with data validation, etc.) and then let people do whatever they want elsewhere.