Zine.net online

Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc
w Szukaj

dev2dev

Zrób to sam – SSMS addin (Exec)

 

W poprzednim odcinku pokazałem jak stworzyć szkielet menu do SSMS. W tym odcinku pokażę, jak stworzyć uniwersalny schemat wywoływania poleceń powiązanych z menu naszej wtyczki.

Można by od biedy zastosować taki prosty schemat:

image

gdzie zastosowanych zostanie tyle “if-ów” ile jest poleceń w naszym menu. Ale to rozwiązanie jest bardzo mało eleganckie.

Aby stworzyć mechanizm automatycznie dopasowujący elementy menu z elementami wykonawczymi należy zauważyć, że:

  • polecenie może być wywołaniem metody z klasy NextAddin.Connect (czyli z klasy macierzystej) lub wywołaniem jakiejś metody z innej klasy (najczęściej byłoby to okienko dialogowe, tak więc byłaby to metoda ShowDialog),
  • polecenie może wymagać określenia domyślnej bazy danych lub może też być wykonane bez kontekstu bazy danych lub w kontekście bazy master.

Aby sprostać pierwszemu warunkowi należałoby przyjąć, że metoda lub klasa obiektu będące przedmiotem wykonania polecenia z menu nazywają się dokładnie tak jak identyfikator menu.

Aby sprostać drugiemu warunkowi należałoby stworzyć atrybut, który miałby zastosowanie do metod i do klas i określałby czy do wykonania polecenia konieczny jest domyślny kontekst określonej bazy danych. Domyślny kontekst bazy danych został opisany w odcinku o ObjectExplorer.

Całość należałoby obsłużyć przy pomocy Reflection.

Zaczniemy od atrybutu określającego, czy wykonanie polecenia z menu wymaga kontekstu domyślnej bazy danych:

image

Od obiektów, które będą tworzone do wykonania poleceń z menu wtyczki będziemy wymagali, że będzie implementował publiczny interfejs, zapewniający, że obiekt ten będzie realizował metodę get zwracającą polecenie T-SQL dla wykonania jako query w SSMS. Czyli:

image

Ostatecznie metody ResetAddin i UninstallAddin miałyby atrybut DbRequired ustawiony na false ponieważ nie wymagają do swego wykonania domyślnej bazy danych:

image

Natomiast okno dialogowe do utworzenia message type dla Service Broker miałoby ten atrybut ustawiony na true ponieważ wymaga określenia domyślnej bazy danych:

image

Aby jeszcze bardziej zautomatyzować cały proces należałoby dokonać jednej zmiany w definicji stałych do menu:

private string CREATE_MESSAGE_TYPE_NAME = typeof(Dialogs.create_message_type).Name;

Jak widać, CREATE_MESSAGE_TYPE_NAME zmieniło się z private const string na private string, ale dzięki temu identyfikator menu jest obecnie powiązany z nazwą klasy reprezentującej okno dialogowe. Ale ponieważ nasza wtyczka już została osadzona w SSMS, wobec tego menu nie będzie ponownie inicjowane a wobec tego ten element menu będzie miał nadal stary identyfikator, pomimo, że kod wtyczki ma już nowy identyfikator. I w tym momencie przychodzi na z pomocą opisane wcześniej polecenie resetowania menu wtyczki. Po wykonaniu tego polecenia menu ma nowy identyfikator zgodny z nazwą klasy okienka dialogowego powiązanego z elementem menu.

Przy tych założeniach kod obsługi polecenia wymagający obsługi okna dialogowego byłby następujący:

image

image

image

Natomiast kod obsługi polecenia, które wymaga wywołania metody z klasy macierzystej wtyczki wygląda następująco:

image

image

Mając taki kod możemy już wywołać z naszej wtyczki polecenie utworzenia nowego typu komunikatu w Service Broker:

image

A po naciśnięciu klawisza OK…

image

W następnym odcinku opiszę jak tworzyć dokowane okna, które dynamicznie dopasowują swoja zawartość do zmiennego kontekstu ObjectExplorer.

Linki:

do poprzedniego odcinka serii o tworzeniu wtyczki do SSMS

do następnego odcinka serii o tworzeniu wtyczki do SSMS

Opublikowane 22 października 2009 18:41 przez marekpow

Komentarze:

 

dotnetomaniak.pl said:

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

października 22, 2009 20:42
Komentarze anonimowe wyłączone
W oparciu o Community Server (Personal Edition), Telligent Systems