2015-09-29 11 views
6

Sfortunatamente, alcune funzionalità dell'API dell'ufficio non si comportano esattamente nello stesso modo in tutti gli ambienti (ad esempio: formattazione in Excel Online ed Excel 2013). Inoltre, alcune nuove funzionalità non sono disponibili in Excel 2013 ma sono disponibili in Excel 2016 (Excel.js)Modi nitidi per ottenere l'ambiente (ad esempio la versione di Office)

Ovviamente, potrei dire agli utenti che possono usare la mia app solo con il 2016, e semplicemente non implementare le cose che non sono 'completamente supportato in tutti gli ambienti.

Preferirei offrire la mia app agli utenti di Excel 2013 anche se non hanno un modo (o l'inclinazione) di eseguire l'aggiornamento fino al 2016. E vorrei piuttosto ridimensionare con garbo il mio elenco di funzionalità in ambienti meno efficienti di limitare il funzionalità di app nel suo complesso)

È abbastanza facile racchiudere tutte le interazioni con il documento ed eseguire codice diverso a seconda dell'ambiente. Cioè, se conosco l'ambiente esatto in cui mi trovo, l'attuale office.js offre un modo pulito per scoprire la versione e il contesto (online/offline) dell'applicazione host? Non ho trovato nulla in office.context ... ecc.

Ci sono alcuni suggerimenti online sull'hacking nell'intera catena .getContext, but these seem to be "undocumented", quindi non sono abbastanza soddisfatto.

Qualche suggerimento?

+1

Aremes, per quanto riguarda la prima differenza che fai notare (formattazione in Excel online ed Excel 2013) : se puoi fornire ulteriori informazioni, sarei felice di dargli un'occhiata. Una cosa è avere alcune funzionalità supportate solo su alcune piattaforme/versioni (per le quali è possibile utilizzare il rilevamento dei requisiti come da mia risposta in basso), ma è un'altra cosa avere un comportamento incoerente. Quindi, se credi in un esempio, ti prego di farmelo sapere e presenterò un bug (lavoro con il team di Estensibilità di Office). –

+0

grazie, ne ho un po ', lo scriverò e te lo darò entro la fine della settimana :) – aremes

risposta

12

Aggiornamento 5 Dicembre 2016: Ci sarà presto rilasceremo un API per rilevare le informazioni piattaforma (in parte in risposta al fatto che il paramater _host_info URL, che le persone avevano ufficiosamente fatto affidamento su, doveva essere di recente rimosso per Office online). Abbiamo anche una soluzione temporanea in previsione della prossima API ufficiale. Vedere "In Excel Online, OfficeJS API is not passing the host_Info_ parameter anymore to Excel Add-In" per informazioni sull'API e soluzione alternativa.

sto mantenendo il vecchio risposta di seguito, in quanto è ancora rilevante per la maggior parte degli scenari di luce-up. Il rilevamento della piattaforma deve essere ancora utilizzato con parsimonia, poiché l'interrogazione dei set di API offre un controllo più dettagliato e garantisce che il componente aggiuntivo "illumini" le nuove funzionalità quando vengono aggiunte a una piattaforma specifica].


Sembra che tu stia descrivendo uno scenario "light-up". Per questi tipi di casi d'uso, non è tanto la versione effettiva di cui si cura (vuoi veramente mantenere un elenco interno di tutte le versioni minime) del desktop Excel, e presto Excel Online e iOS, non è tanto la versione ? e tieni aggiornato?), ma preferisci controllare la capacità dello che qualcosa sia presente. E quindi offrire un'esperienza differenziata a seconda se la capacità è lì o meno.

A tal fine, vorrei raccomandare un'API nuova di zecca che abbiamo appena rilasciato insieme a queste API (e che è backportata a tutte le versioni precedenti, quindi basta che tu stia usando l'ultimo Office.js da il CDN, dovresti essere bravo a farlo). Questa API ti offre la possibilità di verificare, in fase di esecuzione, se è supportato un particolare set di API. Sembra:

if (Office.context.requirements.isSetSupported('ExcelApi', 1.1)) { 
    // Do something that is only available via the new APIs 
} 

La documentazione ufficiale è disponibile a breve e il nostro campione inizierà presto a utilizzarlo. Resta sintonizzato ...

L'attuale serie di API Excel appena rilasciate è tutto in "ExcelApi" versione 1.1.Quando aggiungiamo nuove API, le aggiungeremo a un set 1.2, a un set 1.3 e così via (e contrassegniamo nella documentazione e in IntelliSense la versione di ciascuna API in cui è disponibile). Ha senso?


Per completezza, un paio di altre cose da notare su Office.js delle versioni:

1) Per assicurarsi di avere le ultime API, correzioni di bug, ecc, è necessario utilizzare sempre la posizione CDN , che viene aggiornato sul posto mentre implementiamo nuove funzionalità. Quella posizione è https://appsforoffice.microsoft.com/lib/1/hosted/office.js. https://appsforoffice.microsoft.com/lib/1.1/hosted/office.js funziona anche, con la versione "1" che è solo un alias per "1.1" al momento ... ma a lungo termine, è probabilmente meglio passare all'URL "1".

2) Corollario a quanto sopra: si dovrebbe sempre utilizzare l'ultima posizione CDN anche per gli host precedenti. In questo modo, entrambi riceverete "light-up" per nuove funzionalità e correzioni di bug (anche per versioni di host precedenti). In sostanza, puoi sempre utilizzare l'ultimo CDN e fare affidamento sul caricamento dinamico dello script Office.js per caricare i file specifici dell'host necessari.

3) È possibile utilizzare la nuova API isSetSupported per entrambi i nuovi set di API "ExcelApi" e "WordApi" e per i set esistenti (ad es. "MatrixBinding").

4) Per le API che fanno parte di "Office". spazio dei nomi, è anche possibile utilizzare la "programmazione difensiva" per eseguire i controlli di runtime per le singole funzioni (ad esempio, controllare che siano supportati Office.context.document.bindings && Office.context.document.bindings.addFromSelectionAsync). Tuttavia, è possibile vedere che questo può essere abbastanza dettagliato, quindi il controllo di un set dovrebbe essere molto più semplice. questo NON funzionerà per le API sotto lo spazio dei nomi "Excel" o "Word", quindi è un motivo in più per utilizzare l'API Office.context.requirements.isSetSupported.

5) Infine: per le app che hanno senso funzionare solo se un determinato set di requisiti è presente, è possibile specify the API set in the app's manifest. Detto questo, un controllo manifesto riguarda specificando il minimo assoluto , senza il quale l'app semplicemente non verrà eseguita (o mostrerà anche come disponibile nella finestra di dialogo Inserisci). Un controllo di runtime, nel frattempo, consente di controllare come si desidera reagire se una determinata API non è supportata (offrendo l'opzione di funzionalità "lightup" o un'esperienza declassata). Pertanto, in generale, consiglio di utilizzare il requisito manifest minimo che abbia senso per la tua app, quindi di eseguire controlli di runtime per le nuove funzionalità.

Spero che questo aiuti,

~ Michael Zlatkovsky
      Developer sul team di Office estensibilità, MSFT

+0

molto completo! grazie – aremes

+0

Sono in difficoltà con questo: voglio rilevare se sto eseguendo Word o Excel, tuttavia il codice se (Office.context.requirements.isSetSupported ("ExcelApi", 1.1)) {non ottiene dentro il se per Excel 2013. Ho provato anche 1.0. In sostanza non posso dire se sono in Word o Excel. – gremwell

+0

@gremwell, Sì, per Office 2013, restituisce "false" in entrambi i casi. Ma potresti scegliere un altro requisito (idealmente basato sul PERCHÉ che ti interessa essere in Word o Excel).Ad esempio, se si utilizza OOXML, è possibile eseguire isSetSupported ("OOXMLCoercion"), che restituirebbe effettivamente "true" in Word. Questo aiuta? –

Problemi correlati