dpsidebar - programowanie w windows cz.3

Wszystko wskazuje na to, że seria o dpsidebar będzie pierwszą i być może nawet nie ostatnią serią wpisów, które na łamach DP.pl dokończę... Cóż, czas ucieka, więc biorę się do pisania. W poprzedniej części obiecałem, że zajmę się settingsami i flyoutami. Do dzieła!

Settings

Jak już wcześniej wspominałem, settings to osobna strona, która tak naprawdę jest szablonem, który tylko w niewielkim stopniu możemy modyfikować. Za to dużo ciekawiej robi się, gdy popatrzymy na możliwości settingsów. Przede wszystkim obiekt System.Gadget.Settings posiada cztery metody do zapisywania i odczytywania ustawień. Są to read, readString, write, writeString. Metody te jednak zapisują ustawienia tylko tymczasowo, to znaczy na czas działania gadgetu. Innymi słowy - po restarcie ustawienia się stracą. DPSidebar będzie jednak korzystał z pliku z konfiguracją, wobec tego nie będziemy się musieli przejmować ograniczeniami tych metod.

Komunikacja między settingsami (flyoutami także, do czego dojdziemy) może komunikować się z nadrzędnym ciałem gadgetu przez obiekt System.Gadget.document.parentWindow. HTML jest bardzo prosty - zwykła tabelka z dwoma kolumnami i rzędami. Javascript również jest prosty:

function int()
			{
				
				if(System.Gadget.document.parentWindow.cfg.show_avatars == "true")
				{
					$("#show_avatars").attr("checked", true);
				}
				else
				{
					$("#show_avatars").attr("checked", false);
				}
				$("#refresh").val(System.Gadget.document.parentWindow.cfg.refresh);
			}
				System.Gadget.onSettingsClosing = SettingsClosing;
				function SettingsClosing(event)
				{
					$("#settings").val($("#show_avatars").val());
					if (event.closeAction == event.Action.commit)
					{
						System.Gadget.document.parentWindow.cfg.loadFile();
						if($("#show_avatars").attr("checked") == "checked")
						{
							System.Gadget.document.parentWindow.cfg.show_avatars = true;
							
						}
						else
						{
							System.Gadget.document.parentWindow.cfg.show_avatars = false;
						}
						System.Gadget.document.parentWindow.cfg.refresh = $("#refresh").val();
						
						System.Gadget.document.parentWindow.cfg.saveFile();
						System.Gadget.document.parentWindow.init();
					}
					event.cancel = false;
				}

W kodzie może być nieoczywiste tylko skorzystanie z eventu onSettingsClosing. Odpalany jest on oczywiście w momencie zamykania settingsów. Są tylko trzy znane światu metody na zamknięcie settingsów. Kliknięcie OK, kliknięcie Anuluj i zamknięcie procesu sidebar.exe. Ostatni nie będziemy brać pod uwagę. Pierwsza dwa pozwalają za to zdecydować, czy należy zapisać dane wprowadzone, czy należy je zignorować. Obiekt System.Gadget.Settings.ClosingEvent posiada parametr Action, który przyjmuje dwie wartości: commit i cancel. Weryfikujemy więc czy dostaliśmy commit i zapisujemy w obiekcie nadrzędnym ustawienia korzystając z obiektu cfg. I to wszystko co robimy w settingsach.

Flyout

Flyout to element gadgetu, który "dokleja" się do głównego ciała i pozwala na wyświetlenie dodatkowych danych. Zgodnie z naszymi wymaganiami biznesowymi należy dynamicznie usuwać kolejne artykuły z monitoringu oraz wyświetlanie pełnej wersji komentarza. Oba te wymagania zrealizujemy właśnie przez flyout.

Flyout może być zupełnie osobnym bytem, posiadającym w 100% niezależną strukturę. Jednak dla nas będzie to zupełnie zbędne. Przy pomocy obiektu System.Gadget.Flyout.document będziemy wstrzykiwać do struktury DOM flyouta nasze treści. Utworzyłem sobie dwie proste funkcje by wyświetlić pełnego newsa oraz zarządzać monitorowanymi adresami:

unction getFullComment(comment_id)
			{
				
				if(System.Gadget.Flyout.show) // Flyout juz jest wyswietlony.
				{
					System.Gadget.Flyout.document.getElementById("flyout_div").innerHTML = dpsidebar.createFullComment(comments[comment_id]);
					$(System.Gadget.Flyout.document.body).height($(System.Gadget.Flyout.document.getElementById("wrapper")).height()+45+"px");
				}
				else
				{
					System.Gadget.Flyout.show = true;
					oFlyoutDocument = System.Gadget.Flyout.document;
					System.Gadget.Flyout.onShow = function() 
					{
						System.Gadget.Flyout.document.getElementById("flyout_div").innerHTML = dpsidebar.createFullComment(comments[comment_id]);
						$(System.Gadget.Flyout.document.body).height($(System.Gadget.Flyout.document.getElementById("wrapper")).height()+45+"px");
					}
				}
			}
			
			function manage_urls()
			{
				body = dpsidebar.createURLView(cfg.urls);
				if(System.Gadget.Flyout.show) // Flyout juz jest wyswietlony.
				{
					System.Gadget.Flyout.document.getElementById("flyout_div").innerHTML = body;
					$(System.Gadget.Flyout.document.body).height($(System.Gadget.Flyout.document.getElementById("wrapper")).height()+45+"px");
				}
				else
				{
					System.Gadget.Flyout.show = true;
					oFlyoutDocument = System.Gadget.Flyout.document;
					System.Gadget.Flyout.onShow = function() 
					{
						System.Gadget.Flyout.document.getElementById("flyout_div").innerHTML = body;
						$(System.Gadget.Flyout.document.body).height($(System.Gadget.Flyout.document.getElementById("wrapper")).height()+45+"px");
					}
					System.Gadget.Flyout.onHide = function() 
					{
						cfg.saveFile();
						rotate();
					}
				}
			}

Obie sprawdzają w pierwszej kolejności czy flyout nie jest już czasem wyświetlony, jeśli nie jest podmienia w divie flyout_div treść. Gdyby jednak nie był wyświetlony- wyświetla go (System.Gadget.Flyout.show = true;) oraz w evencie onShow dodaje treść. Zmienia także dynamicznie jego wysokość (tak by wyglądało to nawet-nawet). Mam nadzieję, że nie ma tu dużo do tłumaczenia...

Wspomniana wcześniej komunikacja Flyoutu z ciałem gadgetu odbywa się przy okazji usuwania wpisów z listy monitorowanych. Po kliknięciu ikonki minusika obok skróconego tytułu uruchamiana jest funkcja, która ukrywa element na liście, odpala funkcję rotate() z ciała gadgetu i w końcu zamyka sam flyout. Proste...

Rotate

Rotate to metoda, która odpalana jest przez funkcje setInterval, dzięki czemu możemy odświeżać kontent ciałą gadgetu bez jego całkowitego przeładowywania oraz możemy respektować czas zdefiniowany przez użytkownika.

function rotate()
			{	
				var alarm = false;
				$("#comments").empty();
				var now = new Date();
				$("#last_update").html(now.toLocaleString());
				cfg.loadFile();
				if(cfg.refresh == "")
				{
					cfg.createFile();
					cfg.loadFile();
				}
				for(i in cfg.urls)
				{
					dpsidebar.getPage(cfg.urls[ i ].url);
					commentObj = dpsidebar.getCommentObject(cfg.urls[ i ].url);
					dpsidebar.putComment(commentObj, cfg.show_avatars);
					comments[commentObj.comment_id] = commentObj;
					if(!alarm)
					{
						if(commentObj.comment_id > cfg.urls[ i ].last_comment)
						{
							alarm = true;
						}
					}
					cfg.urls[ i ].last_comment = commentObj.comment_id;
					cfg.urls[ i ].title = commentObj.title;
					dpsidebar.clear();
				}
				cfg.saveFile();
				if(alarm)
				{
					var oBackground = document.getElementById("imgBackground");
					oBackground.src = "url(img/background_n.png)";
				}
				else
				{
					var oBackground = document.getElementById("imgBackground");
					oBackground.src = "url(img/background.png)";
				}
				$("body").height($("#wrapper").height()+"px");
}			

Funkcja ta także weryfikuje, czy komentarz, który właśnie wyświetla nie jest nowy i nie trzeba odpalić informacji (wymaganie biznesowe związane z informacjami o nowym komentarzu).

Realizacja

Mając mnóstwo teorii/praktyki (w zasadzie nie wiem jak to określić...) za sobą czas wrócić do teorii tworzenia aplikacji. Przypomnę, że skończyliśmy w zasadzie na tworzeniu makiet. Po ich utworzeniu zespoły tworzące CSS, JS, HTML (najczęściej to jeden zespół) oraz część backendową (czy to będzie PHP, czy inny język) mogą przystąpić do kodowania. Zespół testerów posiadając informacje o wymaganiach biznesowych może zacząć tworzyć przypadki testowe, a nawet (jeśli jest to w ich kompetencjach) testy jednostkowe przy ścisłej współpracy z zespołami deweloperskimi. W sytuacji idealnej (więc w zasadzie niemożliwej) okaże się, że zespół testerów, który przetestował wersję alfa aplikacji nie zgłosił żadnych błędów, wówczas wersja beta powinna trafić do biznesu celem jej akceptacji. Wersja beta powinna być uruchomiona na środowisku odwzorowującym rzeczywiste środowisko na jakim ostatecznie działać będzie aplikacja. Idąc dalej ścieżką sytuacji idealnych biznes nie zgłosi poprawek i wersja trafi na produkcję.

W rzeczywistości najczęściej jest jednak tak, że biznes zastrzeżenia ma do wszystkiego, od zaakceptowanych pierwotnie makiet, po realizację kodu.

Linkownia

Developing a Gadgets (MSDN) JQuery DPSidebar zipowany Tak tylko, jakby ktoś chciał sobie coś poprawić. DPSidebar gotowy do instalacji

PostScriptum

Być może po skończeniu konkursu z diodą redakcja pozwoli mi opisać jak należałoby zmienić dpsidebar, by monitorował świecenie diody?