Tworzenie widgetów niestandardowych jest łatwiejsze przy użyciu produktów Rational Application
Developer lub Integration Designer.
Zanim rozpoczniesz
Programowanie widgetów wymaga znajomości następujących zagadnień:
W zależności od funkcji realizowanych przez tworzone widgety może być potrzebna znajomość następujących zagadnień:
- Język programowania lub skryptowy umożliwiają tworzenie widgetów, jeśli nie jest używany język JavaScript z pakietem Dojo
- Java™ 2 Enterprise Edition (J2EE)
- Representational State Transfer (REST)
Przed rozpoczęciem należy skonfigurować środowisko programistyczne, instalując następujące oprogramowanie:
- Rational Application
Developer w wersji 7.5.4 lub nowszej bądź Integration Designer w wersji 7.0 lub nowszej. Kroki wykonywane podczas programowania widgetów przy użyciu produktu Integration Designer są takie same, jak w przypadku produktu Rational Application
Developer.
- Jeśli planowane jest testowanie widgetów, należy zainstalować komponent Business Space albo zapewnić dostęp do autonomicznego serwera aplikacji z profilem zawierającym aplikacje Business Space.
Po zaprogramowaniu i przetestowaniu widgetu na serwerze autonomicznym można wdrożyć go w klastrze, wykonując instrukcje opisane w sekcji Nieaktualne: Pakowanie i wdrażanie widgetów niestandardowych.
O tym zadaniu
Aby uzyskać dodatkowe informacje o strukturze widgetu, można zbadać pliki znajdujące się w archiwum
stockdeploy.zip. Można również zbadać zawartość ważnych plików wymienionych w tej procedurze, takich jak definicja widgetu iWidget, aby zapoznać się z prostymi przykładami kodowania trybów.
Procedura
- Korzystając z perspektywy WWW, utwórz dynamiczny projekt WWW na potrzeby widgetu niestandardowego i przypisz ten projekt do archiwum EAR. Dynamiczny projekt WWW zostaje odwzorowany w archiwum WAR podczas eksportowania archiwum EAR.
Wskazówka: jeśli planowane jest, aby widget odnajdywał swoje zasoby przy użyciu swojego kontekstowego katalogu głównego, należy zanotować kontekstowy katalog główny na potrzeby aplikacji WWW.
Można zachować domyślny lub go zmienić. Kontekstowy katalog główny można zmienić na następnej stronie kreatora.
- W katalogu WebContent projektu (tworzonego automatycznie jako część projektu WWW) utwórz strukturę katalogów, w której umieszczony ma zostać kod widgetu. W strukturze katalogu WebContent umieszcza się możliwe do wdrożenia zasoby widgetu, takie jak pliki HTML i JSP. Wszystkie zasoby umieszczone poza strukturą katalogu WebContent nie są wdrażane. Są to takie zasoby, jak pliki Java i SQL.
Wskazówka: typowe widgety mają następującą strukturę: iWidget/widgets/nazwa_widgetu.
Można użyć tej ścieżki dla zachowania spójności lub można zbudować własną strukturę.
- W katalogu widget utwórz plik definicji widgetu iWidget na potrzeby widgetu niestandardowego. Upewnij się, że identyfikator widgetu iWidget jest unikalny i że zasięg iScope jest zgodny z nazwą klasy języka JavaScript definiującej zachowanie widgetu. Informacje na ten temat można znaleźć w sekcji Creating iWidgets (Tworzenie widgetów iWidget) w pomocy do produktu Rational Application Developer.
Wskazówka: nazwa pliku definicji widgetu jest zgodna z następującą konwencją nazewnictwa: nazwa_widgetu_iWidget.xml.
- Za pomocą edytora widgetów iWidget zdefiniuj widget, określając następujące informacje:
- Tryby obsługiwane przez widget i dane lub kod dla każdego trybu.
Zdefiniowanie trybu view jest konieczne, aby możliwe było wyświetlanie informacji. Aby umożliwić użytkownikom modyfikowanie treści widgetu (za pomocą pozycji menu Edytuj ustawienia), należy dodać tryb edit. Tryb edit pozwala na zmiany atrybutów (ustawień) widgetu w warstwie Atrybut instancji.
Aby umożliwić niektórym użytkownikom (zwykle tylko administratorom) modyfikowanie wartości domyślnych widgetu, należy dodać tryb config.
Tryb config pozwala zmieniać atrybuty widgetu w warstwie Administrowanie. Aby umożliwić użytkownikom personalizowanie sposobu wyświetlania danych przez widget oraz aby móc stosować tę zmianę tylko do poszczególnych użytkowników, należy dodać tryb personalize. Tryb personalize pozwala zmieniać atrybuty widgetu w warstwie Użytkownik. Informacje na temat warstw atrybutów i sposobów ich działania zawierają sekcje Nieaktualne: Warstwy atrybutów widgetu i Nieaktualne: Obsługa konfigurowania i personalizowania widgetu.
- Atrybuty widgetu, dodając zestaw elementów i poszczególne elementy w zestawie. Atrybuty te udostępniają wartości domyślne widgetu. Jeśli na przykład widget wyświetla serwis WWW, należy dodać atrybut url umożliwiający zapisanie adresu URL.
Wartości są zapisywane w postaci łańcuchów, dlatego w implementacji może być konieczne ich odpowiednie przekształcenie.
Należy upewnić się, że uwzględniony został atrybut umożliwiający obsługę każdego ustawienia lub każdej personalizacji, które użytkownicy mogą wprowadzić do widgetu. Jeśli na przykład widget zawiera tabelę i użytkownik może określić kolumnę, według której sortowane są informacje znajdujące się w tej tabeli, można określić atrybut sort_column pozwalający na zapisanie tej informacji.
- Definicja i opis każdego zdarzenia publikowanego i obsługiwanego przez widget.
- Ścieżka względna i nazwa pliku, który deklaruje zasięg iScope (dodana jako zasób). Zasięg iScope jest klasą Dojo, stanowiącą punkt wejścia do klasy iContext w czasie wykonywania. Ten punkt wejścia jest częścią widgetu, która współdziała ze środowiskiem za pośrednictwem klasy iContext. Klasa iContext jest klasą centralną środowiska wykonawczego widgetów, która udostępnia wszystkie usługi środowiskowe, takie jak dostęp do zmiennych globalnych, stan współużytkowany, pamięć zmiennych lokalnych, komunikacja widgetów przy użyciu zdarzeń, usługi zdalne, obsługa trybów i wiele innych możliwości.
W tym przypadku plik znajduje się w tym samym katalogu, co definicja widgetu, więc nie ma potrzeby uwzględniania ścieżki.
- Ścieżka względna i nazwa każdego innego pliku używanego przez widget (dodane jako zasoby). Jeśli na przykład widget używa pliku .css na potrzeby formatowania, należy dodać ścieżkę i nazwę tego pliku jako zasób.
Podczas dodawania zasobów należy jednak pamiętać, że zbyt duża liczba żądań zasobów wpływa na wydajność, i kod powinien odwoływać się do jak najmniejszej liczby plików JavaScript, CSS i plików obrazów. Podczas projektowania widgetu należy rozważyć zastosowanie takich technik, jak obrazki przemieszczalne, łączenie oraz minimalizowanie plików JavaScript i CSS, jak również opóźnione ładowanie zasobów (na przykład oczekiwanie na załadowanie zasobów na potrzeby trybu edit do momentu wystąpienia zdarzenia onEdit).
Kod lub dane można również dodać bezpośrednio do pliku XML za pomocą karty Źródło. Więcej informacji na temat definicji widgetu i jego elementów oraz kontekstu iContext można znaleźć w specyfikacji iWidget 2.1.
- Utwórz plik JavaScript, który deklaruje zasięg iScope, a następnie rozpocznij definiowanie zasięgu iScope, identyfikując jego interfejs. Utwórz implementację widgetu za pomocą języka JavaScript lub dowolnego innego języka programowania bądź skryptowego. Kontynuuj opracowywanie zasięgu iScope równolegle z programowaniem implementacji widgetu.
Wskazówka: jeśli widget jest prosty, a do jego implementacji używany jest język JavaScript, można utworzyć implementację widgetu w samym pliku zasięgu iScope.
- Utwórz procedury obsługi na potrzeby trybów dodanych w definicji widgetu iWidget i różnych zdarzeń zdefiniowanych w interfejsie, w tym predefiniowanych zdarzeń ze specyfikacji iWidget. Na potrzeby poniższych zdarzeń iEvent (określonych w specyfikacji iWidget) istnieją domyślne procedury obsługi zdarzeń, które w razie potrzeby można przesłonić:
- onLoad - wywoływana, gdy widget jest ładowany po raz pierwszy oraz podczas odświeżania przeglądarki. W tej procedurze obsługi widget może inicjować swój widok początkowy. To zdarzenie nie ma ładunku.
Wartości elementu można pobrać za pomocą kodu podobnego do następującego:
var att = this.iContext.getiWidgetAttributes();
this.name = att.getItemValue("name");
- onReload - wywoływana podczas przeładowywania widgetu. Ta procedura obsługi zdarzeń jest podobna do onLoad, ale jest wywoływana w trochę innych okolicznościach. Gdy użytkownik pracuje w trybie edit (edycja) i wybiera jeden z przycisków znajdujących się u dołu okna ustawień, procedura obsługi zdarzeń onReload jest wywoływana, kiedy odświeżany jest tryb view (wyświetlanie). To zachowanie różni się trochę do wymagań specyfikacji iWidget, ponieważ specyfikacja ta wzywa do wywołania tego zdarzenia przed przeładowaniem, a nie podczas odświeżania zawartości widgetu iWidget w trybie edit.
To zdarzenie nie ma ładunku.
- onUnload - wywoływana, gdy widget ma zostać usunięty z pamięci. To zdarzenie nie ma ładunku.
Ważne: należy zapewnić, aby wszystkie widgety Dojo utworzone przez użytkownika były czyszczone w trakcie wykonywania tej procedury obsługi zdarzeń. Należy wywołać metodę <widget>.destroyRecursive(), aby zapewnić wyczyszczenie pamięci po wszystkich widgetach potomnych Dojo.
- onRefreshNeeded - wywoływana po stwierdzeniu przez kontekst iContext, że dane widgetu są przestarzałe. To zdarzenie powinno sygnalizować widgetowi iWidget ewentualną konieczność odświeżenia danych.
- Dla każdego trybu określonego przez atrybut supportedModes w definicji widgetu utwórz procedurę obsługi trybu. Jeśli na przykład widget może działać w trybach view i edit, należy utworzyć metody onView i onEdit.
Metodę onView można zakodować w następujący sposób:
onView: function(){
...
}
- Utwórz procedurę obsługi zdarzenia onSizeChanged. Zdarzenie ma ładunek zawierający wartości atrybutów newWidth i newHeight.
Procedura obsługi używa tych informacji w celu zmiany wielkości widgetu na określoną szerokość i wysokość. Po zminimalizowaniu widgetu przez użytkownika, atrybuty te przyjmują wartości 0.
W poniższym kodzie przedstawiono sposób użycia procedury obsługi onSizeChanged:
onSizeChanged: function(iEvent) {
var data = iEvent.payload;
if (data) {
alert("new height: " + data.newHeight);
alert("new width: " + data.newWidth);
}
}
- Opcjonalne: jeśli widget uzyskuje dostęp do danych przy użyciu interfejsów REST API, użyj w kodzie identyfikatorów URI, jak w następującym przykładzie:
dojo.xhrGet({
url: this.iContext.io.rewriteURI(uri),
load: handler
});
Podobne podejście można zastosować w przypadku działań HTTP, takich jak PUT, POST i DELETE.
- Utwórz pliki obrazów podglądu i ikon widgetu niestandardowego i umieść je w dowolnym miejscu w katalogu WebContent. Obraz ikony powinien mieć wielkość 28 x 28 piksli, natomiast obraz podglądu powinien mieć szerokość 160 piksli i wysokość 128 piksli.
- Opcjonalne: jeśli widget niestandardowy ma być wyposażony w pomoc elektroniczną, utwórz jeden lub więcej plików HTML z tekstem pomocy. Pliki te można spakować z widgetem lub można utworzyć wtyczkę dokumentacji i umieścić w niej te pliki pomocy. Informacje na ten temat zawiera sekcja Nieaktualne: Tworzenie wtyczki dokumentacji.
- Aby zarejestrować widget niestandardowy, utwórz definicję tego widgetu w pliku katalogu. Można umieścić wpis w istniejącym pliku katalogu lub można utworzyć własny plik katalogu.
Informacje na temat tworzenia pliku katalogu i definicji rejestracji widgetu zawiera sekcja Nieaktualne: Rejestrowanie widgetów niestandardowych przy użyciu plików katalogu.
Jeśli tworzony jest plik katalogu, należy umieścić go w katalogu catalog poza katalogiem WebContent.
Wskazówka: nazwa pliku rejestracji widgetu jest zgodna z następującą konwencją nazewnictwa: catalog_nazwa_katalogu.xml.
- Spakuj i wdróż widget niestandardowy. Jeśli profil zawierający aplikacje BSpace* nie jest lokalny, należy użyć narzędzia wsadmin na serwerze aplikacji w sposób opisany w sekcji Nieaktualne: Pakowanie i wdrażanie widgetów niestandardowych. Aplikacje BSpace* zawierają kod środowiska na potrzeby
portalu Heritage Process Portal.
Jeśli profil jest lokalny, można uruchomić komendy w obrębie środowiska programistycznego, wykonując następujące kroki:
- Wyeksportuj katalog catalog do pliku JAR i określ dla tego pliku rozszerzenie .zip. Plik katalogu musi znajdować się w tym pliku .zip w katalogu catalog.
- Utwórz katalog zawierający pakiet i skrypt wdrażający. Upewnij się, że katalog skryptu nie znajduje się w katalogu WebContent, ani w żadnym jego katalogu podrzędnym.
- Utwórz plik skryptowy w języku Jython w katalogu skryptów i nadaj mu nazwę podobną do następującej: installBSpaceWidget.py.
- Przeprowadź edycję pliku skryptowego, dodając następujący kod:
AdminTask.installBusinessSpaceWidgets('[-nodeName nazwa_węzła -serverName nazwa_serwera -widgets ścieżka/plik_katalogu.zip]')
- Zapisz plik i zamknij go.
- W widoku eksploratora kliknij prawym przyciskiem myszy ten skrypt i wybierz opcję .
- W oknie Edycja konfiguracji dodaj następujące informacje:
- Na potrzeby środowiska wykonawczego skryptów określ typ serwera aplikacji.
- Określ nazwę profilu zawierającego aplikacje BSpace*.
- Jako argumenty komendy wsadmin wpisz łańcuch -conntype NONE.
- Jeśli włączone są zabezpieczenia, określ identyfikator użytkownika i hasło.
Postęp wykonywania skryptu można śledzić w widoku Konsola. W zależności od używanego serwera wykonanie skryptu może zająć kilka minut.
- Przetestuj widget, wykonując następujące kroki:
- W widoku Serwer kliknij prawym przyciskiem myszy i wybierz opcję Nowy.
- Za pomocą kreatora Nowy serwer utwórz widok wskazujący profil, który zawiera aplikacje BSpace*.
- Dodaj projekt EAR danego widgetu do utworzonego serwera. Po połączeniu środowiska programistycznego z aplikacjami BSpace* można przetestować i wdrożyć widget. Nie trzeba ponownie pakować i wdrażać widgetu, gdy nie są wprowadzane zmiany w pliku katalogu ani we wtyczce jego dokumentacji.
- Za pomocą przeglądarki WWW przejdź do adresu URL portalu
Heritage Process Portal. Adres URL będzie podobny do następującego: http://localhost:9080/BusinessSpace.
- Zaloguj się do portalu Heritage Process Portal, a następnie
przetestuj widgety.
Wyniki
Jeśli po zakończeniu programowania i testowania widgetu niestandardowego planowane jest jego wdrożenie na innym serwerze lub w innym klastrze, należy wyeksportować archiwum EAR i plik katalogu danego widgetu. Następnie można wdrożyć widget, wykonując instrukcje opisane w sekcji
Nieaktualne: Pakowanie i wdrażanie widgetów niestandardowych.