PlayFramework - drugie spotkanie i scenariusz nauki

Gdy coś się dzieje po raz drugi to już trudniej nazwać to coś tymczasową anomalią. I w ten sposób - ku mej uciesze - warsztaty z Playa i Scali wydają się mieć dobrze i będą rozwijać się nadal.

Uwagi i wnioski

1. Tym razem na początku było trochę więcej chaosu związanego z konfiguracją środowisk toteż będę musiał pisać dokładną instrukcję tak krok po kroku jak się przygotować.
2. Muszę pamiętać by ustawiać limity na meetupa bo tym razem przyfarciłem i zorientowałem się jak było akurat 15 osób zapisanych.
3. Nie udało się zrobić tyle zadanek ze scali ile planowałem i do tego niektóre koncepcje nie są od razu jasne przy pierwszym zetknięciu. Być może będzie opcja na niezależne warsztaty ze scali?
4. Chociaż programowanie w parach upraszcza prowadzenie warsztatów to jakoś ludzie wydają się być niechętni co do tego sposobu pracy na zajęciach.

Co dalej

W czerwcu jedno lub dwa spotkanka z dalszej części warsztatów. Czas na formularze, parsery i kompozycje akcji. Materiału jest trochę także może podzielę to jeszcze na dwa części.

Play 2.3 RC1 jest już do pobrania także w lipcu może dla kolejnych chętnych będzie powtórka startu z playa - tym razem wersja 2.3 i scala 2.11.

Scenariusz warsztatów

To jest tak jakby kontynuacja Części pierwszej. Poniżej rozwinięta wersja punktu 3 z programu warsztatów --> Program warsztatów

Start

Tutaj standardowo tworzymy aplikację i w akcji index zmieniamy Your new application is ready. na pomidor albo dupa żeby było więcej zabawy

HTTP

Od razu trzeba pokazać, że dla Playa HTTP to przyjaciel a nie wróg. Robimy dodatkową akcję i prezentujemy jedyny chyba działający "quick fix" dla playa w eclipse - "ctrl+1" i automatyczne generowanie "ruta".

//application.scala
def moja = Action {
    Ok("siema")
}
//routes
GET   /moja           controllers.Application.moja()

I od razu działa bez restartu. Tutaj trzeba zrobić efekt WoW, o ku*wa itd. Wydaje mi się, że za pierwszym razem wyszło mi to bardziej epicko.

Na razie akcja zwraca nam text/plain ale łatwo i przyjemnie można to zmienić.

Ok("siema").as(HTML) //text/html;charset UTF-8
Ok(siema) // application/xml
import play.api.libs.json._
Ok(Json.obj("klucz"->"siema")) // application/json

Parametry

Tutaj przede wszystkim dobrze pokazać jak jasno Play raportuje gdzie brakuje parametru i gdzie popełnione są błędy w mapowaniu. Przy każdej okazji staram się podkreślać, że kompilator stara się tutaj pomóc jak może. Albo się walczy z kompilatorem albo z Runtimem - to pierwsze wydaje mi się bezpieczniejsze i przyjemniejsze

//Application.scala
def moja(name:String) = Action {
   Ok(s"siema $name")
  }

A jak już mapowanie będzie ok, to nadal raportowanie o złym użyciu api jest zajebiste. Aby uspokoić zmysły kolor czerwony zamienia się w kolor klocka.

Tutaj też jest dobry moment aby uświadomić uczestników warsztatów o tym, że play wygenerował nam ładną lokalną dokumentację, w której można sobie sprawdzić opcje na deklaracje parametrów w query, w urlu, na parametry zdefiniowane i opcjonalne. Była krótka dyskusja o tym czy da się zrobić tak aby wartość parametru była deklarowana w akcji a nie w routach - chociaż wydaje mi się to bez sensu bo parametr to części API to jednak w wolnej chwili muszę to sprawdzić.

Szablony

Tutaj dobrze jest ujawnić opcję ~run oraz ciekawe ustawienie w eclipse Window->preferences->General->Workspace->Refresh using native hooks pooling . Ze zwyklym run po stworzeniu nowego widoku trzeba by najpierw odświeżyć stronę a później projekt - co jest zwyczajnie słabe.

I teraz też czas na pokazanie szczodrości kompilatora - ku naszej uciesze nie da się do widoku przekazać Int kiedy oczekiwany jest String. Mniej zjebek typu "Object w jsp" - ano i podpowiadanie jest IDE jak zna typ.

Więcej o szablonach w opisie poprzednich warsztatów -> Szablony

Testy

Wygenerowane testy powinny nam nie przechodzić na tym etapie gdyż domyślny nagłówek strony głównej został zastąpiony słowem pomidor lub dupa. Co akurat pokazuje, że owe testy działają.

Tutaj też fajnie pokazać, jak łatwo testuje się widoki, które są zwykłymi funkcjami.

@* widok Template File *@
@(name: String)
<html>
<head>
<title>widok</title>
</head>
<body>
<h1>Siema @name </h1>
</body>
</html>

I jak mamy ów widoczek to najwygodniej otworzyć worksheet i najzwyklej w świecie widoczek wywołać.

object warszt {
 
 html.widok("Bożenka")                     //> res0: play.api.templates.HtmlFormat.Appendable = 
                                                  //| <html>
                                                  //| <head>
                                                  //| <title>widok</title>
                                                  //| </head>
                                                  //| <body>
                                                  //| <h1>Siema Bożenka </h1>
                                                  //| </body>
                                                  //| </html>
}

I w końcu można testować widok w testach jednostkowych. Nie chce mi się drugi raz opisywać tego samego -->Testy jednostkowe dla widoku

Reverse routing

To jest dosyć ciekawa funkcjonalność bo chyba nie ma czegoś podobnego w innym frameworku javowym. Żeby był efekt jebnięcia wystarczy chyba utworzyć obok siebie link zwykły i link używający reverse routing aby pokazać, że problemy z updatem linków w aplikacji nie będą nas już niepokoić

//widok.scala.html
<a href="/">link do indexu </a> <br/>

<a href="@routes.Application.index">samoupdatujący się link do indexu </a>
//i zmiana w routes
GET   /nowaStrategiaMarketingowa               controllers.Application.index

I to na razie byłoby na tyle

***