एचटीएमएल रूपों के साथ काम करने के लिए स्काला पर डीएसएल

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

• प्रकार फ़ील्ड, जैसे कि शीर्षक, या वैधता के गुणों को परिभाषित करना
• सबमिट करने के बाद प्रोसेसिंग फॉर्म डेटा;
• रेंडरिंग फॉर्म।

इसके अलावा, यह वांछनीय है कि संकलन चरण में कई त्रुटियों का पता लगाया जाएगा।

इस लेख में, मैं स्काला में अपना स्वयं का डीएसएल बनाने की प्रक्रिया का वर्णन करूंगा, और फिर दिखाऊंगा कि प्ले फ्रेमवर्क 2 के संदर्भ में रूपों का वर्णन करने का नया तरीका कैसे लागू किया जाए।

शब्दावली के बारे में थोड़ा।

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

आलेख में वर्णित डीएसएल मूल रूप से प्ले फ्रेमवर्क 2 में फॉर्म इंजन की कुछ सीमाओं के कारण उत्पन्न हुई समस्याओं को हल करने के लिए बनाया गया था। लेकिन अब यह प्ले से स्वतंत्र है और उपयुक्त एडेप्टर को लागू करने पर किसी भी जेवीएम फ्रेमवर्क के साथ उपयोग किया जा सकता है।

DSL विकास कहाँ से शुरू करें?

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

• मेल - पाठ, अनिवार्य, मेलिंग पते की शुद्धता के लिए सत्यापन;
• नाम - आवश्यक पाठ;
• जन्म की तारीख - तारीख, वैकल्पिक।

इसका वर्णन करने के लिए, आप छद्मकोड में ऐसी प्रविष्टि कर सकते हैं:

form( string(email, required, validate(EmailAddress)) string(name, required) date(birthDate) ) 

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

1. बिल्डर पैटर्न और विधि जंजीर

फार्म के लिए फैक्टरी विधि हस्ताक्षर:

 def form(builderFoo: FormBuilder => FormBuilder) 

का उपयोग करें:

 form(_ .string(...) .string(...) .extend(commonFields) .date(...) ) 

यहां हम बिल्डर और मेथड चेनिंग पैटर्न का उपयोग करते हैं। इससे हमें निम्नलिखित लाभ मिलते हैं:

• आप बिल्डर के सार इंटरफ़ेस का उपयोग करके फ़ॉर्म का विवरण बना सकते हैं - यह आपको आवश्यक होने पर विशिष्ट कार्यान्वयन को बदलने की अनुमति देता है;
• कॉल श्रृंखला का हिस्सा एक अलग फ़ंक्शन में निकाला जा सकता है और विभिन्न रूपों में उपयोग किया जा सकता है;
• कम सहायक कोड लिखने की जरूरत है;
• क्लोजर का प्रकार हस्ताक्षर फॉर्म (...) से अनुमानित है।

आगे देखते हुए, मैं कहूंगा कि यह विकल्प चुना गया था ।

2. मापदंडों के एक चर संख्या के साथ एक समारोह के रूप में

फैक्टरी विधि:

 def form(fields: FormBuilder => FormBuilder*) 

का उपयोग करें:

 form( _.string(...), _.string(...), _.date(...), commonFields:_* ) 

इस विकल्प के कई नुकसान हैं:

• अधिक सहायक कोड लिखने की आवश्यकता;
• अतिरिक्त फ़ील्ड को केवल तर्क सूची के अंत में जोड़ा जा सकता है।

3. कॉल अनुक्रम के साथ कोड ब्लॉक

फैक्टरी विधि:

 def form(fields: => ()) 

 : form{ string(...) date(...) commonFields() } 

यह तरीका बुरा है:

• फॉर्म की परिभाषा के समय, हम स्ट्रिंग, दिनांक और विधियों के विशिष्ट कार्यान्वयन से बंधे हैं।
• इसके कार्यान्वयन के लिए, हमें एक परिवर्तनशील स्थिति के साथ काम करना होगा, जिससे हम बचना चाहेंगे;
• प्रेषित भावों की कोई टाइपिंग नहीं है।

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

खेतों का वर्णन

खेतों के विस्तृत विवरण के लिए, विधि जंजीर और बिल्डर का चयन भी उन्हीं कारणों से किया जाता है।
फ़ील्ड परिभाषा विधि हस्ताक्षर:

 def string(fieldFoo: FieldBuilder => FieldBuilder): FormBuilder 

का उपयोग करें:

 .string(_.name("email").required.validate(EmailAddress)) 

निर्माण कार्यान्वयन का स्केच

स्केला में एक बिल्डर को लागू करने के लिए इसकी स्वचालित रूप से परिभाषित copy विधि के साथ एक case class महान है। यह विधि वर्तमान ऑब्जेक्ट को कॉपी करती है, आवश्यक विशेषताओं को संशोधित करती है। एक व्यक्तिगत क्षेत्र के लिए एक बिल्डर इस तरह दिख सकता है:

 case class FieldBuilderImpl(fieldType: String, label: String, isRequired: Boolean, validators: Seq[Validator]) extends FieldBuilder { def fieldType(t: String): FieldBuilder = copy(fieldType = t) def label(l: String): FieldBuilder = copy(label = l) def required: FieldBuilder = copy(isRequired = true) def validate(vs: Validator*): FieldBuilder = copy(validators = validators ++ vs) def build: FieldDescription = ??? } 

मुख्य रूप पैरामीटर इसके खेतों का एक सेट है, इसलिए इसके लिए बिल्डर थोड़ा अलग दिखेगा:

 case class FormBuilderImpl(fields: Map[String, FieldDescription]) extends FormBuilder { def field[F](name: String)(foo: FieldBuilder[F] => FieldBuilder[F]) = copy(fields = fields ++ Map(name -> foo(newFieldBuilder[F]).asInstanceOf[FieldBuilderImpl[F]].build)) def string(name: String)(foo: FieldBuilder[String] => FieldBuilder[String]) = field[String](name)(foo andThen (_.fieldType("string"))) def newFieldBuilder[F]: FieldBuilder[F] = ??? def build: FormDescription = ??? } 

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

प्रपत्र डेटा की प्रस्तुति

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

प्रपत्र डेटा प्रस्तुत करना case class की एक मिसाल के रूप में सुविधाजनक है। संक्षिप्तता के लिए, हम इसे "प्रपत्र डेटा ऑब्जेक्ट" या केवल "फ़ॉर्म डेटा" कहेंगे। इस क्षेत्र के टाइप किए गए फ़ील्ड द्वारा फॉर्म फ़ील्ड का प्रतिनिधित्व किया जाएगा। इस स्थिति में, हम फॉर्म फ़ील्ड्स को एक क्लोजर से पहचान सकते हैं - फॉर्म डेटा ऑब्जेक्ट के इच्छित फ़ील्ड के (_.someField) उदाहरण के लिए, क्लोजर (_.someField) "someField" नामक फॉर्म फ़ील्ड के अनुरूप होगा।

एक स्ट्रिंग के बजाय एक क्लोजर पास करना एक महत्वपूर्ण लाभ है - यह हमें फॉर्म फ़ील्ड के प्रकार को नियंत्रित करने की अनुमति देता है, क्योंकि हम क्लोजर के प्रकार को जानते हैं। उदाहरण के लिए, UserFormData => String के प्रकार से UserFormData => String हम यह निर्धारित कर सकते हैं कि फॉर्म फ़ील्ड केवल स्ट्रिंग होनी चाहिए।

प्रतिबिंब का उपयोग करके फ़ील्ड नाम प्राप्त करना

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

 form[FormData](_.string( _.someField )(_.someProperty)) 

यानी _.someField को बंद _.someField "someField" नाम प्राप्त करें।
ऐसा करने के लिए एक समारोह में निम्नलिखित हस्ताक्षर हो सकते हैं:
fieldName[T:Manifest](fieldFoo: T => Any): String
संकेतन [T:Manifest] अर्थ है कि पैरामीटर के अतिरिक्त, अंतर्निहित सूची को विधि हस्ताक्षर में जोड़ा जाएगा, जो कंपाइलर से मैनिफेस्ट [टी] प्रकार के तर्क की उम्मीद करता है। वास्तव में, यह JVM में टाइप एरासुरे के रूप में ऐसी घटना पर काबू पाने के लिए एक बैसाखी से ज्यादा कुछ नहीं है। मैनिफ़ेस्ट के साथ, हमें रन टाइम के दौरान एक प्रकार का पैरामीटर (जावा में जेनेरिक क्लास के टाइप वेरिएबल का एनालॉग) प्राप्त करने का अवसर मिलता है।
प्रकट से एक वर्ग प्राप्त करने के बाद, हम इसे एक गतिशील प्रॉक्सी प्रॉक्सीबॉज से proxyObject : एक वस्तु जो हमारे पास दिए गए प्रकार को संतुष्ट करती है, जिसका एकमात्र कार्य पहले विधि के नाम को रिपोर्ट करना है। यदि क्लोजर (_: T).someField को fieldFoo: T => Any रूप में पास किया fieldFoo: T => Any , तो fieldFoo(proxyObject) कॉल करने से हमें स्ट्रिंग "someField" । ये कार्रवाई स्काला-रिफ्लेक्टिव-टूल्स लाइब्रेरी में की गई।
इसका उपयोग कुछ इस तरह दिखता है:

 case class MyClass(fieldA: String) import FieldNameGetter._ assertTrue $[MyClass](_.fieldA) == "fieldA" 

अब हम फॉर्म बिल्डर को इस तरह से फिर से लिख सकते हैं:

 case class FormBuilderImpl[T:Manifest](fields: Map[String, FieldDescription]) extends FormBuilder[T] with FieldNameGetter { def field[F](fieldFoo: T => F)(foo: FieldBuilder[F] => FieldBuilder[F]) = copy(fields = fields ++ Map($[T](fieldFoo) -> foo(newFieldBuilder[F]).asInstanceOf[FieldBuilderImpl[F]].build)) def string(fieldFoo: T => String)(foo: FieldBuilder[String] => FieldBuilder[String]) = field[String](fieldFoo)(foo andThen (_.fieldType("string"))) ... } 

प्रपत्र फ़ील्ड आवश्यक और वैकल्पिक हो सकते हैं। हम मामले की श्रेणी में क्षेत्र की वैकल्पिकता की संपत्ति को दर्शा सकते हैं, इसी क्षेत्र को टाइप विकल्प दे […]।
उदाहरण के लिए, हमारे फॉर्म के लिए, एक केस क्लास इस तरह दिख सकता है:

 case class RegistrationFormData( name: String, surname: Option[String], email: String, birthDate: Option[Date] ) 

name फ़ील्ड का गेट्टर प्रकार है RegistrationFormData => String , और surname गेट्टर प्रकार है RegistrationFormData => Option[String] । तदनुसार, खेतों को निर्धारित करने के लिए हमारे पास दो तरीके होने चाहिए।
आवश्यक के लिए:
(def string(fieldFoo: T => String)(foo: FieldBuilder[String] => FieldBuilder[String])
वैकल्पिक के लिए:
def stringOpt(fieldFoo: T => Option[String])(foo: FieldBuilder[String] => FieldBuilder[String])
प्रत्येक प्रकार के क्षेत्र (बूलियन को छोड़कर) के लिए, दोनों विकल्पों की आवश्यकता होती है। हम string विधि को अनुकूलित करते हैं, इसमें required संपत्ति की घोषणा करते हैं। करी का उपयोग करते हुए, मैं एक काफी कॉम्पैक्ट कोड प्राप्त करने में कामयाब रहा:

 case class FormBuilderImpl[T: Manifest](fields: Map[String, FieldDescription]) extends FormBuilder[T] with FieldNameGetter { //    : type FieldFoo[F] = FieldBuilder[F] => FieldBuilder[F] type FormField[F] = FieldFoo[F] => FormBuilder[T] //    def string(fieldFoo: T => String): FormField[String] = fieldBase[String](fieldFoo)(_.required) //    def stringOpt(fieldFoo: T => Option[String]): FormField[String] = fieldBase[String](fieldFoo)(identity) def field[F](fieldName: String)(foo: FieldFoo[F]) = copy(fields = fields ++ Map(fieldName -> foo(newFieldBuilder[F]).asInstanceOf[FieldBuilderImpl[F]].build)) def fieldBase[F: Manifest](fieldFoo: T => Any) (innerConfigFoo: FieldFoo[F]) (userConfigFoo: FieldFoo[F]) = field($[T](fieldFoo))(innerConfigFoo andThen (_.fieldType(fieldTypeBy[F])) andThen userConfigFoo) ... } 

इसके अलावा, यहां हम टाइप पैरामीटर का उपयोग करके fieldType टाइप संपत्ति को परिभाषित करते हैं।

DSL विस्तार

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

निम्नलिखित विधि को FieldBuilder जोड़ें:
def addProperty(key: String, value: Any): FieldBuilder[T]
अगला, हम इसके माध्यम से संपूर्ण फ़ील्ड कॉन्फ़िगरेशन सेट करेंगे। हमारे डीएसएल के उपयोगकर्ता इसे सीधे एक्सेस नहीं करेंगे, यूजर एपीआई फॉर्म के निहितार्थ- प्रकार कन्वर्टर्स बना देगा:

 object FieldDslExtenders { import FieldAttributes._ implicit class StringFieldBuilderExtender(val fb: FieldBuilder[String]) extends AnyVal { def minLength(length: Int) = fb.addProperty(MinLength, length) def maxLength(length: Int) = fb.addProperty(MaxLength, length) } implicit class SeqFieldBuilderExtender[A](val fb: FieldBuilder[Seq[A]]) extends AnyVal { ... } implicit class DateFieldBuilderExtender(val fb: FieldBuilder[Date]) extends AnyVal { def format(datePattern: String) = fb.addProperty(DatePattern, datePattern) } } 

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

सब कुछ हमारे FormBuilder साथ परिपूर्ण नहीं है: इसकी मदद से, आप अभी के लिए फ़ील्ड प्रकारों का एक बहुत सीमित सेट जोड़ सकते हैं। यह स्पष्ट है कि सभी सबसे आम प्रकारों को जोड़ना मुश्किल नहीं है, लेकिन क्या होगा यदि उपयोगकर्ताओं को एक नए प्रकार के फ़ील्ड की आवश्यकता होती है जो FormBuilder में नहीं है? इस समस्या को सभी समान अंतर्निहित वें कन्वर्टर्स की मदद से हल किया जा सकता है जो बेस fieldBase विधि का उपयोग करते हैं। उनकी मदद से, हम FormBuilder विस्तार कर सकते हैं - उदाहरण के लिए, हम एक तिथि के साथ एक फ़ील्ड बनाने के लिए एक विधि जोड़ सकते हैं:

 object FormDslExtensions extends FieldNameGetter { val defaultDateFormat = new SimpleDateFormat("dd.MM.yyyy").toPattern import FieldDslExtenders._ implicit class DateFormExtension[T: Manifest](val fb: FormBuilder[T]) extends AnyVal { def dateOpt(fieldFoo: T => Option[Date]) = fb.fieldBase[Date](fieldFoo)(_.format(defaultDateFormat)) _ def date(fieldFoo: T => Date) = fb.fieldBase[Date](fieldFoo)(_.required.format(defaultDateFormat)) _ } } 

फॉर्म का आंतरिक प्रतिनिधित्व

हमारे बिल्डरों के काम के परिणामस्वरूप, हमें फॉर्मडेसक्रिप्शन फॉर्म का विवरण ऑब्जेक्ट मिलता है जिसमें String -> FieldDescription । बदले में, FieldDescription में एक String -> Any नक्शा होता है। इस प्रकार, हम उन फ़ील्ड्स को किसी भी विशेषता पर सेट कर सकते हैं जिनकी आवश्यकता हो सकती है। फॉर्म का परिणामी विवरण, मेरी राय में, पूरी तरह से फ्रेमवर्क-अज्ञेयवादी है, अर्थात्। विभिन्न चौखटे के साथ इस्तेमाल किया जा सकता है। उपयोग की जाने वाली रूपरेखा के स्वरूप में रूपांतरण को लागू करने के लिए सभी आवश्यक है। इसके बाद, हम देखेंगे कि यह प्ले फ्रेमवर्क के लिए कैसे किया गया था।

एकीकरण खेलें

प्ले पहले से ही एक तंत्र है जो बहुत जटिल रूपों के लिए सुविधाजनक नहीं है। लेकिन इसकी निम्नलिखित सीमाएँ हैं:

• 18 क्षेत्रों में प्रतिबंध;
• केवल फ़ील्ड और सत्यापन के प्रकार को निर्दिष्ट करने की क्षमता;
• एकाधिक पसंद फ़ील्ड की कमी (लेखन के समय, जल्द ही उपलब्ध होनी चाहिए)।

फ़ॉर्म सबमिट करते समय, Play एक HTTP अनुरोध प्राप्त करता है, इसे deserializes और Map[String, Seq[String]] रूप में अनुरोध पैरामीटर प्रस्तुत करता है। तब उन्हें मान्य किया जाएगा और कस्टम कोड के लिए एक उपयुक्त दृश्य में परिवर्तित किया जाएगा। अंतर्निहित प्ले टूल आपको इस डेटा को टपल में या एक मनमानी वस्तु में परिवर्तित करने की अनुमति देते हैं - इसके लिए, हालांकि, आपको इसे बनाने का कार्य प्रदान करना होगा। यदि प्रपत्र में पर्याप्त फ़ील्ड हैं, तो इससे संभावित त्रुटि-समृद्ध कोड हो सकता है। कल्पना करें: आपको यह सुनिश्चित करने की आवश्यकता है कि 18 फ़ंक्शन तर्क सही क्रम में हैं।

कच्चे डेटा को मान्य और रूपांतरित करने के लिए, प्ले मैपिंग क्लास का उपयोग करता है।
प्ले में निर्मित प्रपत्रों की मैपिंग अलग-अलग कंस्ट्रक्टर तर्कों के रूप में फ़ील्ड्स के मैप मैपिंग प्राप्त करती है (उदाहरण के लिए: ObjectMapping9 ), इसलिए एक फॉर्म में इसकी परिभाषा के समय निर्दिष्ट फ़ील्ड का केवल एक निश्चित रूप से निर्धारित सेट हो सकता है। हमारी कक्षा, जिसे हम फॉर्ममैपिंग कहेंगे , एक अनियंत्रित क्षेत्र के साथ काम कर सकती है। दूसरी ओर, इसे पास किए गए फ़ील्ड टाइपिंग खो देते हैं, लेकिन यह डरावना नहीं है, क्योंकि FormMapping उद्देश्य मैन्युअल रूप से फ़ील्ड के साथ काम करना नहीं है। फ़ील्ड्स की टाइपिंग डीएसएल द्वारा गारंटीकृत है, और फॉर्म डेटा ऑब्जेक्ट और इसके विपरीत में रूपांतरण प्रतिबिंब का उपयोग करके स्वचालित है।

प्ले पर फॉर्म केस क्लास play.api.data.Form का उपयोग करके दर्शाए जाते हैं , और फ़ील्ड play.api.data.Field हैं । प्रपत्रों और क्षेत्रों का हमारा कार्यान्वयन इन वर्गों से विरासत में मिला होगा, क्योंकि हमें पुराने एपीआई के साथ संगतता हासिल करने की आवश्यकता है। एक नया attributes फ़ील्ड प्रपत्र फ़ील्ड में दिखाई देगा - इसकी सहायता से अतिरिक्त पैरामीटर स्थानांतरित किए जाएंगे।

उदाहरण का उपयोग करें

आकार परिभाषा:

  PlayFormFactory.form[FormData](_.string(_.name)(_.label("").someAttribute(42)) 

फॉर्म के साथ टेम्प्लेट:

 @(form: com.naumen.scala.forms.play.ExtendedForm[RegistrationFormData]) <div> .... @myComponent(form(_.name)) .... </div> 

MyComponent घटक टेम्पलेट:

 @(customField: com.naumen.scala.forms.play.ExtendedField) <div> .... @customField.ext.attrs("someAttribute") .... </div> 

प्रपत्र का निर्धारण करने के चरण में मनमाना क्षेत्र मापदंडों को निर्दिष्ट करने की क्षमता आपको टेम्पलेट में लेआउट पर ध्यान केंद्रित करने और गैर-लेआउट मापदंडों की परिभाषा नियंत्रक को स्थानांतरित करने की अनुमति देती है।