Upgrade StorageFeature Request - Export Translator File IO Capabilities
I'm currently working on an export translator to allow Zotero to interface with a custom reference management system that I'm developing. The system uses an XML based format for citation data which is easy enough to generate through an export translator, but file attachments are causing me some difficulties. Ideally what I'd like to do is only export PDF format attachments from Zotero entries, and move all the exported PDF files to the same directory as the exported XML file.
As I understand it, this functionality can not be supported through the current Zotero translator sandbox. If the "exportFileData" option is set, all attachments for the exported entries are exported to the user's selected export location in separate sub-directories. As far as I can tell, the translator code does not have the permissions to perform any further file IO beyond writing to the singular export file. While I understand why this is required from a security standpoint, I think it would be worthwhile to provide sandbox functionality to handle basic IO such as moving or renaming files only within the specified export directory.
If anyone could provide some guidance as to how I could support this feature I would be very appreciative. I'd like to maintain compatibility with the standard Zotero install, so if there is no way to further modify attachment exports through the existing translator sandbox code perhaps this feature could be considered as an addition to the standard Zotero package?
To better demonstrate what I'm asking for, I've put together a set of changes to the translator sandbox that are sufficient to fulfill my direct needs. Specifically, I added "moveAttachment" (line 463), and "clearAttachmentDir" (line 504) functions to the export sandbox. I understand that these changes may not be general purpose enough to be included in the base Zotero package, but if someone could point out changes that would need to be made to be considered for inclusion I would be happy to do the implementation myself.
As I understand it, this functionality can not be supported through the current Zotero translator sandbox. If the "exportFileData" option is set, all attachments for the exported entries are exported to the user's selected export location in separate sub-directories. As far as I can tell, the translator code does not have the permissions to perform any further file IO beyond writing to the singular export file. While I understand why this is required from a security standpoint, I think it would be worthwhile to provide sandbox functionality to handle basic IO such as moving or renaming files only within the specified export directory.
If anyone could provide some guidance as to how I could support this feature I would be very appreciative. I'd like to maintain compatibility with the standard Zotero install, so if there is no way to further modify attachment exports through the existing translator sandbox code perhaps this feature could be considered as an addition to the standard Zotero package?
To better demonstrate what I'm asking for, I've put together a set of changes to the translator sandbox that are sufficient to fulfill my direct needs. Specifically, I added "moveAttachment" (line 463), and "clearAttachmentDir" (line 504) functions to the export sandbox. I understand that these changes may not be general purpose enough to be included in the base Zotero package, but if someone could point out changes that would need to be made to be considered for inclusion I would be happy to do the implementation myself.
This is an old discussion that has not been active in a long time. Instead of commenting here, you should start a new discussion. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
Also take a look at the Zotero trunk in SVN (http://www.zotero.org/spport/dev/svn_and_trac_access) to see how you'd be able to fit this in with the significantly reworked translator infrastructure of Zotero 2.2. It'd be great if you then posted this as a patch vs. the trunk-- that'd make it a lot easier to review and consider for inclusion.
I also posted this issue to the dev mailing list last week, but hadn't received a response yet. As requested, I've implemented my changes against the trunk and the patch is available here.