Ik ben zojuist het volgende nieuwe Java-webframework tegengekomen: Afspelen
http://www.playframework.org/documentation/1.0/home
met zo’n verbluffende lijst met functies, ben ik behoorlijk verbaasd dat ik er nog nooit van heb gehoord…
Klinkt als het beloofde land voor Java-webontwikkeling…
heeft iemand het geprobeerd? enige echte ervaring ermee? denk je dat het de moeite waard is om het te bestuderen?
Antwoord 1, autoriteit 100%
Ik ben het met Jason eens dat Play misschien wel beter zal blijken te zijn dan Grails. Met vier Grails-projecten onder mijn riem (voorafgegaan door twee Tapestry-projecten en één Wicket-project), kijk ik serieus naar Play next.
Een van de dingen die ik cool vond aan Grails, is dat ‘alles groovy is’. Dat wil zeggen, u gebruikt Groovy om alles te schrijven (behalve de HTML en de CSS) — domeinen, controllers, services, paginasjablonen (GSP), tagbibliotheken, Hibernate API (GORM), unit-tests (GUnit) en scripts bouwen ( GANT). Je kunt zelfs shellscripts schrijven in Groovy. Dus het opnieuw kunnen coderen van alle aspecten van een app met een enkele taal leek een vereenvoudiging die al veel eerder had moeten gebeuren – terugkijkend op de tijd dat desktop-apps in een enkele taal zoals C++ of Delphi werden geschreven. Ik heb echter geleerd dat één maat hier niet voor iedereen past.
Ten eerste is de IDE-ondersteuning voor Groovy niet geweldig. IntelliJ doet het beste werk, maar omdat Groovy dynamisch is, kan het maar zo ver gaan. De refactoring-tools (kunnen) niet alles vangen, dus je kunt ze niet 100% vertrouwen. Dit betekent dat u extra waakzaam moet zijn bij het testen van eenheden. Ook hier, omdat Grails zoveel afhankelijk is van dynamische “magie” die tijdens runtime plaatsvindt, moeten de eenheidstests in Grails vertrouwen op een uitgebreide spotlaag om het te emuleren, en die spotlaag is eigenzinnig. Een derde probleem is dat veel van de zogenaamde Groovy-code die u schrijft, in feite domeinspecifieke taalcode (DSL) is. (Om een lang verhaal kort te maken, DSL’s zijn afkorting Groovy, gebruikmakend van het feit dat in Groovy en veel van de syntaxis optioneel is.) Grails gebruikt verschillende DSL’s voor verschillende configuraties, URL-toewijzing, enz. en het is inconsistent. Hoe u bijvoorbeeld log4j-instellingen specificeert, lijkt in niets op hoe u de gegevensbronnen specificeert, en geen van beide lijkt op de pure Java waarop Groovy is gebaseerd. Dus de belofte van “alles is Groovy” valt sowieso uit elkaar.
Als dat het geval is, begrijp ik waar het Play-team vandaan komt.
-
Teruggaan naar normaal Java voor de domeinen, controllers, services en JUnits is logisch. Krachtig typen betekent dat de IDE betrouwbaar kan helpen met inteli-sense, codenavigatie, refactoring, enz. (En dus hoeft u niet te betalen voor IntelliJ als u tevreden bent met Eclipse.) Meer uitgebreide code moeten schrijven om sterke toolondersteuning terugkrijgen lijkt me nu een goede deal. We zullen zien.
-
Ik vind het leuk dat ik Groovy nog steeds mag gebruiken in de paginasjablonen. Ik ben echter bang dat ik misschien meer code in de sjablonen stop dan ik zou moeten.
-
Ik heb geen ervaring met JPA, maar het lijkt erop dat het vrij dicht in de buurt komt van wat GORM voor mij doet, dus dat is cool.
-
De ondersteuning van Spring IOC in Grails is volledig transparant, terwijl de ondersteuning van Play minimaal lijkt; ik denk echter dat IOC veel te veel wordt gebruikt en ik ben perfect bereid om een Spring XML-toewijzing te coderen in het zeldzame geval dat ik er echt een nodig heb. (Een van mijn open vragen is dat ik aanneem dat JPA transactie-ondersteuning heeft en daarom heeft Play daar geen Spring voor nodig zoals Grails, niet?)
-
Ik ben nooit een fan van Python geweest, dus ik kromp ineen toen ik las dat Play Python gebruikt voor zijn buildscripts. Maar ik ben het ermee eens dat de GANT-scripts van Grails behoorlijk traag werken. Bovendien vind ik dat, hoewel GANT een enorme verbetering is ten opzichte van XML ANT, het nog steeds moeilijk is om je hoofd rond de ANT-concepten te wikkelen. De Grails GANT-scripts zijn behoorlijk ingewikkeld. Dus ik ga er met een open geest in.
-
Het model van de PLAY “Application Module” klinkt om net als graanten ‘”plug-in” -model te zijn, dus dat is cool.
-
Ik ben behoorlijk onder de indruk van de speeldocumentatie die ik tot nu toe heb gelezen. Ik had een enorm aantal vragen in, maar de helft van hen werd recht van de vleermuis beantwoord.
Ik zal later opnieuw rapporteren terwijl ik dieper in duik.
Antwoord 2, Autoriteit 39%
Ik heb geprobeerd spelen en ik ben onder de indruk: het doet geweldig werk om een nuttig ontwikkelingsmodel te leveren dat veel eenvoudiger is dan de meeste frameworks ‘. Meer dan al het andere, het vermogen van de runtime in ‘Ontwikkelingsmodus’ om te ontleden. Java-bestanden direct de moeite waard: Herladen van de webpagina in de browser zonder een build-script te gebruiken of te wachten op een herschikking is veel ontwikkelingsnelheid waard. De foutmeldingen in de browser zijn ook echt goed.
Een ander ding dat indruk op me was, was de algehele esthetiek: het is misschien een klein ding dat de tutorial-applicatie eigenlijk goed uitziet (zowel de code als het webpagina-ontwerp), maar dit strekt zich uit tot het hele kader, de API evenals de documentatie.
Antwoord 3, Autoriteit 13%
Nadat ik uitkwam uit een collega, volgde ik het, volgde de tutorial en raakte verslaafd. Onmiddellijke feedback krijgen in uw browser betekent dat u geen IDE hoeft te gebruiken. Ik ben dol op Eclipse, maar laten we het tegenkomen: nadat je wat extra’s hebt toegevoegd, is het niet zo stabiel als een eenvoudige teksteditor. Op een Mac met TextMate kunt u zelfs op het foutbericht in uw browser klikken en de tekstmaat verschijnt met de cursor op die lijn.
Testen in het afspelen is ook mooi gedaan, met één knop Druk op U RUND-tests, functionele tests en Seleenium-gebaseerde tests.
Spelen is opwindend omdat het nog steeds klein en ongecompliceerd is. Het gebruikt gewoon mier om te bouwen en doet dit in 25 seconden. Bijdragen aan de prachtige documentatie is een kwestie van het bewerken van de .textielbestanden en het opnieuw laden van de documenten in een PLAY-app.
Dat is hoe ik op een zoektocht is gewikkeld om de tutorial te vertalen om Scala te gebruiken, het toevoegen aan de scala-ondersteuning waar nodig om het zo mooi mogelijk te krijgen.
Antwoord 4, Autoriteit 13%
Ik vind het leuk, ik gebruik het voor kleine projecten en tot nu toe ziet het er perfect uit voor het werk.
Er is echter één ding dat ik erg mis, die opzettelijk is weggelaten: Service / DAO / Model Layers Separation! Documentatie zegt het duidelijk, een van de doelen van het spel is om het ‘anemisch gegevensmodel’ te vermijden:
http://www.playframework.org/documentation/1.0.1/model
Maar in mijn ervaring slaat de klassieke service / DAO / Model Layers Separation ton ontwikkelingstijd op wanneer de toepassing moet worden verfijnd! Met Play zit je vast met statische methoden die vertrouwen op speelspecifieke transactiebeheer en eigenaardigheden …
Er zijn echter veel duimen op voor: Ontwikkelingsnelheid, Code Cleanness, en uiteindelijk … Fun!
Antwoord 5, Autoriteit 8%
Ik heb grails, tapijt 4/5 en rechte Java / JSP / Spring / Hibernate gebruikt.
Ik denk dat dit voor het eerst in de juiste richting in de goede richting gaat. Granten was echt een goede eerste stap maar speel! lijkt op iets dat echt benen zou kunnen hebben. Scala-ondersteuning komt in 1.1. Als er een kans is dat ik mijn controllers / domein in Clojure kan schrijven, ben ik verkocht;)
Antwoord 6, Autoriteit 6%
Sinds één jaar en geen zichtbare bug na 18 kleine releases, gebruiken we spelen! 1.2.4 in een productie “afwezigheden” intranet-aanvraag voor een school (acteurs: & GT; 100 leraren, & GT; 700 studenten, Administrativ Team). Klantkant is geschreven met Flex 4.6 van Adobe (zeer prachtig uitzicht). Gegevens worden verzonden en ontvangen in AMF3-formaat (Cinnamon Module). We gebruiken een eigen eenvoudige DAO-laag op basis van JPA Eclipselink en MySQL voor de DB. Toepassing wordt opgeslagen op een Linux-virtuele server. Ik ben een heel fan-ontwikkelaar van spelen vanwege de eenvoud en de zeer productieve aanpak.
Antwoord 7, Autoriteit 4%
Ik hou van het uiterlijk van Play, maar heb het nog niet geprobeerd. Van het scannen door de documenten viel één ding op: het veelvuldige gebruik van statische methoden. Vanuit het oogpunt van unit-testing maakt dit de zaken altijd veel moeilijker (ik denk spotten), en het is een afwijking van de OO-everywhere-aanpak in typische Java-ontwikkeling. Misschien is dit het punt, maar het is gewoon iets dat me een beetje minder enthousiast maakte…
Antwoord 8, autoriteit 4%
Ik bouw momenteel webapplicaties op het werk met behulp van een play-framework dat enorme gegevensverwerking doet. Ik moet zeggen dat de snelheid die het spel alleen biedt aanzienlijk is en meer dan wat RoR kan bieden. Bovendien is spelen een op Java gebaseerd framework en daarom kan Multi-Threading gemakkelijk worden gedaan. Het volgende is de pure prestatie die je krijgt als je op Java gebaseerde modules zoals Japid en Netty samen met spelen gebruikt. Het is alsof er een eindeloze hoeveelheid aanpassingen kan worden gedaan voor de prestaties. Een must naar mijn mening.
Antwoord 9, autoriteit 3%
Ik gebruik Play in een klein project en het lijkt precies te zijn wat ze hebben gezegd. Maar één functie moet volgens mij standaard in het framework aanwezig zijn: de mogelijkheid om met meer dan één gegevensbron te werken (bijvoorbeeld meer dan één databaseschema gebruiken). Dit is de enige ontbrekende functie die ik tot nu toe heb gevonden.
Met vriendelijke groet,
Uilian.