KoziołekWeb

Za co wszyscy cenią Ruby? Za zajebisty framework jakim jest Ruby on Rails. Gdy dość dawno temu Wiktor Gworek na spotkani WJUGa pokazał jak pisać w RoR byłem oczarowany. Przy springowych, kilometrowych XMLach, przy EJB3 i jego opasłości lekkość Railsów była do pozazdroszczenia.
Później zetknąłem się z Symphony, czyli railsami dla PHP, a w zeszłym roku Jacek Laskowski męczył nas Groovym i Grailsami.Ja też tak chciałem, ale chciałem też by to była Java.
Mam duże opory przed nauką nowych języków, a wynika to niestety z braku możliwości ich stosowania w praktyce. Zarówno w fabryczce jak i prywatnie tworzę przede wszystkim w Javie. Nowy język wymagał by ode mnie zaangażowania środków w nowe nieznane środowisko, a co za tym idzie musiałbym kilka rzeczy w organizacji pracy zmienić. Taki już jest ten Kozioł.

Przeglądałem jeszcze przed świętami plan zajęć WJUGa i rzucił mi się na oczy jeden punkt. Wojciech Erbetowski – Play Framework. Zagooglowałem trochę za tym frameworkiem i po obejrzeniu filmiku z prezentacją byłem pod wrażeniem.
Rozpocząłem więc własną przygodę z tym frameworkiem.

Co jest w nim fajne

Przede wszystkim lekkość. Cały proces tworzenia aplikacji jest nastawiony na maksymalizację szybkości. Jest bardzo dużo CoC i pewnych dobrze znanych zasad. Na przykład używamy plików yml do definiowania danych testowych. Bardzo silnie odseparowane są elementy MVC. Jest to co w railsach fajne, czyli metody CRUD w klasach modelu. Jest w końcu ludzkie wsparcie dla testów.
Przyjrzyjmy się jednak procesowi tworzenia aplikacji.

Let’s play the game

Po ściągnięciu ostatnich binariów wersji 1.0 (w 1.1 jest wsparcie dla Scali, ale całość jest unstable) z serwera, rozpakowujemy, ustawiamy zmienną $PATH i $PLAY_PATH i już możemy działać.
W konsoli przechodzimy do katalogu z wokrspacem Eclipse i piszemy

Listing 1. Tworzenie nowej aplikacji play

koziolek@koziolek-desktop:~/workspace$ play new test
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0-r779, http://www.playframework.org
~
~ The new application will be created in /home/koziolek/workspace/test
~ What is the application name? Test
~
~ OK, the application is created.
~ Start it with : play run test
~ Have fun!
~
koziolek@koziolek-desktop:~/workspace$

Następnie Eclipsujemy aplikację i importujemy ją do IDE:

Listing 2. Eclipsowanie aplikacji

koziolek@koziolek-desktop:~/workspace/test$ play eclipsify
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0-r779, http://www.playframework.org
~
~ OK, the application is ready for eclipse
~ Use File/Import/General/Existing project to import /home/koziolek/workspace/test into eclipse
~
~ Use eclipsify again when you want to update eclipse configuration files.
~ However, it's often better to delete and re-import the project into your workspace since eclipse keeps dirty caches...
~
koziolek@koziolek-desktop:~/workspace/test$

Gościa który wymyślił takie polecenie powinni powiesić. eclipsify jest złe, powinno być eclipse. Przy okazji spis komend:

Listing 3. Polecenia konsoli play

koziolek@koziolek-desktop:~/workspace/test$ play help
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0-r779, http://www.playframework.org
~
~ For all commands, if the application is not specified, the current directory is used
~ Use 'play help cmd' to get more help on a specific command
~
~ Available commands are:
~ ~~~~~~~~~~~~~~~~~~~~~~~
~ auto-test      Automatically run all application tests
~ classpath      Display the computed classpath
~ clean          Delete temporary files (including the bytecode cache)
~ eclipsify      Create all eclipse configuration files
~ help           Display help on a specific command
~ id             Define the framework ID
~ idealize       Create all IntelliJ Idea configuration files
~ modules        Display the computed modules list
~ netbeansify    Create all netbeans configuration files
~ new            Create a new application
~ out            Follow logs/system.out file
~ pid            Show the pid of a running application
~ precompile     Precompile all Java sources and templates to speed up application start
~ run            Run the application in the current shell
~ restart        Restart the running application
~ secret         Generate a new secret key
~ status         Display the status of the running application
~ start          Start the application in background
~ stop           Stop the running application
~ test           Run the application in test mode in the current shell
~ war            Export the application as a standalone WAR archive
~
~ Also refer to documentation at http://www.playframework.org/documentation
~
koziolek@koziolek-desktop:~/workspace/test$

Nasza aplikacja ma następującą strukturę:

Listing 4. Struktura aplikacji

.
|-- app
|   |-- controllers
|   |   `-- Application.java
|   |-- models
|   `-- views
|       |-- Application
|       |   `-- index.html
|       |-- errors
|       |   |-- 404.html
|       |   `-- 500.html
|       `-- main.html
|-- conf
|   |-- application.conf
|   |-- messages
|   `-- routes
|-- eclipse
|   |-- Connect JPDA to Test.launch
|   |-- Test Test.launch
|   `-- Test.launch
|-- lib
|-- logs
|-- public
|   |-- images
|   |   `-- favicon.png
|   |-- javascripts
|   |   `-- jquery-1.3.2.min.js
|   `-- stylesheets
|       `-- main.css
`-- test
    |-- Application.test.html
    |-- ApplicationTest.java
    |-- BasicTest.java
    `-- data.yml

Jak na razie było prosto. Później też jest prosto, a jak idzie się przez tutorial to naprawdę prosto.

Play wady

Wadą frameworku jest praktycznie całkowity brak możliwości rekonfiguracji nazw pakietów (albo jeszcze tego nie odkryłem). Powoduje to, że aplikacje tworzone w play muszą być proste. Nic bardziej złożonego niestety
Kolejną poważną wadą jest narzucenie złych praktyk. Akcje w kontrolerach muszą być metodami statycznymi (sic!). Wiadomo, że static w odniesieniu do metody to zło wcielone w Javie. Niestety wyżej nerek nie podskoczymy.
Ostatnią wadą jest brak znanych z RoR poleceń do generowania kontrolerów i widoków.
Na koniec należy dodać jeszcze wykorzystanie bibliotek majstrujących w bytecodzie po kompilacji. Powoduje to, że nieintuicyjnie działa mechanizm dziedziczenia np. jeżeli chcemy zrobić własną metodę delete to nie można nadpisać tej dziedziczonej z klasy Model ponieważ jest ona podmieniana w naszej klasie na poziomie bytecodu. Powoduje to walenie błędami w trakcie uruchamiania aplikacji.
Oczywiście brakuje też dokumentacji.

Podsumowując, twórcy play mają jeszcze wiele rzeczy do zrobienia, ale już osiągnięte efekty są dobre.

Dodaj do

This entry was posted on Wednesday, January 6th, 2010 at 21:46 and is filed under Antywzorce, Inżynieria Oprogramowania, Java, Play Framework, Spring Framework. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.