PlayFramework 2.0 – co nowego ?

post_img

Ten kolejny framework javowy jest według mnie – i tę opinię podzielają autorzy znanych mi internetowych komentarzy – mało popularny. Jednak jeśli przejrzeć jego dokumentację, to okazuje się on bardzo interesującą pozycją. Szczerze mówiąc, jest dokładnie tym, czego szukałem! Ale zanim zmobilizowałem się, aby przybliżyć w tym miejscu PF 1.x, już pojawił się w wersji 2.0. Dlatego tym razem nie czekam z prezentacją. Postaram się opisać przede wszystkim jego nowe elementy i zastanowić się nad tym, czy warto z niego skorzystać.

PF powstał jako alternatywny framework dla „złożonej” koncepcji wytwarzania aplikacji webowych w JEE. Świadomie odrzuca jsf, jsp czy beany typu stateful. Nastawił się na szybkie tworzenie aplikacji z wykorzystaniem technologii AJAX, a także na to aby programiście pracowało się jak najprościej. Ogólna prezentacja PF 2.0 jest tutaj:PF 2.0 Philosophy. Nie będę jednak tego dublował, skupię się na konkretnych zmianach w api i konfiguracji.

Konfiguracja
Główny plik application.conf domyślnie zawiera 20% tego, co we wcześniejszej wersji PF. Niestety, nie mamy już pod ręką przydatnych opcji konfiguracyjnych, które należy tylko od komentować i cieszyć się zmianami, takich jak np. http.port. Trzeba doczytać samodzielnie w dokumentacji, jak to ustawić, w dodatku nie zawsze można takie informacje znaleźć. Składnia pliku application.conf nic się nie zmieniła. W nowej wersji PF zapewnia większą elastyczność w konfiguracji z wykorzystywanymi bibliotekami. Nie jesteśmy już na przykład przywiązani do hibernate, a możemy skorzystać z dowolnego JPA ( do którego wrócę nieco później). Ponadto dochodzi plik project/Build.scala, w którym trzymamy informacje potrzebne do budowania projektu. Wykorzystywany jest do tego STB, niestety nie ma już możliwości korzystania z mavena, co było dostępne wcześniej przy pomocy modułu. Plik conf/messages.xxx pozostaje bez zmian.

Baza danych
Zmieniła się również współpraca PF z bazą danych. W wersji 1.x dostawaliśmy hibernate na „sterydach” – dodatkowe api ułatwiało wykonywanie zapytań. Domyślnie mieliśmy sterowniki jdbc dla mysql, nie trzeba było się martwić plikiem presistance.xml. Wystarczyło tylko od komentować odpowiednią linijkę z jdbc ulr i podmienić namiary na naszą bazę danych. W 2.x jest już inaczej. Domyślnie nasze encje nie podlegają zarządzaniu przez Hibernate, tylko Ebean. Chcąc dodać Hibernate należy dodać zależność od sterownika jdbc oraz entitymanagera w konfiguracji projektu, skonfigurować połączenie jdbc i stworzyć persistence.xml.

project/Build.scla

1
2
3
4
val appDependencies = Seq(
      "org.hibernate" % "hibernate-entitymanager" % "3.6.9.Final",
      "mysql" % "mysql-connector-java" % "5.1.18"
    )

conf/application.conf

1
2
3
db.default.driver=com.mysql.jdbc.Driver
db.default.url="jdbc:mysql://user:pass@localhost:3306/dbname?"
db.default.jndiName=DefaultDS

conf/META-INF/persistence.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
             version="2.0">
             
    <persistence-unit name="defaultPersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <non-jta-data-source>DefaultDS</non-jta-data-source>
        <properties>
            <property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect"/>
        </properties>
    </persistence-unit>
 
</persistence>

Jak widać, trzeba wykonać więcej pracy, co jest minusem. Dzięki wprowadzeniu tych zmian możemy jednak korzystać z innych jpa niż hibernate.

Szablony
W wersji 1.x do generowania widoku używany był język skryptowy groovy. W 2.x na jego miejsce pojawił się system oparty o scale (wzorowany na ASP.NET Razor).
Na szczęście opanowanie tego jest proste i nie powinno zająć zbyt dużo czasu. W dodatku generacja widoku w PF 2.x jest znacznie szybsza. Pojawia się również statyczne typowanie co pozwala uniknąć problemów z rzutowaniem na etapie kompilacji. Co ciekawsze PF 2.x jest również w stanie wyłapać np. literówki w nazwach zmiennych, również na etapie kompilacji. Zazwyczaj w językach skryptowych o takich błędach dowiadujemy się dopiero podczas uruchomienia aplikacji. Może to się okazać szczególnie przydatne w continuous integration.
Więcej o składni przykładowym użyciu można przeczytać tutaj: JavaTemplates

Formularze
Ciekawym nowym rozwiązaniem wydaje się budowanie formularzy przy pomocy klasy Form. Możemy wygodnie utworzyć formularz w raz z obiektem dla naszej encji na podstawie parametrów z requestu.

1
2
3
4
5
@Entity
public class User {
    public String email;
    public String password;
}
1
2
Form<User> userForm = form(User.class);
User user = userForm.bindFromRequest().get();

Więcej o formularzach http://www.playframework.org/documentation/2.0/JavaForms

Routing
Konfiguracja ciągle pozostaje w pliku conf/routes. Nadal również wspierane są wszystkie rodzaje metod HTTP (GET, POST, PUT, DELETE, HEAD). Nowością jednak jest możliwość określenia typu parametru do przekazywanej metody, aby było to bardziej zrozumiałe poniżej przykłady.

1
2
3
4
5
6
7
8
9
#Statyczna ścieżka
GET   /clients              controllers.Clients.list()

#Dynamiczna
GET   /clients/:id          controllers.Clients.show(id: Long)  

GET   /files/*name          controllers.Application.download(name)  

GET   /clients/$id<[0-9]+>  controllers.Clients.show(id: Long)

Można również podawać wartości domyślne dla parametrów, tak jak jest to pokazane poniżej.

1
2
3
4
GET   /                        controllers.Application.show(page = "home")
GET   /:page                controllers.Application.show(page)

GET   /clients               controllers.Clients.list(page: Integer ?= 1)

Moduły
PF udostępnia możliwość pisania modułów, tak aby można byłoby wygodnie poszerzyć funkcjonalność i wygodnie ją współdzielić między projektami. We wersji 1.x była dość spora lista przydatnych modułów, jak choćby maven, secure czy spring. Niestety nie są one kompatybilne z wersją 2.0. To zdecydowany minus nowego PF. Obecnie moduły nie będą już udostępniane przez stronę PF, tylko przez repozytorium mvn,ivy itd.

Podsumowanie
To tylko część zmian, jednak na początek chciałem zwrócić uwagę na te ważniejsze. Wkrótce powrócę do tego produktu. A zatem – czy warto już teraz „przesiąść się” na PF 2.0 ? Sam tego jeszcze nie zrobiłem w ramach projektu, nad którym zacząłem pracować jakiś czas temu, ponieważ PF 2.0 ma sporo otwartych błędów (ponad 100) oraz z racji braku pełnej wstecznej kompatybilności trzeba wykonać sporo pracy w projekcie, aby podnieść wykorzystywany PF do wersji 2.0.Według mnie nowa wersja straciła trochę na swojej atrakcyjności, gdyż wymaga więcej konfiguracji oraz zaglądania do dokumentacji. Wykorzystuje też mniej znane biblioteki czy narzędzia, jak np. SBT. To co mi się podobało w 1.x, to szybki start oraz intuicyjność co czyniło PF dobrym rozwiązaniem dla małych i średnich projektów w których liczy się przede wszystkim cena i czas. Choć ciągle pozostaje on prostym i przyjaznym frameworkiem, nawet dla początkujących w JEE.

Linki
strona projektu
ciekawa prezentacja play 2.0
grupa dyskusyjna play

Dodaj komentarz

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