खेलने के लिए! लिफ्ट! Srsly?

खेलने के लिए! और लिफ्ट, ये दो रूपरेखाएं हैं, जहां स्काला वेब डेवलपर्स का मुख्य प्रवाह हो रहा है। सच में, स्काला के लिए स्टैक ओवरफ्लो फ्रेमवर्क को देखने का प्रयास करें और आप समझ जाएंगे कि मैं सही हूं। मेरा मानना ​​है कि जटिल हार्वेस्टर से तंग आ चुके लोगों का प्रतिशत अधिक है, इसलिए मैं "अन्य" Xitrum ढांचे के बारे में बात करूंगा ।

दर्शन में Xitrum उनके बिल्कुल विपरीत है, यह एक न्यूनतावादी ढांचा है जिसका लक्ष्य सीधे सामग्री वितरित करना है। इसमें कोई जादू नहीं है और सम्मेलन द्वारा कोई प्रोग्रामिंग नहीं है। इसकी अतिसूक्ष्मवाद द्वारा, यह स्कैलट्रा के करीब है, लेकिन इसके विपरीत, यह पूरी तरह से अतुल्यकालिक है, क्योंकि Netty (v4) और अक्का के आधार पर बनाया गया (अब एक साल से अधिक समय से मैं स्कैलात्रा का अनुसरण कर रहा हूं और अभी भी Netty के लिए कोई समर्थन की घोषणा नहीं की गई है)। लेकिन चिंतित मत हो, प्रविष्टि के लिए सीमा बेहद कम है - अभिनेता केवल वैकल्पिक हैं, हालांकि वे ढांचे के पक्ष में एक महत्वपूर्ण प्लस हैं।

तुरंत प्रदर्शन पर। न्यूनतम कॉन्फ़िगरेशन में, xitrum 64Mb की मेमोरी सीमा के साथ शुरू और चलता है। CPU समय लागत महत्वपूर्ण नहीं हैं, अर्थात् फ्रेमवर्क स्वयं प्रोसेसर को लोड नहीं देता है। बाकी सब आपके ऊपर है।



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



तो xitrum:

• टिपो सुरक्षित (टाइपसेफ़) हर तरह से जहाँ संभव हो
• पूरी तरह से अतुल्यकालिक। किसी अनुरोध को तुरंत प्रतिक्रिया भेजने के लिए आवश्यक नहीं है; आप तैयार होने पर जटिल गणना चला सकते हैं और जवाब दे सकते हैं। लॉन्ग पोलिंग, चंकड रिस्पांस, वेबसॉकेट्स, सॉकज, इवेंटस्ट्रीम जैसी चीजें लागू करने में बहुत आसान हैं।
• बहुत ही उत्पादक, स्टेटिक्स निग्नेक्स के प्रदर्शन में तुलनीय है
• आवेदन के मार्गों (मार्गों) की स्वचालित विधानसभा, किसी भी xml और इतने पर शुरू करने की आवश्यकता नहीं है
• अनुरोध, सत्र और कुकी मापदंडों की सरल हैंडलिंग
• पूर्व और बाद के फिल्टर
• प्रतिक्रिया कैशिंग के लिए अंतर्निहित समर्थन (रेल शैली में), ETag समर्थन
• स्वैगर डॉक्टर के आधार पर एक RESTful API, अंतर्निहित प्रलेखन समर्थन विकसित करने के लिए बढ़िया है
• यदि वे बदलते हैं तो ट्रांसलेशन की डायनामिक रीलोडिंग के साथ GNU- आधारित I18N गेटटेक्स्ट। स्रोत से पॉट फ़ाइलों का स्वचालित जनरेटर
• मॉड्यूलरिटी - xitrum स्वचालित रूप से सभी जार निर्भरता से मार्गों को जोड़ती है
• ऑन-डिमांड, प्लग-इन प्रकार-सुरक्षित स्कैलेट टेम्पलेट इंजन या आपको जो भी पसंद है

Xitrum नियंत्रक-पहला ढांचा है। रनटाइम के दौरान नियंत्रक विचारों को गतिशील रूप से बदलना बहुत आसान है, जो कुछ स्काला / जावा फ्रेमवर्क के लिए तुच्छ नहीं है। मेरी स्मृति में, यह आमतौर पर जावा दुनिया से एकमात्र फ्रेमवर्क है जो सीएमएस को बिना किसी बैसाखी के गतिशील टेंपलेटिंग के साथ लिखने की अनुमति देता है।

मुझे लगता है कि पाठक को फ्रेमवर्क की मूल बातों से परिचित कराना उचित होगा, मैं एक और बार जटिल चीजों का वर्णन करूंगा अगर इसमें रुचि हो।

सरल नियंत्रक

एक्सट्रम में, प्रत्येक अनुरोध को केवल एक्शन से इनहेरिटर द्वारा संसाधित किया जा सकता है। अर्थात्, हमारे सर्वर द्वारा संसाधित प्रत्येक स्वतंत्र मार्ग के लिए, हमें एक अलग नियंत्रक वर्ग घोषित करना चाहिए।

 import xitrum.Action import xitrum.annotation.GET @GET("url/to/HelloAction") class HelloAction extends Action { def execute() { respondHtml( <xml:group> <p>Hello world!</p> </xml:group> ) } } 

सर्वर पर आने वाले प्रत्येक नए अनुरोध को कक्षा के एक नए उदाहरण द्वारा संसाधित किया जाएगा, अर्थात, इन वर्गों में राज्य को संग्रहीत करने का कोई मतलब नहीं है। इस तथ्य को समझना बहुत महत्वपूर्ण है कि अनुरोध प्रसंस्करण अतुल्यकालिक है। जब तक आप प्रतिसाद * () विधि को कॉल नहीं करते, तब तक क्लाइंट से कनेक्शन बंद नहीं होगा और क्लाइंट आपकी प्रतिक्रिया की प्रतीक्षा करेगा, संभवतः हमेशा के लिए। निष्पादन विधि को नेटी थ्रेड पर निष्पादित किया जाता है, इसलिए आपको इसमें लंबा ऑपरेशन नहीं करना चाहिए, उदाहरण के लिए:

 @GET("url/to/HelloAction") class HelloAction extends Action { def execute() { Thread.sleep(1000) // :    Netty  respond() } } 

नियंत्रक के इस कार्यान्वयन के साथ, आपका सर्वर प्रति सेकंड 1 से अधिक कनेक्शन की सेवा देने में सक्षम होने की संभावना नहीं है। इस समस्या को हल करने के लिए आपको FutureAction या ActorAction का उपयोग करना होगा।

• कार्रवाई - एक्सटी विधि को सीधे नेट्टी थ्रेड में निष्पादित किया जाएगा
• FutureAction - निष्पादित विधि को एक अलग थ्रेड (एक्का सिस्टम डिस्पैचर) में निष्पादित किया जाएगा
• एक्टोरिएशन - एक नियमित अभिनेता एक नियंत्रक के रूप में कार्य करता है

मार्ग

Xitrum GET, POST, और अधिक का उपयोग करके सभी प्रकार के HTTP अनुरोधों का समर्थन करता है। कोई भी नियंत्रक असीमित संख्या में मार्गों को संभाल सकता है। आप पहले और अंतिम एनोटेशन का उपयोग करके नियंत्रकों के क्रम को निर्धारित कर सकते हैं। डिफ़ॉल्ट नियंत्रक को METHOD (": *") के रूप में परिभाषित किया गया है

 @GET("url1") @First class A extends Action { ... } @GET("url1", "url2", "...") @POST("url1", ...) class B extends Action { ... } @GET(":*") @Last class Default extends Action { ... } 

नियंत्रक का संदर्भ प्राप्त करने के लिए, एक्शन एक यूआरएल विधि प्रदान करता है जो मापदंडों के साथ एक जीईटी लिंक उत्पन्न करता है।

 url[HelloAction]("name" -> "caiiiycuk") // url/to/HelloAction?name=caiiiycuk 

सार्वजनिक या classpath निर्देशिका से स्थिर संसाधनों का लिंक क्रमशः publicUrl और resourceUrl विधियों का उपयोग करके प्राप्त किया जा सकता है। क्लासिक रीडायरेक्ट फॉरवर्डटो और रीडायरेक्टो जैसे समर्थित हैं ।

पैरामीटर विश्लेषण

Xitrum आपको तीन प्रकार के मापदंडों के साथ पारदर्शी रूप से काम करने की अनुमति देता है:

• uriParams - 'के बाद पैरामीटर?' (उदाहरण के लिए: example.com/blah ? x = 1 और y = 2 )
• bodyParams - पैरामीटर POST अनुरोध के शरीर में पारित कर दिया
• pathParams - url में एन्कोडेड पैरामीटर (उदाहरण के लिए: example.com/article/ : id )

मापदंडों तक पहुंच बहुत सरल है:

 param("X") //   X  String,      params("X") //   X  List[String],      paramo("X") //   X  Option[String] paramso("X") //   X  Option[List[String]] param[Type]("X") //   X  [Type],      params[Type]("X") //   X  List[[Type]],      paramo[Type]("X") //   X  Option[[Type]] paramso[Type]("X") //   X  Option[List[[Type]]] 

pathParams को प्रतीक का उपयोग करके रेल के साथ समानता से निर्धारित किया जाता है: '(: id ,: लेख ,: आदि), इसके अलावा, पैरामीटर मान' <> '(उदाहरण के लिए: आईडी <0-9) + में संलग्न नियमित अभिव्यक्तियों का उपयोग करके सीमित किए जा सकते हैं। >)।

 @GET("articles/:id<[0-9]+>", "articles/:id<[0-9]+>.:format") class ArticlesShow extends Action { def execute() { val id = param[Int]("id") val format = paramo("format").getOrElse("json") ... } } 

कभी-कभी POST अनुरोध के मुख्य भाग के बाइनरी डेटा को पढ़ना आवश्यक हो जाता है, यह इस प्रकार किया जाता है:

 val body = requestContentString //  String val bodyMap = requestContentJson[Type] //  Json,  Type val raw = request.getContent //  ByteBuf 

मानकीकरण

Xitrum में एक अंतर्निहित टेम्पलेट इंजन नहीं है, टेम्पलेट इंजन के बिना निम्नलिखित प्रतिक्रिया प्रकार उत्पन्न करना संभव है:

• responseText - स्ट्रिंग "प्लेन / टेक्स्ट" के साथ उत्तर दें
• responseHtml - स्ट्रिंग "टेक्स्ट / html" के साथ उत्तर दें
• responseJson - Scala ऑब्जेक्ट को Json string में बदलें
• responseBinary - बाइनरी डेटा
• responseFile - शून्य-प्रतिलिपि (सेंड-फाइल) का उपयोग करके फ़ाइल भेजें
• कम महत्वपूर्ण - responseJs, responseJsonP, responseJsonText, responseJsonPText, responseEventSource

मानकीकरण के लिए , आप स्केलेट का उपयोग कर सकते हैं, यह एक टेम्पलेट प्रोजेक्ट में जुड़ा हुआ है। टेम्पलेट इंजन कई अलग-अलग सिंटैक्स का समर्थन करता है: मूंछें, स्कैटल, जेड और एसपीएस। मैं ssp का उपयोग करना पसंद करता हूं क्योंकि यह html के सबसे करीब है। टेम्प्लेट प्रोजेक्ट में, जेड कॉन्फ़िगर किया गया है, ताकि आपको xitrum.conf कॉन्फ़िगरेशन में सिंटैक्स प्रकार को बदलने की आवश्यकता हो, लाइन को डिफ़ॉल्ट टाइप करें = जेड को डिफ़ॉल्ट टाइप = एसपीएस के साथ बदलें।



प्रत्येक नियंत्रक के लिए स्कैलेट का उपयोग करते समय, आप अपने स्वयं के दृष्टिकोण को परिभाषित कर सकते हैं। स्कैलेट नियमों के अनुसार, टेम्पलेट का मार्ग नियंत्रक पैकेज के अनुरूप होना चाहिए।

 src/main/scala/quickstart/action/SiteIndex.scala #   src/main/scalate/quickstart/action/SiteIndex.ssp #   src/main/scalate/quickstart/action/SiteIndex/ #    package quickstart.action import xitrum.annotation.GET @GET("") class SiteIndex extends DefaultLayout { def execute() { respondView() } } 

जैसा कि आप देख सकते हैं, SiteIndex.ssp ​​टेम्प्लेट प्रदर्शित करने के लिए, बस responseView () कॉल करें। एक टुकड़े की अवधारणा प्रदान की जाती है, इसकी मदद से आप नियंत्रक के प्रतिनिधित्व को बदल सकते हैं।

 @GET("") class SiteIndex extends DefaultLayout { def execute() { respondHtml(renderFragment("some")) #      } } 

Xitrum दृश्य और नियंत्रक के सख्त पत्राचार पर प्रतिबंध नहीं लगाता है, इसलिए एक ही दृश्य का उपयोग विभिन्न नियंत्रकों में किया जा सकता है। नतीजतन, डिफ़ॉल्ट रूप से, टेम्पलेट्स में एक्शन बेस विशेषता से केवल तरीकों का उपयोग करने की क्षमता होती है। डेटा को मेथड एट एट मेथड के जरिए ट्रांसफर किया जा सकता है।

नियंत्रक	टेम्पलेट
def execute() { at("login") = "caiiiycuk" at("rating") = 5 respondView() }	Hello ${at("login")} You rating is ${at("rating")}

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

नियंत्रक	टेम्पलेट
def random = Random.nextInt def execute() { respondView() }	<% val myAction = currentAction.asInstanceOf[MyAction]; import myAction._ %> You random number is ${random}

एटजोन विधि कुछ रुचि की है - यह स्वचालित रूप से मॉडल को जोंस में परिवर्तित कर देती है, जो सीधे जावास्क्रिप्ट में डेटा स्थानांतरित करते समय बहुत उपयोगी होती है।

नियंत्रक	टेम्पलेट
case class User(login: String, name: String) ... def execute() { at("user") = User("admin", "Admin") respondView() }	<script type="text/javascript"> var user = ${atJson("user")}; alert(user.login); alert(user.name); </script>

सत्र और कुकीज़

कंट्रोलर के अंदर, आपको कुकी को एक्सेस करने के लिए रिक्वेस्टसुकिएस वैरिएबल का उपयोग करने की आवश्यकता है, और एक नया कुकी सेट करने के लिए क्रमशः, क्रमशः प्रतिक्रिया करें ।

 //  requestCookies.get("myCookie") match { case None => ... case Some(string) => ... } //  responseCookies.append(new DefaultCookie("name", "value")) 

Xitrum स्वचालित रूप से कुकीज़ में सत्र को बचाता है, पुनर्स्थापित करता है, और एन्क्रिप्ट करता है। सत्र चर के माध्यम से सत्र के साथ काम किया जाता है।

 session.clear //   session("userId") = 1 //   session.isDefinedAt("userId") //   session("userId") //    

फिल्टर

फ़िल्टर के उपयोग से अनुरोध प्रसंस्करण को और अधिक नियंत्रित किया जा सकता है, कुल में तीन हैं: फ़िल्टर से पहले , फ़िल्टर और उसके बाद फ़िल्टर । इससे पहले कि किसी भी रिक्वेस्ट प्रोसेसिंग से पहले फाइटर को निष्पादित किया जाए, यदि वह गलत हो जाता है, तो इस कंट्रोलर द्वारा रिक्वेस्ट की कोई और प्रोसेसिंग नहीं की जाएगी। इसके विपरीत, afterFilters अंतिम निष्पादित किए जाते हैं।

 before1 -true-> before2 -true-> +--------------------+ --> after1 --> after2 | around1 (1 of 2) | | around2 (1 of 2) | | action | | around2 (2 of 2) | | around1 (2 of 2) | +--------------------+ 

उदाहरण, अनुरोध को संसाधित करने से पहले एक अंतर्राष्ट्रीयकरण भाषा को परिभाषित करना।

 beforeFilter { val lango: Option[String] = yourMethodToGetUserPreferenceLanguageInSession() lango match { case None => autosetLanguage("ru", "en") case Some(lang) => setLanguage(lang) } true } def execute() { ... } 

कैशिंग

इसलिए, अनुरोध प्रसंस्करण को निम्नानुसार सरल किया गया है: (1) अनुरोध -> (2) फ़िल्टर से पहले -> (3) फ़िल्टर के बाद नियंत्रक विधि -> (4) निष्पादित करें -> (5) प्रतिक्रिया। Xitrum में CachePageMinute एनोटेशन और सीधे (3) मेथड का उपयोग करके संपूर्ण अनुरोध प्रोसेसिंग चेन (2 - 3 - 4 - 5) को कैश करने के लिए अंतर्निहित क्षमताएं हैं, - CacheActionMinute एनोटेशन। कैश जीवनकाल मिनटों में इंगित किया गया है। केवल 200 ओके की स्थिति के साथ प्रतिक्रियाएं कैश में मिलती हैं।

 import xitrum.Action import xitrum.annotation.{GET, CacheActionMinute, CachePageMinute} @GET("articles") @CachePageMinute(1) class ArticlesIndex extends Action { def execute() { ... } } @GET("articles/:id") @CacheActionMinute(10) class ArticlesShow extends Action { def execute() { ... } } 

डिफ़ॉल्ट रूप से, फ्रेमवर्क कैशिंग के लिए अपने Lru कैश कार्यान्वयन का उपयोग करता है। हालांकि, कॉन्फ़िगरेशन में कैशिंग तंत्र के कार्यान्वयन को आसानी से बदला जा सकता है। एक गुच्छेदार कैश के लिए, हेज़ेलकास्ट, कनेक्शन के तरीके , सबसे उपयुक्त हैं।

एनोटेशन के अलावा, एक्सट्रम कैश ऑब्जेक्ट तक पहुंच प्रदान करता है। इसका उपयोग आपके डेटा को कैश करने के लिए किया जा सकता है।

 import xitrum.Config.xitrum.cache // Cache with a prefix val prefix = "articles/" + article.id cache.put(prefix + "/likes", likes) cache.put(prefix + "/comments", comments) // Later, when something happens and you want to remove all cache related to the article cache.remove(prefix) 

कैश ऑब्जेक्ट द्वारा प्रदान की गई विधियाँ

• put (की, वेल्यू) - अनिश्चित काल तक कैश में "की, वैल्यू" की एक जोड़ी रखें
• putSecond, putMinute, putHour, putDay (कुंजी, मूल्य, अंतराल) - समय की निश्चित अवधि के बाद कैश से मूल्य निकाल दिया जाएगा
• putIfAbsent, putIfAbsentSecond, putIfAbsentMinute, putIfAbsentHour, putIfAbsentDay - एक ही बात, कैश में केवल अगर यह पहले से ही समाहित है तो मूल्य अपडेट नहीं किया जाएगा।

रेस्टफुल एपीआई

स्पष्ट रूटिंग के लिए धन्यवाद, RESTful API का कार्यान्वयन तुच्छ है। स्वैगर का उपयोग करके समर्थित बॉक्स एपीआई प्रलेखन में से

 import xitrum.{Action, SkipCsrfCheck} import xitrum.annotation.{GET, Swagger} @Swagger( Swagger.Note("Dimensions should not be bigger than 2000 x 2000") Swagger.OptStringQuery("text", "Text to render on the image, default: Placeholder"), Swagger.Response(200, "PNG image"), Swagger.Response(400, "Width or height is invalid or too big") ) trait ImageApi extends Action with SkipCsrfCheck { lazy val text = paramo("text").getOrElse("Placeholder") } @GET("image/:width/:height") @Swagger( // <--   ImageApi Swagger.Summary("Generate rectangle image"), Swagger.IntPath("width"), Swagger.IntPath("height") ) class RectImageApi extends Api { def execute { val width = param[Int]("width") val height = param[Int]("height") // ... } } @GET("image/:width") @Swagger( // <--   ImageApi Swagger.Summary("Generate square image"), Swagger.IntPath("width") ) class SquareImageApi extends Api { def execute { val width = param[Int]("width") // ... } } 

रन समय में, xitrum swagger.json उत्पन्न करेगा जो स्वैगर UI में आसानी से प्रलेखन देखने के लिए उपयोग किया जा सकता है।

महत्वपूर्ण : सभी POST अनुरोधों के लिए, CSRF हमलों से सुरक्षा प्रदान की जाती है, इसलिए आपको किसी भी POST अनुरोध के साथ csrf-token पास करना होगा, या SkipCsrfCheck विशेषता से विरासत का उपयोग करके इस सुरक्षा को स्पष्ट रूप से अक्षम करना होगा। सीएसआरएफ-टोकन का उपयोग करने के बारे में अधिक जानें।



यदि आप इस लेख को अंत तक पढ़ते हैं, तो मुझे लगता है कि अब आप ढांचे की कार्यक्षमता के बारे में 70% जानते हैं। और यह मुझे लगता है कि मेरे विचार की पुष्टि करता है कि प्रवेश सीमा बहुत कम है। इसलिए, मैं सुझाव देने और सवाल पूछने की सलाह देता हूं।

आप पाठ्यपुस्तक में हमेशा आधिकारिक वेबसाइट पर बाकी सामग्री देख सकते हैं। प्रश्न जो मैं बताना चाहूंगा:

• JRebel के साथ एकीकरण
• ActorAction का उपयोग करना
• postbacks
• WebScoket, SockJS, EventSource
• तैनाती

सूत्रों का कहना है

• प्रलेखन
• Google समूह
• आधिकारिक वेबसाइट