【问题标题】:How to best maintain a script in a large amount of spreadsheets?如何在大量电子表格中最好地维护脚本?
【发布时间】:2012-05-12 09:26:12
【问题描述】:

我即将发布一个应用程序(时间表),其中多达 80 位用户将在我分享给他们的自己的时间表上工作。所有这些工作表目前都包含 2 个脚本(onOpen 和 onEdit),它们支持用户输入他的数据。

如果我必须在某个时间点对脚本进行更改,我现在担心的是更新所有这 80 个脚本。

是否有关于如何做到这一点的最佳做法?我可以为此使用“发布即服务”功能吗?如果是,我如何在这 80 个电子表格中应用这项服务?

欢迎提出任何想法。

亨氏

【问题讨论】:

    标签: google-apps-script


    【解决方案1】:

    目前还没有简单、标准的方法来做到这一点。我们都希望issue 40 解决后会容易得多。您应该为它加注星标以跟踪更新并为它投票。

    现在,有一些解决方法。有一个可能适合你。其中一些在issue 40cmets 上有描述,你应该认真阅读。

    第一个是“远程代码获取”。您的 80 个脚本中的每一个都将只有一个框架脚本,该脚本将获取要远程执行的代码。可能存储在“母亲”电子表格或站点的单元格中,您可以从脚本轻松访问的任何位置。这是一个例子:

    var sourceScript = 'url-to-your-script-file-hosted-anywhere';
    
    function onEdit() {
      eval(UrlFetchApp.fetch(sourceScript).getContentText());
      onEditImpl(); //this function is declared on the imported script
    }
    
    function onOpen() {
      eval(UrlFetchApp.fetch(sourceScript).getContentText());
      onOpenImpl(); //this function is declared on the imported script
    }
    
    //only hold the API calls that you may do on the imported script
    //so there's a nice authorization popup for the user
    function stub() {
      return;
      SpreadsheetApp.openById('').getRange('').setValue('');
      CalendarApp.getCalendarById('').createAllDayEvent('', null);
      SitesApp.getSite(''); //and so on...
      //add/remove all services you'll use here in the stub
      //more is better, in case you decide the script have to something new
      //you don't have to go and edit each script manually :)
    }
    

    另一种可能的解决方法是使用包含脚本的“模板”电子表格。这样您就可以通过再次复制(使用更新的脚本)重新创建所有 80 个电子表格,并将每个文件的值和权限复制到新文件上。这种方法的缺点是所有到文件的链接都会改变。文件、cmets、文件夹等的每个用户设置都将丢失。但同样,根据您的使用情况,他们如何访问文件,例如他们甚至可能没有 Google 帐户,它可以与任何知道链接的人共享,该链接位于您的站点中。我不知道场景,它可能适合你。

    这就是我能想到的所有限制(使用 onOpen 和 onEdit)。所有这些都非常笨拙且不是真正的解决方案。但就目前而言,这就是我们所得到的。

    【讨论】:

    • 你好 Henrique,我很喜欢你的想法:function onEdit() { eval(UrlFetchApp.fetch(sourceScript).getContentText()); onEditImpl(); //这个函数是在导入的脚本上声明的但是,我想这会很慢。不会吗?我使用 onEdit() 脚本来支持用户输入数据并控制数据输入错误,因此响应必须非常快。不管怎么说,还是要谢谢你。亨氏
    • 您可以将代码“缓存”在本地某处,例如脚本属性、缓存服务、隐藏单元格等,并具有一些其他功能来更新它(或使其过期)。无论如何,总会有开销,没有什么可以与直接在那里的代码相比。但恕我直言,onEdit 从来都不是“相当快”,它自然很慢。我想你已经尝试看看这种差异在你的用例中是否真的很重要。但同样,这不是一个真正的解决方案,只是一个有很多妥协的解决方法。
    • UrlFetchApp 在 onOpen\onEdit 的上下文中是否可用???根据我的实验和您在productforums.google.com/forum/#!topic/apps-script/… 的回答,似乎不是。如果我错了,请告诉我。
    • UrlFetch 可用于 onEdit/onOpen,因为它与用户无关。例如您可以完美地 UrlFetch 基于编辑的 google 结果并将其显示在弹出窗口中给用户。您不能在简单的事件处理程序上做的是访问任何需要用户凭据的东西。反正issue 40已经解决了!所以这些都不再是必需的/相关的了。
    猜你喜欢
    • 2014-11-06
    • 1970-01-01
    • 2013-04-11
    • 1970-01-01
    • 2010-10-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-08-28
    相关资源
    最近更新 更多