توضیحات فرم های کنترل شده uv 1s. StavAnalit

همه ما می دانیم که شرکت 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، از این رو تمام عواقب ناشی از آن. کد نیز باید به سرویس گیرنده و سرور تقسیم شود.

با ظهور پلتفرم 1C Enterprise 8.2، مکانیسم توسعه رابط کاربری به طور قابل توجهی تغییر کرده است. ایجاد فرم ها و برنامه های مدیریت شده امکان پذیر شد (شکل 1).

تصویر 1

علاوه بر این، یک سیستم جدید برای تقسیم عملکرد بین برنامه مشتری و سرور پیشنهاد شده است.
برنامه مدیریت شده از انواع مشتریان زیر پشتیبانی می کند:

  • کلاینت ضخیم (حالت راه اندازی عادی و مدیریت شده)،
  • تین مشتری،
  • سرویس گیرنده وب.

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

  • &OnClient،
  • &در سرور،
  • &OnServerWithoutContext،
  • &OnClientOnServerWithoutContext.

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

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

عملکرد فرم های کنترل شده دارای ویژگی های متمایز زیر است (شکل 2):

  • فرم هم روی کلاینت و هم روی سرور وجود دارد.

این تعامل مشتری و سرور (انتقال داده ها و ویژگی های طراحی عناصر) را انجام می دهد.

  • فرم با اشیاء برنامه کار نمی کند


شکل 2

فرم از اشیاء جهانی ویژه استفاده می کند
DataForms(شکل 3).


شکل 3

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

  • شی از پایگاه داده خوانده می شود،
  • شی به داده فرم تبدیل می شود،
  • شی حذف می شود (از حافظه)،
  • داده های فرم برای مشتری ارسال می شود.

هنگام ضبط:

  • داده های فرم از مشتری به دست می آید،
  • داده های فرم به یک شی تبدیل می شوند،
  • شی در پایگاه داده نوشته می شود،
  • شیء حذف می شود (از حافظه).

فرض کنید برای نسخه 8.1 پردازش خارجی نوشته شده است. آیا می توان آن را در نسخه 8.2 اجرا کرد تا با فرم قدیمی و مدیریت نشده خود کار کند؟ پردازش فقط یک بار برای انتقال داده ها مورد نیاز است و شما نمی خواهید فقط برای یک بار یک فرم مدیریت شده برای آن ایجاد کنید...

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

فرم های معمولی (مدیریت نشده) فقط می توانند در مشتری ضخیم کار کنند. کلاینت های تین و وب فقط از فرم های مدیریت شده پشتیبانی می کنند.

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

ساده ترین راه این است که کلاینت ضخیم را در حالت برنامه مدیریت شده از پیکربندی راه اندازی کنید و این را در پارامترها مشخص کنید: سرویس - گزینه ها - راه اندازی 1C: Enterprise - Basic - Thick Client (برنامه مدیریت شده).

لازم به یادآوری است که راه اندازی کلاینت ها در حالت مدیریت شده تنها در صورتی امکان پذیر است که پیکربندی سازگاری نسخه 8.1 را غیرفعال کند (ویژگی حالت سازگاری).

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

توانایی استفاده از فرم های منظم در حالت کنترل شده توسط یک ویژگی پیکربندی خاص تنظیم می شود - از فرم های عادی در یک برنامه مدیریت شده استفاده کنید. این ویژگی باید تنظیم شود.

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

و در نهایت، شیئی که می خواهید فرم عادی آن را در حالت مدیریت شده ببینید، باید یک فرم شی اصلی واحد داشته باشد و این فرم باید عادی و بدون مدیریت باشد.

در موارد دیگر (اگر شیء هیچ فرم اصلی نداشته باشد یا شی دارای فرم اصلی مدیریت شده باشد)، پلتفرم به صورت پیش فرض فرم مدیریت شده را تولید یا باز می کند (اگر دارای فرم باشد).

مشکل اصلی این است که در طی 10-15 سال کدهای زیادی برای فرم های معمولی کامپایل شده است. هیچ کس نمی خواهد همه اینها را روی سرویس گیرنده-سرور بازنویسی کند + افراد زیادی برای کار با رابط آموزش دیده اند. انتقال اجباری به BP 3.0 که از سال آینده شروع می شود، وحشت را در ذهن توسعه دهندگان و حسابداران ایجاد می کند. بازخورد بسیار ناخوشایند خواهد بود. علاوه بر این، نوار ورود به این حرفه بالا می رود، برنامه نویسی دشوارتر است و استانداردها حتی دشوارتر شده اند. هزینه الگوریتم جدید در اسناد استاندارد چقدر است؟ UV وقتی 2 تا 3 دکمه روی اسناد داشته باشید عالی به نظر می رسد، UV برای کار بر روی دستگاه های تلفن همراه عالی است، اما تنها 0.01٪ از شرکت ها از آن استفاده می کنند. اگر 1C چیز جدیدی ارائه نکرد، باید تغییر دهید، اما برای همه طولانی و دردناک خواهد بود. و خود شرکت ها باید پول را پرداخت کنند.

من نیز تاکنون فقط چیزهای منفی را از اشکال کنترل شده تجربه کرده ام، در اینجا برخی از معایب نوآوری وجود دارد:

  • هیچ چی؟ خوب، من چند بار با این مواجه شدم، به عنوان مثال، نوشتن و پیوست کردن یک فرم چاپ خارجی به conf ZUP، پردازش وجود دارد یک حماسه کامل، پر از دستورالعمل ها در اینترنت و صفحات کد باید.
    در یک کلاینت ضخیم یک رویه با پارامترها وجود دارد. توسعه یک موضوع چند دقیقه است.
    و ترمزها با چشم غیر مسلح نازک هستند
  • در مورد توانایی تهیه فرم های قابل مدیریت - این هنر برای هنر است، اما نکته کاربردی به خصوص برای نسخه فایل چیست؟
  • من 3 سال در اشعه ماوراء بنفش مجسمه‌سازی کردم، اما اکنون به فرم‌های ساده برگشتم و باور کنید، انجام این انتقال از نظر روانی بسیار دشوار بود، اما این انتخاب آگاهانه من است زیرا آنچه 1c در UV ارائه می‌کند کاملاً UG است…. شاید یکی دو سال دیگر 1c پیشرفت کند، اما اکنون او فقط به دنبال مکانی است که بتواند این پیشرفت را انجام دهد ...
  • UV ها در پیکربندی زمان بیشتری برای باز شدن نیاز دارند.
    بعد از آن باز کردن فرم ها در 8.1 مانند انتقال از کامیون به هواپیما است!
  • مشکلات بیشتر برای همه وجود دارد، کاربران از رابط جدید شوکه شده اند (همه آن را اعتراف نمی کنند، اما در مورد چیزهای کوچکتر احمق تر هستند)، نیمی از برنامه نویسان برای حرفه ای بودن نامناسب شده اند، برای متخصصان معمولی سخت تر شده است. پیدا کردن شغل و نحوه تولید محصول با کیفیت و جالب‌ترین موضوع بازاریابی UV این است که آنها در همه جا اوج می‌گیرند که انتقال با یک به‌روزرسانی ساده اتفاق می‌افتد، اما همه فراموش می‌کنند که از ابتدا باید به آخرین نسخه‌های منتشر شده برسید! اما در اصل من این ایده را دوست دارم!
  • نمی دانم، تجربه من برعکس را نشان می دهد. در جایی که چندین سال است که رونق در اشکال سختگیرانه به طور خودکار وارد می شود، در استانداردهای جدید UV هر ماه شروع می شود "چرا، پس از به روز رسانی این دکمه اکنون 1C کجاست و چرا اکنون کار نمی کند"، که می بینید. ، سرعت اضافه نمی کند.
  • - کد بیشتری وجود دارد
    - کد پیچیده تر شده است
    - اصلاح استانداردها بسیار دشوارتر است
    - کاربرانی که به آنها UT11 دادم هیچ مزیتی در مقایسه با 10.x پیدا نکردند
    - اما آنها کاهش سرعت و کمبود برخی عملکردها مانند جستجو را پیدا کردند (به دلایلی آنها جستجوی رو به عقب را می خواستند و نه انتخابی)
    نظر من این است که قربانی ها به خاطر مشتری وب و تبلت ها بسیار زیاد است. علاوه بر این، من شخصاً هنوز کار واقعی با یک مشتری وب را ندیده ام که باید با موفقیت از دسترسی از راه دور استفاده کند.
  • کلاینت-سرور bedlam باید عملکرد و مقیاس پذیری را افزایش دهد، در حالی که در عین حال هزینه ها شامل افزایش کدنویسی می شود.
    با این حال، همه افزایش را تجربه نکردند، از این رو ناامیدی. و در همان زمان، همه در هزینه های کدنویسی متعهد بودند.
    P.S. در واقع من کنترل شده ها را دوست دارم، با آرامش روی آنها نقاشی می کشم. اما معمولی ها منحرف شده اند.
  • در خانه (کامپیوتر معمولی) من نوشیدنی خود را مطابق با کارآفرینان فردی انجام می دهم.
    8.3، BP3، شطرنجی. تصور اصلی این است که من کار نمی کنم، اما همیشه منتظر هستم. پاسخ هموروئیدی SALT برای حساب به سادگی جهنم شکل می گیرد - به نظر می رسد یک کارت حساب برای سال در یک شرکت بزرگ.
  • UT11 یک ترمز وحشی، ترسناک و در کل یک کابوس است.
    UT10 در مقایسه با UT11 پرواز می کند.
    در مورد اشعه ماوراء بنفش - سال هاست که حشرات آلوده شده اند، همه چیز کج است، ستون ها هرگز روی یک صفحه قرار نمی گیرند، کشش در بسیاری از موارد وحشتناک است.
    و من هنوز می توانم بسیاری از موارد منفی را لیست کنم، اما احتمالاً چیزی در مورد مزایا نخواهم گفت. آنها به سادگی وجود ندارند.
    شرکت ها به طور خاص به این فرم ها ختم شدند، زیرا توسعه هزینه های بیشتری دارد، هیچ ویژه ای وجود نداشت و هیچ گونه معمولی وجود ندارد.

مزایای کمی وجود دارد، اما البته وجود دارد ...

طرفداران:

پاسخ برای مدت طولانی وجود داشته است، آنچه که UP داده است:

مشتری متقابل پلت فرم

  • کار روی خطوط ارتباطی بد
  • توانایی کار از طریق مرورگر (بدون نصب کلاینت)

و 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" ما فقط متدهای در دسترس مشتری را علامت گذاری می کنیم.
  • خوانایییک موضوع سلیقه ای، زمانی که ماژول با مراحل ایجاد فرم در سرور و روش های دسترسی از راه دور شروع می شود، سفارش را می پذیریم.
  • قابلیت نگهداری.باید مکان مشخصی برای افزودن کد جدید وجود داشته باشد. نکته مهم این است که الگوهای متد ایجاد شده به صورت خودکار توسط پیکربندی کننده به انتهای ماژول اضافه می شوند. از آنجایی که کنترل‌کننده‌های رویداد برای عناصر فرم اغلب به‌طور خودکار ایجاد می‌شوند، بلوک مربوطه در آخر قرار می‌گیرد، به طوری که هر کنترل‌کننده را به مکان دیگری در ماژول نمی‌کشد.
در زیر ساختار اصلی ماژول است که اهداف ذکر شده را پیاده سازی می کند.
  • گزینه گرافیکی - به وضوح جریان اصلی اجرا را نشان می دهد.
  • گزینه متن نمونه ای از طراحی قالب برای درج سریع ساختار در یک ماژول فرم جدید است.

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

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


 

شاید خواندن آن مفید باشد: