المفاتيح، التطبيق العادي، النماذج المُدارة. التبديل، والتطبيق العادي، والنماذج المدارة 1C مشاكل مع النماذج المدارة

يتيح لك النظام الأساسي 1C:Enterprise إضافة عناصر النموذج المُدار وتغييرها برمجيًا. دعونا نكتشف لماذا قد تكون هناك حاجة لذلك.

قد تكون هناك حاجة إلى تعديل برمجي للنموذج في عدة حالات:

• عند الانتهاء من التكوينات القياسية لتسهيل إجراء التحديث اللاحق. في هذه الحالة، سيتم تغيير وحدة النموذج فقط. يعد تحديث الوحدات أسهل بكثير من تحديث النماذج.
• عند تنفيذ بعض الخوارزميات الشائعة. على سبيل المثال، في النظام الفرعي "حظر تحرير تفاصيل الكائن"، يمكن إنشاء زر برمجيًا لجميع الكائنات المتصلة بالنظام الفرعي لتمكين القدرة على تحرير التفاصيل.
• عند تنفيذ بعض الخوارزميات المحددة. على سبيل المثال، في دليل Nomenclature، يتم إنشاء الحقول لتحرير التفاصيل الإضافية.

في النموذج المُدار، يمكنك إضافة وتغيير وحذف ما يلي برمجيًا:

• المتطلبات؛
• الفرق المحلية؛
• عناصر.

كل هذه العمليات ممكنة فقط على الخادم.

إعادة التشكيل البرمجي لها قيود:

• يمكنك فقط حذف التفاصيل/الأوامر/العناصر المضافة برمجيًا. لا يمكنك حذف الكائنات التي تم إنشاؤها في المكوّن برمجياً.
• لا يمكنك تعيين سمة باعتبارها السمة الرئيسية.

تغيير أوامر النموذج

لإدارة تكوين الأوامر لكائن ما ManagedFormهناك مجموعة فرق

يضيف (< ИмяКоманды >)

كمية ()

يجد (< ИмяКоманды >)

يمسح (< Команда >)

تتوفر مجموعة Teams على كل من العميل والخادم. يمكنك تغيير المجموعة (أساليب Add() وDelete()) على الخادم فقط. يمكنك البحث عن عدد العناصر والحصول عليها (طريقتا Find () وCount ()) على كل من العميل والخادم.

كمثال على العمل مع أوامر النموذج، لنقم بإنشاء أمر ChangeHistory جديد بالعنوان "ChangeHistory..."، والذي سيستدعي المعالج تاريخ العرض(). يحدث الإنشاء عند فتح النموذج.

&على الخادم
إجراء WhenCreatingOnServer (الفشل، المعالجة القياسية)
فريق = الفرق. يضيف( ""تاريخ التغيرات"");
فريق . العمل = ;
فريق . العنوان = ""تاريخ التغيرات..."";
نهاية الإجراء
&OnClient
إجراء Connectable_DisplayHistory(Command)
// إجراءات الأمر
نهاية الإجراء

يجب أن يكون معالج الأوامر موجودًا في النموذج وأن يكون له توجيه التحويل البرمجي &OnClient.

تغيير تفاصيل النموذج

تتم قراءة تكوين تفاصيل النموذج بواسطة الوظيفة احصل على التفاصيل(< Путь >) إرجاع مصفوفة من النوع FormAttributes. تحدد معلمة الوظيفة المسار إلى السمة الأصلية (كسلسلة). إذا تم حذف المعلمة أو تم تحديد سلسلة فارغة، فسيتم إرجاع تفاصيل المستوى الأعلى.

يتم تغيير التفاصيل باستخدام الطريقة تغيير التفاصيل(<التفاصيل المضافة>, <تفاصيل قابلة للإزالة>) هدف ManagedForm. إلى المعلمات التفاصيل المضافةو تفاصيل قابلة للإزالةيتم إرسال المصفوفات التي تحتوي على عناصر من نوع سمات النموذج.

انتباه!

عملية تغيير تكوين التفاصيل كثيفة الاستخدام للموارد. يتم بالفعل إعادة إنشاء النموذج. في هذا الصدد، يتم تنفيذ العمل مع تفاصيل النموذج في الوضع الدفعي.

لنقم بإنشاء سمة نموذج جديدة بالاسم Buyer:

AddedDetails = مصفوفة جديدة؛
التفاصيل المضافة. إضافة (سمات النموذج الجديد("المشتري"، وصف النوع الجديد ("DirectoryLink.Counterparties")، "العميل"))؛

// التغييرات في تكوين التفاصيل
);

تغيير عناصر النموذج

للتحكم في تكوين عناصر الكائن ManagedFormهناك مجموعة عناصر. الجمع له عدة طرق:

إدراج (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

يضيف (< Имя>, < ТипЭлемента>, < Родитель >)

كمية ()

يجد (< Имя >)

يتحرك(< Элемент>, < Родитель>, < МестоРасположения >)

يمسح (< Элемент >)

مجموعة العناصر متاحة على كل من العميل والخادم. تعديل مجموعة (إدراج الأساليب () وAdd () وMove () وDelete () ) متاحة فقط على الخادم. يمكنك البحث عن عدد العناصر والحصول عليها (طريقتا Find () وCount ()) على كل من العميل والخادم. عناصر المجموعة يمكن أن تكون:

• يشكل مجموعه؛
• this.FormTable;
• حقل النموذج؛
• زر النموذج.

يمكنك تعيين معالجات الأحداث برمجيًا لعناصر النموذج. الطريقة مخصصة لهذه الأغراض سيتاكشن(< ИмяСобытия>, < Действие >) .

دعونا نلقي نظرة على بعض الأمثلة الأكثر شيوعًا للعمل مع الأوامر والتفاصيل وعناصر النموذج.

إضافة أمر والزر المرتبط به:

// إنشاء أمر
فريق = الفرق. يضيف( ""تاريخ التغيرات"");
فريق . العمل = "المكون الإضافي_عرض_التاريخ"; // يجب أن يحتوي النموذج على إجراء بالاسم المحدد
فريق . عنوان = ""تاريخ التغيرات..."";
// قم بإنشاء زر وربطه بأمر
عنصر = العناصر. يضيف( ""تاريخ التغيرات""، النوع("FormButton" ));
اسم العنصر = ""تاريخ التغيرات"";

إضافة سمة وحقل الإدخال المرتبط بها:

// وصف التفاصيل المضافة
AddedDetails = مصفوفة جديدة؛
التفاصيل المضافة. يضيف(دعائم النموذج الجديد ("المشتري"، وصف النوع الجديد ( "DirectoryLink.Counterparties")، "عميل" ))؛
// تغيير تكوين التفاصيل
تغيير التفاصيل (التفاصيل المضافة);
// إنشاء حقل إدخال والاتصال بالسمات
عنصر = العناصر. Add("Buyer" , Type("FormField" ));
عنصر . عرض = FormFieldView. حقل الإدخال؛
عنصر . PathToData= "المشتري" ;

تعيين معالج حدث لعنصر النموذج:

ItemCustomer. SetAction("عندما يتغير" , "Connected_BuyerOnChange");

&OnClient
إجراء Connected_BuyerOnChange(عنصر)
// إجراءات الحدث
نهاية الإجراء

انتباه!

الإجراءات التي تم تعيينها كمعالجات للأحداث من التعليمات البرمجية باستخدام الطريقة سيتاكشن ()يوصى بتعيين البادئة Connectable_.

انتباه!

يمكنك تنزيل المعالجة باستخدام أمثلة للبحث البرمجي وتغيير التفاصيل والأوامر وعناصر النموذج المُدار.

وكائن نقل البيانات إلى هيكلة التعليمات البرمجية، يتم التحكم فيه في بيئة 1C 8.2.

مقدمة

لنبدأ بوصف موجز لمفهوم "النموذج المُدار" والمفاهيم ذات الصلة بمنصة 1C. قد يرغب خبراء النظام الأساسي في تخطي هذا القسم.

في عام 2008، أصبح الإصدار الجديد من منصة 1C متاحًا: Enterprise 8.2 (المشار إليه فيما يلي باسم التطبيق المُدار)، والذي يغير طبقة العمل بالكامل مع الواجهة بالكامل. يتضمن ذلك واجهة الأوامر والنماذج ونظام النوافذ. في الوقت نفسه، لا يتغير نموذج تطوير واجهة المستخدم في التكوين فحسب، بل يُقترح أيضًا بنية جديدة لفصل الوظائف بين تطبيق العميل والخادم.
يدعم التطبيق المُدار الأنواع التالية من العملاء:

• عميل سميك (وضع التشغيل العادي والمُدار)
• عميل رقيق
• العميل على شبكة الإنترنت

يستخدم التطبيق المُدار نماذج مبنية على تقنية جديدة. انهم يسمى النماذج المدارة. لتسهيل عملية الانتقال، يتم أيضًا دعم النماذج السابقة (ما يسمى بالنماذج العادية)، ولكن لم يتم تطوير وظائفها وهي متاحة فقط في وضع تشغيل العميل الكثيف.
الاختلافات الرئيسية بين النماذج المُدارة للمطور:

• وصف تعريفي، وليس "بكسلًا ببكسل" للهيكل. يتم تنفيذ الموضع المحدد للعناصر تلقائيًا بواسطة النظام عند عرض النموذج.
• يتم وصف جميع وظائف النموذج على أنها تفاصيلو فرق. التفاصيل هي البيانات التي يعمل النموذج معها، والأوامر هي الإجراءات التي سيتم تنفيذها.
• يعمل النموذج على كل من الخادم والعميل.
• في سياق العميل، لا تتوفر جميع أنواع التطبيقات تقريبًا، وبالتالي من المستحيل تغيير البيانات في قاعدة المعلومات.
• يجب تحديد كل أسلوب أو متغير نموذج التوجيه التجميعيوتحديد موقع التنفيذ (العميل أو الخادم) والوصول إلى سياق النموذج.

دعونا ندرج التوجيهات لتجميع أساليب النموذج:

• &OnClient
• &على الخادم
• &OnServerبدون سياق
• &OnClientOnServerبدون سياق

دعونا نوضح ما سبق. تعرض لقطة الشاشة مثالاً لنموذج مُدار والوحدة النمطية الخاصة به في وضع التطوير. ابحث عن الوصف التعريفي والدعائم وتوجيهات التجميع وما إلى ذلك.

ستكون جميع المناقشات الإضافية حول الجانب الأيمن من الرسم التوضيحي، وحول كيفية بناء كود الوحدة وما هي المبادئ التي ستسمح لك بتنفيذ تفاعل فعال بين العميل والخادم.

دعونا نحدد المشكلة

لقد مرت عدة سنوات منذ الاستخدام النشط للإصدار الجديد من منصة 1C وتم إصدار العديد من الحلول (التكوينات) بواسطة كل من 1C والعديد من شركائها.
خلال هذا الوقت، هل طور المطورون فهمًا مشتركًا لمبادئ التفاعل بين العميل والخادم عند إنشاء النماذج، وهل تغير نهج تنفيذ وحدات البرامج في الواقع المعماري الجديد؟

دعونا نلقي نظرة على بنية التعليمات البرمجية (وحدة النموذج) في عدة أشكال من نفس التكوين القياسي ونحاول العثور على الأنماط.
نعني بالبنية أقسام التعليمات البرمجية (غالبًا ما تكون كتل تعليق) المخصصة من قبل المطور لتجميع الأساليب وتوجيهات التجميع لهذه الأساليب.
مثال 1:
قسم معالجات الأحداث الطريقة - على العميل الطريقة - على الخادم الطريقة - على العميل قسم إجراءات الخدمة ووظائفها وظائف التحكم في الإدخال المساعد
مثال 2:
إجراءات الخدمة ووظائفها وثائق الدفع القيم معالجات الأحداث
مثال 3:
إجراءات الخدمة على الخادم إجراءات الخدمة على العميل إجراءات الخدمة على الخادم بدون سياق معالجات أحداث الرأس معالجات أحداث الأوامر
مثال 4:
إجراءات للأغراض العامة معالجات أحداث النموذج إجراءات النظام الفرعي "معلومات الاتصال".
في الأساس، بنية التعليمات البرمجية مفقودة، أو بعبارة ملطفة، فهي مشابهة لما كان في النماذج 8.1:

• الكلمات غير الإعلامية "عام، خدمة، مساعد".
• محاولات خجولة للفصل بين أساليب العميل والخادم.
• غالبًا ما يتم تجميع الطرق حسب عناصر الواجهة "العمل مع الجزء الجدولي من المنتجات ومعلومات الاتصال".
• الترتيب التعسفي للطرق ومجموعات التعليمات البرمجية. على سبيل المثال، قد تكون معالجات الأحداث في الأعلى في نموذج ما، وفي الأسفل في نموذج آخر، ولا يتم تمييزها على الإطلاق في نموذج ثالث، وما إلى ذلك.
• ودعنا لا ننسى أن كل هذا يتم ضمن تكوين واحد.
• نعم، هناك تكوينات تكون فيها الكلمات "عام، خدمة، مساعد" دائمًا في نفس الأماكن ولكن...

لماذا تحتاج إلى هيكل التعليمات البرمجية؟

• تبسيط الصيانة.
• تبسيط التعلم.
• تسجيل المبادئ العامة/المهمة/الناجحة.
• ... خيارك

لماذا لا يساعد معيار التطوير الحالي من 1C؟

دعونا نلقي نظرة على المبادئ المنشورة على أقراص ITS وفي "أدلة المطورين..." المتنوعة التي يوصى بها عند كتابة نموذج مُدار.

• تقليل عدد مكالمات الخادم.
• الحد الأقصى للحوسبة على الخادم.
• تعد مكالمات الخادم غير السياقية أسرع من المكالمات السياقية.
• برنامج مع وضع التواصل بين العميل والخادم في الاعتبار.
• وما إلى ذلك وهلم جرا.

هذه شعارات صحيحة تمامًا، لكن كيف ننفذها؟ كيفية تقليل عدد المكالمات، ماذا يعني البرنامج في وضع خادم العميل؟

أنماط التصميم أو حكمة الأجيال

لقد تم استخدام التفاعل بين العميل والخادم في تقنيات البرامج المختلفة لعقود من الزمن. إن الإجابة على الأسئلة الموضحة في القسم السابق معروفة منذ زمن طويل وتتلخص في مبدأين أساسيين.

• الواجهة البعيدة(يشار إليها فيما بعد بواجهة الوصول عن بعد)
• كائن نقل البيانات(يشار إليه فيما بعد بكائن نقل البيانات)

كلمة من مارتن فاولر وصفه لهذه المبادئ:

• … يجب أن يكون لكل كائن يحتمل أن يكون مخصصًا للوصول عن بعد واجهة ذات تفاصيل منخفضة، مما سيؤدي إلى تقليل عدد المكالمات المطلوبة لتنفيذ إجراء معين. ... بدلاً من طلب الفاتورة وجميع بنودها بشكل منفصل، عليك قراءة كافة بنود الفاتورة وتحديثها في طلب واحد. يؤثر هذا على بنية الكائن بالكامل...تذكر: واجهة الوصول عن بعد لا يحتوي على منطق المجال.
• ...لو كنت أمًا حانية، فسأقول لطفلي بالتأكيد: "لا تكتب أبدًا كائنات نقل البيانات!" في معظم الحالات، كائنات نقل البيانات ليست أكثر من مجموعة الحقول المتضخمة... قيمة هذا الوحش المثير للاشمئزاز تكمن فقط في الإمكانية إرسال أجزاء متعددة من المعلومات عبر الشبكة في مكالمة واحدة- تقنية ذات أهمية كبيرة للأنظمة الموزعة.

أمثلة على القوالب في منصة 1C

تحتوي واجهة برمجة التطبيقات المتوفرة للمطور عند تطوير نموذج مُدار على العديد من الأمثلة على هذه المبادئ.
على سبيل المثال، طريقة OpenForm()، وهي واجهة "تقريبية" نموذجية.
OpeningParameters = New Structure("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm(FormName, OpeningParameters);
قارن مع النمط المعتمد في الإصدار 8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

في سياق النموذج المُدار، هناك العديد من "كائنات نقل البيانات". يمكنك الاختيار النظاميةو تعريف المطور.
تقوم وحدات النظام بتصميم كائن تطبيق على العميل، في شكل عنصر بيانات نموذج واحد أو أكثر. من المستحيل إنشائها دون الرجوع إلى تفاصيل النموذج.

• بنية نماذج البيانات
• DataFormsCollection
• DataFormStructureWithCollection
• شجرة أشكال البيانات

يتم تحويل كائنات نقل بيانات النظام إلى أنواع التطبيقات والعكس باستخدام الطرق التالية:

• فاليوإنفورمداتا ()
• قيمة بيانات النموذج ()
• كوبيفورمداتا ()
• فاليو إنفورماتريبتس ()
• قيمة سمات النموذج ()

غالبًا ما يتم استخدام التحويل الصريح عند تكييف حل موجود. قد تتوقع الأساليب معلمات إدخال (استخدام الميزات)، مثل ValueTable بدلاً من FormDataCollection، أو تم تعريف الطريقة في سياق كائن التطبيق وأصبحت غير متوفرة للاتصال المباشر من النموذج.
مثال 1C v8.1:
// على العميل في سياق النموذج fillUserCache(DepartmentLink)
مثال 1C v8.2:
// على الخادم في سياق النموذج ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

كائنات نقل البيانات، التي يحدد المطور بنيتها، هي مجموعة فرعية صغيرة من الأنواع المتوفرة على كل من العميل والخادم. في أغلب الأحيان، يتم استخدام ما يلي كمعلمات ونتائج لطرق الواجهة "الخشنة":

• الأنواع البدائية (سلسلة، رقم، منطقية)
• بناء
• مراسلة
• مجموعة مصفوفة
• روابط لكائنات التطبيق (المعرف الفريد وتمثيل النص)

مثال: تقبل الطريقة قائمة أوامر تغيير الحالة وتعيد وصفًا للأخطاء إلى العميل.
&OnServerWithoutContext الدالة ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [الطلب] [وصف الخطأ] لكل دورة من الطلبات StartTransaction(); جرب DocOb = Order.GetObject(); …. إجراءات أخرى، ممكنة ليس فقط مع الأمر... استثناء CancelTransaction(); Errors.Insert(Order, ErrorDescription()); this.EndAttempt; EndCycle; خطأ في العودة؛ EndFunction // ServerChangeOrderStatus()

هيكلة الكود

الأهداف الرئيسية التي يجب أن تعكسها وحدة النموذج المُدار وأساليب الحل.

• فصل واضح بين رمز العميل والخادم.دعونا لا ننسى أنه في وقت التنفيذ، تكون هاتان عمليتان متفاعلتان، ولكل منهما وظائف متاحة مختلفة بشكل كبير.
• تحديد واضح لواجهة الوصول عن بعد، ما هي طرق الخادم التي يمكن استدعاؤها من العميل وأيها لا يمكن استدعاؤها؟ تبدأ أسماء طرق الواجهة البعيدة بالبادئة "الخادم". يسمح لك هذا برؤية نقل التحكم إلى الخادم على الفور أثناء قراءة التعليمات البرمجية، ويبسط استخدام المساعدة السياقية. لاحظ أن التوصية الرسمية (ITS) تقترح تسمية الأساليب ذات الإصلاحات اللاحقة، على سبيل المثال، ChangeOrderStatusOnServer(). ومع ذلك، نكرر أنه لا يمكن استدعاء كافة أساليب الخادم من العميل، وبالتالي فإن إمكانية الوصول المنطقي أكثر أهمية من موقع التجميع. ولذلك، باستخدام البادئة "Server"، فإننا نحدد فقط الطرق المتاحة للعميل؛ فلنستدعي طريقة المثال ServerChangeOrderStatus().
• مقروئية.مسألة ذوق، نحن نقبل الطلب عندما تبدأ الوحدة بإجراءات إنشاء نموذج على الخادم وطرق الوصول عن بعد.
• قابلية الصيانة.يجب أن يكون هناك موقع واضح لإضافة الكود الجديد. النقطة المهمة هي أن قوالب الطريقة التي تم إنشاؤها تلقائيًا بواسطة المكوّن تتم إضافتها إلى نهاية الوحدة. نظرًا لأن معالجات الأحداث لعناصر النموذج يتم إنشاؤها تلقائيًا في أغلب الأحيان، يتم وضع الكتلة المقابلة في الأخير، حتى لا يتم سحب كل معالج إلى مكان آخر في الوحدة.

يوجد أدناه الهيكل الأساسي للوحدة التي تنفذ الأهداف المذكورة.

• خيار رسومي – يُظهر بوضوح التدفق الرئيسي للتنفيذ.
• يعد خيار النص مثالاً لتصميم قالب لإدراج بنية بسرعة في وحدة نموذج جديدة.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""التاريخ =""/> // <Описание> // // ////////////////////////////////////////////////////////////////////// ////////////////////////// // متغيرات الوحدة //////////////// // //////////////////////////////////////////////////////////// ////////// // على الخادم //******* الأحداث على الخادم ******* &في إجراء الخادم عند الإنشاء على الخادم (الفشل، المعالجة القياسية) / / أدخل محتويات المعالج نهاية الإجراء //******* واجهة الوصول عن بعد ******* //******* منطق الأعمال على الخادم ******* ///////// ////////////////////////////////////////// /////// /////////////////// // الطرق الشائعة للعميل والخادم /////////////// /////// /////////////////////////////////////////////////// ///// //////// // على العميل //******* منطق العمل على العميل ******* //******* الفريق * ***** //********* أحداث العميل ******* ////////////////////////// ///// ///////////////////////////////////////////////////// // // مشغلو البرنامج الرئيسيون

أسئلة ذات صلة

في الختام، سنحدد العديد من المجالات التي من المفيد التفكير فيها عند برمجة التفاعل بين العميل والخادم.

• خيارات تنفيذ واجهة الوصول عن بعد. عدم التزامن، ومستوى التفاصيل...
• التخزين المؤقت.اتخذت 1C قرارًا معماريًا غير ناجح، حيث قدمت التخزين المؤقت فقط على مستوى طرق استدعاء الوحدات النمطية المشتركة وعدم توفير إمكانيات التحكم (وقت الملاءمة، إعادة التعيين عند الطلب).
• مكالمات الخادم الضمنية. لا تنس الميزات التكنولوجية، فالعديد من العمليات "غير الضارة" التي تتم على العميل تستفز النظام الأساسي للاتصال بالخادم.

نماذجفي 1C:Enterprise مخصص لعرض وتحرير المعلومات الموجودة في قاعدة البيانات. يمكن أن تنتمي النماذج إلى كائنات تكوين محددة أو توجد بشكل منفصل عنها ويتم استخدامها بواسطة حل التطبيق بأكمله.

على سبيل المثال، دليل التسمياتقد تحتوي على العديد من النماذج التي سيتم استخدامها لأغراض محددة - تحرير عنصر الدليل، وعرض القائمة، وما إلى ذلك:

جنبا إلى جنب مع هذا، قد تكون هناك نماذج عامة لا تنتمي إلى كائنات تكوين محددة - النماذج العامة.

النماذج الأساسية

يمكن استخدام كل كائن تكوين لتنفيذ بعض الإجراءات القياسية. على سبيل المثال، بالنسبة لأي دليل، قد تحتاج إلى عرض قائمة بعناصره، وعرض العناصر الفردية للدليل، وعرض مجموعة من الدليل، وتحديد عناصر ومجموعات من العناصر من الدليل. بالنسبة لأي مستند، ستكون قائمة هذه الإجراءات أصغر بكثير: عرض قائمة المستندات، والاختيار من قائمة المستندات، وعرض مستند منفصل.

لضمان تنفيذ هذه الإجراءات القياسية باستخدام بيانات كائنات حلول التطبيق، يوجد لكل منها مجموعة من النماذج الأساسية التي سيتم استخدامها عند تنفيذ الإجراءات المقابلة. يمكن تعيين أي من النماذج التابعة لهذا الكائن باعتباره النموذج الرئيسي. على سبيل المثال، في الدليل التسمياتقد توجد الأشكال الأساسية التالية:

والوثيقة استلام البضائع والخدماتسيكون تكوين النماذج الرئيسية مختلفًا:

وهكذا، إذا كان المستخدم يريد عرض قائمة الدليل التسمياتأو قائمة الوثائق استلام البضائع والخدمات، سيقوم النظام بفتح النموذج المقابل المخصص كنموذج قائمة لهذه الكائنات.

النماذج التي تم إنشاؤها تلقائيًا

إحدى الميزات المهمة لنظام 1C:Enterprise 8 هي آلية النماذج التي يتم إنشاؤها تلقائيًا. تحرر هذه الآلية المطور من الاضطرار إلى إنشاء جميع النماذج الممكنة لكل كائن تكوين. يحتاج المطور فقط إلى إضافة كائن تكوين جديد، وسيقوم النظام نفسه، في اللحظات المناسبة من عمل المستخدم، بإنشاء النماذج اللازمة لعرض المعلومات الموجودة في هذا الكائن.

وبالتالي، يحتاج المطور إلى إنشاء نماذجه الخاصة من كائنات حلول التطبيقات فقط إذا كان يجب أن يكون لها اختلافات (تصميم مختلف أو سلوك محدد) عن النماذج التي تم إنشاؤها تلقائيًا بواسطة النظام.

ربط النموذج بالبيانات

ما إذا كان النموذج ينتمي إلى كائن تكوين معين لا يحدد تركيبة البيانات التي يتم عرضها في النموذج. حقيقة أن النموذج ينتمي، على سبيل المثال، إلى الدليل التسميات، يسمح لك بتعيينه كأحد النماذج الرئيسية لهذا الدليل، لكنه لا يحدد بأي حال من الأحوال البيانات التي سيعرضها هذا النموذج وما سيكون سلوكه.

من أجل ربط نموذج بالبيانات، يتم استخدام تفاصيل النموذج، التي تشير إلى قائمة البيانات التي يعرضها النموذج. جميع النماذج نفسها لها نفس السلوك، بغض النظر عن البيانات التي تعرضها. ومع ذلك، يمكن تعيين إحدى سمات النموذج باعتبارها السمة الرئيسية له (يتم تمييزها بالخط العريض)، وفي هذه الحالة سيتم استكمال السلوك القياسي للنموذج وخصائصه اعتمادًا على نوع سمة النموذج الرئيسية:

على سبيل المثال، إذا تم تعيين مستند كسمة النموذج الرئيسية استلام البضائع والخدمات، فعند إغلاق النموذج سيطلب النظام تأكيد تسجيل هذه الوثيقة ونشرها. إذا قمت بتعيين دليل، على سبيل المثال، باعتباره السمة الرئيسية للنموذج التسميات، فلن يظهر طلب التأكيد هذا عند إغلاق النموذج.

هيكل النموذج

الميزة الرئيسية للنماذج هي أنها لا يتم رسمها من قبل المطور بالتفصيل “بكسل ببكسل”. النموذج الموجود في التكوين هو وصف منطقي لتكوين النموذج. ويتم تنفيذ الموضع المحدد للعناصر تلقائيًا بواسطة النظام عند عرض النموذج.

يتم وصف الجزء المعروض من النموذج (المرئي للمستخدم) على أنه شجرة تحتوي على عناصر النموذج.

يمكن أن تكون العناصر عبارة عن حقول إدخال، أو خانات اختيار، أو أزرار اختيار، أو أزرار، وما إلى ذلك. بالإضافة إلى ذلك، يمكن أن يكون العنصر عبارة عن مجموعة تتضمن عناصر أخرى. يمكن تمثيل المجموعة على هيئة لوحة بإطار، أو لوحة بها صفحات (إشارات مرجعية)، أو صفحة نفسها، أو لوحة أوامر. بالإضافة إلى ذلك، يمكن أن يكون العنصر عبارة عن جدول يتضمن أيضًا عناصر (أعمدة). يصف هيكل العنصر كيف سيبدو النموذج.

يتم وصف جميع وظائف النموذج في شكل تفاصيل وأوامر. التفاصيل هي البيانات التي يعمل النموذج معها، والأوامر هي الإجراءات التي سيتم تنفيذها. وبالتالي، يجب على المطور في محرر النماذج تضمين التفاصيل والأوامر الضرورية في النموذج، وإنشاء عناصر النموذج التي تعرضها، وإذا لزم الأمر، ترتيب العناصر في مجموعات.

وبناءً على هذا الوصف المنطقي، يقوم النظام تلقائيًا بإنشاء مظهر النموذج لعرضه للمستخدم. في هذه الحالة، يأخذ النظام في الاعتبار الخصائص المختلفة للبيانات المعروضة (على سبيل المثال، النوع) من أجل ترتيب عناصر النموذج بشكل ملائم قدر الإمكان للمستخدم.

يمكن للمطور التأثير على ترتيب العناصر بإعدادات مختلفة. يمكنه تحديد ترتيب العناصر وتحديد العرض والارتفاع المطلوب. ومع ذلك، هذه مجرد بعض المعلومات الإضافية لمساعدة النظام في عرض النموذج.

في النماذج، لا يمكن للمطور استخدام أوامر النموذج نفسه فحسب، بل أيضًا الأوامر العامة المستخدمة في واجهة الأوامر الخاصة بالتكوين بأكمله. بالإضافة إلى ذلك، من الممكن إنشاء أوامر قابلة للضبط والتي ستفتح نماذج أخرى مع الأخذ في الاعتبار البيانات المحددة للنموذج الحالي. على سبيل المثال، قد يكون ذلك بمثابة استدعاء تقرير عن الأرصدة في المستودع المحدد حاليًا في نموذج الفاتورة.

نعلم جميعًا أن شركة 1C كان لديها العديد من الإصدارات المختلفة لمنصة 1C، سنهتم الآن بأحد الإصدارات الأحدث وقت كتابة هذا المقال، وهي الإصدارات 1C 8.2 و1C 8.3. إذا كان عليك العمل في كلا الإصدارين، فأنت على الأرجح لاحظت اختلافات في واجهات هذه الإصداراتبالنسبة للمستخدمين يختلفون فقط في المظهر. في الأساس خيار التطبيق العادي أو المداريخبر النظام بالنماذج التي سيتم عرضها للتشغيل، منتظمة أو خاضعة للرقابة، بالإضافة إلى عميل التطبيق الذي سيتم استخدامه افتراضيًا، سواء كان سميكًا أم رفيعًا. للحصول على معلومات أكثر تفصيلاً عن العملاء، اقرأ المقال "ما هي العملاء السميكة والرفيعة في 1C، بالإضافة إلى الاختلافات بينهم."

تطبيق 1C العادي (أشكال عادية، واجهة عادية، الإصدار 1C 8.2)

في 1C 8.2 من الممكن العمل فقط مع النماذج العادية، في وضع التطبيق العادي. توضح الصورة أدناه قاعدة البيانات في وضع التشغيل "تطبيق 1C العادي" (النماذج العادية).

تطبيق 1C المُدار (النماذج المُدارة، الواجهة المُدارة، الإصدار 1C 8.3)

على منصة 1C 8.3، يمكننا العمل مع كل من النماذج العادية (في وضع التوافق) والنماذج المُدارة. علاوة على ذلك تحتوي النماذج المدارة على نوعين من العرض، وهو قياسي وسيارة أجرة. يظهر أدناه مثال لتكوين 1C 8.3 مع النماذج المُدارة القياسية، وبعده تظهر واجهة "Taxi".

ما الفرق بين تطبيق 1C العادي والمُدار؟

كما اكتشفنا بالفعل التطبيق العادي والتطبيق المُدار هما هذان النوعان من إطلاق برنامج 1C. علاوة على ذلك، اعتمادًا على قيمة نوع الإطلاق 1C ( التطبيق العادي أو المدار)، سيتم تحميل واجهة محددة افتراضيًا ( النماذج العادية أو المدارة)، وبالتالي هناك الكثير من المرادفات لهذا المفهوم. نود أن نشير إلى أن الاختلافات في الواجهات كبيرة جدًا؛ فقد تم إعادة تصميم الواجهة المُدارة بالكامل. من حيث المبدأ، هذه هي كل الاختلافات التي يراها المستخدمون العاديون لبرنامج 1C. أما بالنسبة للمبرمجين، فإن الواجهة المُدارة تتطلب كتابة تعليمات برمجية معدلة، لأن التطوير تم بالفعل في 1C 8.3، وليس في 1C 8.2، وبالتالي كل العواقب المترتبة على ذلك. يجب أيضًا تقسيم الكود إلى عميل وخادم؛ تتم الإشارة إلى ذلك باستخدام التوجيهات المقابلة في أداة التهيئة.

كليويف ف.

http://prof1c.kklab.ru

العمل مع المفاتيح

يرجى مراعاة جميع مستخدمي خدمة الموقع - أقوم بنشر المواد في قسم المبتدئين !!!

8.2 النماذج المُدارة

أثناء دراسة سلوك النماذج المُدارة، يواجه المبرمجون أو مطورو الواجهة مسألة مكان وجود المحولات في النماذج المُدارة وكيفية إضافتها إلى النموذج. إنه شيء صغير، ولكن من غير السار قضاء الكثير من الوقت في مثل هذه التفاهات، على الرغم من أنه يمكن قضاء هذا الوقت في تطوير الخوارزمية وتحسينها، بدلاً من تصميم النموذج.

لذلك، دعونا ننشئ تكوينًا فارغًا لفهم السؤال، أو نختار أي تكوين نموذجي.
انتقل إلى المجموعة التي تحتوي على الأدلة، وأضف دليلاً جديدًا للتجربة. أود أن أشير إلى أن التكوين يجب أن يحتوي على وضع التشغيل الرئيسي - التطبيق المُدار.

لذا، فلنقم بإنشاء دليل جديد وإضافة السمة "Property1" بالنوع "Boolean"

الآن دعنا ننتقل إلى علامة التبويب "النماذج" ونضيف نموذجًا جديدًا.

لذلك، تم إنشاء النموذج الذي يتم التحكم فيه، والآن دعونا نعمل مع النموذج ونجد مكان وجود المفتاح.
هذا هو شكلنا، وعليه نرى دعائمنا، ولكن على شكل علم

إذن ما الخطأ الذي فعلناه؟
دعونا ننظر إلى خصائص الدعائم لمعرفة ما إذا كان هناك تبديل لنوع التحكم.
ونرى أن حقل التبديل ليس هنا!(أين أخطأنا؟

على ما يبدو، يعتمد نوع التحكم في النموذج على نوع البيانات، فلنعود إلى خصائص النموذج، وهي علامة تبويب التفاصيل، ونغير خصائص السمة لدينا - وهي نوعها "منطقي" إلى النوع "رقم" ".

الآن دعنا نعود إلى خصائص عنصر التحكم ونتحقق مما إذا كان عرض عنصر التحكم قد تمت إضافته إلى خصائصه - - - ومرحبًا، نرى العرض هناك - تبديل الحقل.

والآن ننظر إلى النموذج، ما نرى:

نرى - 3 قيم افتراضية، 3 مفاتيح، لكننا نحتاج إلى اثنين منها، انتقل مرة أخرى إلى خصائص السمة، وانظر إلى خصائص "عدد الأعمدة" هناك

لـ 2 - اضبط عدد الأعمدة - 2.

قد يوقف هذا المبرمج المتعب قليلًا)) ولكن الآن هو ونحن نعرف ذلك!

8.2 النماذج العادية.

مملة مع المفاتيح في الأشكال العادية.
هناك مثل هذه اللحظات، وهي تحدث بالفعل) عندما تحتاج إلى تعديل بعض النماذج الجاهزة، والتي تحتوي بالفعل على بعض المفاتيح، وتحتاج إلى إضافة مفتاح آخر إلى هذا النموذج. هذا هو المكان الذي ينشأ فيه نوع من الملل، والذي يستغرق الكثير من الوقت، وليس الوقت لبرمجة الكود - ولكن مضيعة للوقت من أجل عرض هذه المفاتيح للمستخدم.

لذلك دعونا ننظر إلى مثال. يوجد مثل هذا المستند لتعديل الإيصالات في 1C UPP - إنه موجود بالتأكيد. لقد احتجنا ذات مرة إلى إضافة مفاتيح إليها بحيث يتم رسم إدخالات مختلفة قليلاً للمحاسبة. ما هي المشكلة، يبدو أننا يجب علينا، يجب أن نفعل ذلك. لكن هذا النموذج يحتوي بالفعل على زري اختيار.

هذا هو الشكل الذي يبدو عليه النموذج الذي نحتاج فيه إلى إضافة المزيد من المفاتيح

في علامة التبويب خيارات متقدمة، نود وضع زري اختيار آخرين. لذا فإن الخطوة الأولى هي إضافة عنصر تحكم جديد بجرأة إلى المكان الذي نحتاجه وإدراجه.

يبدو أن كل شيء بسيط. نقوم بإنشاء سمة جديدة بالنوع "الرقم" ونقوم بإدخال مفتاحين، أحدهما سيكون قادرًا على كتابة البيانات إلى السمة، والآخر لن يتمكن من ذلك.

أضف عنصر تحكم جديدًا - Switch، وأضف Switch2 في الجدول مع عدد المفاتيح ووصفها، وقم بتعيين Switch1 أولاً في المجموعة واضغط على OK. ضع عناصر التحكم التي تم إنشاؤها في النموذج. نقوم بتحديث تكوين قاعدة البيانات (F7) وتشغيله لتصحيح الأخطاء.

عند التنفيذ (عند إنشاء مستند جديد في وضع 1C:Enterprise)، نرى أنه بغض النظر عن مقدار محاولتنا النقر على Switch2، لا يحدث شيء. العناصر لا تعمل كما ينبغي. هناك خدعة واحدة هنا.
العودة إلى التكوين. حدد عنصر القائمة النموذج -> تعيين ترتيب الاجتياز... (من المهم أن يكون النموذج مفتوحًا على الشاشة)

لكي تعمل المحولات الخاصة بنا، يجب عليك كسر الطلب التلقائي والموافقة على الترتيب اليدوي. ووضعها في النموذج بحيث تسير مفاتيحنا الواحدة تلو الأخرى بالترتيب.

نعم. قم بتحديث التكوين وحاول تشغيله.
عظيم. كل شيء يعمل.

بالإضافة إلى ذلك - فيديو (بدون صوت، لذلك كل شيء واضح)