Multiple files

[rasqual]

If my data needs to be exported to multiple files (first 8 rows to fileA, next 430 rows to fileB, etc.), using the left column to specify the filename would help.

Want to solve the problem of specifying export location? Allow the first column to specify the document ID.

Perhaps creating the export files the first time would use the first method above (filename), then I could move those files wherever I like and put their IDs in the first column henceforward.

This would permit writing out numerous files in one fell swoop.

The options for export could be stored in cell A1, so that the settings could be easily remembered from session to session.

Basically, column one would just not be part of the add-on's processing to XML. It'd be a configuration and file destination column.

This would be ridiculously handy. In fact, there are some things we just can't do with the add-on the way it is now.

[Synthoid]

Hmm, interesting ideas. I hadn't thought about exporting multiple sets of data from the same document to separate documents all at once. I think the theory you've proposed is sound, but I'm not sure about using the first column as the identifier for the target document. It would require a large number of redundant values, and most users would not need this functionality. I would prefer a simpler method like using a specific sequence of characters in a mostly empty row above the target rows to specify output target. This is mostly a design issue though, and could be done in a variety of ways.

There are two main concerns that are immediately obvious:

1. Add-ons have a limited number of documents they can create per day (for most users this is 250)
2. I will need to create utility windows for users to select target documents or at least retrieve their IDs

The second issue is something I was already planning on doing (no timeframe for that yet...) but the first issue is something completely out of my hands. It will somewhat be helped once I refactor how files are created when exporting, but the limited number of file creations per day is something I have to note to users, otherwise they may think ESD is at fault.

There are a few other concerns, but this post is quite the door stop already. I like the idea of exporting multiple documents at once, but it's definitely something that needs to be thought out so the UX isn't too obtuse.

[rasqual]

Thanks for the reply.

The redundant data in the first column is indeed a design issue, but a database one. It's the only proper way to do it from a database design standpoint -- where it's not regarded as redundant but rather a referential relation between the data and the file. This would allow, among other things, the direct insertion of database information into the sheet for this use.

The use of section headings is intuitive to lay persons but breaks things entirely for database people.

From your standpoint for coding, you would just be looking for a change in that first column, rather than needing to reference some specific pinned cell or row for each set of rows.

Again, not an urgent matter for us; I've managed to cobble something we can use in apps script for the moment.

Best of luck!

On Apr 22, 2018 18:45, "Chris" notifications@github.com wrote:

Hmm, interesting ideas. I hadn't thought about exporting multiple sets of data from the same document to separate documents all at once. I think the theory you've proposed is sound, but I'm not sure about using the first column as the identifier for the target document. It would require a large number of redundant values, and most users would not need this functionality. I would prefer a simpler method like using a specific sequence of characters in a mostly empty row above the target rows to specify output target. This is mostly a design issue though, and could be done in a variety of ways.

There are two main concerns that are immediately obvious:

1. Add-ons have a limited number of documents they can create per day (for most users this is 250 https://developers.google.com/apps-script/guides/services/quotas)
2. I will need to create utility windows for users to select target documents or at least retrieve their IDs

The second issue is something I was already planning on doing (no timeframe for that yet...) but the first issue is something completely out of my hands. It will somewhat be helped once I refactor how files are created when exporting https://github.com/Synthoid/ExportSheetData/issues/32, but the limited number of file creations per day is something I have to note to users, otherwise they may think ESD is at fault.

There are a few other concerns, but this post is quite the door stop already. I like the idea of exporting multiple documents at once, but it's definitely something that needs to be thought out so the UX isn't too obtuse.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Synthoid/ExportSheetData/issues/61#issuecomment-383421532, or mute the thread https://github.com/notifications/unsubscribe-auth/AXv4ocImpFcu9j_8cAp6QrJ7ykTw03ENks5trRX7gaJpZM4TcWHO .

[Synthoid]

Ah, I hadn't thought about that. Guess it makes sense to make things more convenient for people working with databases since they are likely the only people who would use this particular feature. I should just need to replace the hard coded 0 index for element naming with a variable that set to 0 or 1 depending on if this option was enabled.

Not sure when this feature would be implemented. There are a few tasks I'll need to complete before I could get to this, including the earlier mentioned adjustments to how files are created as well as allowing custom export locations. Once those are done, combining this with the plans for automation and MongoDB support might actually make ESD pretty useful for database workflows.