https://www.pexels.com/photo/schedule-planning-startup-launching-7376/

Sterownik Domowy – dalsze prace

W dniu dzisiejszym rozpoczyna się 10 tydzień trwania konkursu Daj się poznać 2017. Biorąc pod uwagę, że wystartowałem od samego początku, czyli od 1 marca, oznacza to dla mnie, że pozostał tylko jeden obowiązkowy post do osiągnięcia regulaminowego minimum (tzn. ten i jeden następny).

Tym razem będzie inaczej niż zwykle, bo nie będę zamieszczał wielu listingów kodu. Co prawda mam już jakiś wstępny zarys tego, co chcę osiągnąć, ale póki co są to wstępne założenia realizacji funkcjonalności, prosty prototyp będący kodem spagetti, który nie powinien ujrzeć światła dziennego. 🙂 W ramach tego wpisu przedstawię jedynie koncepcję, nad którą teraz pracuję. Natomiast jeśli chodzi o stronę programistyczną, muszę poświęcić trochę czasu na poszerzenie wiedzy z zakresu wzorców, dobrych praktyk oraz sposobów pisania kodu w JavaScript. Mam na oku książkę „JavaScript. Wzorce” (Stoyan Stefanov), którą chcę przejrzeć korzystając z długiego weekendu majowego i która mam nadzieje powie mi coś więcej, jak dobrze pisać w JS. Moje próby z JavaScriptem oczywiście są wrzucone na GitHuba, gdyby ktoś miał ochotę się temu przyjrzeć i dać poradę. :]

Na początku przygody z DSP2017 ze znakiem zapytania wymieniłem CoffeeScript jako narzędzie, które rozważałem wykorzystać. Finalnie nie zdecydowałem się na tą technologię, bo.. jak zasłyszałem, po prostu nie przyjęła się zbytnio i są aktualnie lepsze alternatywy w postaci języków kompilowanych do JS, jak np. TypeScript, z którego mam zamiar w niedalekiej przyszłości się podszkolić, przy okazji nauki Angular 2/4+. Miałem o tym wspomnieć już przy okazji poprzedniego wpisu, ale wyleciało mi z głowy, więc piszę o tym teraz. 🙂

Wracając do projektu, jaki jest stan obecny i najbliższe plany? W aplikacji funkcjonuje już możliwość dodawania nowych sensorów oraz pomieszczeń. Jest również opcja wyświetlania list wszystkich elementów w obu tych grupach. W dalszym ciągu zajmuję się konfiguracją systemu, a pierwsze co powinienem teraz zrobić to wprowadzić możliwość ustalenia lokalizacji wybranego sensora. Nie będzie to czynność wykonywana na co dzień, a jedynie przez administratora systemu podczas pierwszej konfiguracji lub w przypadku dodania nowego elementu. Z perspektywy użytkownika taka możliwość będzie dostępna z poziomu listy czujników, tuż obok opcji edycji i kasowania.

Widok z listą zainstalowanych w systemie sensorów
Widok z listą zainstalowanych w systemie sensorów

W momencie, gdy użytkownik będzie chciał rozmieścić sensor lub zmienić jego wcześniej ustawioną lokalizację, zostanie przeniesiony do widoku z rzutem mieszkania, gdzie klikając w wybranym miejscu, rozmieści konfigurowany element. Poniżej, na prostym prototypie, możecie zobaczyć jak wstępnie to sobie wyobraziłem.

Widok z elementem canvas, umożliwiającym rozmieszczenie wybranego sensora
Widok z elementem canvas, umożliwiającym rozmieszczenie wybranego sensora

Podczas dodawania nowego sensora administrator systemu wybiera m. in. nazwę pomieszczenia, w którym nowy element będzie fizycznie zainstalowany. W kolejnym kroku, czyli w momencie jego rozmieszczania na planie mieszkania chciałbym wprowadzić dodatkowe ograniczenie korzystające z tej informacji. Możliwa lokalizacja sensora powinna być ograniczona tylko do pomieszczenia, które było wybrane podczas operacji dodawania. Aby to zrealizować, będą potrzebne dodatkowe zmiany wokół modelu pomieszczenia, gdzie będę musiał dodać możliwość ustawienia zajmowanego przez nie obszaru. To jest jednak dalszy plan i zapewne wrócę do niego w kolejnych wpisach.

Jeśli chodzi o sytuację obecną i kod, to co mogę pokazać na tą chwilę to miejsce osadzenia elementu <canvas> w szablonie disposeSensor.scala.html. Nie jestem jednak z tego specjalnie zadowolony, bo na pewno stosuje się lepsze rozwiązania, które umożliwią odczytanie przez kod JS parametrów przekazanych przez serwer do widoku. Mam na myśli dwa elementy <div> oznaczone klasą hidden, z których za pomocą JavaScriptu pobieram numer ID oraz typ aktualnie konfigurowanego sensora. Na pewno mógłbym tutaj wykorzystać np. cookies czy localStorage i prawdopodobnie tak to się niedługo skończy, chyba, że ktoś podpowie mi lepsze rozwiązanie! 🙂

@(message: String)(sensor: Sensor)
 
@scripts = {
    <script src="@routes.Assets.versioned("javascripts/disposeSensor.js")" type="text/javascript"></script>
}
 
@main("Home Controller", scripts) {
    <div id="sensorId" class="hidden">@sensor.id</div>
    <div id="sensorType" class="hidden">@sensor.sensorType.sensorType</div>
        Wybierz lokalizację sensora: @sensor.sensorType.sensorType (@sensor.room.name)
    <canvas id="appartmentPlan" width="945" height="500">Wymaga się nowszej przeglądarki</canvas>
}

Na koniec chciałem wspomnieć o jednym irytującym problemie, z którym zmagam się raz na jakiś czas podczas pracy z Play Framework w Netbeans. Mianowicie po niektórych zmianach w szablonach widoku, po odświeżeniu strony pojawia się strona z błędem NullPointerException. Nie wiem co może być przyczyną, natomiast naprawa problemu sprowadza się do wykonania Clean and build project, a następnie ponowne uruchomienie, czyli Run Project. Prawda, że irytujące?

Irytujący błąd NullPointerException
Irytujący błąd NullPointerException

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *