प्ले के साथ काम करने के इंप्रेशन! फ्रेमवर्क 2.1 + जावा

प्ले के साथ भारी लड़ाई का चौथा सप्ताह था! फ्रेमवर्क 2.1 + जावा। विजय अकस्मात निकट आ रहा था, लेकिन यह पूर्ण आत्मसमर्पण से दूर था।
प्ले के विकास के बारे में उत्साहजनक खबर के बाद! 2.1, उदाहरण के लिए लिंक्डइन पर, इसे एक नई परियोजना में आज़माने का निर्णय लिया गया। यह परीक्षण करने के लिए, व्यापार में बोलने के लिए। इसका क्या हुआ? मैं कहूंगा कि यह मेरे और प्ले के बीच एक छोटा युद्ध था! 2.1। क्यों? कटौती के तहत विवरण, लेकिन अधीर के लिए:

संक्षिप्त निष्कर्ष

हमले के लिए, एक गुप्त हथियार लेना जरूरी था, जिसका नाम स्कैला है। यदि आप Play के साथ आमने सामने आते हैं! 2.1 फ्रेमवर्क और अपने सभी ताकत के साथ चिल्लाओ: "आप एक स्काला फ्रेमवर्क हैं!", फिर वह इस तरह की प्रत्यक्षता से डर जाएगा और महान अवसरों की दुनिया के लिए अपने दरवाजे खुले रूप से करेगा।
"स्काला नहीं जानते?" - "प्ले 1.2 का उपयोग करें।"
"शाला में अच्छी तरह से वाकिफ हैं?" - "2.1 खेलने की कोशिश करना सुनिश्चित करें। लेकिन फिर भी धैर्य रखें। ”

प्रागितिहास

एक तलवार और ढाल के साथ माउस और कीबोर्ड के साथ 7 वर्षों के लिए, मैंने जावा के विभिन्न देशों का दौरा किया है। ये एंटरप्राइज के प्राचीन खंडहर थे, जहां जीवन अभी भी गर्म है, और स्प्रिंगलैंड को फूल रहा है, और ग्रिल्स सिटी में राजधानी के साथ उसका वासाल ग्राउविंडिया, और एक बार उन्नत और विदेशी प्लीट्रा पेरोवो, और कई, कई अन्य राज्यों, शहरों और यहां तक ​​कि दूरदराज के गांवों। लेकिन प्लेटर्रा II पर अभियान अप्रत्याशित रूप से कठिन था।
लगभग 9 महीने तक मैंने प्ले 1.2.x का उपयोग करते हुए एक परियोजना पर काम किया, और बिल्कुल खुश था। स्प्रिंग फ्रेमवर्क 3 के बाद भी, यह गतिमान और विकास में आसानी के शिखर की तरह लग रहा था, राक्षसी जावा ईई 5 + जेएसएफ का उल्लेख नहीं करने के लिए।
तब एक छोटा ब्रेक था जिसमें मैं 3 महीने के लिए ग्रिल्स 2.x के साथ गहनता से काम करने में कामयाब रहा और यह समझा कि जावा सुविधा और वाक्यविन्यास क्षमताओं के मामले में ग्रूवी से कैसे पिछड़ गया। और यह कि शुद्ध स्प्रिंग फ्रेमवर्क 3 + जावा से विकसित करने के लिए ग्रेल्स कुछ आसान और तेज है।
हालांकि, यह एक नई परियोजना के लिए एक रूपरेखा चुनने का समय था, और विकल्प 2.1 पर गिर गया। क्या यह सही फैसला था? यकीन के लिए दिलचस्प है, लेकिन सही एक - यह अभी भी समय दिखाएगा।
इस बीच, मैं प्ले 2.1 के साथ काम करने के अपने इंप्रेशन को साझा करना चाहता हूं। जावा और भावनाओं के बारे में विलाप करते हुए, प्ले 1.2.x के साथ कई तुलनाएं होंगी। लगभग कोई कोड नहीं होगा, और आम तौर पर स्वीकृत शर्तों और अवधारणाओं का रूसी में अनुवाद नहीं किया जाएगा। उदाहरण के लिए, स्टेटलेस फ्रेमवर्क ।

छापों

प्रलेखन का अभाव

Playterre II के शासकों द्वारा प्रदान किए गए नक्शे पूर्ण से बहुत दूर थे। मुख्य सड़कों को काफी सटीक रूप से इंगित किया गया है, लेकिन इन सड़कों के आसपास अगम्य डंप है। भटका नहीं करने के लिए, मुझे स्थानीय लोगों को पकड़ना पड़ा और उनसे कई सवाल पूछे। वैसे, उन्होंने बहुत स्वेच्छा से उत्तर दिया।
आधिकारिक दस्तावेज बल्कि कंजूस है। जावा के साथ प्ले 2 और स्काला के साथ प्ले 2 की दो किताबें हैं। जावा के बारे में पहला, काफी हद तक शुरुआती के लिए टिप्पणियों के साथ आधिकारिक दस्तावेज को दोहराता है। दूसरा, स्काला के बारे में, थोड़ा अधिक उपयोगी है और आवश्यक विषयों को शामिल करता है, उदाहरण के लिए, अध्याय 8. JSON के साथ एकल-पृष्ठ जावास्क्रिप्ट अनुप्रयोग का निर्माण।
बेशक, एक बड़ा और सक्रिय समुदाय है, आप मदद मांग सकते हैं और Google समूह और Stackoverflow दोनों पर एक प्रश्न पूछ सकते हैं। लेकिन विकसित होने की खुशी कुछ हद तक खो जाती है अगर आपको लगातार सरल सवालों के जवाब तलाशने पड़ते हैं।
मैंने प्रलेखन ( यहां ) को बेहतर बनाने में भी भाग लिया, लेकिन अभी भी कई जगह हैं जिन्हें मैं अधिक विस्तार से कवर करना चाहता हूं।
प्ले 1.2.x के लिए, प्रलेखन अधिक पूर्ण और अधिक उपयोगी था। केवल Stackoverflow और Google समूह पर खोज करना वास्तव में असामान्य चीजें थीं।

संकलन की गति

यहां की सड़कें आदर्श से बहुत दूर हैं। कभी-कभी मुझे घंटों सवारी करनी पड़ती थी, कीचड़ में डूबना और घोड़े को भीख नहीं देना और तेजी से सवारी करना। एक बड़ी सेना के स्थानांतरण में बहुत लंबा समय लगता है। सड़कों पर हर जगह चौकियां और चौकियां।
कई लोगों के लिए, यह खबर नहीं होगी, लेकिन यहां संकलन धीमा है। प्ले 1.2.x की तुलना में बहुत धीमा। मैं समझता हूं कि लगभग सब कुछ यहाँ संकलित है, सरल जावा कक्षाओं से लेकर स्काला टेम्पलेट्स और कॉफी स्क्रिप्ट तक। लेकिन यह एक लंबा समय है। मान लें कि त्रुटि संदेश जारी हो गए हैं, लेकिन यह एक लंबा समय है। बिजली की तेजी से आदर्श रूप से ताज़ा करें वर्कफ़्लो स्टॉल और एनॉय को मारो ।

डेटाबेस के साथ काम करें

प्रसिद्ध निवासियों को पता नहीं है कि स्वतंत्र रूप से किले कैसे बनाए जाते हैं। वे यह नहीं कह सकते: "एक और टॉवर को ठीक करें, लेकिन जल्दी से!"। नहीं। उन्हें एक विस्तृत योजना की जरूरत है।
इसमें बिल्ट-इन डेटाबेस इवोल्यूशन इंजन है। लेकिन इन लिपियों की पीढ़ी के साथ एक समस्या है। Ebean अभी भी एक पूरी स्क्रिप्ट बना सकता है, लेकिन पहले से ही वृद्धिशील लोगों के साथ समस्याएं हैं। दुर्भाग्य से, मुझे jpa.ddl=update लिए एनालॉग jpa.ddl=update नहीं मिला। अगर कोई मुझे बताता है, तो मैं बहुत खुश हो जाऊंगा। LiquiBase's Diff का एक एनालॉग या अनुकूलन भी बहुत मददगार होगा।

किराए के ग्रामीण अजीब आदमी बन गए। यह काम करने लगता है, लेकिन आप लगातार आपूर्ति में व्यवधान की प्रतीक्षा कर रहे हैं।
अवधारणा के रूप में ईबेयन बहुत अच्छा है। मुख्य लाभ:

• सत्रों की कमी (सत्र, एंटिटी मैनजर, ​​आदि), जो स्टेटलेस फ्रेमवर्क के साथ अच्छी तरह से फिट बैठता है। हालांकि, इस तरह, एक पर्सेंट कॉन्सेप्ट है।
• आंशिक वस्तुएँ अधिक कुशल प्रश्न लिखने के लिए समर्थन करती हैं।

विवादास्पद मुद्दे:

• आंशिक JPA समर्थन। आपको यह जानने और समझने की आवश्यकता है कि यह समर्थन कहाँ समाप्त होता है।
• प्रलेखन और उपयोग के उदाहरणों की कमी।
• इस तरह के एक सक्रिय विकास नहीं और हाइबरनेट के रूप में बड़े समुदाय के रूप में नहीं।

यहां भी लेन-देन होता है। आप नियंत्रक विधि को भी @Transactional चिह्न के रूप में चिह्नित कर सकते हैं। लेकिन केवल नियंत्रक विधि या नियंत्रक ही। तृतीय-पक्ष कक्षाओं के लिए, आपको पहले से ही इस बात का ध्यान रखना चाहिए।
सामान्य तौर पर, Ebean एक बहुत ही रोचक लाइब्रेरी है, कभी-कभी हाइबरनेट या JPA से भी अधिक सरल और समझने योग्य है, लेकिन मुझे संदेह से छुटकारा नहीं मिल सकता है कि बढ़ती परियोजना की सभी जरूरतों को पूरा करने के लिए पर्याप्त संभावनाएं हैं।
बेशक, आप मानक JPA का उपयोग कर सकते हैं, लेकिन प्ले 1.2.x से Model.find("byName", name) या स्प्रिंग डेटा JPA ^{1 के} साथ एकीकरण गायब है। एक भावना है कि आप पिछले कई वर्षों से लौट रहे हैं।

वैसे, Ebean में कई महत्वपूर्ण कमियां हैं: आप Ebean ORB पृष्ठ के कैविट्स अनुभाग में उनके बारे में अधिक पढ़ सकते हैं। और तथ्य यह है कि प्ले 2.1, गेट्टर / सेटर को उत्पन्न करना बंद कर देता है, यदि कक्षा में कम से कम एक ऐसी हस्तलिखित विधि है, तो get या set साथ शुरू होने वाले तरीकों के नामों से बचना आवश्यक है। byName लिए, मैं अब केवल शब्द को छोड़ देता हूं और byName या byEmail कॉल करता byName ।

लेकिन इस तरह की एक अविश्वसनीय बात, आप एबिन में हत्यारे की सुविधा को भी कह सकते हैं, क्योंकि स्टेटलेसिंग फ्रेमवर्क में पेजिंगलिस्ट लागू नहीं है। काश और आह।

NoSql डेटाबेस के साथ काम करने के लिए, आप आसानी से Elasticsearch, MongoDB (यहां तक ​​कि कुछ टुकड़े) और OrientDB के लिए प्लगइन्स पा सकते हैं। मैंने इसे स्वयं उपयोग नहीं किया है, इसलिए मैं इन प्लग इन की गुणवत्ता के बारे में कुछ नहीं कह सकता।

परीक्षण

दुश्मन की जासूसी से सेना की स्थिति की लगातार जाँच हो रही है। स्थानीय जानवर अभ्यास के संगठन में हस्तक्षेप करते हैं: बंदर नारियल फेंकते हैं, आइवी अपने पैरों को ब्रैड करते हैं, और कभी-कभी कामिकेज़ स्केक पाए जाते हैं।
यह है, कई संभावनाएं हैं: मॉडल की सरल इकाई-परीक्षणों से लेकर नियंत्रक परीक्षण और सेलेनियम का उपयोग करना।
मेरे परीक्षणों में, मैंने दस्तावेज़ीकरण में वर्णित इन-मेमोरी डेटाबेस का उपयोग करने की कोशिश की:

 @Before public void setUp() throws Exception { start(fakeApplication(inMemoryDatabase(""))); } 

हालांकि, मुझे तुरंत दो समस्याएं थीं, बड़ी और छोटी।

छोटा: परीक्षणों में लेनदेन से कैसे निपटें? बसंत या दालों से मुझे मिले कुछ भी नहीं। यह केवल अपने आप को परीक्षणों में वापस खोलने और लेन-देन करने के लिए रहता है। अपरिमेय और अपरिपक्व।

बड़ा एक: इस तथ्य के बीच संघर्ष कि मुख्य आधार MySql है, और इन-मेमोरी H2 परीक्षणों के लिए। इसलिए, H2 MySql के लिए अपविकास स्क्रिप्ट को समझने से इनकार करता है, लेकिन इस तरह से एक गैर-डिफ़ॉल्ट डेटाबेस कॉन्फ़िगरेशन का उपयोग कर रहा है:

 start(fakeApplication(inMemoryDatabase("login-test"))); 

यदि आप कॉन्फ़िगरेशन को निर्दिष्ट किए बिना save() विधि का उपयोग करते हैं, तो डेटा की अनिश्चितता को save() है, जहां डेटा अभी भी सहेजा जाएगा।
मैंने इस समस्या के समाधान के कुछ अस्पष्ट विवरण देखे हैं, लेकिन सादगी वहाँ गंध नहीं करती है।
परीक्षणों में डेटाबेस के काम को कैसे व्यवस्थित किया जाए, इसके बारे में आधिकारिक दस्तावेज कुछ भी नहीं कहते हैं।

अच्छे का। उपयोगी कमांड हैं ~test या ~test-only जो हर बार जब आप स्रोत कोड को बदलते हैं तो काम करेंगे। परीक्षण चलाने के लिए आवश्यक समय बचाता है।

सुरक्षा

राज्य के फोर्ज में केवल सबसे सरल कवच होते हैं। शिल्पकार बहुत बेहतर चीजें बनाते हैं।
प्राधिकरण और प्रमाणीकरण क्षमताएं प्ले 1.2.x पर बनी रहीं। @With एनोटेशन के साथ एक एक्शन @With , Security.Authenticator और इसका उपयोग करने का एक अच्छा उदाहरण है: ऑथेंटिकेशन पेज को जोड़ना , @With को लागू करना।
तृतीय-पक्ष प्लगइन्स अधिक सुविधाएँ प्रदान करते हैं। उदाहरण के लिए, डेडबोल्ट या सिक्योरसोशल , लेकिन वे एक छोटी सी परियोजना के लिए बहुत कसकर लग रहे थे, और मैंने अपने हस्तलिखित प्राधिकरण को पूरी तरह से प्रबंधित किया।
वैसे, यह आश्चर्य की बात है, लेकिन प्ले 2. 0 ने ऑथेंटिसिटी टोकन के रूप में ऐसी उपयोगी सुविधा खो दी है, लेकिन एक तृतीय-पक्ष प्लगइन है जो खोई हुई क्षमताओं के लिए बनाता है। हालाँकि, प्ले 2.1 में कुछ filters जोड़े गए थे, जिनका उल्लेख संस्करण 2.1 के प्रेस विज्ञप्ति में किया गया है, लेकिन जिसके बारे में बहुत कम प्रलेखन है। सिर्फ CSRFFilter उल्लेखित CSRFFilter । उनके बारे में केवल एक चीज यह पोस्ट थी जो बताती है कि स्काला में सीएसआरएफ फिल्टर के साथ कैसे काम किया जाए। कैसे लागू करें और क्या यह सभी 2.1 पर लागू होता है + जावा को अभी भी पता लगाने की आवश्यकता है।

अस्थिरता

कभी-कभी रास्ते में मिरज़े आ जाते थे। पास आते ही वे गायब हो गए। नक्शों पर कोई मृगतृष्णा नहीं थी।
कई बार, पूरी तरह से काम करने वाले कोड ने काम करना बंद कर दिया! जाहिरा तौर पर, संकलन / प्राप्त करने और बसने की पीढ़ी हमेशा सही ढंग से काम नहीं करती है। प्रोजेक्ट को play clean और रीस्टार्ट करने में मदद की।
जो सबसे अजीब बात मुझे पता चली वह यह थी कि JDK 7 लिए मान्य कोड प्रकार JDK 7 :

 catch (IndexOutOfBoundsException | ArrayStoreException e) 

लाया 2.1 पूर्ण बेवकूफ के लिए: कोई त्रुटि नहीं, कोई संदेश नहीं, बस सर्वर इन लाइनों पर जमा देता है और आगे कुछ भी नहीं होता है। यहां एक सवाल पूछा गया , जवाब का इंतजार किया।

टेम्पलेट्स

ऐसे दलदल हैं कि वे अपने सिर के साथ चूस सकते हैं। और वे नहीं चूस सकते हैं।
मुझे स्पष्ट रूप से कहना चाहिए: टेम्प्लेट के प्रभावी उपयोग के लिए आपको स्काला को अच्छी तरह से जानना होगा, या कम से कम इसमें कुछ समझना चाहिए। अन्यथा, यह सब कोड की एक समझ से बाहर की चाल में बदल जाता है। और आपको बहुत सावधान रहना होगा, क्योंकि यह इस तरह काम करता है:

 @main(title = "Home") { <h1>Home page</h1> } 

और इसलिए नई लाइन पर { कारण पहले से ही एक त्रुटि होगी:

 @main(title = "Home") { <h1>Home page</h1> } 

या दूसरा उदाहरण:

 //  @if(user == null) //  ,    : @if (user == null) 

जब मैंने पहली बार प्ले 2.0 में स्काला टेम्प्लेट के बारे में पढ़ा, तो मुझे बहुत खुशी हुई क्योंकि यह .Net से बहुत सुविधाजनक रेजर की तरह लग रहा था। यह वास्तव में जावा दुनिया में कई टेम्पलेट इंजनों की तुलना में अधिक सुविधाजनक और मेरी राय में दिखता है। हालांकि, यह मत भूलो कि आपको सभी इनपुट मापदंडों को पहली पंक्ति के रूप में घोषित करना होगा। और कोड में एक fullName वैरिएबल घोषित करना केवल इस तरह से fullName जा सकता fullName :

 @defining(user.getFirstName() + " " + user.getLastName()) { fullName => <div>Hello @fullName</div> } 

और आपको कुछ चीजों के लिए आयात करने की आवश्यकता है: @import helper._ । और भी बहुत से "इफ़्स" और "बट्स", जिनके भीतर आप बहुत स्वतंत्र महसूस नहीं करते हैं।
मुख्य प्लस स्काला टेम्प्लेट संकलित अवस्था में संकलित और जांचा जाता है, जो अनचाही त्रुटियों और आक्रामक टाइपो की संख्या को कम करता है।
सामान्य तौर पर, चाहे प्ले 2.1 में स्केल टेम्प्लेट अच्छा है या बुरा, एक म्यूट पॉइंट है, लेकिन यह बैकग्राउंड में रिक्रिएट होता है, क्योंकि जावास्क्रिप्ट MVC फ्रेमवर्क लोकप्रियता प्राप्त कर रहा है, और निम्नलिखित प्रासंगिक हो जाता है:

JSON के साथ काम करें

तब बहादुर योद्धा आम तौर पर परेशान था और एक सराय में पीने के लिए गया था।
मेरी राय में, प्ले 2.1. प्ले 1.2.x पर थोड़ा खो देता है। मुख्य कारण यह है कि Gson के बजाय, जैक्सन जावा में JSON के साथ काम करने के लिए मुख्य पुस्तकालय के रूप में उपयोग किया जाता है। मुझे प्ले 1.2.x में GSON के साथ काम करना पसंद था, यह सुविधाजनक और लचीला था। जैक्सन को पूरी तरह से अलग तरीके से काम करने की जरूरत है। जाहिरा तौर पर, मैं अभी तक जैक्सन की समझ के उस स्तर तक नहीं पहुंच पाया हूं कि उसका आनंद ले सकूं। और तथ्य यह है कि JSON स्ट्रिंग में फ़ील्ड नामों को दोहरे उद्धरणों से बच जाना चाहिए, इससे मुझे भारी आघात लगा:

 return ok(Json.parse("{\"status\": \"success\"}")); 

लगभग कोई पठनीयता नहीं है। विशेष रूप से जब ग्रेन्स में JSON के साथ काम करने में आसानी की तुलना में:

 render([result: 'fail'] as JSON) 

बेशक, सब कुछ इतना बुरा नहीं है, लेकिन सबसे अच्छी बात आप जावा में कुछ कर सकते हैं:

 ObjectNode result = Json.newObject(); ArrayNode arrayNode = result.putArray("photos"); for (Photo photo : photos) { ObjectNode photoAsJson = arrayNode.addObject(); photoAsJson.put("id", photo.id); photoAsJson.put("guid", photo.guid); } return ok(arrayNode); 

काफी सहन करने योग्य।
हालांकि, स्काला के लिए, प्ले 2.1 में JSON समर्थन में काफी सुधार किया गया है:

 Json.obj( "users" -> Json.arr( Json.obj( "name" -> "bob", "age" -> 31, "email" -> "bob@gmail.com" ), Json.obj( "name" -> "kiki", "age" -> 25, "email" -> JsNull ) ) ) 

लेकिन ग्रूवी में, यह अभी भी छोटा और सरल दिखता है। यह आशा की जाती है कि स्काला अभी भी मूल JSON समर्थन को जोड़ेगी, क्योंकि यह अब XML के लिए है।
मैंने अपने जीवन को आसान बनाने का फैसला किया, मैंने दो अतिरिक्त वर्गों को स्थिर विधियों के साथ जोड़ा: एक Pair , Tuple2 से Tuple2 का एक एनालॉग, दूसरा वह वर्ग है जो Map में Pair रखता है। परिणामस्वरूप, यह मेरे लिए आसान हो गया:

 return ok(toJson(map( pair("status", "fb-logged-in"), pair("user", map( pair("id", fbUser.id), pair("facebookUserId", fbUser.facebookUser.userId), pair("fullName", fbUser.fullName()) )) ))); 

जब से हम ट्यूपल्स के बारे में बात कर रहे हैं, तब प्ले 2.1 में जावा फंक्शनल के लिए सपोर्ट को प्ले 1.2.x से कॉपी किया जाता है, लाइब्रेरी play.libs.F हालाँकि, इस बारे में आधिकारिक दस्तावेज में कोई उल्लेख नहीं है। हमें प्ले 1.2.x के लिए डॉक देखना चाहिए।

और एक और बात: XML समर्थन भी प्ले 1.2.x से माइग्रेट किया गया, और XML के साथ काम करने के लिए play.libs.XPath का उपयोग करना बहुत सुविधाजनक है।

मेल से काम करें

वाहक कबूतर और कौवे सभी यहां आयात किए जाते हैं। उन्हें प्राप्त करना आसान है और ऐसी अफवाहें हैं कि प्लेटरे II के शासकों ने सभी पक्षियों को खुद को गोली मार ली।
मैं मेल के बारे में कुछ शब्द कहना चाहता हूं क्योंकि प्ले 1.2.x में मेल भेजने के लिए अंतर्निहित समर्थन था, लेकिन प्ले 2.1 में नहीं। मेल के लिए एक आधिकारिक प्लगइन है । यहाँ वे कहते हैं कि रचनाकारों ने स्वयं मेल समर्थन न जोड़ने का निर्णय लिया। कथित तौर पर, यह इतना आसान और सरल है कि हर कोई इसे अपने लिए कर सकता है। Google समूह में बहुत सारे प्रश्न और आक्रोश इस दृष्टिकोण का खंडन करते हैं: लोग प्ले 2.1 से उम्मीद करते हैं कि यह प्ले 1.2.x में इससे कम कार्यक्षमता नहीं है।

विन्यास

यदि पहले अनुबंध स्क्रॉल पर लिखे गए थे, तो अब अलग-अलग पत्तियों पर।
ध्यान देने योग्य मुख्य बात यह है कि उन्होंने framework ID हटा दिया। अब, एक बड़ी कॉन्फ़िगरेशन फ़ाइल के बजाय, आपको कई अलग-अलग होने की आवश्यकता है। विवादास्पद बिंदु, प्रत्येक दृष्टिकोण के पेशेवरों और विपक्ष हैं। यदि production शुरू करने से पहले यह था:
play run --%production
अब यह इस तरह दिखता है:
play -Dconfig.resource=prod.conf start
और prod.conf में बिना किसी उपसर्ग के सभी सेटिंग्स ओवरराइड होती हैं।

आईडीई एकीकरण

मेरे सबसे अच्छे घोड़े ने स्थानीय सड़कों पर अपना पैर जमाया!
मैंने आपको सभी आईडीई के लिए सभी ओडेसा के लिए नहीं कहा था, लेकिन मेरी प्यारी इंटेलीज आइडिया को प्ले 2.x के लिए आदर्श से समर्थन मिला है। कोड नेविगेशन बहुत बार उत्पन्न कक्षाओं की ओर जाता है जिसे आपको देखने और देखने की आवश्यकता नहीं होती है, कभी-कभी स्केला टेम्पलेट संपादित करने में समस्याएं होती हैं, पूर्ण एसबीटी समर्थन केवल संस्करण 13 में उपलब्ध होगा। यहाँ सिर्फ वही हैं जो मैंने स्वयं पाया और रिपोर्ट किया: youtrack.jetbrains.com/issues/SCL?q=reported+by%3A+Andrey.Volkov+
कोड लिखने का सुख पर्याप्त नहीं है। मैं समझता हूं कि प्ले 2.x को बहुत पहले नहीं जारी किया गया था और आईडीई में इसके समर्थन पर बड़े संसाधनों को खर्च करने के लिए उतना लोकप्रिय नहीं हो सकता है। बस इस बात का ध्यान रखें कि आपको आईडीई से बहुत मदद की उम्मीद नहीं करनी चाहिए।
प्ले 1.2.x के साथ, यह बहुत बेहतर है।

सरलता चली गई

यदि Playterre I का देश चमत्कारों से भरा था और जादू की छड़ी की लहर के साथ बहुत कुछ किया गया था, तो Playterra II में कोई जादू नहीं है, केवल एक फावड़ा और एक कुदाल, एक ढाल और एक तलवार है।
प्ले 1.2.x बहुत सरल और सुविधाजनक था। बहुत कुछ अपने आप से किया गया था, और यह काम किया। हां, मैंने राय सुनी कि प्ले 1.2.x में बहुत कुछ हुआ था, बहुत अधिक उत्पन्न हुआ था और सामान्य जावा दुनिया से पूरी तरह से अलग था, लेकिन यह बस, आसानी से और जल्दी से काम किया। सभी जटिलताएं सामान्य उपयोगकर्ताओं से छिपी हुई थीं, और केवल सबसे सावधानीपूर्वक प्रोग्रामर को जटिल स्रोत कोड में खोदना था।
प्ले 2.1 में, लगभग सभी "जादू" को स्काला के लिए छोड़ दिया गया है। और यह अब जादू नहीं है, यह स्काला का स्पष्ट रूप से परिभाषित कार्य है। जिस पर प्रोग्रामर को लगातार ठोकर खाना पड़ता है। और यहां तक ​​कि स्काला की मूल बातों के ज्ञान के बिना, यह पता लगाना बहुत मुश्किल है।
मज़े के लिए तुलना करें:

 public static void index() { render() } 

और

 public static Result login() { return ok( login.render() ); } 

कोड का पहला टुकड़ा सरल है, लेकिन आपको कुछ सम्मेलनों को जानने और उनका पालन करने की आवश्यकता है, और कोड का दूसरा टुकड़ा अधिक क्रिया है, लेकिन आपको कुछ जानने और कुछ का पालन करने की भी आवश्यकता है। दूसरा अधिक लचीला हो सकता है, लेकिन सरल नहीं। मैं व्यक्तिगत रूप से पहले वाले को अधिक पसंद करता हूं।
वैसे, आपको क्या लगता है कि login दूसरे उदाहरण में है? यह स्कैला टेम्पलेट से उत्पन्न एक वर्ग है। जो इस बहुत ही स्कैला टेम्पलेट के संकलन के बाद ही दिखाई देता है। यानी आईडीई शिकायत करेगा कि ऐसा कोई वर्ग नहीं है, या यदि आप कुछ बदलते हैं तो विधि हस्ताक्षर मेल नहीं खाते हैं। संकलन के बाद, शिकायतें गायब हो जाती हैं, लेकिन आईडीई के संकेतों का उपयोग समस्याग्रस्त हो जाता है।
Playterre एक प्रकाश-पंखों वाली परियों और अच्छी आत्माओं से भरा था। Playterra II में केवल यांत्रिक गोले हैं, जिसमें आप प्रत्येक गियर को देख सकते हैं।

निर्विवाद लाभ

कई विषमताओं के बावजूद, यदि दोषों को नहीं कहना है, तो प्ले 2.1 में कई निर्विवाद फायदे हैं।

प्रपत्र और सत्यापन के साथ काम करें

बहुत सहज है। JSR-303 (बीन वैलिडेशन) के लिए पूर्ण समर्थन और विशिष्ट जांच के लिए अपना स्वयं का validate तरीका जोड़ने की क्षमता। मैं आधिकारिक दस्तावेज से उदाहरणों को फिर से नहीं लिखूंगा। आप उन्हें पूरी तरह से यहां देख सकते हैं।
टेम्प्लेट के लिए, input फ़ील्ड की एक अंतर्निहित पीढ़ी है, और आप तुरंत ट्विटर बूटस्ट्रैप के लिए मार्कअप उत्पन्न कर सकते हैं। केवल दया है कि संस्करण 1.4 के लिए। आपको एक कस्टम जनरेटर ( अपने स्वयं के फ़ील्ड निर्माता को लिखना अनुभाग) लिखना होगा ।
यदि प्रामाणिकता टोकन को हटाया नहीं गया था और ट्विटर बूटस्ट्रैप 2.3 फ़ील्ड उत्पन्न किए गए थे, तो यह लगभग आदर्श होगा।

अक्का और अन्य अतुल्यकालिक चीजें

स्थानीय सराय और सराय बहुत तेज सेवा है। और कभी कतार नहीं हैं।
मल्टीस्ट्रेडिंग के लिए अतुल्यकालिक और समर्थन के संदर्भ में, घोडे पर 2.1 खेलो। अकास के साथ अतुल्यकालिक HTTP अनुरोधों और एकीकरण के लिए मूल समर्थन है । यदि केवल जावा वर्बोसिटी का उल्लेख कार्यों के साथ काम करते समय आधिकारिक दस्तावेज में भी नहीं किया गया है ...
बस तुलना कीजिए। जावा:

 public static Result index() { Promise<Integer> promiseOfInt = play.libs.Akka.future( new Callable<Integer>() { public Integer call() { return intensiveComputation(); } } ); return async( promiseOfInt.map( new Function<Integer,Result>() { public Result apply(Integer i) { return ok("Got result: " + i); } } ) ); } 

स्केला:

 def index = Action { val futureInt = scala.concurrent.Future { intensiveComputation() } Async { futureInt.map(i => Ok("Got result: " + i)) } } 

स्काला में स्विच करने का एक और कारण। या कुछ और, लेकिन जावा की तुलना में अधिक "कार्यात्मक"।
हालांकि, प्रतियोगी सो नहीं रहे हैं: ग्रिल्स 2.3 में अतुल्यकालिक कंप्यूटिंग ( आधिकारिक ब्लॉग पर पोस्ट ) के लिए बहुत अच्छा समर्थन होगा। इसके अलावा, एसिंक्रोनस कंप्यूटिंग ग्रूवी पर जावा की तुलना में अधिक सुविधाजनक है: बंद करने के लिए समर्थन एक भूमिका निभाता है।

स्केलेबिलिटी और बादल

यहां की भूमि उपजाऊ है और लगभग किसी भी आबादी को खिला सकती है। और विभिन्न आकार और आकारों के बादल आकाश में तैरते और तैरते दिखाई देते हैं।
यह कहा जाता है कि इसकी अतुल्यकालिक और स्टेटलेस प्रकृति के कारण, 2.1 अच्छी तरह से खेलते हैं। अब तक, मेरी परियोजना ऐसी जरूरतों के लिए नहीं बढ़ी है, इसलिए मैं अपने अनुभव से इसकी पुष्टि नहीं कर सकता।
हां, और प्ले 2.x कई क्लाउड होस्टिंग साइटों द्वारा समर्थित है। इसके अलावा, मूल समर्थन, अर्थात्। युद्ध फाइल बनाने और टॉमकैट / जेट्टी के तहत तैनात करने की कोई आवश्यकता नहीं है।
यदि आपको अभी भी युद्ध-फ़ाइल एकत्र करने की आवश्यकता है, तो आप इसे केवल तृतीय-पक्ष प्लग-इन की मदद से कर सकते हैं।

कॉफीस्क्रिप्ट और कम समर्थन

छोटे राक्षसों को यहां रखा गया था, और अब वे लोगों की ईमानदारी से सेवा कर रहे हैं।
CoffeeScript और कम के लिए मूल समर्थन। मुझे यह भी पता नहीं है कि यहाँ क्या जोड़ा या समझाया जा सकता है। सुविधाजनक। यह सही है। यहां तक ​​कि सब कुछ छोटा भी सरल है: बस .js बजाय .min.js लोड करें।
इससे अभी तक कोई समस्या नहीं हुई है।

कंसोल

Playterra II के प्रवेश द्वार पर सीमा शुल्क ने नए श्रमिकों को काम पर रखा है। हालांकि कौन परवाह करता है, किसी को भी अपने काम को नहीं देखता है उन्हें अच्छा काम करने दें, फिर कोई उन पर ध्यान नहीं देगा।
कंसोल प्ले 1.2.x की तुलना में बहुत अधिक सुविधाजनक और कार्यात्मक हो गया है। लेकिन यह केवल प्ले 2.1 से एसबीटी (स्काला बिल्ड टूल) के क्रेडिट के लिए अधिक है।
जो काम आया, उससे मैं ~ साथ शुरू होने वाली कमांड्स का उल्लेख करना चाहता हूं, जो हर बार स्रोत कोड में परिवर्तन करने पर निष्पादित होते हैं। एक उदाहरण ~test मैं ऊपर उद्धृत।

परिणाम क्या है?

Playterra II में छुट्टी पर जाना दिलचस्प है। प्रवासन का मुद्दा अभी भी काफी खुला है।
अपने लिए, मैंने निम्नलिखित निष्कर्ष दिए:

• प्ले 2.1 को इसकी पूरी क्षमता तक उपयोग करने के लिए, आपको स्काला को अच्छी तरह से जानना होगा।
• जावा में जल्दी से वेब एप्लिकेशन लिखने की आवश्यकता है? प्ले 1.2.x लें। या दाने। ग्रूवी को स्काला को समझना उतना कठिन नहीं है।
• हमें स्काला सीखने की जरूरत है। इसका अध्ययन करना है, क्योंकि जावा और यहां तक ​​कि ग्रूवी से मतभेद बहुत महत्वपूर्ण हैं।
• अन्य प्रोग्रामिंग भाषाओं के पीछे जावा लगभग निराशाजनक है। कार्यात्मक प्रोग्रामिंग का आनंद लेने के लिए जावा में केवल लेखन कोड पर वापस जाना बहुत मुश्किल है। शायद जावा 8 स्थिति को बचाएगा।

---

[१] - ईमानदारी से, स्प्रिंग को प्ले २.१ में एकीकृत करना संभव है, यह बहुत मुश्किल नहीं दिखता है । यानी स्प्रिंग डेटा जेपीए और स्प्रिंग डेटा से अन्य प्रोजेक्ट्स को सैद्धांतिक रूप से जोड़ा जा सकता है, लेकिन मुझे इस विषय पर विशिष्ट उदाहरण और लेख नहीं मिले हैं। उसके हाथ या तो नहीं पहुँचे।
[२] - लेख की तैयारी के दौरान, उन्होंने पाया कि JSON प्रसंस्करण के लिए Java API को EE 7 के लिए लागू किया जाना चाहिए। ओरेकल ब्लॉग पर इस पोस्ट को देखते हुए, यह दिए गए उदाहरण से अधिक सुविधाजनक और बेहतर होगा। ग्रूवी के JSON समर्थन के लिए पर्याप्त बंद करें। केवल भविष्य में यह।