جزئیات فرم مدیریت شده (1Cv8). افزودن و تغییر عناصر فرم های مدیریت شده به صورت برنامه ای افزودن ویژگی ها به فرم مدیریت شده

پلتفرم 1C: Enterprise به شما امکان می دهد عناصر یک فرم مدیریت شده را به صورت برنامه ریزی شده اضافه و تغییر دهید. بیایید بفهمیم که چرا ممکن است این مورد نیاز باشد.

تغییر نرم افزار فرم ممکن است در موارد مختلفی مورد نیاز باشد:

  • هنگام نهایی کردن پیکربندی های استاندارد برای تسهیل روند به روز رسانی بعدی. در این صورت فقط ماژول فرم تغییر خواهد کرد. به روز رسانی ماژول ها بسیار ساده تر از فرم ها است.
  • هنگام پیاده سازی برخی از الگوریتم های رایج برای مثال، در زیرسیستم «ممنوعیت ویرایش جزئیات شی»، می‌توان دکمه‌ای را به‌صورت برنامه‌نویسی برای تمام اشیاء متصل به زیرسیستم ایجاد کرد تا امکان ویرایش جزئیات را فعال کند.
  • هنگام پیاده سازی برخی از الگوریتم های خاص. به عنوان مثال، در فهرست نامگذاری، فیلدهایی برای ویرایش جزئیات اضافی ایجاد می شود.

در یک فرم مدیریت شده، می توانید به صورت برنامه ریزی شده اضافه، تغییر و حذف کنید:

  • ملزومات؛
  • تیم های محلی؛
  • عناصر.

تمام این عملیات فقط روی سرور امکان پذیر است.

تغییر شکل برنامه ای محدودیت هایی دارد:

  • شما فقط می توانید جزئیات / دستورات / عناصر اضافه شده را حذف کنید. شما نمی توانید به صورت برنامه ریزی شده اشیاء ایجاد شده در پیکربندی را حذف کنید.
  • شما نمی توانید یک ویژگی را به عنوان اصلی اختصاص دهید.

تغییر دستورات فرم

برای مدیریت ترکیب دستورات برای یک شی فرم مدیریت شدهمجموعه ای وجود دارد تیم ها

    اضافه کردن (< ИмяКоманды >)

    تعداد ()

    پیدا کردن (< ИмяКоманды >)

    حذف (< Команда >)

مجموعه Teams هم روی کلاینت و هم روی سرور در دسترس است. شما می توانید مجموعه (روش های Add() و Delete()) را فقط در سرور تغییر دهید. می‌توانید تعداد عناصر (روش‌های Find () و Count ()) را هم در کلاینت و هم در سرور جستجو کنید و دریافت کنید.

به عنوان مثالی از کار با دستورات فرم، اجازه دهید یک دستور ChangeHistory جدید با عنوان "ChangeHistory..." ایجاد کنیم که کنترل کننده را فراخوانی می کند. تاریخچه نمایش(). ایجاد زمانی رخ می دهد که فرم باز شود.

&روی سرور
روش WhenCreatingOnServer (شکست، پردازش استاندارد)
تیم = تیم ها اضافه کردن( "تاریخچه تغییرات");
تیم . عمل = ;
تیم . عنوان = "تاریخچه تغییرات...";
پایان رویه
&OnClient
روش Connectable_DisplayHistory(Command)
// اعمال فرمان
پایان رویه

کنترل کننده فرمان باید بر روی یک فرم قرار داشته باشد و دارای دستورالعمل کامپایل &OnClient باشد.

تغییر جزئیات فرم

خواندن ترکیب جزئیات فرم توسط تابع انجام می شود دریافت جزئیات(< Путь >) برگرداندن آرایه ای از نوع FormAttributes. پارامتر تابع مسیر صفت والد (به عنوان رشته) را مشخص می کند. اگر پارامتر حذف شود یا یک رشته خالی مشخص شود، جزئیات سطح بالا برگردانده می شود.

تغییر جزئیات با استفاده از روش انجام می شود تغییر جزئیات(<جزئیات اضافه شد>, <جزئیات قابل جابجایی>) هدف - شی فرم مدیریت شده. به پارامترها جزئیات اضافه شدو جزئیات قابل جابجاییآرایه هایی با عناصری از نوع ویژگی های فرم منتقل می شوند.

توجه!

فرآیند تغییر ترکیب جزئیات کاملاً منابع فشرده است. فرم در واقع در حال بازسازی است. در این راستا کار با جزئیات فرم به صورت دسته ای انجام می شود.

بیایید یک ویژگی فرم جدید با نام خریدار ایجاد کنیم:


AddedDetails = آرایه جدید.
جزئیات اضافه شده افزودن (ویژگیهای فرم جدید("خریدار"، توضیحات نوع جدید ("DirectoryLink. Counterparties")، "Client")).

// تغییرات در ترکیب جزئیات
);

تغییر عناصر فرم

برای کنترل ترکیب عناصر یک شی فرم مدیریت شدهمجموعه ای وجود دارد عناصر. این مجموعه چندین روش دارد:

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

    اضافه کردن (< Имя>, < ТипЭлемента>, < Родитель >)

    تعداد ()

    پیدا کردن (< Имя >)

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

    حذف (< Элемент >)

مجموعه Items هم روی کلاینت و هم روی سرور در دسترس است. یک مجموعه را اصلاح کنید (روش‌ها را وارد کنید () ، افزودن () ، انتقال () و حذف ()) فقط در سرور موجود هستند. می‌توانید تعداد عناصر (روش‌های Find () و Count ()) را هم در کلاینت و هم در سرور جستجو کنید و دریافت کنید. عناصر مجموعه می توانند عبارتند از:

  • FormGroup;
  • FormTable;
  • FormField;
  • دکمه فرم.

می‌توانید به‌صورت برنامه‌نویسی، کنترل‌کننده‌های رویداد را به عناصر فرم اختصاص دهید. این روش برای این اهداف در نظر گرفته شده است SetAction(< ИмяСобытия>, < Действие >) .

بیایید به برخی از رایج ترین نمونه های کار با دستورات، جزئیات و عناصر فرم نگاه کنیم.

افزودن یک فرمان و دکمه مربوط به آن:

// یک دستور ایجاد کنید
تیم = تیم ها اضافه کردن( "تاریخچه تغییرات");
تیم . عمل = "Plug-in_Display History"; // فرم باید حاوی رویه ای با نام مشخص شده باشد
تیم . سرفصل = "تاریخچه تغییرات...";
// یک دکمه ایجاد کنید و آن را با یک دستور مرتبط کنید
عنصر = اقلام اضافه کردن( "تاریخچه تغییرات", Type("FormButton" ));
Element.CommandName = "تاریخچه تغییرات";

افزودن یک ویژگی و فیلد ورودی مرتبط:

// شرح جزئیات اضافه شده
AddedDetails = آرایه جدید.
جزئیات اضافه شده اضافه کردن(«خریدار»، توضیحات نوع جدید ( "DirectoryLink. طرف مقابل")، "مشتری" ))؛
// تغییر ترکیب جزئیات
ChangeDetails (جزئیات اضافه شده);
// ایجاد یک فیلد ورودی و اتصال با ویژگی ها
عنصر = اقلام Add("خریدار" , Type("FormField" ));
عنصر . View = FormFieldView. فیلد ورودی؛
عنصر . PathToData= "خریدار" ;

تخصیص یک کنترل کننده رویداد به یک عنصر فرم:

مورد مشتری. SetAction("وقتی تغییر می کند"، "Connected_BuyerOnChange");

&OnClient
روش Connected_BuyerOnChange(عنصر)
// اقدامات رویداد
پایان رویه

توجه!

رویه هایی که به عنوان کنترل کننده رویداد از کد با استفاده از روش تنظیم می شوند SetAction()، توصیه می شود پیشوند Connectable_ را تنظیم کنید.

توجه!

می توانید پردازش را با نمونه هایی از جستجوی برنامه ای و تغییر جزئیات، دستورات و عناصر یک فرم مدیریت شده دانلود کنید.

جزئیات فرم

مجموعه ای از جزئیات فرم، ترکیب داده هایی را که در فرم نمایش داده، ویرایش یا ذخیره می شود، توصیف می کند. در عین حال، جزئیات فرم به خودی خود امکان نمایش و ویرایش داده ها را فراهم نمی کند. عناصر فرم (به بخش "عناصر فرم" این فصل مراجعه کنید) مرتبط با جزئیات فرم برای نمایش و ویرایش استفاده می شود. مجموعه تمام جزئیات فرم داده فرم نامیده می شود.

مهم!باید به خاطر داشت که برخلاف فرم‌های معمولی، تمام داده‌ها در یک فرم مدیریت شده باید در قالب جزئیات شرح داده شوند. استفاده از متغیرهای ماژول فرم به عنوان منابع داده برای عناصر فرم مجاز نیست.

امکان واگذاری وجود دارد جزئیات فرم اولیه، یعنی ویژگی هایی که عملکرد استاندارد فرم را تعیین می کنند (پسوند فرم). باید به خاطر داشت که یک فرم فقط می تواند یک ویژگی اصلی داشته باشد.

پسوند فرم- اینها ویژگی ها، روش ها و پارامترهای فرم اضافی شی ManagedForm هستند، مشخصه شی که عنصر اصلی فرم است.

در طول فرآیند توسعه فرم، می‌توانید به صراحت توانایی مشاهده و ویرایش جزئیات فرم خاص، از نظر نقش‌ها را با استفاده از ویژگی‌های مشاهده و ویرایش تنظیم کنید (برای جزئیات بیشتر، به بخش «تنظیمات فرم مبتنی بر نقش» در «ویرایشگران» مراجعه کنید. فصل). علاوه بر این، در دسترس بودن یک ویژگی خاص در خود فرم را می توان با استفاده از گزینه های کاربردی پیکربندی کرد (جزئیات بیشتر در مورد گزینه های عملکردی را می توان در فصل "مدیریت رابط پیکربندی" مشاهده کرد).

ویژگی ویژگی فرم داده های ذخیره شدهنشانه این است که تغییر تعاملی در جزئیات منجر به تلاش برای مسدود کردن داده های فرم برای ویرایش و همچنین تنظیم خودکار پرچم اصلاح فرم می شود.

انواع داده در فرم مدیریت شده موجود است

یک فرم مدیریت شده همچنین از نظر نوع داده ای که با آن کار می کند با یک فرم معمولی متفاوت است. اگر فرم معمولی با اکثر انواعی که 1C:Enterprise ارائه می دهد کار می کند (از جمله انواع DirectoryObject، DocumentObject، و غیره)، سپس در فرم مدیریت شده می توان دسته بندی های زیر را از هم تشخیص داد:

  • انواعی که مستقیماً در فرم استفاده می‌شوند، انواعی هستند که در کنار مشتری نازک و وب وجود دارند (به عنوان مثال، Number، DirectoryLink.Products، GraphicScheme، TabularDocument).
  • انواعی که به انواع داده های ویژه تبدیل می شوند - انواع داده های فرم مدیریت شده. چنین انواعی در لیست جزئیات فرم در داخل پرانتز نمایش داده می شوند، به عنوان مثال (DirectoryObject.Products).
  • لیست پویا (برای جزئیات بیشتر به بخش «فهرست پویا» این فصل مراجعه کنید).

تبدیل اشیاء برنامه به داده های فرم

برخی از انواع برنامه ها (مانند DirectoryObject و غیره) در سمت نازک و سرویس گیرنده وب وجود ندارند (برای جزئیات بیشتر به فصل مفهوم برنامه مدیریت شده مراجعه کنید). بنابراین، این پلتفرم برای نشان دادن این گونه برنامه ها در فرم، انواع داده های ویژه ای را معرفی کرده است که برای کار در فرم های مدیریت شده طراحی شده اند. این ویژگی یک برنامه مدیریت شده، تبدیل اشیاء برنامه به شکل داده را ضروری می کند (و بالعکس).

انواع داده های زیر استفاده می شود:

  • Form DataStructure – شامل مجموعه ای از خواص از نوع دلخواه است. ویژگی ها می توانند سایر ساختارها، مجموعه ها یا ساختارهایی با مجموعه باشند. این نوع به عنوان مثال به شکل DirectoryObject نشان داده می شود.
  • FormDataCollection فهرستی از مقادیر تایپ شده، شبیه به یک آرایه است. یک عنصر مجموعه با نمایه یا شناسه قابل دسترسی است. دسترسی با شناسه ممکن است در برخی موارد در دسترس نباشد. این به دلیل نوع شیء کاربردی است که توسط این مجموعه نشان داده شده است. شناسه می تواند هر عدد صحیحی باشد. این نوع به عنوان مثال در قالب یک قسمت جدولی نشان داده می شود.
  • Form DataStructureWithCollection یک شی است که به صورت یک ساختار و یک مجموعه نمایش داده می شود. می توان با آن مانند هر یک از این موجودات رفتار کرد. این نوع به عنوان مثال مجموعه ای از رکوردها را در یک فرم نشان می دهد.
  • Form DataTree – یک شی طراحی شده برای ذخیره داده های سلسله مراتبی.

یک شی برنامه توسط یک یا چند عنصر داده فرم نمایش داده می شود. به طور کلی، سلسله مراتب و ترکیب داده های فرم به پیچیدگی و ارتباط بین اشیاء کاربردی فرم مدیریت شده بستگی دارد.

به عنوان مثال، یک سند حاوی یک بخش جدولی توسط یک شی از نوع FormDataStructure (خود سند) نشان داده می شود که یک شی از نوع FormDataCollection (بخش جدولی سند) تابع آن است.

مهم!هنگام توسعه یک پیکربندی، مهم است که به یاد داشته باشید که اشیاء برنامه فقط در سرور در دسترس هستند، در حالی که اشیاء داده فرم را می توان هم در سرور و هم در سرویس گیرنده استفاده کرد.

انتقال داده ها بین بخش های مشتری و سرور یک فرم مدیریت شده

در واقع می توان گفت که داده های فرم نمایش یکپارچه داده ها از اشیاء برنامه های مختلف است که فرم با آنها به طور یکنواخت کار می کند و روی سرور و کلاینت وجود دارد. به این معنا که فرم حاوی مقداری «طرح‌نمایی» از داده‌های شی برنامه در قالب انواع داده‌های خودش است و در صورت لزوم تبدیل بین آنها را انجام می‌دهد. با این حال، اگر توسعه‌دهنده پیکربندی الگوریتم پردازش داده خود را پیاده‌سازی کند، باید تبدیل داده‌ها (از انواع تخصصی به انواع برنامه‌ها و بالعکس) را به طور مستقل انجام دهد.

هنگام ویرایش جزئیات فرم در یک ویرایشگر تخصصی (برای جزئیات بیشتر، به بخش "جزئیات فرم" از فصل "ویرایشگران" مراجعه کنید)، ممکن است در حین اجرای فرم بر انتقال داده ها بین مشتری و سرور تأثیر بگذارد. برای این کار از ستون ویرایشگر جزئیات استفاده می شود. همیشه استفاده کنید. تأثیر این ویژگی برای سه نوع ویژگی متفاوت است:

  • برای یک ویژگی تابع یک لیست پویا (ستون لیست پویا):
    • ویژگی فعال - ویژگی همیشه از پایگاه داده خوانده می شود و در داده های فرم گنجانده می شود.
    • ویژگی غیرفعال است - ویژگی از پایگاه داده خوانده می شود و تنها زمانی در داده های فرم گنجانده می شود که یک عنصر فرم قابل مشاهده در حال حاضر مرتبط با ویژگی یا ویژگی فرعی آن وجود داشته باشد.
  • برای وسایل زیر مجموعه حرکت:
    • ویژگی فعال است - حرکات سند از پایگاه داده خوانده می شود و در داده های فرم وجود خواهد داشت.
    • ویژگی غیرفعال است - حرکات سند از پایگاه داده خوانده نمی شود و در داده های فرم گنجانده نمی شود (اگر هیچ عنصر فرمی وجود نداشته باشد که به حرکات سند اشاره کند).
  • سایر جزئیات فرم:
    • ویژگی فعال است - مشخصه در داده های فرم وجود دارد، صرف نظر از اینکه حداقل یک عنصر فرم مرتبط با ویژگی یا ویژگی فرعی آن وجود دارد یا خیر.
    • ویژگی غیرفعال است - این ویژگی فقط در صورتی در داده های فرم وجود دارد که یک عنصر فرم مرتبط با ویژگی یا ویژگی تابع آن وجود داشته باشد. برخلاف ویژگی‌های لیست پویا، قابل مشاهده بودن عنصر مرتبط با ویژگی در اینجا اهمیتی ندارد.

توجه داشته باشید. باید به خاطر داشت که ویژگی تنظیم شده روی صفت والد بر تمام ویژگی های فرعی تأثیر می گذارد. به عنوان مثال، اگر ویژگی Use همیشه برای قسمت جدولی سند پاک شود، سیستم در نظر می‌گیرد که این ویژگی برای تمام جزئیات فرعی نیز پاک می‌شود (علی‌رغم وضعیت واقعی ویژگی).

روش‌هایی برای تبدیل داده‌های شی برنامه به داده‌های فرم

برای تبدیل اشیاء برنامه به داده های فرم و برگشت، مجموعه ای از روش های جهانی وجود دارد:

  • ValueInFormData()،
  • FormDataInValue()،
  • CopyFormData().

مهم!روش هایی که با اشیاء برنامه کار می کنند فقط در رویه های سرور موجود هستند. روش کپی کردن مقادیر بین داده های فرم در سرور و مشتری در دسترس است، زیرا به اشیاء برنامه به عنوان پارامتر نیاز ندارد.

هنگام تبدیل داده های فرم به یک شی برنامه، باید سازگاری آنها را در نظر بگیرید.

  • ValueInFormData() - یک شی از نوع برنامه را به داده فرم تبدیل می کند.
  • FormDataInValue() – داده های فرم را به یک شی از نوع برنامه تبدیل می کند.
  • CopyFormData() - داده های فرمی را کپی می کند که ساختاری سازگار دارند. در صورت موفقیت آمیز بودن کپی، True یا اگر ساختار شی ناسازگار باشد، False را برمی‌گرداند.

توجه داشته باشید. هنگام انجام اقدامات استاندارد (باز کردن فرم، اجرای دستور استاندارد Write و غیره) یک فرم با جزئیات اصلی، تبدیل به صورت خودکار انجام می شود.

بیایید مثالی از نحوه استفاده از تبدیل داده در الگوریتم های خود ارائه دهیم.

&OnServerProcedure هنگام CreateOnServer (شکست، پردازش استاندارد)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem، Object);

پایان رویه

&OnClient رویه نوشتن()

WriteOnServer();

پایان رویه

رویه &روی سرور WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

پایان رویه

شی ManagedForm همچنین دارای روش های موجود در سرور است:

  • ValueВFormAttribute() – یک شی از نوع برنامه را به ویژگی فرم مشخص شده تبدیل می کند.
  • FormAttributeVValue() – یک ویژگی داده فرم را به یک شی از نوع برنامه تبدیل می کند.

استفاده از این روش‌ها معمولا راحت‌تر است، زیرا برای مثال اطلاعاتی در مورد نوع جزئیات فرم دارند. علاوه بر این، متد Form AttributesValue() مطابقت بین داده های فرم و شی را تنظیم می کند که هنگام تولید پیام استفاده می شود. می‌توانید در بخش «قابلیت‌های ناوبری سرویس» در مورد این موضوع بیشتر بخوانید.

بیایید مثالی از استفاده از این روش ها بزنیم.

رویه &روی سرور RecalculateOnServer()

// ویژگی Object را به یک شی برنامه تبدیل می کند. Document = Form AttributesValue("Object"); // محاسبه مجدد را با استفاده از روش تعریف شده در ماژول سند انجام می دهد. Document.Recalculate(); // شی برنامه را به یک prop تبدیل می کند. ValueВFormAttributes (سند، "شیء");

پایان رویه

رابط نرم افزاری

FormDataTree

  • FindById
  • GetItems

شرح:

طراحی شده برای مدل سازی یک درخت در داده های فرم مدیریت شده.

این شی را می توان به/از XDTO سریال کرد. نوع XDTO مربوط به این شی در فضای نام تعریف شده است. نام نوع XDTO:

GetItems

نحو:

GetItems()

ارزش برگشتی:

نوع: Form DataCollection of Tree Elements.

شرح:

مجموعه ای از عناصر درختی سطح بالا را دریافت می کند.

در دسترس بودن: کلاینت، سرور، تین کلاینت، سرویس گیرنده وب.

FindById

نحو:

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

گزینه ها:

<Идентификатор>(ضروری)

نوع: شماره شناسه عنصر درخت.

ارزش برگشتی:

نوع: FormDataTreeElement.

شرح:

یک عنصر مجموعه را با شناسه دریافت می کند.

در دسترس بودن: کلاینت، سرور، تین کلاینت، سرویس گیرنده وب.

FormDataTreeItem

خواص:

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

  • GetId (GetId)
  • GetParent
  • GetItems
  • ویژگی

شرح:

عنصر درخت داده فرم.

FormDataTreeItemCollection

عناصر مجموعه: DataFormTreeElement

برای یک شی، می توان مجموعه را با استفاده از عملگر For every... From... Loop پیمایش کرد. پیمایش عناصر مجموعه را انتخاب می کند. دسترسی به عنصر مجموعه با استفاده از عملگر [...] امکان پذیر است. شاخص عنصر به عنوان آرگومان ارسال می شود.

  • درج کنید
  • اضافه کردن
  • فهرست (IndexOf)
  • شمردن
  • پاک کردن
  • گرفتن
  • حرکت
  • حذف

شرح:

مجموعه ای از عناصر چوبی.

در دسترس بودن: کلاینت، سرور، تین کلاینت، سرویس گیرنده وب.

همچنین ببینید:

  • FormDataTreeElement، روش GetElements
  • DataFormTree، متد GetItems

ویژگی های کار با درخت ارزش

به روز رسانی درخت

مشکلی وجود دارد سقوطپلتفرم ها هنگام به روز رسانی درخت.

اگر هر گره ای در درخت گسترش یافته باشد و یک گره فرعی انتخاب شده باشد، هنگام به روز رسانی درخت با تابع ValueInFormDataسکو می افتد

راه حل: قبل از به روز رسانی باید درخت را پاک کنید.

مثلا:

&روی رویه سرور ClearTree(Elements) برای هر عنصر از عناصر Loop ClearTree(element.GetElements()); چرخه پایان عناصر.Clear(); پایان رویه

&روی رویه سرور Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts، ConceptTree); پایان رویه

رویه &OnClient OnDateOnChange(Element) Fill ConceptTree(); پایان رویه

و Data Transfer Object به ساختار کد، فرم کنترل شده در محیط 1C 8.2.

معرفی

بیایید با توضیح کوتاهی از مفهوم "فرم مدیریت شده" و مفاهیم مرتبط با پلت فرم 1C شروع کنیم. خبره های پلت فرم ممکن است بخواهند از این بخش صرف نظر کنند.

در سال 2008، نسخه جدیدی از پلتفرم 1C: Enterprise 8.2 (از این پس به عنوان برنامه مدیریت شده نامیده می شود) در دسترس قرار گرفت که به طور کامل کل لایه کار با رابط را تغییر می دهد. این شامل رابط فرمان، فرم ها و سیستم پنجره است. در عین حال، نه تنها مدل توسعه رابط کاربری در پیکربندی تغییر می کند، بلکه یک معماری جدید برای جداسازی عملکرد بین برنامه مشتری و سرور پیشنهاد شده است.
برنامه مدیریت شده از انواع مشتریان زیر پشتیبانی می کند:

  • کلاینت ضخیم (حالت راه اندازی عادی و مدیریت شده)
  • تین مشتری
  • مشتری وب
برنامه مدیریت شده از فرم های ساخته شده بر اساس فناوری جدید استفاده می کند. آنها نامیده می شوند فرم های مدیریت شده. برای سهولت انتقال، فرم‌های قبلی (به اصطلاح فرم‌های منظم) نیز پشتیبانی می‌شوند، اما عملکرد آنها توسعه‌یافته نیست و فقط در حالت راه‌اندازی کلاینت ضخیم در دسترس هستند.
تفاوت های اصلی فرم های مدیریت شده برای یک توسعه دهنده:
  • توضیحی، نه "پیکسل به پیکسل" از ساختار. هنگام نمایش فرم، قرارگیری خاص عناصر به طور خودکار توسط سیستم انجام می شود.
  • تمام عملکردهای فرم به شرح زیر است جزئیاتو تیم ها. جزئیات داده هایی هستند که فرم با آنها کار می کند و دستورات اقداماتی هستند که باید انجام شوند.
  • فرم هم روی سرور و هم روی کلاینت اجرا می شود.
  • در زمینه مشتری، تقریباً همه انواع برنامه ها در دسترس نیستند و بر این اساس تغییر داده ها در پایگاه اطلاعات غیرممکن است.
  • برای هر متد یا متغیر فرم باید مشخص شود دستورالعمل تدوین، تعریف مکان اجرا (کلاینت یا سرور) و دسترسی به زمینه فرم.
بیایید دستورالعمل های کامپایل متدهای فرم را فهرست کنیم:
  • &OnClient
  • &روی سرور
  • &OnServerWithout Context
  • &OnClientOnServerWithout Context
اجازه دهید موارد فوق را توضیح دهیم. اسکرین شات نمونه ای از فرم مدیریت شده و ماژول آن را در حالت توسعه نشان می دهد. توضیحات اعلامی، لوازم، دستورالعمل های تدوین و غیره را بیابید.

تمام بحث های بعدی در مورد سمت راست تصویر، در مورد چگونگی ساختار کد ماژول و اینکه چه اصولی به شما اجازه می دهد تا تعامل موثر مشتری و سرور را اجرا کنید، خواهد بود.

بیایید مشکل را تعریف کنیم

چندین سال از استفاده فعالانه از نسخه جدید پلت فرم 1C می گذرد و بسیاری از راه حل ها (پیکربندی ها) هم توسط 1C و هم بسیاری از شرکای آن منتشر شده است.
در طول این مدت، آیا توسعه دهندگان درک مشترکی از اصول تعامل مشتری و سرور هنگام ایجاد فرم ها ایجاد کرده اند و آیا رویکرد پیاده سازی ماژول های نرم افزار در واقعیت های جدید معماری تغییر کرده است؟

بیایید به ساختار کد (ماژول فرم) در چندین شکل از همان پیکربندی استاندارد نگاه کنیم و سعی کنیم الگوها را پیدا کنیم.
منظور ما از ساختار بخش‌هایی از کد است (اغلب اینها بلوک‌های نظر هستند) که توسط توسعه‌دهنده به گروه‌بندی روش‌ها و دستورالعمل‌های کامپایل برای این روش‌ها اختصاص داده می‌شود.
مثال 1:
روش بخش کنترل کننده رویداد - روی روش مشتری - روش روی سرور - روی مشتری بخش رویه ها و توابع سرویس توابع کنترل ورودی کمکی
مثال 2:
رویه‌ها و عملکردهای خدمات اسناد پرداخت ارزش‌ها گردانندگان رویداد
مثال 3:
رویه‌های سرویس در سرور رویه‌های سرویس روی سرویس گیرنده رویه‌های سرویس در سرور بدون زمینه کنترل‌کننده‌های رویداد سرصفحه کنترل‌کننده‌های رویداد فرمان
مثال 4:
رویه های همه منظوره گردانندگان رویداد فرم رویه های زیرسیستم «اطلاعات تماس»
اساساً، ساختار کد وجود ندارد، یا به زبان ساده، شبیه به آنچه در فرم‌های 8.1 بود:

  • کلمات غیر آموزنده "عمومی، خدماتی، کمکی".
  • ترسو تلاش می کند تا روش های کلاینت و سرور را از هم جدا کند.
  • روش‌ها اغلب با عناصر رابط گروه‌بندی می‌شوند: «کار با بخش جدولی محصولات، اطلاعات تماس».
  • ترتیب خودسرانه روش ها و گروه های کد. به عنوان مثال، Event Handlers ممکن است در یک شکل در بالا، در شکل دیگر در پایین، به هیچ وجه در شکل سوم برجسته نشده باشند، و غیره.
  • و فراموش نکنیم که همه اینها در یک پیکربندی است.
  • بله، پیکربندی هایی وجود دارد که در آنها کلمات "عمومی، خدمات، کمکی" همیشه در یک مکان وجود دارد اما ...
چرا به ساختار کد نیاز دارید؟
  • ساده سازی تعمیر و نگهداری
  • یادگیری را ساده کنید.
  • ثبت اصول کلی/مهم/موفق.
  • ... گزینه شما
چرا استاندارد توسعه موجود از 1C کمک نمی کند؟
بیایید به اصول منتشر شده بر روی دیسک‌های ITS و در «راهنماهای توسعه‌دهنده...» که هنگام نوشتن یک فرم مدیریت‌شده توصیه می‌شوند، نگاهی بیندازیم.
  • تعداد تماس های سرور را به حداقل برسانید.
  • حداکثر محاسبات روی سرور
  • تماس های سرور غیر متنی سریعتر از تماس های متنی هستند.
  • برنامه ای با در نظر گرفتن ارتباط مشتری و سرور.
  • و غیره
اینها شعارهایی است که کاملا درست است، اما چگونه می توان آنها را اجرا کرد؟ چگونه تعداد تماس ها را به حداقل برسانیم، برنامه نویسی در حالت سرویس گیرنده-سرور به چه معناست؟

الگوهای طراحی یا خرد نسلی

تعامل مشتری و سرور برای چندین دهه در فناوری های مختلف نرم افزاری مورد استفاده قرار گرفته است. پاسخ به سوالات مطرح شده در بخش قبل از دیرباز شناخته شده است و در دو اصل اساسی خلاصه شده است.
  • نما از راه دور(از این پس به عنوان رابط دسترسی از راه دور شناخته می شود)
  • شی انتقال داده(از این پس هدف انتقال داده نامیده می شود)
سخنی از مارتین فاولر، توصیف او از این اصول:
  • هر شی به طور بالقوه برای دسترسی از راه دور باید داشته باشد رابط با دانه بندی کم، که تعداد تماس های مورد نیاز برای انجام یک رویه خاص را به حداقل می رساند. ... به جای درخواست فاکتور و تمامی موارد آن به صورت جداگانه، باید تمامی موارد فاکتور را در یک درخواست مطالعه و به روز کنید. این بر کل ساختار شی تأثیر می گذارد ... به یاد داشته باشید: رابط دسترسی از راه دور شامل منطق دامنه نیست.
  • اگر من یک مادر دلسوز بودم، حتما به فرزندم می گفتم: «هرگز اشیاء انتقال داده را ننویس!» در اکثر موارد، اشیاء انتقال داده چیزی بیش از این نیستند مجموعه زمینه پف کرده... ارزش این هیولای منزجر کننده صرفا در امکان نهفته است انتقال چند قطعه اطلاعات از طریق شبکه در یک تماس- تکنیکی که برای سیستم های توزیع شده اهمیت زیادی دارد.
نمونه هایی از قالب ها در پلتفرم 1C
رابط برنامه نویسی کاربردی که هنگام توسعه یک فرم مدیریت شده در اختیار توسعه دهنده قرار می گیرد، شامل نمونه های زیادی از این اصول است.
به عنوان مثال، روش OpenForm()، یک رابط معمولی "خشن".
OpeningParameters = ساختار جدید ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm(FormName, OpeningParameters);
مقایسه با سبک اتخاذ شده در v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

در زمینه یک فرم مدیریت شده، "اشیاء انتقال داده" زیادی وجود دارد. می توانید انتخاب کنید سیستمیکو توسعه دهنده تعریف شده است.
آنهایی که سیستم یک شی برنامه کاربردی را در کلاینت به شکل یک یا چند عنصر داده فرم مدل می کنند. ایجاد آنها بدون اشاره به جزئیات فرم غیرممکن است.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
تبدیل اشیاء انتقال داده های سیستم به انواع برنامه ها و بالعکس با استفاده از روش های زیر انجام می شود:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
اغلب هنگام تطبیق راه حل موجود از تبدیل صریح استفاده می شود. متدها ممکن است انتظار داشته باشند (از ویژگی‌ها) پارامترهای ورودی مانند 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(); // [order][شرح خطا] برای هر سفارش از Orders Cycle StartTransaction(); DocOb = Order.GetObject(); …. سایر اقدامات، نه تنها با دستور... Exception CancelTransaction(); Errors.Insert(Order, ErrorDescription()); EndAttempt; چرخه پایان خطای بازگشت؛ EndFunction // ServerChangeOrderStatus()

ساختار کد

اهداف اصلی که ماژول فرم مدیریت شده باید منعکس کند و به راه حل نزدیک شود.
  • جداسازی کد مشتری و سرور را پاک کنید.فراموش نکنیم که در زمان اجرا، این دو فرآیند متقابل هستند که هر کدام عملکردهای قابل‌توجهی متفاوتی دارند.
  • شناسایی واضح رابط دسترسی از راه دور، کدام روش های سرور را می توان از مشتری فراخوانی کرد و کدام را نمی توان؟ نام روش های رابط راه دور با پیشوند "سرور" شروع می شود. این به شما امکان می دهد در حین خواندن کد بلافاصله انتقال کنترل به سرور را مشاهده کنید و استفاده از کمک متنی را ساده می کند. توجه داشته باشید که توصیه رسمی (ITS) نامگذاری روش ها را با پسوندها پیشنهاد می کند، به عنوان مثال، ChangeOrderStatusOnServer(). با این حال، تکرار می کنیم که همه روش های سرور را نمی توان از مشتری فراخوانی کرد، و بنابراین دسترسی منطقی به جای مکان کامپایل مهم تر است. بنابراین، با پیشوند "Server" فقط متدهای در دسترس مشتری را علامت گذاری می کنیم؛ بیایید متد مثالی (ServerChangeOrderStatus) را فراخوانی کنیم.
  • خوانایییک موضوع سلیقه ای، زمانی که ماژول با مراحل ایجاد فرم در سرور و روش های دسترسی از راه دور شروع می شود، سفارش را می پذیریم.
  • قابلیت نگهداری.باید مکان مشخصی برای افزودن کد جدید وجود داشته باشد. نکته مهم این است که الگوهای متد ایجاد شده به صورت خودکار توسط پیکربندی کننده به انتهای ماژول اضافه می شوند. از آنجایی که کنترل‌کننده‌های رویداد برای عناصر فرم اغلب به‌طور خودکار ایجاد می‌شوند، بلوک مربوطه در آخر قرار می‌گیرد، به طوری که هر کنترل‌کننده را به مکان دیگری در ماژول نمی‌کشد.
در زیر ساختار اصلی ماژول است که اهداف ذکر شده را پیاده سازی می کند.
  • گزینه گرافیکی - به وضوح جریان اصلی اجرا را نشان می دهد.
  • گزینه متن نمونه ای از طراحی قالب برای درج سریع ساختار در یک ماژول فرم جدید است.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""تاریخ = ""/> // <Описание> // // ////////////////////////////////////////////////// ////////////////////////// // متغیرهای ماژول /////////////////// //////////////////////////////////////////////////////////////////////// ////////// // روی سرور //******** رویدادهای روی سرور ******* &روی روی سرور هنگام ایجاد روی سرور (شکست، پردازش استاندارد) / /درج محتویات کنترل کننده پایان رویه //******** رابط دسترسی از راه دور ******* //******** منطق تجاری روی سرور ******* ////////////////////////////////////////////////// /////// /////////////////// // روش‌های رایج مشتری و سرور /////////////// //////////////////////////////////////////////////////// ///// //////// // در مورد مشتری //******** منطق کسب و کار بر روی مشتری ******* //******** تیم * ****** //******** رویدادهای مشتری ******* ////////////////////////// ///// //////////////////////////////////////////////////////////////// // / / اپراتورهای برنامه اصلی

سوالات مرتبط
در خاتمه، ما چندین حوزه را که در برنامه‌نویسی تعامل مشتری و سرور مفید است، توضیح خواهیم داد.
  • گزینه های پیاده سازی رابط دسترسی از راه دور. ناهمزمانی، سطح جزئیات ...
  • ذخیره سازی. 1C یک تصمیم معماری ناموفق گرفت و ذخیره سازی را فقط در سطح روش های فراخوانی ماژول های رایج معرفی کرد و قابلیت های کنترلی را ارائه نکرد (زمان ارتباط، تنظیم مجدد در صورت تقاضا).
  • تماس های ضمنی سرور. ویژگی های فن آوری را فراموش نکنید؛ بسیاری از عملیات "بی ضرر" روی مشتری، پلت فرم را برای تماس با سرور تحریک می کند.

فرم از طریق عناصر فرم مختلف کنترل می شود که به صورت سلسله مراتبی در برگه قرار دارند عناصرطراح فرم مهمترین عنصر خود فرم است که در بالای سلسله مراتب عناصر قرار دارد و عناصر باقی مانده تابع آن هستند.

تمام عناصر فرم را می توان به پنج گروه تقسیم کرد: فیلدها، عناصر گروه بندی، دکمه ها، تزئینات و جداول. در مقالاتم هر یک از گروه ها را تجزیه و تحلیل خواهم کرد. در این مقاله، ما شروع به مطالعه یکی از انواع عنصر فیلد خواهیم کرد - فیلد ورودی، اما قبل از آن یاد می گیریم که چگونه یک عنصر را به فرم اضافه کنیم.

افزودن عناصر به فرم

این به سادگی انجام می شود: شما باید عنصر را انتخاب کنید فرمدر پنجره Form Design Elements و روی دکمه "Add" کلیک کنید. پس از این، پنجره ای باز می شود که در آن باید نوع عنصر مورد نظر را انتخاب کنید

پس از انتخاب، عنصر مورد نظر در پنجره ظاهر می شود عناصر.

عنصر فرم مدیریت شده رشته

بیایید به یک عنصر فرم مدیریت شده نگاه کنیم رشته. این عنصر برای وارد کردن اطلاعات در فرم مورد نیاز است. و همچنین برای نمایش هرگونه اطلاعات. پس از افزودن این عنصر به فرم، پالت ویژگی های عنصر فرم در سمت راست باز می شود. در حال حاضر، شما باید به دو ویژگی علاقه مند باشید - DataPath و View.

در ویژگی DataPath، توسعه دهنده می تواند یک عنصر فرم را با ویژگی فرم مورد نظر مرتبط کند. لطفا توجه داشته باشید که پس از اضافه شدن عنصر فیلد ورودیدر فرم در خود فرم نمایش داده نشد. این اتفاق افتاد زیرا عنصر جدید ما با . به عنوان مثال، من چندین ویژگی در فرم پردازش با انواع مختلف اولیه و یک ویژگی با یک نوع مرجع ایجاد کردم.

اکنون بیایید عنصر فرم اخیراً اضافه شده خود را با یکی از جزئیات وصل کنیم. برای این کار، ویژگی مورد نظر را از ویژگی PathKData عنصر انتخاب کنید.

پس از این، ویژگی های DataPath و View پر می شوند و خود عنصر در نمای فرم نمایش داده می شود.

به ویژگی عنصر توجه کنید چشم انداز. این ویژگی عملکرد فیلد ورودی را تعیین می کند. می توانید مقادیر مختلفی را برای این ویژگی انتخاب کنید.

بسته به مقدار انتخاب شده، عملکرد مشخص می شود. در شکل های بالا، مقدار انتخاب شده برابر است با – فیلد ورودی، یعنی می توانیم هر مقداری را در این فیلد ورودی وارد کنیم و اگر مقداری را انتخاب کنیم فیلد برچسب، پس ما نمی توانیم چیزی وارد کنیم.

این ارزش دارایی چشم انداززمانی که شما فقط نیاز دارید اطلاعات راهنما را به کاربر نشان دهید، انتخاب فیلدهای ورودی راحت است.

حالا بیایید یک عنصر فرم جدید با type اضافه کنیم فیلد ورودیو آن را با پایه ها وصل کنید جزئیات تاریخاز طریق ویژگی DataPath که قبلاً برای ما آشنا بود

همانطور که می بینید، ظاهر فیلد ورودی تغییر کرده است و انتخاب مقادیر ممکن برای ویژگی View نیز تغییر خواهد کرد.

بنابراین، نتیجه می گیریم که عملکرد فیلد ورودی به نوع ویژگی بستگی دارد.

برای لوازم با نوع بولیمقادیر ویژگی View زیر در دسترس خواهد بود.

و برای ویژگی‌های دارای نوع مرجع، مقادیر دیگری از ویژگی View در دسترس خواهد بود.

کار دقیق تر با عناصر فرم با استفاده از مثال های عملی در کتاب "مبانی توسعه در 1C: تاکسی" آورده شده است. توسعه برنامه مدیریت شده در 12 مرحله».

گاهی اوقات به نظر می رسد که یادگیری زبان برنامه نویسی در 1C پیچیده و دشوار است. در واقع، برنامه نویسی در 1C آسان است. کتاب های من به شما کمک می کند تا به راحتی و به سرعت در برنامه نویسی 1C: و "مبانی توسعه در 1C: Taxi" تسلط پیدا کنید.

آموزش برنامه نویسی در 1C با کمک کتاب من "برنامه نویسی در 1C در 11 مرحله"

  1. بدون شرایط فنی پیچیده
  2. بیش از 700 صفحه مطالب کاربردی.
  3. هر کار با یک نقاشی (اسکرین شات) همراه است.
  4. مجموعه ای از مشکلات برای تکالیف.
  5. این کتاب به زبانی واضح و ساده - برای یک مبتدی - نوشته شده است.

این کتاب برای کسانی که قبلا برنامه نویسی را شروع کرده اند و مشکلات خاصی در این موضوع دارند و برای کسانی که مدت زیادی است برنامه نویسی می کنند، اما هرگز با فرم های مدیریت شده 1C کار نکرده اند، مناسب است.

  1. بدون اصطلاحات فنی پیچیده؛
  2. بیش از 600 صفحه مطالب عملی؛
  3. هر نمونه با یک نقاشی (اسکرین شات) همراه است.
  4. کتاب در قالب پی دی اف از طریق ایمیل ارسال می شود. در هر دستگاهی قابل باز شدن است!

کد تبلیغاتی برای 15٪ تخفیف - 48PVXHeYu


اگر این درس به شما کمک کرد مشکلی را حل کنید، آن را دوست داشتید یا آن را مفید یافتید، می توانید با اهدای هر مبلغی از پروژه من حمایت کنید:

می توانید به صورت دستی پرداخت کنید:

Yandex.Money - 410012882996301
وب مانی - R955262494655

به گروه های من بپیوندید