Właśnie natknęliśmy się na następującym nowych ram Java Web: Playjakiekolwiek doświadczenie z ramą programistyczną java "Play"?
http://www.playframework.org/documentation/1.0/home
z takiej wspaniałej listę funkcji, jestem całkiem dużo zaskoczony ja nie słyszałem to przed ...
Brzmi jak internetowej java Development ziemi obiecanej ...
czy ktoś próbował? jakiekolwiek prawdziwe doświadczenie z tym? myślisz, że warto to studiować?
Zgadzam się z Jasonem, że Play może okazać się lepszym od Grails'a. Z czterema projektami Grails pod moim pasem (poprzedzonymi dwoma projektami Tapestry i jednym projektem Wicket), poważnie patrzę teraz na Play.
Jedną z rzeczy, które uważałem za fajne w Grails, jest to, że "wszystko jest Groovy". Oznacza to, że używasz Groovy do pisania wszystkiego (z wyjątkiem HTML i CSS) - domen, kontrolerów, usług, szablonów stron (GSP), bibliotek znaczników, interfejsu Hibernate API (GORM), testów jednostkowych (GUnit) i skryptów kompilacji (GANT). Możesz nawet pisać skrypty powłoki w Groovy. Tak więc ponowne kodowanie wszystkich aspektów aplikacji za pomocą jednego języka znów wydawało się uproszczeniem, które było dawno spóźnione - powracając do czasów pisania aplikacji komputerowych w jednym języku, takim jak C++ lub Delphi. Jednak nauczyłem się, że jeden rozmiar nie pasuje do wszystkich tutaj.
Po pierwsze, wsparcie IDE dla Groovy nie jest wspaniałe. IntelliJ robi najlepszą robotę, ale przy Groovy jest dynamiczny, może tylko posunąć się tak daleko. Narzędzia do refaktoryzacji nie (nie mogą) uchwycić wszystkiego, więc nie można im ufać w 100%. Oznacza to, że musisz być szczególnie czujny podczas testowania jednostkowego. Ponownie, ponieważ Grails polega tak bardzo na dynamicznej "magii", która dzieje się w czasie wykonywania, testowanie jednostki w Grails musi polegać na obszernej szyderczej warstwie, aby ją emulować, i że szydercza warstwa jest dziwaczna. Trzecią kwestią jest to, że znaczna część tak zwanego kodu Groovy, który piszecie, jest w rzeczywistości kodem specyficznym dla domeny (DSL). (Krótko mówiąc, DSL to skrót od Groovy'ego, wykorzystujący fakt, że w Groovy i wiele składni jest opcjonalna.) Grails używa różnych DSL dla różnych konfiguracji, mapowania adresów URL itp. I jest niespójny. Sposób określania ustawień log4j na przykład nie przypomina sposobu, w jaki określasz źródła danych, a żadna z nich nie przypomina czystej Javy, na której oparte jest Groovy. Tak więc obietnica "wszystkiego groovy" rozpada się.
W takiej sytuacji widzę, skąd pochodzi zespół Play.
Powrót do zwykłej Java dla domen, kontrolerów, usług i JUnits ma sens.Silne pisanie oznacza, że IDE może niezawodnie pomagać z intelisem, nawigacją kodu, refaktoryzacją itp. (A więc nie musisz płacić za IntelliJ, jeśli jesteś zadowolony z Eclipse.) Konieczność napisania bardziej szczegółowego kodu w celu odzyskać silne narzędzie wsparcia wydaje mi się teraz dobrą okazją. Zobaczymy.
Podoba mi się, że nadal używam Groovy w szablonach stron. Obawiam się, że mogę włożyć więcej kodu do szablonów niż powinienem.
Nie mam żadnego doświadczenia z JPA, ale wydaje mi się, że jest to bardzo zbliżone do tego, co GORM robi dla mnie, więc jest fajnie.
Wiosenne wsparcie IOC w Grails jest całkowicie przezroczyste, podczas gdy wsparcie Play wydaje się minimalne; jednak myślę, że IOC jest nadużywany i jestem całkowicie skłonny do ręcznego zakodowania mapowania Spring XML w rzadkich przypadkach, kiedy naprawdę go potrzebuję. (Jednym z moich otwartych pytań jest to, że zakładam, że JPA ma wsparcie transakcyjne, dlatego Play nie potrzebuje Springa na to jak Grails, czyż nie?)
Nigdy nie byłem fanem Pythona, więc wzdrygnęłam się, gdy przeczytałam, że Play używa Pythona do tworzenia skryptów. Ale zgadzam się, że skrypty GANT Grailsa działają dość wolno. Dodatkowo uważam, że chociaż GANT jest ogromnym ulepszeniem w stosunku do XML ANT, wciąż trudno jest objąć głowę koncepcjami ANT. Skrypty Grails GANT są dość zawiłe. Więc wejdę do tego z otwartym umysłem.
Model "modułu aplikacji" brzmi jak model "wtyczki" Grails, więc jest fajnie.
Jestem pod dużym wrażeniem dokumentacji Play, którą przeczytałem do tej pory. Miałem ogromną liczbę pytań, ale połowa z nich odpowiedziała od razu.
będę zgłosić ponownie później jak nurkować głębiej w
Użyłem Grails, Tapestry 4/5 oraz prostej Java/JSP/Spring/Hibernate.
Myślę, że to idzie w dobrym kierunku po raz pierwszy od dłuższego czasu. Grails był naprawdę dobrym pierwszym krokiem, ale zagraj! wygląda jak coś, co naprawdę może mieć nogi. Obsługa Scala nadchodzi w wersji 1.1. Jeśli jest szansa, że mogę napisać moje kontrolery/domenę w Clojure, jestem sprzedany;)
Zastanawiam się, czy można użyć groovy przez cały czas ... Chyba tak ... W każdym razie, może warto dać scala strzał ... – opensas
Podoba mi się wygląd Play, ale go nie wypróbowałem. Od skanowania przez dokumenty jedno, co wyróżniało się, to intensywne stosowanie metod statycznych. Z punktu widzenia testów jednostkowych zawsze czyni to o wiele trudniejszym (myślę, że kpi) i jest odejściem od podejścia OO-everywhere w typowym rozwoju Java. Może o to chodzi, ale to tylko coś, co sprawiło, że byłem trochę mniej zachwycony ...
Myślę, że ich argumentem jest to, że kontroler to po prostu zachowanie, to jest nie ma żadnych danych, coś w rodzaju biblioteki funkcji, więc nie są to obiekty ... ale i tak widzę twoją kwestię dotyczącą kpiny ... – opensas
Próbowałem grać i jestem pod wrażeniem. Robi wielkie zadanie dostarczanie użytecznej modelu rozwoju, który jest znacznie prostszy niż większość ram ". Co więcej, zdolność środowiska wykonawczego w "trybie programowania" do bezpośredniego analizowania plików .java jest warta wiele: po prostu przeładowanie strony internetowej w przeglądarce bez uruchamiania skryptu kompilacji lub czekanie na przeniesienie jest warte dużej szybkości programowania. Komunikaty o błędach wyświetlane w przeglądarce są również bardzo dobre.
Inną rzeczą, która zrobiła na mnie wrażenie, była ogólna estetyka: być może jest to mała rzecz, że tutorialowa aplikacja rzeczywiście wygląda dobrze (zarówno kod, jak i projekt strony internetowej), ale to rozszerza się na cały framework, API również jako dokumentacja.
Napisałem więcej na ten temat: http://www.lunatech-research.com/archives/2010/03/15/play-framework-usability –
+1 za wzmiankę o "ogólnej estetyce". – fastcodejava
Po utknięciu od kolegi spojrzałem na niego, podążyłem za tutorialem i się zaczepiłem. Uzyskanie natychmiastowej odpowiedzi bezpośrednio w przeglądarce oznacza, że nie musisz używać IDE. Uwielbiam Eclipse, ale spójrzmy prawdzie w oczy: po dodaniu kilku dodatków nie jest tak stabilny jak zwykły edytor tekstu. Na Macu z TextMate możesz nawet kliknąć na komunikat o błędzie w przeglądarce, a TextMate pojawi się z kursorem na tej linii.
Testowanie w grze jest również przyjemne, jednym naciśnięciem przycisku uruchamia się testy jednostkowe, testy funkcjonalne i testy oparte na selenach.
Gra jest ekscytująca, ponieważ wciąż jest mała i nieskomplikowana. Używa tylko mrówki do zbudowania i robi to za 25 sekund. Przyczynianie się do pięknej dokumentacji to edycja plików .textile i ponowne ładowanie dokumentów w dowolnej aplikacji do odtwarzania.
Tak właśnie skończyłem, aby przetłumaczyć samouczek do korzystania z Scali, dodając wsparcie Scala tam, gdzie było to potrzebne, aby było to jak najbardziej przyjemne.
+1 w Scala. To naprawdę poprawia wydajność. – Magnus
Używam gry w małym projekcie i wydaje mi się, że dokładnie tak było. Ale jedna funkcja powinna być domyślnie obecna w strukturze: możliwość pracy z więcej niż jednym źródłem danych (np. Używanie więcej niż jednego schematu bazy danych). Jest to jedyna brakująca funkcja, którą udało mi się znaleźć do tej pory.
Pozdrawiam, Uilian.
To był problem z wczesnym Django, ale jestem pewien, że zostanie to naprawione wraz z dojrzewaniem programu. Będzie to ważna skarga. –
masz na myśli używać więcej niż jednej bazy danych na raz? – rogerdpack
Wystarczy zauważyć, że istnieje moduł odtwarzania, który pozwala na wiele baz danych. To prawdopodobnie nie było prawdą w momencie odpowiedzi, ale zmieniło się od tego czasu. – Codemwnci
Podoba mi się, używam go do małych projektów i do tej pory wygląda idealnie do tej pracy. Jest jednak jedna rzecz, za którą tęsknię bardzo, która została celowo pominięta: separacja warstw Service/DAO/Model! Dokumentacja mówi wyraźnie, jednym z celów gry jest, aby uniknąć „anemiczny model danych”: http://www.playframework.org/documentation/1.0.1/model
ale z mojego doświadczenia klasyczne warstwy życzenie/DAO/typu separacja pozwala zaoszczędzić mnóstwo czasu rozwoju, gdy potrzebuje aplikacji, aby być refaktoryzowane! Dzięki Play utkniesz w statycznych metodach, które polegają na specyficznych dla Play zarządzaniu transakcjami i osobliwościach ...
Jednak wiele kciuków za: szybkość rozwoju, czystość kodu, aw końcu ... zabawę!
Obecnie tworzę aplikacje internetowe w pracy za pomocą mechanizmu odtwarzania, który masowo przetwarza dane. Muszę powiedzieć, że prędkość, jaką oferuje gra, jest znacząca i większa niż ta, którą może zapewnić RoR. Poza tym gra jest strukturą opartą na Javie, a zatem wielowątkowość można łatwo zrobić. Następna jest sama wydajność, gdy korzystasz z modułów opartych na Javie, takich jak Japid i Netty oraz gra. To jak niekończąca się ilość poprawek, które można wykonać dla wydajności. Musi spróbować w mojej opinii.
Od roku i bez widocznego błędu po 18 małych wydaniach, używamy Play! 1.2.4 w aplikacji "nieobecności" w intranecie dla szkoły (aktorzy:> 100 nauczycieli,> 700 studentów, zespół administracyjny). Strona klienta została napisana z FLEX 4.6 od Adobe (bardzo piękne widoki). Dane są wysyłane i odbierane w formacie AMF3 (moduł Cinnamon). Używamy własnej prostej warstwy dao opartej na JPA EclipseLink i MySql dla DB. Aplikacja jest przechowywana na wirtualnym serwerze Linux. Jestem zagorzałym fanem Play z powodu jego prostoty i bardzo produktywnego podejścia.
Ta aplikacja jest teraz uruchomiona z grą 2.2.3 na serwerze Windows (żądanie od administracji IT). – jcstritt
Wygląda na to, że mam jeszcze inną aplikację. – skaffman