Bug w SharePoint Designer?

Dziś natrafiłem na nietypowe zachowanie SharePoint Designer. Podczas tworzenia własnego z modernizowanego view na listę poprzez konwersję List View Web Part do XSLT Data View Web Part, linki do elementów uległy zmianie.

Mianowicie, standardowy List View Web Part wyświetlał nazwy raportów Excel, które są wyświetlane za pomocą Excel Services. Kliknięcie na raport przekierowuje do strony znajdującej się w katalogu leyaouts – xlsviewer.aspx, która jaki query string przyjmuje link do pliku Excel. W kodzie źródłowym strony możemy zauważyć iż przekserowanie wykonywane jest przez funkcję OnLick na tag’u <A>:

<A onfocus="OnLink(this)" HREF="/OddsOn/ReportsLibrary/Report.xlsx" onclick="return DispEx(this, event, 'TRUE', 'FALSE', 'FALSE', 'SharePoint.OpenDocuments.3'
, '1', 'SharePoint.OpenDocuments', '', 
'1http:u002fu002flsharepointu002fOddsOnu002f_layouts
u002fxlviewer.aspx?
id=u002fOddsOnu002fReportsLibraryu002fReport.xlsx'
, '', '2', '0', '0', '0x7fffffffffffffff')" >Report</A>

Funkcja DispEx przyjmuje następujące parametry:

• ele – Element którego tyczy dany kod. Tak naprawdę nie jest on wykorzystywany przez DispEx, ale jest przekazany do kolejnej metody wywoływanej przez DispEx.
• objEvent – Obiekt event, do którego będą podpinane zdarzenia.
• fTransformServiceOn – Wartość Boolean, określająca czy dany dokument ma być poddany transformacji. Np.: w naszym przypadku czy Excel ma zostać wyświetlony za pomocą Excel Services.
• fShouldTransformExtension – Szczerze mówiąc nie wiem co to dokładnie jest, nie jest to prawie wykorzystywane oprócz jednego IF’a, w którym również nie jest zbyt dużo powiedziane. Przypuszczam, że jeżeli się stworzy własny konwerter na podstawie konwerterów dostarczonych w MOSS, to będzie miało wtedy ręce i nogi.
• fTransformHandleUrl – Patrz wyżej.
• strHtmlTrProgId – Element służy do oznaczenia, że MOSS jest wstanie przekształcić i otworzyć samemu dany dokument. Tak naprawdę, element ten może być równy strHtmlType. SharePoint sam doda .3 do końcówki.
• iDefaultItemOpen – Jeżeli zostanie podana wartość 1, to MOSS wykorzysta parametr strServerFileRedirect by otworzyć dany element w MOSS. Jakakolwiek inna wartość zostanie zignorowana.
• strProgId – Informacja dla MOSS, że to on powinien otworzyć dokument. W tym wypadku nie możemy podać .3, gdyż z automatu to jest dodawane bez sprawdzenia czy istnieje. Mianowicie MOSS tworzy obiekt ActiveX o nazwie „SharePoint.OpenDocuments.3”.
• strHtmlType – Dla dokumentów Excel czy Word, musi być null, w innych wypadkach można podać tym dokument – np.: SharePoint.WebPartPage.Document.
• strServerFileRedirect – URL zaczynający się od dowolnego jednego znaku. To znaczy, że zanim podamy URL gdzie chcemy by nas funkcja przekserowała podajemy np.: 1 lub 2 lub a, cokolwiek by odciąć możliwość wyciągania łatwego URLi. MOSS sam zadba o to by ten pierwszy znak usunąć.
• strCheckoutUser – Użytkownik, który wyczekaoutował dokument.
• strCurrentUser – ID aktualnego użytkownika.
• strRequireCheckout – Informacja, która mówi MOSS, że przy otwarciu/edycji ma z powodować check out dokumentu. Wartość 1 oznacza, że tak. Każda inna, że nie.
• strCheckedoutTolocal – Oznacza czy dokument został wyczekaoutowany czy nie. Wartość 1 oznacza, że tak. Zaś każda inna, że nie.
• strPermmask – Maska uprawnień do elementu.

Teraz, kiedy taki widok otworzymy sobie w SharePoint Designer i klikniemy na nie prawym przyciskiem myszy, dostaniemy możliwość przekonwertowania go do XSLT Data View Web Part.

Jeżeli taki widok zapiszemy w katalogu Forms od naszej biblioteki, będzie on dostępny z menu Views na liście. No to od słów do czynu. Konwertujemy List View Web Part, zapisujemy zmiany i otwieramy View na stronie MOSS. Niestety, od razu czeka nas niemiła niespodzianka. Mianowicie nasz link przestał działać! Teraz zamiast renderowania raportu w Excel Services, pojawia nam się śliczne okienko z zapytaniem czy ściągnąć dokument, otworzyć go czy anulować operację.

Dzieje się tak, gdyż SharePoint Designer konwertuje nasz tag <A> do następującej postaci:

<A onfocus="OnLink(this)" HREF="{@FileRef}" onclick="return DispEx(this,event,'',
'', '', '', '{ddwrt:ListProperty(&quot;DefaultItemOpen&quot;)}'
, '{ddwrt:MapToControl(&quot;&quot;, string())}'
, '{@HTML_x0020_File_x0020_Type}',''
, '{ddwrt:GetUserID('CheckoutUser')}','{$Userid}'
, '{ddwrt:ListProperty(&quot;ForceCheckout&quot;)}'
, '{$FieldIDAY3AFD}'
, '{ddwrt:CurrentRights()}')" >...</A>

Od razu można zauważyć iż nie korzystamy z usług transformacyjnych, a parametr strServerFileRedirect nie jest nawet podany. Niestety, nie tylko to się dzieje. Jak otworzymy sobie nasz widok za pomocą podglądu źródła strony zobaczymy, że na stronie wygląda to tak:

<A onfocus="OnLink(this)" HREF="/OddsOn/ReportsLibrary/Report.xlsx" 
onclick="return DispEx(this,event, '', '', '', '', '', '', ''
,'', '', '2', '', '0', '7FFFFFFFFFFFFFFF')" >Report</A>

Tak jak już wiemy, część parametrów nie trzeba podawać gdyż MOSS się sam nimi zajmie, jednak część trzeba podać. Do nich na pewno możemy zaliczyć pierwsze 10 parametrów.

Jednak nic straconego ;) wystarczy, że kod za pomocą SharePoint Designer zamienimy na:

<A onfocus="OnLink(this)" HREF="/OddsOn/ReportsLibrary/Report.xlsx" onclick="return DispEx(this, event, 'TRUE', 'FALSE', 'FALSE', 'SharePoint.OpenDocuments.3', '1'
, 'SharePoint.OpenDocuments', ''
, '1http:u002fu002fladsharepointu002fOddsOnu002f_layouts
u002fxlviewer.aspx?
id={@ServerUrl}', '{ddwrt:GetUserID('CheckoutUser')}', '{$Userid}', 
'0', '{$FieldIDATD1BB}', '{ddwrt:CurrentRights()}')" >Report</A>

I wszystko będzie nam śmigać :) Zwróćcie uwagę na link w strServerFileRedirect, jako że musicie go dopasować do swojego adresu.

PS.: Jeżeli się pobawicie różnymi kolumnami, to zobaczycie, że tych Bugów jest więcej. Na przykład, jeżeli wykorzystacie kolumnę Name linked to report to po konwersji będziecie mieli taki błąd:

Jeżeli zaś wykorzystanie kolumnę Edit (czyli link do edycji elementu), to nawet nie uda wam się poprawnie przekonwertować widoku.