फॉर्म का मूल विवरण. प्रबंधित प्रपत्र विवरण (1Cv8) 1c प्रबंधित प्रपत्र प्रोग्रामेटिक रूप से विवरण जोड़ते हैं

प्रपत्र विवरण

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

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

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

प्रपत्र विस्तार- ये प्रबंधितफॉर्म ऑब्जेक्ट के अतिरिक्त गुण, विधियां और फॉर्म पैरामीटर हैं, ऑब्जेक्ट की विशेषता जो फॉर्म का मुख्य तत्व है।

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

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

डेटा प्रकार प्रबंधित रूप में उपलब्ध हैं

एक प्रबंधित प्रपत्र उस डेटा के प्रकार में भी नियमित प्रपत्र से भिन्न होता है जिसके साथ वह काम करता है। यदि सामान्य फॉर्म उन अधिकांश प्रकारों के साथ काम करता है जो 1C:एंटरप्राइज प्रदान करता है (डायरेक्टरीऑब्जेक्ट, डॉक्यूमेंटऑब्जेक्ट आदि प्रकार सहित), तो प्रबंधित फॉर्म में प्रकारों की निम्नलिखित श्रेणियों को प्रतिष्ठित किया जा सकता है:

• जो प्रकार सीधे फॉर्म में उपयोग किए जाते हैं वे वे प्रकार हैं जो थिन और वेब क्लाइंट के पक्ष में मौजूद होते हैं (उदाहरण के लिए, नंबर, डायरेक्ट्रीलिंक.प्रोडक्ट्स, ग्राफिकस्कीम, टेबुलरडॉक्यूमेंट);

• वे प्रकार जिन्हें विशेष डेटा प्रकारों में परिवर्तित किया जाएगा—प्रबंधित प्रपत्र डेटा प्रकार। ऐसे प्रकार कोष्ठक में प्रपत्र विवरण की सूची में प्रदर्शित किए जाते हैं, उदाहरण के लिए (DirectoryObject.Products);

• गतिशील सूची (अधिक विवरण के लिए, इस अध्याय का "गतिशील सूची" अनुभाग देखें)।

एप्लिकेशन ऑब्जेक्ट को फॉर्म डेटा में परिवर्तित करना

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

निम्नलिखित डेटा प्रकारों का उपयोग किया जाता है:

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

• फॉर्मडाटाकोलेक्शन एक सरणी के समान टाइप किए गए मानों की एक सूची है। एक संग्रह तत्व को सूचकांक या पहचानकर्ता द्वारा एक्सेस किया जाता है। कुछ मामलों में आईडी द्वारा पहुंच उपलब्ध नहीं हो सकती है। यह उस एप्लिकेशन ऑब्जेक्ट के प्रकार के कारण है जिसे इस संग्रह द्वारा दर्शाया गया है। पहचानकर्ता कोई भी पूर्णांक हो सकता है. इस प्रकार को, उदाहरण के लिए, सारणीबद्ध भाग के रूप में दर्शाया गया है।

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

• फॉर्म डेटाट्री - पदानुक्रमित डेटा संग्रहीत करने के लिए डिज़ाइन किया गया एक ऑब्जेक्ट।

एक एप्लिकेशन ऑब्जेक्ट को एक या अधिक फॉर्म डेटा तत्वों द्वारा दर्शाया जाता है। सामान्य तौर पर, प्रपत्र डेटा का पदानुक्रम और संरचना प्रबंधित प्रपत्र के एप्लिकेशन ऑब्जेक्ट की जटिलता और अंतर्संबंध पर निर्भर करती है।

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

महत्वपूर्ण!कॉन्फ़िगरेशन विकसित करते समय, यह याद रखना महत्वपूर्ण है कि एप्लिकेशन ऑब्जेक्ट केवल सर्वर पर उपलब्ध हैं, जबकि फॉर्म डेटा ऑब्जेक्ट का उपयोग सर्वर और क्लाइंट दोनों पर किया जा सकता है।

प्रबंधित प्रपत्र के क्लाइंट और सर्वर भागों के बीच डेटा पास करना

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

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

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

• आंदोलन संग्रह के अधीनस्थ प्रॉप्स के लिए:
  • संपत्ति सक्षम है - दस्तावेज़ आंदोलनों को डेटाबेस से पढ़ा जाता है और फॉर्म डेटा में मौजूद होगा;
  • संपत्ति अक्षम है - दस्तावेज़ आंदोलनों को डेटाबेस से नहीं पढ़ा जाएगा और फॉर्म डेटा में शामिल नहीं किया जाएगा (यदि कोई फॉर्म तत्व नहीं है जो दस्तावेज़ आंदोलनों को संदर्भित करता है)।

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

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

एप्लिकेशन ऑब्जेक्ट डेटा को फॉर्म डेटा में परिवर्तित करने की विधियाँ

एप्लिकेशन ऑब्जेक्ट को फॉर्म डेटा और बैक में परिवर्तित करने के लिए, वैश्विक तरीकों का एक सेट है:

• वैल्यूइनफॉर्मडेटा(),
• फॉर्मडेटाइनवैल्यू(),
• कॉपीफॉर्मडेटा()।

महत्वपूर्ण!एप्लिकेशन ऑब्जेक्ट के साथ काम करने वाली विधियाँ केवल सर्वर प्रक्रियाओं में उपलब्ध हैं। प्रपत्र डेटा के बीच मानों की प्रतिलिपि बनाने की विधि सर्वर और क्लाइंट पर उपलब्ध है, क्योंकि इसमें पैरामीटर के रूप में एप्लिकेशन ऑब्जेक्ट की आवश्यकता नहीं होती है।

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

• वैल्यूइनफॉर्मडेटा() - एक एप्लिकेशन प्रकार ऑब्जेक्ट को फॉर्म डेटा में परिवर्तित करता है;
• फॉर्मडाटाइनवैल्यू() - फॉर्म डेटा को एप्लिकेशन प्रकार ऑब्जेक्ट में परिवर्तित करता है;
• CopyFormData() - प्रपत्र डेटा की प्रतिलिपियाँ जिसमें एक संगत संरचना होती है। यदि प्रतिलिपि सफल थी, तो सत्य लौटाता है, या यदि ऑब्जेक्ट संरचना असंगत है, तो गलत लौटाता है।

टिप्पणी। मुख्य विवरण के साथ किसी फॉर्म की मानक क्रियाएं (फॉर्म खोलना, मानक राइट कमांड निष्पादित करना आदि) करते समय, रूपांतरण स्वचालित रूप से किया जाता है।

आइए एक उदाहरण दें कि अपने स्वयं के एल्गोरिदम में डेटा परिवर्तन का उपयोग कैसे करें।

&OnServerProcedure जब CreateOnServer(विफलता, मानक प्रसंस्करण)

ऑब्जेक्टप्रोडक्ट = निर्देशिकाएँ.प्रोडक्ट्स.FindByName("कॉफ़ीपॉट").GetObject(); वैल्यूइनफॉर्मडेटा (ऑब्जेक्टआइटम, ऑब्जेक्ट);

प्रक्रिया का अंत

&ऑनक्लाइंट प्रक्रिया लिखें()

WriteOnServer();

प्रक्रिया का अंत

&ऑनसर्वर प्रक्रिया राइटऑनसर्वर()

ऑब्जेक्टप्रोडक्ट = फॉर्मडेटावैल्यू (ऑब्जेक्ट, प्रकार ("डायरेक्टरीऑब्जेक्ट.प्रोडक्ट्स")); ऑब्जेक्टआइटम.लिखें();

प्रक्रिया का अंत

प्रबंधितफॉर्म ऑब्जेक्ट में सर्वर पर विधियाँ भी उपलब्ध हैं:

• वैल्यूएफ़ॉर्मएट्रिब्यूट() - एक एप्लिकेशन प्रकार ऑब्जेक्ट को निर्दिष्ट फॉर्म विशेषता में परिवर्तित करता है।
• फॉर्मएट्रिब्यूटवीवैल्यू() - फॉर्म डेटा विशेषता को एप्लिकेशन प्रकार के ऑब्जेक्ट में परिवर्तित करता है।

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

आइए इन विधियों के उपयोग का एक उदाहरण दें।

&ऑनसर्वर प्रक्रिया पुनर्गणनाऑनसर्वर()

// ऑब्जेक्ट विशेषता को एप्लिकेशन ऑब्जेक्ट में परिवर्तित करता है। दस्तावेज़ = प्रपत्र गुण मान('ऑब्जेक्ट'); // दस्तावेज़ मॉड्यूल में परिभाषित विधि का उपयोग करके पुनर्गणना करता है। दस्तावेज़.पुनर्गणना(); // एप्लिकेशन ऑब्जेक्ट को वापस प्रोप में परिवर्तित करता है। वैल्यू फॉर्म एट्रिब्यूट्स (दस्तावेज़, "ऑब्जेक्ट");

प्रक्रिया का अंत

सॉफ़्टवेयर इंटरफ़ेस

फॉर्मडेटाट्री

• FindById
• आइटम प्राप्त करें

विवरण:

प्रबंधित प्रपत्र डेटा में एक पेड़ को मॉडल करने के लिए डिज़ाइन किया गया।

इस ऑब्जेक्ट को XDTO से/से क्रमबद्ध किया जा सकता है। इस ऑब्जेक्ट से संबंधित XDTO प्रकार को नेमस्पेस में परिभाषित किया गया है। XDTO प्रकार का नाम:

आइटम प्राप्त करें

वाक्य - विन्यास:

आइटम प्राप्त करें()

प्रतिलाभ की मात्रा:

प्रकार: वृक्ष तत्वों का प्रपत्र डेटा संग्रह।

विवरण:

शीर्ष-स्तरीय वृक्ष तत्वों का संग्रह प्राप्त करता है।

उपलब्धता: क्लाइंट, सर्वर, थिन क्लाइंट, वेब क्लाइंट।

FindById

वाक्य - विन्यास:

FindById(<Идентификатор>)

विकल्प:

<Идентификатор>(आवश्यक)

प्रकार: संख्या. वृक्ष तत्व पहचानकर्ता.

प्रतिलाभ की मात्रा:

प्रकार:फॉर्मडेटाट्रीएलिमेंट।

विवरण:

आईडी द्वारा एक संग्रह तत्व प्राप्त करता है।

उपलब्धता: क्लाइंट, सर्वर, थिन क्लाइंट, वेब क्लाइंट।

फॉर्मडेटाट्रीआइटम

गुण:

<Имя свойства> (<Имя свойства>)

• गेटआईडी (गेटआईडी)
• अभिभावक बनें
• आइटम प्राप्त करें
• संपत्ति

विवरण:

प्रपत्र डेटा ट्री तत्व.

फॉर्मडेटाट्रीआइटमकलेक्शन

संग्रह तत्व: डेटाफॉर्मट्रीएलिमेंट

किसी ऑब्जेक्ट के लिए, प्रत्येक के लिए... से... लूप ऑपरेटर का उपयोग करके संग्रह को पार करना संभव है। ट्रैवर्सल संग्रह के तत्वों का चयन करता है। [...] ऑपरेटर का उपयोग करके संग्रह तत्व तक पहुंचना संभव है। तत्व के सूचकांक को एक तर्क के रूप में पारित किया जाता है।

• डालना
• जोड़ना
• सूचकांक (सूचकांक)
• गिनती करना
• स्पष्ट
• पाना
• कदम
• मिटाना

विवरण:

लकड़ी के तत्वों का संग्रह.

उपलब्धता: क्लाइंट, सर्वर, थिन क्लाइंट, वेब क्लाइंट।

यह सभी देखें:

• फॉर्मडाटाट्रीएलिमेंट, गेटएलिमेंट्स विधि
• डेटाफॉर्मट्री, विधि GetItems

वैल्यू ट्री के साथ काम करने की विशेषताएं

वृक्ष अद्यतन

एक समस्या है फॉल्सपेड़ को अद्यतन करते समय प्लेटफ़ॉर्म।

यदि ट्री में किसी नोड का विस्तार किया गया है और एक अधीनस्थ नोड का चयन किया गया है, तो फ़ंक्शन के साथ ट्री को अपडेट करते समय वैल्यूइनफॉर्मडेटामंच गिर जाता है.

समाधान: आपको अपडेट करने से पहले पेड़ को साफ़ करना होगा।

उदाहरण के लिए:

&सर्वर प्रक्रिया पर ClearTree(Elements) तत्वों में से प्रत्येक तत्व के लिए Loop ClearTree(element.GetElements()); अंतचक्र; तत्व.साफ़ करें(); प्रक्रिया का अंत

&सर्वर प्रक्रिया पर कॉन्सेप्ट ट्री भरें() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); वैल्यूइनफॉर्मडेटा (डीकॉन्सेप्ट्स, कॉन्सेप्टट्री); प्रक्रिया का अंत

&ऑनक्लाइंट प्रक्रिया ऑनडेटऑनचेंज(एलिमेंट) कॉन्सेप्टट्री भरें(); प्रक्रिया का अंत

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

कई मामलों में फॉर्म में सॉफ़्टवेयर संशोधन की आवश्यकता हो सकती है:

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

प्रबंधित प्रपत्र में, आप प्रोग्रामेटिक रूप से जोड़ सकते हैं, बदल सकते हैं और हटा सकते हैं:

• आवश्यकताएँ;
• स्थानीय टीमें;
• तत्व.

ये सभी ऑपरेशन केवल सर्वर पर ही संभव हैं।

प्रोग्रामेटिक रीशेपिंग की सीमाएँ हैं:

• आप केवल प्रोग्रामेटिक रूप से जोड़े गए विवरण/आदेश/तत्वों को हटा सकते हैं। आप कॉन्फिगरेटर में बनाए गए ऑब्जेक्ट को प्रोग्रामेटिक रूप से हटा नहीं सकते हैं।
• आप किसी विशेषता को मुख्य के रूप में निर्दिष्ट नहीं कर सकते.

प्रपत्र आदेश बदलना

किसी ऑब्जेक्ट के लिए कमांड की संरचना का प्रबंधन करना प्रबंधित प्रपत्रएक संग्रह है टीमें

जोड़ना (< ИмяКоманды >)

मात्रा ()

खोजो (< ИмяКоманды >)

मिटाना (< Команда >)

टीम संग्रह क्लाइंट और सर्वर दोनों पर उपलब्ध है। आप केवल सर्वर पर संग्रह (जोड़ें() और हटाएँ() विधियाँ) बदल सकते हैं। आप क्लाइंट और सर्वर दोनों पर तत्वों की संख्या (फाइंड () और काउंट () विधियां) खोज और प्राप्त कर सकते हैं।

फॉर्म कमांड के साथ काम करने के उदाहरण के रूप में, आइए "ChangeHistory..." शीर्षक के साथ एक नया ChangeHistory कमांड बनाएं, जो हैंडलर को कॉल करेगा प्रदर्शन इतिहास(). प्रपत्र खुलने पर सृजन होता है.

&सर्वर पर
प्रक्रिया जबCreatingOnServer(विफलता, मानक प्रसंस्करण)
टीम = टीमें. जोड़ना( "परिवर्तन का इतिहास");
टीम . क्रिया = ;
टीम . शीर्षक= "परिवर्तन का इतिहास...";
प्रक्रिया का अंत
&ऑनक्लाइंट
प्रक्रिया कनेक्ट करने योग्य_डिस्प्लेहिस्ट्री(कमांड)
// कमांड क्रियाएँ
प्रक्रिया का अंत

कमांड हैंडलर को एक फॉर्म पर स्थित होना चाहिए और उसमें &OnClient संकलन निर्देश होना चाहिए।

फॉर्म विवरण बदलना

प्रपत्र विवरण की संरचना को पढ़ना फ़ंक्शन द्वारा किया जाता है विवरण प्राप्त करें(< Путь >) फॉर्मएट्रिब्यूट्स प्रकार की एक सरणी लौटा रहा है। फ़ंक्शन पैरामीटर मूल विशेषता (एक स्ट्रिंग के रूप में) के लिए पथ निर्दिष्ट करता है। यदि पैरामीटर छोड़ दिया गया है या एक खाली स्ट्रिंग निर्दिष्ट की गई है, तो शीर्ष-स्तरीय विवरण लौटाए जाते हैं।

विवरण बदलना विधि का उपयोग करके किया जाता है विवरण बदलें(<विवरण जोड़ा गया>, <हटाने योग्य विवरण>) वस्तु प्रबंधित प्रपत्र. मापदंडों के लिए विवरण जोड़ा गयाऔर हटाने योग्य विवरणप्रपत्र गुण प्रकार के तत्वों के साथ सारणी प्रसारित की जाती है।

ध्यान!

विवरणों की संरचना को बदलने की प्रक्रिया काफी संसाधन-गहन है। असल में फॉर्म को दोबारा बनाया जा रहा है. इस संबंध में, प्रपत्र विवरण के साथ कार्य बैच मोड में किया जाता है।

आइए क्रेता नाम से एक नया फॉर्म एट्रिब्यूट बनाएं:

जोड़ा गया विवरण = नई सारणी;
विवरण जोड़ा गया. जोड़ें(नए फॉर्म गुण("खरीदार", नए प्रकार का विवरण ("निर्देशिकालिंक। प्रतिपक्ष"), "ग्राहक"));

// विवरण की संरचना में परिवर्तन
);

रूप तत्वों को बदलना

किसी वस्तु के तत्वों की संरचना को नियंत्रित करना प्रबंधित प्रपत्रएक संग्रह है तत्वों. संग्रह की कई विधियाँ हैं:

डालना (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

जोड़ना (< Имя>, < ТипЭлемента>, < Родитель >)

मात्रा ()

खोजो (< Имя >)

कदम(< Элемент>, < Родитель>, < МестоРасположения >)

मिटाना (< Элемент >)

आइटम संग्रह क्लाइंट और सर्वर दोनों पर उपलब्ध है। एक संग्रह को संशोधित करें (तरीके डालें)। () , ऐड () , मूव () और डिलीट () ) केवल सर्वर पर उपलब्ध हैं। आप क्लाइंट और सर्वर दोनों पर तत्वों की संख्या (फाइंड () और काउंट () विधियां) खोज और प्राप्त कर सकते हैं। संग्रह तत्व हो सकते हैं:

• फॉर्मग्रुप;
• फॉर्मटेबल;
• फॉर्मफ़ील्ड;
• प्रपत्र बटन.

आप तत्वों को बनाने के लिए प्रोग्रामेटिक रूप से ईवेंट हैंडलर असाइन कर सकते हैं। विधि इन उद्देश्यों के लिए अभिप्रेत है सेटएक्शन(< ИмяСобытия>, < Действие >) .

आइए कमांड, विवरण और फॉर्म तत्वों के साथ काम करने के कुछ सबसे सामान्य उदाहरण देखें।

एक कमांड और उससे संबंधित बटन जोड़ना:

// एक कमांड बनाएं
टीम = टीमें. जोड़ना( "परिवर्तन का इतिहास");
टीम . क्रिया= "प्लग-इन_डिस्प्लेहिस्ट्री"; // फॉर्म में निर्दिष्ट नाम के साथ एक प्रक्रिया होनी चाहिए
टीम . शीर्षक = "परिवर्तन का इतिहास...";
// एक बटन बनाएं और इसे एक कमांड के साथ संबद्ध करें
तत्व = आइटम. जोड़ना( "परिवर्तन का इतिहास", टाइप करें ("फॉर्मबटन" ));
तत्व.कमांडनाम = "परिवर्तन का इतिहास";

एक विशेषता और संबंधित इनपुट फ़ील्ड जोड़ना:

// जोड़े गए विवरण का विवरण
जोड़ा गया विवरण = नई सारणी;
विवरण जोड़ा गया. जोड़ना(नया फॉर्म प्रॉप्स ("खरीदार", नए प्रकार का विवरण ( "निर्देशिकालिंक। प्रतिपक्ष"), "ग्राहक" ));
// विवरण की संरचना बदलना
विवरण बदलें(विवरण जोड़ा गया);
// एक इनपुट फ़ील्ड बनाना और विशेषताओं के साथ जुड़ना
तत्व = आइटम. जोड़ें("खरीदार", प्रकार("फॉर्मफ़ील्ड" ));
तत्व . देखें = फॉर्मफ़ील्डव्यू। प्रवेश क्षेत्र;
तत्व . पाथटूडेटा= "खरीदार" ;

किसी ईवेंट हैंडलर को किसी प्रपत्र तत्व पर असाइन करना:

आइटम ग्राहक. सेटएक्शन("जब यह बदलता है", "कनेक्टेड_बायरऑनचेंज");

&ऑनक्लाइंट
प्रक्रिया कनेक्टेड_बायरऑनचेंज(तत्व)
// घटना क्रियाएँ
प्रक्रिया का अंत

ध्यान!

प्रक्रियाएँ जो विधि का उपयोग करके कोड से इवेंट हैंडलर के रूप में सेट की जाती हैं सेटएक्शन(), उपसर्ग Connectable_ सेट करने की अनुशंसा की जाती है।

ध्यान!

आप प्रोग्रामेटिक खोज और प्रबंधित प्रपत्र के विवरण, आदेश और तत्वों को बदलने के उदाहरणों के साथ प्रसंस्करण डाउनलोड कर सकते हैं।

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

परीक्षा 1सी का प्रश्न 10.05: प्लेटफ़ॉर्म प्रोफेशनल। मुख्य प्रपत्र विशेषता का उपयोग किसके लिए किया जाता है?

1. संपूर्ण प्रपत्र के लिए डेटा स्रोत को परिभाषित करता है
2. मुख्य विशेषता में निर्दिष्ट प्रकार के डेटा के साथ प्रपत्र के साथ काम करने के लिए प्लेटफ़ॉर्म की मानक क्षमताओं को परिभाषित करता है
3. स्थानीय प्रपत्र संदर्भ से ऑब्जेक्ट विवरण को प्रोग्रामेटिक रूप से एक्सेस करने की क्षमता प्रदान करना
4. प्रपत्र संवाद पर ऑब्जेक्ट विवरण का विज़ुअलाइज़ेशन प्रदान करता है
5. 2 और 3 सही हैं
6. 1 और 2 सही हैं

सही उत्तर संख्या छह है, ऊपर देखें।

परीक्षा 1सी का प्रश्न 10.06: प्लेटफ़ॉर्म प्रोफेशनल। प्रपत्र विवरण किस लिए आवश्यक हैं?

1. किसी प्रपत्र में प्रदर्शित, संपादित या संग्रहीत डेटा की सामग्री का वर्णन करना
2. डेटा को किसी फॉर्म में प्रदर्शित और संपादित करना
3. 1 और 2 सही हैं

सही उत्तर तीसरा है - दोनों।

परीक्षा 1सी का प्रश्न 10.07: प्लेटफ़ॉर्म प्रोफेशनल। एक मनमाने ढंग से नियंत्रित रूप में बुनियादी विशेषताओं को निर्दिष्ट करने के लिए...

1. आपको प्रपत्र विशेषताओं के गुणों में "बुनियादी विवरण" चेकबॉक्स को जांचना होगा
2. आपको आवश्यक प्रपत्र विशेषता का चयन करके प्रपत्र की "डेटा" संपत्ति को भरना होगा

सही उत्तर दूसरा है:

परीक्षा 1सी का प्रश्न 10.08: प्लेटफ़ॉर्म प्रोफेशनल। मुख्य विवरण को एक मनमाना नियमित रूप में निर्दिष्ट करने के लिए...

1. प्रपत्र को मुख्य बनाने की आवश्यकता है, मुख्य विवरण स्वचालित रूप से निर्धारित होते हैं
2. आपको प्रपत्र विशेषताओं के गुणों में "बुनियादी विवरण" चेकबॉक्स को जांचना होगा
3. आपको "संपादन" मेनू, "बुनियादी विवरण" पर जाना होगा और वांछित मान का चयन करना होगा
4. आपको आवश्यक प्रपत्र विशेषता का चयन करके प्रपत्र की "डेटा" संपत्ति को भरना होगा

चौथा सही उत्तर है:

मुख्य विवरण बोल्ड में हाइलाइट किए गए हैं:

परीक्षा 1सी का प्रश्न 10.09: प्लेटफ़ॉर्म प्रोफेशनल। यदि एक मुख्य प्रपत्र विशेषता है, तो क्या दूसरी मुख्य विशेषता जोड़ना संभव है?

1. ऐसा हो ही नहीं सकता
2. प्रपत्र विशेषता संपत्ति को उचित मान निर्दिष्ट करके यह संभव है
3. यह केवल प्रोग्रामेटिक रूप से संभव है, जब "फॉर्म" ऑब्जेक्ट तक पहुंच हो
4. यह संबंधित फॉर्म प्रॉपर्टी में एक और मान जोड़कर संभव है

सही उत्तर पहला है, कड़ाई से एक मुख्य आवश्यकता है, क्योंकि वस्तु के साथ संबंध स्पष्ट होना चाहिए।

परीक्षा 1सी का प्रश्न 10.113: प्लेटफ़ॉर्म प्रोफेशनल। चित्र में प्रस्तुत प्रपत्र का कौन-सा विवरण मुख्य है?

1. मुद्रा दरों की सूची
2. निर्देशिकावस्तु
3. निर्देशिका प्रपत्रों में बुनियादी विवरण नहीं हैं
4. निर्देशिका प्रपत्रों में सभी बुनियादी विवरण होते हैं

दूसरा सही उत्तर बोल्ड में दिया गया उत्तर है।

प्रपत्र को विभिन्न प्रपत्र तत्वों के माध्यम से नियंत्रित किया जाता है, जो टैब पर पदानुक्रम में स्थित होते हैं तत्वोंफॉर्म डिजाइनर. सबसे महत्वपूर्ण तत्व स्वयं स्वरूप है, जो तत्वों के पदानुक्रम के शीर्ष पर स्थित है, और शेष तत्व इसके अधीन हैं।

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

किसी प्रपत्र में तत्व जोड़ना

यह काफी सरलता से किया जाता है: आपको तत्व का चयन करना होगा रूपफॉर्म डिज़ाइन एलिमेंट्स विंडो में और "जोड़ें" बटन पर क्लिक करें। इसके बाद एक विंडो खुलेगी जिसमें आपको वांछित एलिमेंट प्रकार का चयन करना होगा

चयन के बाद वांछित तत्व विंडो में दिखाई देगा तत्वों.

प्रबंधित प्रपत्र तत्व मैदान

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

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

आइए अब अपने हाल ही में जोड़े गए फॉर्म तत्व को किसी एक विवरण के साथ जोड़ते हैं। ऐसा करने के लिए, तत्व की PathKData प्रॉपर्टी से वांछित विशेषता का चयन करें।

इसके बाद, डेटापाथ और व्यू गुण भर दिए जाएंगे, और तत्व स्वयं फॉर्म व्यू में प्रदर्शित होगा।

तत्व गुण पर ध्यान दें देखना. यह गुण इनपुट फ़ील्ड की कार्यक्षमता निर्धारित करता है। आप इस प्रॉपर्टी के लिए अलग-अलग मान चुन सकते हैं.

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

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

अब टाइप के साथ एक नया फॉर्म एलिमेंट जोड़ते हैं प्रवेश क्षेत्रऔर इसे प्रॉप्स से कनेक्ट करें विवरण दिनांकपहले से ही परिचित डेटापाथ संपत्ति के माध्यम से

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

इस प्रकार, हम यह निष्कर्ष निकालते हैं कि इनपुट फ़ील्ड की कार्यक्षमता विशेषता के प्रकार पर निर्भर करती है।

टाइप वाले प्रॉप्स के लिए बूलियननिम्नलिखित दृश्य संपत्ति मान उपलब्ध होंगे।

और संदर्भ प्रकार वाली विशेषताओं के लिए, व्यू प्रॉपर्टी के अन्य मान उपलब्ध होंगे।

व्यावहारिक उदाहरणों का उपयोग करते हुए फॉर्म तत्वों के साथ अधिक विस्तृत कार्य "1सी में विकास की मूल बातें: टैक्सी" पुस्तक में दिया गया है। 12 चरणों में प्रबंधित अनुप्रयोग विकास"।

कभी-कभी ऐसा लगता है कि 1C में प्रोग्रामिंग भाषा सीखना जटिल और कठिन है। वास्तव में, 1सी में प्रोग्रामिंग करना आसान है। मेरी किताबें आपको 1सी में प्रोग्रामिंग में तेजी से और आसानी से महारत हासिल करने में मदद करेंगी: और "1सी में विकास की मूल बातें: टैक्सी"

मेरी पुस्तक "11 चरणों में 1सी में प्रोग्रामिंग" की सहायता से 1सी में प्रोग्रामिंग सीखें।

1. कोई जटिल तकनीकी शब्द नहीं.
2. व्यावहारिक सामग्री के 700 से अधिक पृष्ठ।
3. प्रत्येक कार्य के साथ एक ड्राइंग (स्क्रीनशॉट) भी है।
4. गृहकार्य के लिए समस्याओं का संग्रह.
5. पुस्तक स्पष्ट और सरल भाषा में लिखी गई है - एक शुरुआत के लिए।

यह पुस्तक उन लोगों के लिए उपयुक्त है जिन्होंने पहले ही प्रोग्रामिंग शुरू कर दी है और इस विषय के साथ कुछ कठिनाइयों का सामना कर रहे हैं और उन लोगों के लिए जो लंबे समय से प्रोग्रामिंग कर रहे हैं, लेकिन कभी भी 1 सी प्रबंधित रूपों के साथ काम नहीं किया है।

1. जटिल तकनीकी शब्दों के बिना;
2. व्यावहारिक सामग्री के 600 से अधिक पृष्ठ;
3. प्रत्येक उदाहरण के साथ एक चित्र (स्क्रीनशॉट) है;
4. पुस्तक पीडीएफ प्रारूप में ईमेल द्वारा भेजी जाती है। किसी भी डिवाइस पर खोला जा सकता है!

15% छूट के लिए प्रोमो कोड - 48PVXHeYu

यदि इस पाठ से आपको किसी समस्या का समाधान करने में मदद मिली, आपको यह पसंद आया या यह उपयोगी लगा, तो आप कोई भी राशि दान करके मेरे प्रोजेक्ट का समर्थन कर सकते हैं:

आप मैन्युअल रूप से भुगतान कर सकते हैं:

यांडेक्स.मनी - 410012882996301
वेब मनी - R955262494655

मेरे समूहों में शामिल हों.

और डेटा ट्रांसफर ऑब्जेक्ट को कोड संरचना में, 1C 8.2 वातावरण में नियंत्रित रूप में।

परिचय

आइए "प्रबंधित प्रपत्र" की अवधारणा और 1C प्लेटफ़ॉर्म की संबंधित अवधारणाओं के संक्षिप्त विवरण के साथ शुरुआत करें। प्लेटफ़ॉर्म के जानकार इस अनुभाग को छोड़ना चाह सकते हैं।

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

• मोटा ग्राहक (सामान्य और प्रबंधित लॉन्च मोड)
• दूसरे कंप्यूटर पर निर्भर रहने वाला कंप्यूटर प्रोग्राम
• वेब क्लाइंट

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

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

आइए फॉर्म विधियों को संकलित करने के निर्देशों को सूचीबद्ध करें:

• &ऑनक्लाइंट
• &सर्वर पर
• &संदर्भ के बिना सर्वर पर
• &ऑनक्लाइंटऑनसर्वरबिना संदर्भ के

आइए उपरोक्त को स्पष्ट करें। स्क्रीनशॉट एक प्रबंधित प्रपत्र और विकास मोड में उसके मॉड्यूल का एक उदाहरण दिखाता है। घोषणात्मक विवरण, प्रॉप्स, संकलन निर्देश आदि खोजें।

आगे की सभी चर्चाएँ चित्रण के दाईं ओर, मॉड्यूल कोड की संरचना कैसे करें और कौन से सिद्धांत आपको प्रभावी क्लाइंट-सर्वर इंटरैक्शन को लागू करने की अनुमति देंगे, के बारे में होंगे।

आइए समस्या को परिभाषित करें

1C प्लेटफ़ॉर्म के नए संस्करण को सक्रिय रूप से उपयोग किए हुए कई साल बीत चुके हैं और 1C और इसके कई भागीदारों द्वारा कई समाधान (कॉन्फ़िगरेशन) जारी किए गए हैं।
इस समय के दौरान, क्या डेवलपर्स ने फॉर्म बनाते समय क्लाइंट-सर्वर इंटरैक्शन के सिद्धांतों की एक सामान्य समझ विकसित की है, और क्या नई वास्तुशिल्प वास्तविकताओं में सॉफ्टवेयर मॉड्यूल को लागू करने का दृष्टिकोण बदल गया है?

आइए एक ही मानक कॉन्फ़िगरेशन के कई रूपों में कोड संरचना (फॉर्म मॉड्यूल) को देखें और पैटर्न खोजने का प्रयास करें।
संरचना से हमारा तात्पर्य इन विधियों के लिए समूह विधियों और संकलन निर्देशों के लिए डेवलपर द्वारा आवंटित कोड के अनुभागों (अक्सर ये टिप्पणी ब्लॉक होते हैं) से है।
उदाहरण 1:
इवेंट हैंडलर का अनुभाग विधि - क्लाइंट पर विधि - सर्वर पर विधि - क्लाइंट पर सेवा प्रक्रियाओं और कार्यों का अनुभाग सहायक इनपुट नियंत्रण कार्य
उदाहरण 2:
सेवा प्रक्रियाएँ और कार्य, भुगतान दस्तावेज़, मूल्य, इवेंट हैंडलर
उदाहरण 3:
सर्वर पर सेवा प्रक्रियाएँ क्लाइंट पर सेवा प्रक्रियाएँ संदर्भ के बिना सर्वर पर सेवा प्रक्रियाएँ हेडर इवेंट हैंडलर कमांड इवेंट हैंडलर
उदाहरण 4:
सामान्य प्रयोजन प्रक्रियाएं फॉर्म इवेंट हैंडलर "संपर्क जानकारी" उपप्रणाली की प्रक्रियाएं
अनिवार्य रूप से, कोड संरचना गायब है, या इसे हल्के ढंग से कहें तो यह फॉर्म 8.1 के समान है:

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

आपको कोड संरचना की आवश्यकता क्यों है?

• रखरखाव का सरलीकरण.
• सीखने को सरल बनाएं.
• सामान्य/महत्वपूर्ण/सफल सिद्धांतों को रिकार्ड करना।
• ...आपका विकल्प

1सी से मौजूदा विकास मानक मदद क्यों नहीं करता?

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

• सर्वर कॉल की संख्या कम करें.
• सर्वर पर अधिकतम कंप्यूटिंग.
• गैर-प्रासंगिक सर्वर कॉल प्रासंगिक की तुलना में तेज़ होती हैं।
• क्लाइंट-सर्वर संचार को ध्यान में रखकर प्रोग्राम।
• और इसी तरह।

ये वो नारे हैं जो बिल्कुल सच हैं, लेकिन इन पर अमल कैसे किया जाए? कॉल की संख्या को कैसे कम करें, क्लाइंट-सर्वर मोड में प्रोग्राम करने का क्या मतलब है?

डिज़ाइन पैटर्न या पीढ़ीगत ज्ञान

क्लाइंट-सर्वर इंटरैक्शन का उपयोग दशकों से विभिन्न सॉफ्टवेयर प्रौद्योगिकियों में किया जाता रहा है। पिछले अनुभाग में उल्लिखित प्रश्नों का उत्तर लंबे समय से ज्ञात है और इसे दो बुनियादी सिद्धांतों में संक्षेपित किया गया है।

• दूरस्थ मुखौटा(इसके बाद रिमोट एक्सेस इंटरफ़ेस के रूप में संदर्भित)
• डेटा ट्रांसफर ऑब्जेक्ट(इसके बाद डेटा ट्रांसफर ऑब्जेक्ट के रूप में संदर्भित)

मार्टिन फाउलर का एक शब्द, इन सिद्धांतों का उनका विवरण:

• … दूरस्थ पहुंच के लिए संभावित रूप से इच्छित प्रत्येक वस्तु में यह होना चाहिए कम ग्रैन्युलैरिटी इंटरफ़ेस, जो एक निश्चित प्रक्रिया को निष्पादित करने के लिए आवश्यक कॉलों की संख्या को कम कर देगा। ... किसी चालान और उसकी सभी वस्तुओं के लिए अलग-अलग अनुरोध करने के बजाय, आपको एक ही अनुरोध में सभी चालान वस्तुओं को पढ़ने और अपडेट करने की आवश्यकता है। यह ऑब्जेक्ट की संपूर्ण संरचना को प्रभावित करता है...याद रखें: रिमोट एक्सेस इंटरफ़ेस डोमेन तर्क शामिल नहीं है.
• ...अगर मैं एक देखभाल करने वाली माँ होती, तो मैं निश्चित रूप से अपने बच्चे से कहती: "कभी भी डेटा ट्रांसफर ऑब्जेक्ट न लिखें!" ज्यादातर मामलों में, डेटा ट्रांसफर ऑब्जेक्ट इससे ज्यादा कुछ नहीं हैं फूला हुआ फ़ील्ड सेट...इस घृणित राक्षस का मूल्य पूरी तरह से संभावना में निहित है एक कॉल में नेटवर्क पर अनेक जानकारी प्रसारित करना- एक ऐसी तकनीक जो वितरित प्रणालियों के लिए बहुत महत्वपूर्ण है।

1C प्लेटफ़ॉर्म में टेम्प्लेट के उदाहरण

प्रबंधित प्रपत्र विकसित करते समय डेवलपर के लिए उपलब्ध एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस में इन सिद्धांतों के कई उदाहरण शामिल हैं।
उदाहरण के लिए, OpenForm() विधि, एक विशिष्ट "रफ़" इंटरफ़ेस।
ओपनिंग पैरामीटर्स = नई संरचना ("पैरामीटर 1, पैरामीटर 2, पैरामीटर 3", वैल्यू 1, वैल्यू 2, वैल्यू 3); फॉर्म = ओपनफॉर्म (फॉर्मनाम, ओपनिंग पैरामीटर्स);
v8.1 में अपनाई गई शैली से तुलना करें।
फॉर्म = गेटफॉर्म(फॉर्मनाम); प्रपत्र.पैरामीटर1 = मान1; प्रपत्र.पैरामीटर2 = मान2; फॉर्म.ओपन();

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

• डेटाफॉर्म्सस्ट्रक्चर
• डेटाफॉर्म संग्रह
• डेटाफॉर्मस्ट्रक्चरविथकलेक्शन
• डेटाशेप्सट्री

सिस्टम डेटा ट्रांसफर ऑब्जेक्ट का एप्लिकेशन प्रकारों में रूपांतरण और इसके विपरीत निम्नलिखित विधियों का उपयोग करके किया जाता है:

• वैल्यूइनफॉर्मडेटा()
• फॉर्मडेटावैल्यू()
• कॉपीफॉर्मडेटा()
• वैल्यूइनफॉर्मएट्रिब्यूट्स()
• फॉर्मएट्रिब्यूट्सवैल्यू()

किसी मौजूदा समाधान को अपनाते समय अक्सर स्पष्ट रूपांतरण का उपयोग किया जाता है। विधियाँ इनपुट पैरामीटर्स की अपेक्षा कर सकती हैं (सुविधाओं का उपयोग करें), जैसे कि फॉर्मडेटाकोलेक्शन के बजाय वैल्यूटेबल, या विधि को किसी एप्लिकेशन ऑब्जेक्ट के संदर्भ में परिभाषित किया गया है और फॉर्म से सीधे कॉल के लिए अनुपलब्ध हो गया है।
उदाहरण 1सी v8.1:
// क्लाइंट पर फ़ॉर्म fillUserCache(DepartmentLink) के संदर्भ में
उदाहरण 1सी v8.2:
// सर्वर पर फॉर्म प्रोसेसिंगऑब्जेक्ट = फॉर्म एट्रिब्यूट्सवैल्यू ("ऑब्जेक्ट"); के संदर्भ में; प्रोसेसिंगऑब्जेक्ट.फिलयूजरकैश(डिपार्टमेंटरेफ); वैल्यूएफ़ॉर्मएट्रिब्यूट्स(प्रोसेसिंगऑब्जेक्ट, "ऑब्जेक्ट");

डेटा ट्रांसफर ऑब्जेक्ट, जिसकी संरचना डेवलपर द्वारा निर्धारित की जाती है, क्लाइंट और सर्वर दोनों पर उपलब्ध प्रकारों का एक छोटा उपसमूह है। अक्सर, निम्नलिखित का उपयोग "मोटे" इंटरफ़ेस के तरीकों के पैरामीटर और परिणाम के रूप में किया जाता है:

• आदिम प्रकार (स्ट्रिंग, संख्या, बूलियन)
• संरचना
• पत्र-व्यवहार
• सरणी
• एप्लिकेशन ऑब्जेक्ट के लिंक (विशिष्ट पहचानकर्ता और पाठ प्रतिनिधित्व)

उदाहरण: विधि स्थिति बदलने के लिए आदेशों की एक सूची स्वीकार करती है और क्लाइंट को त्रुटियों का विवरण लौटाती है।
&OnServerWithoutContext फ़ंक्शन ServerChangeOrderStatus(ऑर्डर, NewStatus) त्रुटियाँ = नया मिलान(); // [ऑर्डर] [त्रुटि विवरण] ऑर्डर चक्र से प्रत्येक ऑर्डर के लिए स्टार्ट ट्रांज़ैक्शन(); DocOb = order.GetObject() आज़माएं; .... अन्य कार्रवाइयां, न केवल ऑर्डर के साथ संभव... अपवाद CancelTransaction(); Errors.Insert(ऑर्डर, ErrorDescription()); अंतप्रयास; अंतचक्र; वापसी त्रुटि; एंडफ़ंक्शन // सर्वरचेंजऑर्डरस्टैटस()

कोड की संरचना करना

मुख्य लक्ष्य जो प्रबंधित प्रपत्र मॉड्यूल को प्रतिबिंबित करना चाहिए और समाधान के लिए दृष्टिकोण करना चाहिए।

• क्लाइंट और सर्वर कोड का स्पष्ट पृथक्करण।आइए यह न भूलें कि निष्पादन के समय ये दो इंटरैक्टिंग प्रक्रियाएं हैं, जिनमें से प्रत्येक की उपलब्ध कार्यक्षमता काफी भिन्न है।
• रिमोट एक्सेस इंटरफ़ेस की स्पष्ट पहचान, क्लाइंट से कौन से सर्वर तरीकों को कॉल किया जा सकता है और कौन से नहीं? दूरस्थ इंटरफ़ेस विधियों के नाम उपसर्ग "सर्वर" से शुरू होते हैं। यह आपको कोड पढ़ते समय सर्वर पर नियंत्रण के हस्तांतरण को तुरंत देखने की अनुमति देता है, और प्रासंगिक सहायता के उपयोग को सरल बनाता है। ध्यान दें कि आधिकारिक अनुशंसा (आईटीएस) पोस्टफ़िक्स के साथ नामकरण विधियों का सुझाव देती है, उदाहरण के लिए, ChangeOrderStatusOnServer()। हालाँकि, हम दोहराते हैं कि सभी सर्वर विधियों को क्लाइंट से नहीं बुलाया जा सकता है, और इसलिए संकलन स्थान के बजाय तार्किक पहुंच अधिक महत्वपूर्ण है। इसलिए, उपसर्ग "सर्वर" के साथ हम केवल क्लाइंट के लिए उपलब्ध विधियों को चिह्नित करते हैं; आइए उदाहरण विधि को ServerChangeOrderStatus() कहते हैं।
• पठनीयता.पसंद की बात है, हम उस आदेश को स्वीकार करते हैं जब मॉड्यूल सर्वर और रिमोट एक्सेस विधियों पर एक फॉर्म बनाने की प्रक्रियाओं के साथ शुरू होता है।
• रख-रखाव।नया कोड जोड़ने के लिए एक स्पष्ट स्थान होना चाहिए. एक महत्वपूर्ण बिंदु यह है कि विन्यासकर्ता द्वारा स्वचालित रूप से बनाए गए विधि टेम्पलेट मॉड्यूल के अंत में जोड़े जाते हैं। चूँकि प्रपत्र तत्वों के लिए ईवेंट हैंडलर अक्सर स्वचालित रूप से बनाए जाते हैं, संबंधित ब्लॉक अंतिम स्थान पर स्थित होता है, ताकि प्रत्येक हैंडलर को मॉड्यूल में किसी अन्य स्थान पर न खींचा जाए।

नीचे मॉड्यूल की मूल संरचना है जो सूचीबद्ध लक्ष्यों को लागू करती है।

• ग्राफिकल विकल्प - निष्पादन के मुख्य प्रवाह को स्पष्ट रूप से दिखाता है।
• टेक्स्ट विकल्प किसी संरचना को नए फॉर्म मॉड्यूल में शीघ्रता से सम्मिलित करने के लिए टेम्पलेट डिज़ाइन का एक उदाहरण है।

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""तारीख =""/> // <Описание> // // ///////////////////////////////////////////// // /////////////////////////// // मॉड्यूल चर ///////////////// // //////////////////////////////////////////// //// ///////// // सर्वर पर // ******* सर्वर पर घटनाएँ ******* और सर्वर पर प्रक्रिया जब सर्वर पर बनाई जाती है (विफलता, मानक प्रसंस्करण) / /हैंडलर की सामग्री डालें प्रक्रिया का अंत //******* रिमोट एक्सेस इंटरफ़ेस ******* //******* सर्वर पर बिजनेस लॉजिक ******* ///////// ////////////////////////////////////// ////// //////////////////// // क्लाइंट और सर्वर के सामान्य तरीके /////////////// ////// ///////////////////////////////////////// ///// /////// // क्लाइंट पर //******* बिजनेस लॉजिक क्लाइंट पर ******* //******* टीम * ****** //******* ग्राहक कार्यक्रम ******* ////////////////////////// ///// ////////////////////////////////////////// // // / मुख्य कार्यक्रम संचालक

संबंधित सवाल

अंत में, हम ऐसे कई क्षेत्रों की रूपरेखा तैयार करेंगे जिनके बारे में क्लाइंट-सर्वर इंटरैक्शन की प्रोग्रामिंग करते समय सोचना उपयोगी होता है।

• रिमोट एक्सेस इंटरफ़ेस कार्यान्वयन विकल्प. अतुल्यकालिक, विस्तार का स्तर...
• कैशिंग. 1C ने एक असफल वास्तुशिल्प निर्णय लिया, केवल सामान्य मॉड्यूल के कॉलिंग तरीकों के स्तर पर कैशिंग शुरू की और नियंत्रण क्षमताएं (प्रासंगिकता समय, मांग पर रीसेट) प्रदान नहीं की।
• अंतर्निहित सर्वर कॉल. तकनीकी सुविधाओं के बारे में मत भूलिए; क्लाइंट पर कई "हानिरहित" ऑपरेशन प्लेटफ़ॉर्म को सर्वर से संपर्क करने के लिए उकसाते हैं।