Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Office Automation VS OpenXML SDK

Hej,

Dynamiczne generowanie dokumentów jest funkcjonalnością, którą czasem chcielibyśmy dodać w swoim programie. Jeśli np.: implementujemy aplikację wspomagającą redagowanie tekstu warto byłoby umożliwić eksport stworzonego dokumentu do formatu obsługiwanego przez Worda w celu dalszej edycji.

Kiedy już podejmiemy decyzję o dodaniu możliwości wygenerowania dokumentu, zaczniemy poszukiwać sposobu jego implementacji. Możliwości są różne i zależą od formatu pliku, który chcemy uzyskać. Wśród dostępnych rozwiązań warte uwagi wydaje się użycie mechanizmu automatyzacji udostępnianego przez pakiet Office lub stworzenie dokumentów w oparciu OpenXML SKD. W tym artykule postaram się przybliżyć zalety i wady każdego z nich. Będę się opierał na informacjach dotyczących głównie generowania dokumentów Worda, ponieważ z nim miałem głównie do czynienia :).

Automation for Office (Office Interop)

Jeśli posiadasz zainstalowany pakiet Office, możesz do generacji dokumentów wykorzystać API, które udostępnia np.: Word. Obsługa może wydawać się początkowo dość niewygodna, szczególnie ze względu na dużą ilość argumentów przyjmowanych przez poszczególne metody.

Już podczas nauki podstaw można zauważyć dużą analogię kolejnych metod do operacji wykonywanych przez użytkownika. Dzięki temu podczas implementacji rozwiązań można wykorzystywać do pomocy samego Worda :). Wystarczy nagrać makro realizujące daną funkcjonalność i przeczytać wygenerowany kod. Z jego pomocą znacznie łatwiej stworzyć odpowiedni własny kod w implementowanej aplikacji.

Wadą mechanizmu Office Automation jest wymóg posiadania pakietu Office na komputerze docelowym, na którym będzie uruchamiana nasza aplikacja. Nie twierdzę, że wadą jest posiadanie Office'a, bo sam go używam i zwykle podobają mi się jego możliwości. Niewygodne jest natomiast wymaganie posiadania pakietu przez osobę, która być może go nie ma, a chciałaby skorzystać z naszego programu. W takim przypadku zamiast kupić go, żeby używać naszej aplikacji, wybierze raczej alternatywę, która takiego wymogu nie posiada.
Konieczność posiadania Office'a wynika z faktu, że posługując się Office Automation w swojej aplikacji, uruchamiamy tak naprawdę proces odpowiedniego programu z pakietu Office, który wykonuje kolejno operacje odpowiadające metodom wywoływanym z wnętrza programu.

Inną wadę może stanowić również nieduża szybkość działania, szczególnie podczas operacji na tabelach (wygenerowanie zaledwie kilkunastu stron z tabelami może zająć nawet kilka minut). Trzeba o tym pamiętać projektując sposób generowania (np.: używając szablonów i ograniczając liczbę operacji na tabelach), co może pozwolić na znaczne przyspieszenie szybkości działania. Istnieją również sposoby pozwalające zwiększyć wydajność tego mechanizmu np.: poprzez zmianę pewnych opcji konfiguracyjnych. W zależności od konkretnego przypadku szybkość nie musi więc być jego wadą.

Generowania dokumentów za pomocą Office Automation powinno się też (poza pewnymi uzasadnionymi przypadkami) unikać w aplikacjach serwerowych. Wymagany jest oczywiście zakup pakietu do zainstalowania na serwerze, jednak problem tkwi w braku przystosowania tej metody generacji dokumentów do środowiska serwerowego. Taki scenariusz użycia nie jest zalecany ani wspierany przez Microsoft. Z tego względu nawet w pełni działające rozwiązanie może np.: przestać poprawnie funkcjonować po aktualizacji systemu. Na tej stronie możemy zapoznać się z bardziej szczegółowymi informacjami o komplikacjach, które mogą wystąpić podczas używania Office Automation w środowisku serwerowym.

Zaletą implementacji rozwiązania w oparciu o ten mechanizm generacji dokumentów jest niewątpliwie zapewnienie zgodności z danym formatem pliku, a także dostępność wszystkich formatów obsługiwanych przez odpowiednią aplikację. Liczbę dostępnych formatów można zwiększyć np.: poprzez instalację odpowiedniego dodatku do Office'a, dostępnego na stronie Microsoftu uzyskujemy możliwość zapisu w formatach PDF i XPS.

OpenXML SDK

W pakiecie Office 2007 występujące we wcześniejszych wersjach domyślne formaty zapisu, jak *.doc, *.xls, *.ppt zostały zastąpione przez odpowiedniki z końcówką x (*.docx, *.xlsx, *.pptx). Różnica nie sprowadza się jednak tylko do dodania nowej literki na końcu rozszerzenia :P. W przeciwieństwie do swoich poprzedników nowe formaty są oparte na skompresowanym zestawie struktur XMLowych, co pozwala łatwo modyfikować je bez specjalnego API (są to archiwa ZIP, które można otworzyć np.: programem 7-zip dostępnym na łamach portalu) :). W celu ułatwienia programistom operowania na strukturach dokumentów wydane zostało OpenXML SDK, które dostarcza typowane klasy odpowiadające różnym elementom zawartym w pliku, jak tabele, nagłówki, style itp.

Ze strony Microsoftu pobrać można również narzędzie pozwalające na podgląd struktury wybranego dokumentu. Nawigując po jej drzewie możemy wyświetlać dokumentację poszczególnych elementów, odpowiadające mu poddrzewo w postaci XML, a także kod programu potrzebny do jego odtworzenia. Możemy więc np.: stworzyć dokument w Wordzie i zobaczyć jak został wygenerowany, aby później odwzorować taką strukturę podczas dynamicznej generacji.

Wadami, które zauważyłem przed czas korzystania z tego sposobu generacji dokumentów są czasem mylące informacje, które można znaleźć w sieci szukając rozwiązań konkretnych problemów wynikające być może z różnic pomiędzy SDK w wersji 1 oraz 2.

OpenXML SDK w wersji 2.0 oraz narzędzie umożliwiające podgląd dokumentów można pobrać ze strony Microsoftu. Ponadto z tej strony można pobrać oficjalnie udostępniony zestaw snippetów, które mogą dodatkowo ułatwić implementację w typowych przypadkach.

Podsumowanie

Moim zdaniem wygoda implementacji rozwiązań w obu przypadkach jest zbliżona, jednak XMLowa struktura w drugim przypadku pozwala łatwiej zapanować nad tworzonym dokumentem, co przemawia na korzyść tego rozwiązania.

OpenXML SDK może generować dokumenty szybko i nie wymaga zainstalowanego Office'a na komputerze, na którym nasz program będzie uruchamiany. Jego wadą jest możliwość wygenerowania dokumentów tylko w nowych formatach Office'a, formatach zgodnych z OpenXML (jak *.docx, *.xlsx oraz *.pptx).

Jeśli natomiast jednym z wymagań jest wygenerowanie dokumentów w starszym formacie i nie posiadamy odpowiedniego konwertera, Office Automation wydaje się być dobrym wyborem.

Możliwym rozwiązaniem jest również np.: wygenerowanie dokumentu za pomocą OpenXML SDK i późniejsze użycie Office Automation w celu konwersji gotowego już pliku do wybranego formatu.

Mam nadzieję, że informacje tu zebrane pomogą dokonać właściwego wyboru osobom, które chcą zawrzeć funkcjonalność związaną z generacją dokumentów w tworzonych przez siebie aplikacjach.

Pozdrawiam,

Łukasz 

Komentarze

0 nowych
  #1 30.11.2010 14:15

Obydwa rozwiązania mają poważną wadę w postaci wynikowego formatu czytanego tylko przez MS Office. Argument o potrzebie instalacji pakietu MSO bądź jego braku nie ma zatem kompletnie znaczenia.

StawikPiast   10 #2 30.11.2010 16:56

@Woowas

To sa formaty Otwarte, zatwierdzone przez ISO, wiec sobie odpusc podobne brednie.

A co do wpisu.
Czy moglbys nieco szerzej napisac o wyswietlaniu docx w strukturze strony html (asp.net) bo wlasnie szukam czegos co mi to umozliwi.

ŁukaszPL   3 #3 30.11.2010 19:21

@Woowas: Tak, jak słusznie zauważył StawikPiast OpenXMLowe formaty w Office (jak *.docx, *.xlsx, *.pptx) są otwarte, więc inne edytory mogą posiadać wsparcie dla nich.
Przykładem darmowego pakietu OpenOffice, którego aplikacje potrafią odczytywać pliki zapisane w ten sposób, a co więcej obsługują one wcześniej używane formaty plików (jak *.doc czy *.xls). Może wsparcie innych aplikacji nie jest idealne (szczególnie w przypadku starszych formatów), jednak wydaje mi się, że brak wymogu Office'a ma pewne znaczenie.

@StawikPiast: Prosiłbym o doprecyzowanie pytania. Czy chcesz wyświetlić dokument jak element strony, umożliwiając jego podgląd czy pozwolić również na jego edycję? Obie rzeczy da się zrobić, jednak ilość kodu będzie pewnie znaczna ;) (chociaż do podglądu dokumentów Worda są dostępne gotowe kontrolki).

Pozdrawiam,

Łukasz

  #4 30.11.2010 21:57

"To sa formaty Otwarte, zatwierdzone przez ISO, wiec sobie odpusc podobne brednie."
"ak, jak słusznie zauważył StawikPiast OpenXMLowe formaty w Office (jak *.docx, *.xlsx, *.pptx) są otwarte, więc inne edytory mogą posiadać wsparcie dla nich. "
Pliki produkowane przez ms office nie są kompatybilne z standardem ISO/ECMA żadnym nawet tym przepchniętym przez ms w aurze skandalu i porzuconym niedługo po tym. Ms office produkuje ich specjalną wersję.

StawikPiast   10 #5 30.11.2010 22:18

Łukasz, dzięki za odpowiedz.
Chodzi jedynie o wyswietlenie zawartosci docx-a na stronie w jakims div-ie. Sama aplikacja ma byc w asp.net. Tak dzis zaczałem szukać, ale jak masz jakieś fajne gotowce, to z miłą chęcią zobaczę.

  #6 30.11.2010 22:57

@StawikPiast @ŁukaszPL
Formaty może i otwarte ale docx z MS Office nie jest z nimi w pełni zgodny i jeszcze długo nie będzie. Open Office co prawda je "jakoś" odczytuje ale chyba to "jakoś" to za mało.

http://www.dobreprogramy.pl/Pelna-zgodnosc-z-Office-Open-XML-dopiero-w-Office,Ak...

ŁukaszPL   3 #7 01.12.2010 19:52

Macie rację, MS Office nie jest zgodny w pełni z otwartą specyfikacją. Tak naprawdę jednak podejrzewam, że np.: w OO będą starali się pomimo tego obsługiwać prawidłowo takie nie w pełni poprawne dokumenty, ze względu na dużą liczbę użytkowników MS Office'a.

@StawikPiast: pewnie sam znalazłeś, ale przeglądając na szybko Google'a widziałem jakieś gotowe kontrolki. Nie podaję linków, bo nie testowałem, więc nie wiem jakiej są jakości, a po wpisaniu w Google'u "display DOCX in ASP.NET" była na jednej z pierwszych stron, więc łatwo ją znaleźć :).

Jeśli znajdziesz coś ciekawego, napisz :).