整洁的获取环境的方法(即Office版本) [英] Neat ways to get environment (i.e. Office version)
问题描述
不幸的是，Office API的某些功能在所有环境中的行为都不完全相同(例如:Excel Online和Excel 2013中的格式).另外，一些不错的新功能在Excel 2013中不可用，但在Excel 2016(Excel.js)中可用
Unfortunately, some features of the office API do not behave exactly the same in all environments (example: formatting in Excel Online and Excel 2013). Additionally, some nice new features are not available in Excel 2013 but are available in Excel 2016 (Excel.js)
当然，我可以告诉用户他们只能在2016年使用我的应用，而根本无法实现并非在所有环境中都得到完全支持的功能.
Of course, I could tell users they can only use my app with 2016, and simply not implement things that aren't fully supported in all environments.
我宁愿将应用程序提供给Excel 2013用户，即使他们没有办法(或倾向)升级到2016年.我宁愿在功能较弱的环境中优雅地降级功能列表，而不是限制应用程序的功能.整体功能)
I would prefer offering my app to users of Excel 2013 even if they don't have a way (or the inclination) to upgrade to 2016. And I would rather gracefully downgrade my feature list in less capable environments than limit the app's functionality as a whole)
封装与文档的所有交互并根据环境运行不同的代码非常容易.也就是说，如果我知道我所处的确切环境，当前的office.js是否提供一种巧妙的方法来发现主机应用程序的版本和上下文(在线/离线)?我在office.context ...等中找不到任何内容.
It's easy enough to encapsulate all interaction with the document and run different code depending on the environment. That is, if I know what exact environment I'm in. does the current office.js offer a neat way to discover version and context(online/offline) of the host application? I couldn't find anything in office.context... etc.
网上有一些关于入侵整个.getContext链的建议，，所以我对此不太满意.
There are some suggestions online about hacking into the whole .getContext chain, but these seem to be "undocumented", so I'm not quite happy with that.
有什么建议吗?
推荐答案
更新2016年12月5日:我们将很快发布API以检测平台信息(部分原因是由于以下事实:人们已经非正式地删除了人们非正式地依赖的_host_info URL参数，以用于Office Online.在预期即将发布的正式API方面，我们还有一个临时的解决方法. 请参阅"
Update Dec 5, 2016: We will soon be releasing an API to detect the platform info (partially in response to the fact that the _host_info URL paramater, which folks had unofficially relied on, needed to be recently removed for Office Online). We also have a temporary workaround in anticipation of the forthcoming official API. See "In Excel Online, OfficeJS API is not passing the host_Info_ parameter anymore to Excel Add-In" for information on the API and workaround.
我保留下面的旧答案，因为它仍然与大多数点亮情况相关.. 仍应谨慎使用平台检测功能，因为查询API集可为您提供更细粒度的控制，并确保您的加载项在添加到特定平台时点亮"新功能]
I am keeping the old answer below, as it is still relevant for most light-up scenarios. Platform-detection should still be used sparingly, as querying API sets give you more fine-grained control, and ensures that your add-in "lights up" new features when they are added to a particular platform].
听起来您正在描述点亮"场景.对于这类用例，您所关心的并不是 actual 版本(您是否真的想保留所有最低版本的内部列表-Excel桌面，很快Excel Online和iOS，并保持最新状态?)，但是，您想检查功能是否存在某些内容.然后根据功能是否存在提供差异化的体验.
It sounds like you're describing a "light-up" scenario. For these sort of use cases, it isn't so much the actual version that you care about (do you really want to keep an internal list of all the minimum versions -- of Excel desktop, and soon Excel Online and iOS, and keep that updated?), but rather, you want to check the capability that something is present. And then offer a differentiated experience depending on whether the capability is there or not.
为此，我建议使用一个刚与这些API一起发布的全新API(并且将其反向移植到所有以前的版本中-只要您使用的是最新版的Office.js， CDN，您应该一切顺利).该API使您能够在运行时检查是否支持特定的API集.看起来像:
To that end, I would recommend a brand-new API that we just released alongside these APIs (and that is back-ported to all previous versions -- so as long as you're using the latest Office.js from the CDN, you should be good to go). That API offers you the ability to check, at runtime, whether a particular API set is supported. It looks like:
if (Office.context.requirements.isSetSupported('ExcelApi', 1.1)) {
// Do something that is only available via the new APIs
}
有关它的官方文档即将发布，我们的示例也将很快开始使用它.敬请期待...
Official documentation for it is forthcoming shortly, and our sample will soon start using it as well. Stay tuned...
当前新发布的Excel API集全部在"ExcelApi" 1.1版下.添加新API时，会将它们添加到1.2集，1.3集等(并在文档和IntelliSense中标记每个API可用的版本集).这有道理吗?
The current set of newly-released Excel APIs is all under "ExcelApi" version 1.1. As we add new APIs, we'll add them to a 1.2 set, 1.3 set, and so on (and mark in the documentation and IntelliSense what set version each API is available in). Does that make sense?
为了完整起见，有关Office.js版本控制的其他注意事项:
For completeness sake, a few other things to note about Office.js versioning:
1)为确保您拥有最新的API，错误修复等，应始终使用CDN位置，该位置会在我们推出新功能时就地更新.该位置为 https://appsforoffice.microsoft.com/lib/1/hosted /office.js . https://appsforoffice.microsoft.com/lib/1.1/hosted/office. js 也可以使用，目前"1"版本只是"1.1"的别名...但是从长远来看，最好切换到"1" URL.
1) To ensure that you have the latest APIs, bug fixes, etc., you should always use the CDN location, which gets updated in-place as we roll out new features. That location is https://appsforoffice.microsoft.com/lib/1/hosted/office.js. https://appsforoffice.microsoft.com/lib/1.1/hosted/office.js also works, with the "1" version being just an alias to "1.1" at the moment... but long-term, it's probably best to switch over to the "1" URL.
2)以上推论:即使对于较旧的主机，也应始终使用最新的CDN位置.这样，您就可以同时获得新功能的亮灯"和错误修复(包括较旧的主机版本).基本上，您始终可以使用最新的CDN，并依靠Office.js脚本的动态加载来加载所需的实际主机特定文件.
2) Corollary to the above: you should always use the latest CDN location even for older hosts. That way, you both get "light-up" for new features, and bug fixes (including for older host versions). Basically, you can always use the latest CDN, and rely on the dynamic loading of Office.js script to load the actual host-specific files you need.
3)您可以将新的isSetSupported API用于新的API集"ExcelApi"和"WordApi"，以及现有的集(例如"MatrixBinding").
3) You can use the new isSetSupported API for both the new API sets "ExcelApi" and "WordApi", and for existing sets (e.g., "MatrixBinding").
4)对于属于"Office"的API.在名称空间中，您还可以使用防御性编程"对单个函数进行运行时检查(例如，检查是否支持Office.context.document.bindings && Office.context.document.bindings.addFromSelectionAsync).但是，您可以看到它变得非常冗长，因此检查集合应该容易得多.此外，这不适用于"Excel"或"Word"命名空间下的API，因此，更多原因是使用Office.context.requirements.isSetSupported API.
4) For APIs that are part of the "Office." namespace, you can also use "defensive programming" to do runtime checks for individual functions (e.g., check that Office.context.document.bindings && Office.context.document.bindings.addFromSelectionAsync) are supported. However, you can see that this can get quite verbose, so checking for a set should be much easier. Also, this will NOT work for APIs under the "Excel" or "Word" namespaces, so all the more reason to use the Office.context.requirements.isSetSupported API.
5)最后:对于只有在存在给定需求集的情况下才有意义运行的应用程序，您可以
5) Finally: for apps that ONLY make sense to run if a given requirement set is present, you can specify the API set in the app's manifest. That being said, a manifest check is about specifying the absolute minimum essentials, without which the app simply won't run (or even show up as available in the insert dialog). A runtime check, meanwhile, lets you control how you want to react if a particular API is unsupported (offering the option of "lightup" features, or a downgraded experience). So, I would generally recommend using the lowest manifest-requirement that makes sense for your app, and then doing runtime checks to light up for new features.
希望这会有所帮助，
〜迈克尔·兹拉特科夫斯基(Michael Zlatkovsky)
Office可扩展性团队的开发人员，MSFT
~ Michael Zlatkovsky
Developer on Office Extensibility team, MSFT
这篇关于整洁的获取环境的方法(即Office版本)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
