და მონაცემთა გადაცემის ობიექტი კოდის სტრუქტურირებაში, მართული ფორმა 1C 8.2 გარემოში.

შესავალი

დავიწყოთ „მართული ფორმის“ კონცეფციისა და 1C პლატფორმის მასთან დაკავშირებული ცნებების მოკლე აღწერით. პლატფორმის ექსპერტებს შეუძლიათ გამოტოვონ ეს განყოფილება.

ხელმისაწვდომი გახდა 2008 წელს ახალი ვერსიაპლატფორმა 1C: Enterprise 8.2 (შემდგომში მართული აპლიკაცია), რომელიც მთლიანად ცვლის ინტერფეისთან მუშაობის მთელ ფენას. ეს მოიცავს ბრძანების ინტერფეისს, ფორმებს და ფანჯრის სისტემას. ეს არა მხოლოდ ცვლის მომხმარებლის ინტერფეისის განვითარების მოდელს კონფიგურაციაში, არამედ გვთავაზობს ახალ არქიტექტურას კლიენტის აპლიკაციასა და სერვერს შორის ფუნქციონირების გამიჯვნისთვის.
მართული აპლიკაცია მხარს უჭერს შემდეგი ტიპის კლიენტებს:

• სქელი კლიენტი (ნორმალური და მართული გაშვების რეჟიმი)
• გამხდარი კლიენტი
• ვებ კლიენტი

მართული აპლიკაცია იყენებს აგებულ ფორმებს ახალი ტექნოლოგია. მათ ეძახიან მართული ფორმები. გადასვლის სიმარტივის მიზნით, ასევე მხარდაჭერილია ძველი ფორმები (ე.წ. რეგულარული ფორმები), მაგრამ მათი ფუნქციონირება არ არის განვითარებული და ისინი ხელმისაწვდომია მხოლოდ მდიდარი კლიენტის გაშვების რეჟიმში.
დეველოპერისთვის მართული ფორმების ძირითადი განსხვავებები:

• სტრუქტურის დეკლარაციული და არა „პიქსელებით“ აღწერა. ელემენტების სპეციფიკური განლაგება ხდება სისტემის მიერ ავტომატურად, როდესაც ფორმა გამოჩნდება.
• ფორმის ყველა ფუნქცია აღწერილია ფორმაში დეტალებიდა ბრძანებებს. დეტალები არის მონაცემები, რომლებთანაც მუშაობს ფორმა, ხოლო ბრძანებები არის შესრულებული მოქმედებები.
• ფორმა შესრულებულია როგორც სერვერზე, ასევე კლიენტზე.
• კლიენტის კონტექსტში აპლიკაციის თითქმის ყველა ტიპი მიუწვდომელია და შესაბამისად ინფობაზაში მონაცემების შეცვლა შეუძლებელია.
• თითოეული მეთოდის ან ფორმის ცვლადისთვის ის უნდა იყოს მითითებული შედგენის დირექტივა A, რომელიც განსაზღვრავს შესრულების ადგილს (კლიენტი თუ სერვერი) და ფორმის კონტექსტზე წვდომა.

აქ მოცემულია ინსტრუქციები ფორმის მეთოდების შედგენისთვის:

• &კლიენტი
• &სერვერზე
• &სერვერზე კონტექსტის გარეშე
• &კლიენტში სერვერზე კონტექსტის გარეშე

ავღნიშნოთ ზემოთქმული. სკრინშოტი აჩვენებს მართული ფორმისა და მისი მოდულის მაგალითს განვითარების რეჟიმში. იპოვნეთ დეკლარაციული აღწერა, რეკვიზიტები, კომპილაციის დირექტივები და ა.შ.

ყველა შემდგომი დისკუსია იქნება ილუსტრაციის მარჯვენა მხარეს, იმის შესახებ, თუ როგორ უნდა სტრუქტურირდეს მოდულის კოდი და რა პრინციპები მოგცემთ საშუალებას განახორციელოთ კლიენტ-სერვერის ეფექტური ურთიერთქმედება.

მოდით განვსაზღვროთ პრობლემა

რამდენიმე წელი გავიდა მას შემდეგ, რაც 1C პლატფორმის ახალი ვერსია აქტიურად იქნა გამოყენებული და მრავალი გადაწყვეტა (კონფიგურაცია) გამოვიდა როგორც 1C-ის, ასევე მისი მრავალი პარტნიორის მიერ.
შეიმუშავეს თუ არა დეველოპერებმა ამ დროის განმავლობაში ფორმების შექმნისას კლიენტ-სერვერის ურთიერთქმედების პრინციპების საერთო გაგება და შეიცვალა თუ არა განხორციელების მიდგომა? პროგრამული მოდულებიახალ არქიტექტურულ რეალობაში?

განვიხილოთ კოდის სტრუქტურა (ფორმის მოდული) ერთი და იგივე ტიპიური კონფიგურაციის რამდენიმე ფორმით და შეეცადეთ იპოვოთ შაბლონები.
სტრუქტურის ქვეშ ჩვენ ვგულისხმობთ კოდის სექციებს (ყველაზე ხშირად ეს არის კომენტარების ბლოკები), რომლებიც გამოყოფილია დეველოპერის მიერ ამ მეთოდების შედგენის მეთოდებისა და დირექტივების დაჯგუფებისთვის.
მაგალითი 1:
მოვლენის დამმუშავებლის განყოფილების მეთოდი - კლიენტზე მეთოდი - სერვერზე მეთოდი - კლიენტზე მომსახურების პროცედურების და ფუნქციების განყოფილება შეყვანის კონტროლის დამხმარე ფუნქციები
მაგალითი 2:
მომსახურების პროცედურები და ფუნქციები გადახდის დოკუმენტები Valuables Event handlers
მაგალითი 3:
სერვისის პროცედურები სერვერზე მომსახურების პროცედურები კლიენტზე სერვისის პროცედურები სერვერზე კონტექსტის გარეშე Header event handlers ბრძანების ღონისძიების დამმუშავებლები
მაგალითი 4:
ზოგადი დანიშნულების პროცედურები ფორმა მოვლენის დამმუშავებლები „საკონტაქტო ინფორმაციის“ ქვესისტემის პროცედურები
სინამდვილეში, კოდის სტრუქტურა აკლია, ან რბილად რომ ვთქვათ, ის მსგავსია 8.1 ფორმებში:

• არაინფორმაციული სიტყვები "გენერალი, სერვისი, დამხმარე".
• მორცხვი მცდელობა კლიენტისა და სერვერის მეთოდების გამიჯვნას.
• ხშირად მეთოდები ჯგუფდება ინტერფეისის ელემენტების მიხედვით "მუშაობა ტაბულურ ნაწილებთან პროდუქტები, საკონტაქტო ინფორმაცია".
• მეთოდებისა და კოდების ჯგუფების თვითნებური მოწყობა. მაგალითად, Event Handlers შეიძლება იყოს ზემოთ ერთი ფორმით, ბოლოში მეორეში, საერთოდ არ იყოს მონიშნული მესამეში და ა.შ.
• და არ უნდა დაგვავიწყდეს, რომ ეს ყველაფერი ერთსა და იმავე კონფიგურაციაშია.
• დიახ, არის კონფიგურაციები, რომლებშიც სიტყვები "გენერალი, სერვისი, დამხმარე" ყოველთვის ერთსა და იმავე ადგილებშია, მაგრამ ...

რატომ გჭირდებათ კოდის სტრუქტურა?

• მოვლის გამარტივება.
• სწავლის გამარტივება.
• ზოგადი/მნიშვნელოვანი/წარმატებული პრინციპების დაფიქსირება.
• …თქვენი ვარიანტი

რატომ არ ეხმარება განვითარების არსებული სტანდარტი 1C-დან?

მოდით გადავხედოთ ITS დისკებზე გამოქვეყნებულ პრინციპებს და სხვადასხვა "დეველოპერთა სახელმძღვანელოში ...", რეკომენდირებულია მართული ფორმის დაწერისას.

• შეამცირეთ სერვერის ზარების რაოდენობა.
• მაქსიმალური გამოთვლა სერვერზე.
• არაკონტექსტური სერვერის ზარები უფრო სწრაფია, ვიდრე კონტექსტური ზარები.
• პროგრამა კლიენტისა და სერვერის ურთიერთქმედების გათვალისწინებით.
• და ა.შ.

ეს არის სლოგანები, რომლებიც აბსოლუტურად მართალია, მაგრამ როგორ შეიძლება მათი რეალიზება? როგორ შევამციროთ ზარების რაოდენობა, რას ნიშნავს კლიენტ-სერვერის რეჟიმში დაპროგრამება?

დიზაინის ნიმუშები ან თაობის სიბრძნე

კლიენტ-სერვერის ურთიერთქმედება ათწლეულების განმავლობაში გამოიყენება სხვადასხვა პროგრამულ ტექნოლოგიებში. წინა ნაწილში გაწერილ კითხვებზე პასუხი დიდი ხანია ცნობილია და შეჯამებულია ორ ძირითად პრინციპში.

• დისტანციური ფასადი(შემდგომში დისტანციური წვდომის ინტერფეისი)
• მონაცემთა გადაცემის ობიექტი(შემდგომში მონაცემთა გადაცემის ობიექტი)

სიტყვა მარტინ ფაულერს, მისი აღწერა ამ პრინციპების შესახებ:

• … თითოეულ ობიექტს, რომელიც პოტენციურად არის განკუთვნილი დისტანციური წვდომისთვის, უნდა ჰქონდეს დაბალი მარცვლოვნების ინტერფეისი, რაც მინიმუმამდე დააყენებს კონკრეტული პროცედურის შესასრულებლად საჭირო ზარების რაოდენობას. ... ინვოისის და მისი ყველა პუნქტის ცალ-ცალკე მოთხოვნის ნაცვლად, აუცილებელია ინვოისის ყველა პუნქტის წაკითხვა და განახლება ერთი ზარით. ეს გავლენას ახდენს ობიექტის მთელ სტრუქტურაზე... გახსოვდეთ: დისტანციური წვდომის ინტერფეისი არ შეიცავს დომენის ლოგიკას.
• ... მზრუნველი დედა რომ ვიყო, ჩემს შვილს აუცილებლად ვეტყოდი: „არასოდეს დაწერო მონაცემთა გადაცემის ობიექტები!“ უმეტეს შემთხვევაში, მონაცემთა მიგრაციის ობიექტები სხვა არაფერია გაბერილი მინდვრის ნაკრები… ამ ამაზრზენი მონსტრის ღირებულება მხოლოდ შესაძლებლობებშია გადასცეს მრავალი ინფორმაცია ქსელში ერთი ზარით- ტექნიკა, რომელსაც დიდი მნიშვნელობა აქვს განაწილებული სისტემებისთვის.

შაბლონების მაგალითები 1C პლატფორმაზე

მართული ფორმის შემუშავებისას დეველოპერისთვის ხელმისაწვდომი API შეიცავს ამ პრინციპების მრავალ მაგალითს.
მაგალითად, OpenForm() მეთოდი, ტიპიური "უხეში" ინტერფეისი.
OpenParameters = ახალი სტრუქტურა ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm(FormName, OpenParameters);
შედარება v8.1 სტილთან.
ფორმა = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

მართული ფორმის კონტექსტში, "მონაცემთა გადაცემის ობიექტების" ნაკრები. შეიძლება გამოიყოს სისტემურიდა დეველოპერის მიერ განსაზღვრული.
System ones მოდელირებს განაცხადის ობიექტს კლიენტზე, ერთი ან მეტი ფორმის მონაცემთა ელემენტის სახით. თქვენ არ შეგიძლიათ შექმნათ ისინი ფორმის დეტალების მიღმა.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

მონაცემთა გადაცემის სისტემის ობიექტების აპლიკაციის ტიპებად გადაქცევა და პირიქით ხდება შემდეგი მეთოდებით:

• ValueVDataForm()
• FormDataToValue()
• CopyFormData()
• ValueVFormProps()
• FormAttributeToValue()

ხშირად აშკარა კონვერტაცია გამოიყენება არსებული გადაწყვეტის ადაპტაციისას. მეთოდებს შეიძლება მოელოდეს (ფუნქციების) შეყვანის პარამეტრები, როგორიცაა ValueTable და არა FormDataCollection, ან მეთოდი განისაზღვრა აპლიკაციის ობიექტის კონტექსტში და მიუწვდომელი გახდა ფორმიდან პირდაპირი გამოძახებისთვის.
მაგალითი 1C v8.1:
// კლიენტზე FillUsersCache(DepartmentReference) ფორმის კონტექსტში
მაგალითი 1C v8.2:
// სერვერზე ფორმის კონტექსტში ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");

მონაცემთა მიგრაციის ობიექტები, რომელთა სტრუქტურა განისაზღვრება დეველოპერის მიერ, არის ტიპების მცირე ქვეჯგუფი, რომელიც ხელმისაწვდომია როგორც კლიენტზე, ასევე სერვერზე. ყველაზე ხშირად, როგორც "უხეში" ინტერფეისის მეთოდების პარამეტრები და შედეგები, გამოიყენება შემდეგი:

• პრიმიტიული ტიპები (სტრიქონი, რიცხვი, ლოგიკური)
• სტრუქტურა
• კონფორმულობა
• მასივი
• აპლიკაციის ობიექტებთან ბმულები (უნიკალური იდენტიფიკატორი და ტექსტის წარმოდგენა)

მაგალითი: მეთოდი იღებს შეკვეთების ჩამონათვალს სტატუსის შესაცვლელად და უბრუნებს კლიენტს შეცდომების აღწერას.
&OnServerWithoutContext ფუნქცია ServerChangeOrderStatus(Orders, NewStatus) შეცდომები = New Match(); // [ბრძანება][შეცდომის აღწერა] ყოველი შეკვეთისთვის Orders From Loop StartTransaction(); მცდელობა DocOb = Order.GetObject(); …. სხვა ქმედებები, შესაძლოა არა მხოლოდ შეკვეთით... გამონაკლისი CancelTransaction(); Errors.Insert(Order, DescriptionError()); მცდელობის დასასრული; საბოლოო ციკლი; დაბრუნების შეცდომა; EndFunction // ServerChangeOrderStatus()

კოდის სტრუქტურირება

ძირითადი მიზნები, რომლებიც უნდა ასახავდეს მართული ფორმის მოდულს და მიდგომას გადაწყვეტისკენ.

• კლიენტისა და სერვერის კოდის ნათელი გამიჯვნა.არ უნდა დაგვავიწყდეს, რომ შესრულების დროს ეს არის ორი ურთიერთდაკავშირებული პროცესი, რომელთაგან თითოეულში არსებული ფუნქციონალობა მნიშვნელოვნად განსხვავდება.
• დისტანციური წვდომის ინტერფეისის მკაფიო შერჩევა, რომელი სერვერის მეთოდების გამოძახება შეიძლება კლიენტისგან და რომელი არა? დისტანციური ინტერფეისის მეთოდების სახელები იწყება პრეფიქსით "სერვერი". ეს საშუალებას გაძლევთ დაუყოვნებლივ ნახოთ კონტროლის სერვერზე გადასვლა კოდის წაკითხვისას და ამარტივებს კონტექსტური მინიშნებების გამოყენებას. გაითვალისწინეთ, რომ ოფიციალური რეკომენდაცია (ITS) გვთავაზობს მეთოდების დასახელებას პოსტფიქსებით, როგორიცაა ChangeOrderStatusOnServer(). თუმცა, გავიმეოროთ, სერვერის ყველა მეთოდის გამოძახება არ შეიძლება კლიენტისგან და ამიტომ ლოგიკური ხელმისაწვდომობა უფრო მნიშვნელოვანია, ვიდრე კომპილაციის მდებარეობა. ამიტომ, „სერვერის“ პრეფიქსით ჩვენ აღვნიშნავთ მხოლოდ კლიენტისთვის ხელმისაწვდომ მეთოდებს, მაგალითის მეთოდს დაერქმევა ServerChangeOrderStatus().
• კითხვადობა.გემოვნების საკითხია, ჩვენ ვიღებთ შეკვეთას, როდესაც მოდული იწყება სერვერზე ფორმის შექმნის პროცედურებით და დისტანციური წვდომის მეთოდებით.
• შენარჩუნებაუნარიანობა.ახალი კოდის დამატების ადგილი მკაფიოდ უნდა იყოს განსაზღვრული. მნიშვნელოვანი წერტილი, რომლებიც ავტომატურად იქმნება მეთოდის stub კონფიგურატორის მიერ, ემატება მოდულის ბოლოს. ვინაიდან ფორმის ელემენტების მოვლენის დამმუშავებლები ყველაზე ხშირად იქმნება ავტომატურად, შესაბამისი ბლოკი მოთავსებულია ბოლოს ისე, რომ არ გადაიტანოს თითოეული დამმუშავებელი მოდულის სხვა ადგილას.

ქვემოთ მოცემულია მოდულის ძირითადი სტრუქტურა, რომელიც ახორციელებს ჩამოთვლილ მიზნებს.

• გრაფიკული ვარიანტი - ნათლად აჩვენებს შესრულების ძირითად ნაკადს.
• ტექსტური ვერსია არის შაბლონის დიზაინის მაგალითი სწრაფი ჩასმასტრუქტურები ახალი ფორმის მოდულში.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""თარიღი = ""/> // <Описание> // // //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////// // ///////////// // სერვერზე //******* მოვლენები სერვერზე ******* &სერვერზე პროცედურა სერვერზე შექმნისას( წარუმატებლობა, სტანდარტული დამუშავება) // დამმუშავებლის შიგთავსის ჩასმა EndProcedure //******* დისტანციური წვდომის ინტერფეისი ******* //******** BUSINESS LOGIC სერვერზე **** *** /////////////////////////////////////////////////////////////// //////////////////////////////// // კლიენტისა და სერვერის საერთო მეთოდები ///////// ////////////////////////////////////////////////////////////////// /////////////// //////// // კლიენტზე //******* ბიზნეს ლოგიკა კლიენტზე ******* //******** ბრძანებები ******* //******** ღონისძიებები კლიენტზე ****** ////////////// /////////////////////////////////////////////////////////////////// //////////////// / / პროგრამის მთავარი ოპერატორები

დაკავშირებული კითხვები

დასასრულს, ჩვენ გამოვყოფთ რამდენიმე სფეროს, რომლებზეც გამოსადეგია ფიქრი კლიენტ-სერვერის ურთიერთქმედების პროგრამირებისას.

• დისტანციური წვდომის ინტერფეისის განხორციელების ვარიანტები. ასინქრონულობა, გრანულარულობა...
• ქეშირება. 1C-მ მიიღო სამწუხარო არქიტექტურული გადაწყვეტილება, შემოიღო ქეშირება მხოლოდ ჩვეულებრივი მოდულების გამოძახების მეთოდების დონეზე და არ უზრუნველყო კონტროლის ვარიანტები (განახლებული დრო, გადატვირთვა მოთხოვნით).
• იმპლიციტური სერვერის ზარები. ნუ დაივიწყებთ ტექნოლოგიურ მახასიათებლებზე, კლიენტზე მრავალი „უვნებელი“ ოპერაცია იწვევს პლატფორმის სერვერზე წვდომის პროვოცირებას.

11.12.2016

მართული ფორმების შესახებ 1C (დასაწყისი)

გამხდარი კლიენტი

უფრო თხელი არსად არის. ახლა კლიენტის აპლიკაცია არ ითხოვს მონაცემთა ბაზას (ეს არის სერვერის საქმე). კლიენტის აპლიკაცია უბრალოდ აჩვენებს ინტერფეისს და მონაცემებს.

აღსანიშნავია, რომ ასეთი გარდაქმნების გამო კოდის სტრუქტურა უფრო გართულდა. კლიენტზე არ არის მითითებები, ობიექტები, მნიშვნელობების ცხრილი... ხელმისაწვდომია მხოლოდ პრიმიტიული ტიპები (სტრიქონი, თარიღი, ლოგიკური, მასივი, სტრუქტურა...). ეს ნიშნავს, რომ პროგრამისტმა ახლა უნდა იფიქროს იმაზე, თუ რა უნდა მიიღოს სერვერზე და როგორ გააკეთოს ეს მინიმალურ ფასად.

კლიენტ-სერვერის ურთიერთქმედება

კლიენტსა და სერვერს შორის ურთიერთქმედების ახალმა მიდგომამ საშუალება მოგვცა შეგვექმნა მომხმარებლის ინტერფეისის ახალი მოდელი. ახლა ინტერფეისი გამოცხადებულია(!) ინტერფეისის დიზაინი იწყება მონაცემებით, დეტალებითა და ცხრილის სექციებით. რეკვიზიტის შექმნისას უნდა იფიქროთ, როგორ გამოიყურება ის ინტერფეისში, იქნება თუ არა საჭირო, როგორ არის დაკავშირებული სხვა რეკვიზიტებთან...

სერვერზე კონტექსტი (მდგომარეობა) არ არის

1C სერვერი მუშაობს "stateless" (ინგლისური state-less) პრინციპით. ეს ნიშნავს, რომ სერვერი პასუხობს მხოლოდ მოთხოვნებს და ამავდროულად არ ინახავს არაფერს ორ მოთხოვნას შორის (ამ მიზნით არის დროებითი საცავი).

FormDataToValue,FormDataCollection,FormData...

ჩვენ მივმართეთ სერვერს, მან ყველაფერი გააკეთა ჩვენთვის, წაშალა მონაცემები და დაავიწყდა, რომ მოვედით. ყველა ობიექტი სახელად "FormData" + "something there" დაგვეხმარება ჩვენი მონაცემების შენახვაში სერვერის ორ ზარს შორის.

დროებითი შენახვა

დროებითი შენახვა არის სპეციალური ადგილი, სადაც (ფორმის დეტალების გარდა) შეგიძლიათ შეინახოთ მდგომარეობა სერვერზე. საცავს შეუძლია შეინახოს მონაცემები, რომლებიც მიუწვდომელია კლიენტზე (ანუ არ შეიძლება განთავსდეს ფორმის დეტალებში).

დროებით მეხსიერებასთან მუშაობისთვის გამოიყენეთ MoveToTempStorage() მეთოდები სინტაქსი: PlaceToTempStorage(<Данные>, <Адрес>) აღწერა: ინახავს სერიულ მნიშვნელობას დროებით შენახვაში. ხელმისაწვდომობა: თინ კლიენტი, ვებ კლიენტი, სერვერი, სქელი კლიენტი, გარე კავშირი, მობილური აპლიკაცია (კლიენტი), მობილური აპლიკაცია (სერვერი). მეთოდის ზარი ურეკავს სერვერს.<Адрес>(არასავალდებულო) ტიპი: UniqueIdentifier; ხაზი. ფორმის უნიკალური ID, რომლის დროებით საცავში უნდა განთავსდეს მონაცემები და დაბრუნდეს ახალი მისამართი. ან მისამართი დროებით საცავში, სადაც მონაცემები უნდა განთავსდეს. ამ მეთოდით ადრე უნდა მიიღოთ მისამართი. თუ ფორმის UniqueIdentifier ან მისამართი ინახება, მაშინ მნიშვნელობა ავტომატურად წაიშლება ფორმის დახურვის შემდეგ. თუ UniqueIdentifier გადაეცემა, რომელიც არ არის ფორმის უნიკალური იდენტიფიკატორი, მაშინ მნიშვნელობა წაიშლება მომხმარებლის სესიის დასრულებისას. თუ პარამეტრი არ არის მითითებული, განთავსებული მნიშვნელობა წაიშლება გაზიარებული მოდულიდან სერვერის შემდეგი მოთხოვნის შემდეგ, კონტექსტური და არაკონტექსტური სერვერის ზარების ფორმიდან, სერვერის ზარების ბრძანების მოდულიდან ან ფორმის მიღებისას. შენიშვნა: ერთ სესიაზე შექმნილი დროებითი მეხსიერება მიუწვდომელია სხვა სესიიდან. გამონაკლისი არის ფონური სამუშაოდან მონაცემების გადატანის შესაძლებლობა სესიაზე, რომელმაც დაიწყო ფონური სამუშაო დროებითი შენახვის გამოყენებით. ასეთი გადაცემისთვის, მშობლის სესიაში, მოათავსეთ ცარიელი მნიშვნელობა დროებით საცავში, გადასვით ფორმის იდენტიფიკატორი. შემდეგ მიღებული მისამართი გადაეცით ფონურ სამუშაოს ფონის სამუშაოს პარამეტრების მეშვეობით. გარდა ამისა, თუ ეს მისამართი გამოიყენება პარამეტრში<Адрес>, შედეგი დაკოპირდება სესიაზე, საიდანაც დაიწყო ფონის სამუშაო. ფონური სამუშაოს დროებით საცავში განთავსებული მონაცემები ხელმისაწვდომი არ იქნება მშობლის სესიიდან, სანამ ფონური დავალება არ დასრულდება. და GetFromTempStorage() სინტაქსი: GetFromTempStorage(<Адрес>) აღწერა: იღებს მნიშვნელობას დროებითი შენახვისგან. ხელმისაწვდომობა: თინ კლიენტი, ვებ კლიენტი, სერვერი, სქელი კლიენტი, გარე კავშირი, მობილური აპლიკაცია (კლიენტი), მობილური აპლიკაცია (სერვერი). მეთოდის ზარი ურეკავს სერვერს. შენიშვნა: შესრულების შედეგი არ არის ქეშირებული, სერვერის გამოძახება ხდება ყოველი მეთოდის გამოძახებისას.

სერვერის კოდის დარეკვა

ნებისმიერი ზარი სერვერის კოდზე ყოველთვის ახდენს გადაცემული მონაცემების სერიალს. ყველა პარამეტრი შეფუთულია სტრიქონში და გადაიცემა ქსელში. სამუშაოს შედეგი ასევე გადადის უკან სერიული სახით, სადაც შემდეგ აღდგება ნაცნობ ობიექტებად.

მოდულის დროშების მინიჭება

• დროშა მიუთითებს სად შედგენილი იქნება მოდულის კოდი (სერვერზე, კლიენტზე, გარე კავშირში)
• თუ მოდული შედგენილია რამდენიმე ადგილას, მაშინ ის მხოლოდ დროშების მიხედვით იქნება ხილული
• კოდის შესრულების გადაცემა შესაძლებელია მხოლოდ იმ შემთხვევაში, თუ არ არის მოწოდებული მოდული მიმდინარე შესრულების კონტექსტში, მაგრამ ის არსებობს სხვაგან (თუ მოდული არსებობს მხოლოდ სერვერზე და ის არ არსებობს კლიენტზე, მაშინ სერვერი გამოიძახება)

სერვერის ზარის დროშა

1C:Enterprise 8.2 პლატფორმიდან დაწყებული, დაემატა „სერვერის ზარის“ დროშა. რაც უბრალოდ ეხმარება სხვა მანქანაზე გადასვლის პირობების „გადაჭრას“. თუ ეს დროშა მინიჭებულია მოდულზე, მაშინ მოდული გამოჩნდება კლიენტისგან, თუ არა, მაშინ კლიენტისგან დარეკვის მცდელობა გამოიწვევს შეცდომას. მოდულის კოდი არ ჩანს, თითქოს საერთოდ არ არსებობს.

ამრიგად, ჩვეულებრივ სქელ კლიენტში შეგიძლიათ კოდი სერვერზე გადაიტანოთ მხოლოდ იმ შემთხვევაში, თუ კლიენტისგან გამოიძახებთ საერთო მოდულს, რისთვისაც:

• სერვერის ჩამრთველი მონიშნულია
• მონიშნულია "ზარის სერვერის" ველი
• წაშლილია ყველა „კლიენტის“ ჩამრთველი

1C Enterprise 8.2 პლატფორმის მოსვლასთან ერთად, მომხმარებლის ინტერფეისის განვითარების მექანიზმი მნიშვნელოვნად შეიცვალა. ახლა თქვენ შეგიძლიათ შექმნათ მართული ფორმები და აპლიკაციები (სურათი 1).

სურათი 1

გარდა ამისა, შემოთავაზებულია ახალი სისტემა კლიენტის აპლიკაციასა და სერვერს შორის ფუნქციონირების გამიჯვნისთვის.
მართული აპლიკაცია მხარს უჭერს შემდეგი ტიპის კლიენტებს:

• სქელი კლიენტი (ნორმალური და მართული გაშვების რეჟიმი),
• თხელი კლიენტი,
• ვებ კლიენტი.

მართული ფორმების შექმნის მექანიზმი მნიშვნელოვნად განსხვავდება ჩვეულებრივი ფორმებისგან. უპირველეს ყოვლისა, მართული ფორმები განსხვავდება იმით, რომ ისინი ავტომატურად იქმნება სისტემის მიერ სპეციალური პარამეტრების საფუძველზე; ახლა პროგრამისტს არ სჭირდება თითოეული ფორმის დეტალურად დახატვა. ფორმის ყველა ფუნქცია აღწერილია დეტალებისა და ბრძანებების სახით. დეტალები არის მონაცემები, რომლებთანაც მუშაობს ფორმა, ხოლო ბრძანებები არის შესრულებული მოქმედებები. თითოეული მეთოდის ან ფორმის ცვლადისთვის უნდა იყოს მითითებული კომპილაციის დირექტივა, რომელიც განსაზღვრავს შესრულების ადგილს (კლიენტი ან სერვერი). კომპილაციის დირექტივები შეიძლება იყოს:

• &კლიენტი,
• &სერვერზე,
• &სერვერზე კონტექსტის გარეშე,
• &კლიენტში სერვერზე კონტექსტის გარეშე.

მართული ფორმა ასევე განსხვავდება ჩვეულებრივი ფორმისგან იმ მონაცემთა ტიპებით, რომლებთანაც მუშაობს. თუ ჩვეულებრივი ფორმა მუშაობს 1C:Enterprise-ის მიერ მოწოდებულ ტიპებთან (მათ შორის, ტიპები DirectoryObject, DocumentObject და ა.შ.), მაშინ შემდეგი კატეგორიების ტიპები შეიძლება გამოიყოს მართული ფორმით:

• ტიპები, რომლებიც პირდაპირ გამოიყენება ფორმაში, არის ის ტიპები, რომლებიც არსებობს თხელი და ვებ კლიენტის მხარეს (მაგალითად, Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
• ტიპები, რომლებიც გარდაიქმნება მონაცემთა სპეციალურ ტიპებად, იმართება მონაცემთა ტიპებიდან. ასეთი ტიპები ნაჩვენებია ფორმის ატრიბუტების სიაში ფრჩხილებში, მაგალითად (CatalogObject.Products);
• დინამიური სია.

მართული ფორმების ფუნქციონირებას აქვს შემდეგი გამორჩეული მახასიათებლები (სურათი 2):

• ფორმა არსებობს როგორც კლიენტზე, ასევე სერვერზე.

იგი ახორციელებს კლიენტ-სერვერის ურთიერთქმედებას (მონაცემების გადაცემა და ელემენტების დიზაინის თვისებები).

• ფორმა არ მუშაობს განაცხადის ობიექტებთან

სურათი 2

ფორმა იყენებს სპეციალურ ზოგად ობიექტებს
DataForms(სურათი 3).


სურათი 3

აპლიკაციის ობიექტები მუშაობს მხოლოდ სერვერზე და მხოლოდ გარკვეული ოპერაციების დროს.
ფორმის გახსნისას:

• ობიექტი იკითხება მონაცემთა ბაზიდან,
• ობიექტი გარდაიქმნება ფორმის მონაცემად,
• ობიექტი ამოღებულია (მეხსიერებიდან),
• ფორმის მონაცემები გადაეცემა კლიენტს.

ჩაწერისას:

• ფორმის მონაცემები მიიღება კლიენტისგან,
• ფორმის მონაცემები გარდაიქმნება ობიექტად,
• ობიექტი იწერება მონაცემთა ბაზაში,
• ობიექტი ამოღებულია (მეხსიერებიდან).

ბოლო გაკვეთილზე განვიხილეთ რეგულარული (მსუქანი) კლიენტი. პლატფორმის ვერსიაში 1C 8.2. ისინი იყენებენ ეკრანის ახალ ფორმებს 1C 8.2. მათ უწოდებენ მართულ ფორმებს 1C 8.2.

მართული ფორმები 1C 8.2 არის 1C-ის მომავალი. ისინი განსხვავდებიან ჩვეულებრივი 1C 8.2 ფორმებისგან იმით, რომ ისინი ავტომატურად წარმოიქმნება სისტემის მიერ სპეციალური პარამეტრების საფუძველზე ("რეგულარული" ფორმები უბრალოდ შედგენილია პროგრამისტის მიერ სურვილისამებრ).

მართული ფორმების 1C 8.2 შემუშავებაში განსხვავებები ჩვეულებრივია. ამიტომ, ჩვენ დღეს შევიკრიბეთ, რათა ცალკე განვიხილოთ მართული ფორმების შექმნა და მოდიფიკაცია 1C 8.2.

მართული ფორმები 1C 8.2

თუ ადრე ავითარებდით 1C კონფიგურაციებს, როცა გახსნით 1C 8.2 მართული ფორმის რედაქტორს, მაშინვე დაბნეული იქნებით იმით, რომ შეუძლებელია მაუსით 1C 8.2 ფორმაზე ზემოქმედება საერთოდ.

თქვენ არ შეგიძლიათ შეცვალოთ 1C 8.2 ფორმა, ვერ გადაიტანოთ ელემენტი, ვერც კი იხილოთ ველის თვისებები, როგორც ადრე - ორჯერ დააწკაპუნეთ ველზე 1C 8.2 ფორმაზე.

ახლა 1C 8.2 ფორმის შემუშავების საფუძველი არ არის სავალდებულო ველები ფორმაზე კოორდინატებისთვის, არამედ სპეციალური პარამეტრები. სისტემა ავტომატურად წარმოქმნის მართულ ფორმას 1C 8.2 ამ პარამეტრების საფუძველზე.

პარამეტრები შედგება 1C 8.2 ფორმის ელემენტების სიისგან, რომელიც მდებარეობს რედაქტორში ზედა მარცხენა კუთხეში. 1C 8.2 ფორმის ელემენტები მოიცავს:

• რეკვიზიტები
• ბრძანებები (ახალი კონცეფცია 1C 8.2, შეიძლება გამოიყურებოდეს როგორც ღილაკები ან მენიუს ელემენტები)
• ჯგუფები (დეტალებისა და ბრძანებების გაერთიანება).

შესაბამისად, ამ ელემენტების პარამეტრები არ არის ველების თვისებებში, არამედ ამ პარამეტრების ელემენტების თვისებებში (მარჯვენა დაწკაპუნებით მენიუ, თვისებათა პუნქტი).

როგორ მუშაობს მართული ფორმები 1C 8.2

მართულ ფორმებთან მუშაობა 1C 8.2 განსხვავებულია მომხმარებლისთვის. მათ აქვთ მეტი ფუნქცია, მაგრამ უჩვეულოა მათთვის, ვინც დიდი ხანია მუშაობს 1C-ით.

უპირველეს ყოვლისა, 1C 8.2 ფორმაზე ჩვეულებრივი ელემენტების ადგილმდებარეობა განსხვავდება. ბრძანების ზოლი ყოველთვის ზედა ნაწილშია.

ბრძანების ზოლის მარცხენა მხარე კონფიგურირებადია. ის ჩვეულებრივ შეიცავს ისეთ ტიპურ ღილაკებს, როგორიცაა ჩანაწერი და პოსტი.

ბრძანების პანელის მარჯვენა მხარე არის 1C ფორმის ყველა მოქმედების ახალი სტანდარტული მენიუ. ეს მენიუ საშუალებას გაძლევთ მართოთ 1C 8.2 ფორმა, როგორც გსურთ, ისევე, როგორც ACS ანგარიშის პარამეტრები საშუალებას გაძლევთ მნიშვნელოვნად შეცვალოთ ანგარიშის გარეგნობა.

მენიუს თვითნებური ელემენტები 1C ყველა მოქმედება

იმისდა მიხედვით, ეკუთვნის თუ არა ეს ფორმა 1C 8.1 ამა თუ იმ სხვას, მენიუ ივსება ელემენტებით, რომლებიც საშუალებას გაძლევთ მართოთ ეს ობიექტი. მაგალითად, თუ ეს არის დირექტორიაში სიის ფორმა, მაშინ იქნება ბრძანებები, როგორიცაა შექმნა ან რედაქტირება.

პუნქტი მენიუს სიის მორგება 1C ყველა მოქმედება

თუ 1C 8.2 ფორმაზე არის სია, მაშინ მენიუს აქვს ბრძანება Set up list და Display list.
თუ Output List ბრძანება უკვე ნაცნობია თქვენთვის - ის საშუალებას გაძლევთ შეინახოთ ნებისმიერი სია 1C-ში Excel-ში / დაბეჭდოთ იგი, მაშინ მეორე ბრძანება ახალია.

როგორც უკვე შენიშნეთ, სიების ბრძანების ზოლზე აღარ არის შერჩევის ღილაკები. ამის ნაცვლად, გამოჩნდა ღილაკი Find, რომელზეც მუშაობს (ისევე, როგორც ახლა გამორთულია კურსორის პოზიციონირება სიაში აკრეფისას) - არის საჩივრები.

Find ღილაკის ფუნქციონალობა, რა თქმა უნდა, არ არის შედარებული არჩეულებთან, მაგრამ ისინი არსად გაქრა!
ისინი ახლა იმყოფებიან მენიუს მორგების სიის პუნქტში. შერჩევა ახლა შეიძლება გაკეთდეს ნებისმიერი ველით და გარდა ამისა, დახარისხება და პირობითი ფორმატირება შეიძლება განხორციელდეს ისევე, როგორც ეს შეიძლება გაკეთდეს SKD ანგარიშებში.

პუნქტი მენიუს შეცვლა ფორმა 1C ყველა ქმედება

ფორმის შეცვლა საშუალებას გაძლევთ ანალოგიურად შეცვალოთ არა მხოლოდ სია 1C 8.2 ფორმაში, არამედ თავად 1C 8.2 ფორმაშიც.

მომხმარებელს შეუძლია დამოუკიდებლად ჩართოს ან გამორთოს ველების ხილვადობა 1C 8.2 ფორმაზე, სიგანე და სიმაღლე, ნაგულისხმევი ველის გააქტიურება გახსნისას და ა.შ.

მართული ფორმების 1C 8.2 და ჩვეულებრივი ფორმების 1C გამოყენებით

ნაგულისხმევად, ჩვეულებრივი 1C ფორმები გამოიყენება კონფიგურაციებში სქელი (რეგულარული) 1C კლიენტისთვის, ხოლო მართული ფორმები გამოიყენება კონფიგურაციებში თხელი და ვებ 1C კლიენტისთვის. თუმცა, 1C-ის ორივე ფორმა შეიძლება გამოყენებულ იქნას ნებისმიერ კონფიგურაციაში, მათ შორის ერთდროულად.

ამისათვის თქვენ ასევე უნდა შეიყვანოთ კონფიგურაციის თვისებები (ზედა ელემენტი კონფიგურაციის ფანჯარაში).

1C 8.2-ის კონფიგურაციის თვისებებში გამოჩნდა ორი ახალი ველი, რომელიც საშუალებას გაძლევთ ჩართოთ 1C ფორმების არასტანდარტული გამოყენება.

მართული ფორმების შექმნა 8.2

ახალი ფორმის 1C 8.2 დამატება ხდება ისე, როგორც ადრე - კლავიატურაზე Ins ღილაკის ან ღილაკის დამატება. არსებულის შესასვლელად, ორჯერ დააწკაპუნეთ მასზე მაუსის საშუალებით.

ნაგულისხმევად, შეიქმნება ფორმა (ჩვეულებრივი ან მართული), რომელიც დაყენებულია კონფიგურაციაში (იხ. ძირითადი გაშვების რეჟიმის თვისება კონფიგურაციის თვისებებში).

კონსტრუქტორი მოგთხოვთ აირჩიოთ ფორმის ტიპი - ელემენტის ფორმა, სია. აქ შეგიძლიათ დაამატოთ ან წაშალოთ ბრძანების ზოლები ფორმაზე. ყველაზე ხშირად, ეს პარამეტრები ნაგულისხმევად რჩება ისე, როგორც არის.

იხსნება ნაგულისხმევად შევსებული ფორმა - 1C ობიექტის ყველა დეტალი, რომელიც მას ემატება. თქვენ შეგიძლიათ მონიშნოთ საჭირო ველების კონკრეტული სია კონსტრუქტორის მეორე ჩანართზე.

ფორმის რედაქტორი შედგება სამი განყოფილებისგან.

• ზედა მარცხენა კუთხეში არის ფორმის ელემენტების სია. იგი შედგება ველებისგან, ბრძანებებისგან და ჯგუფებისგან, რომლებიც საშუალებას გაძლევთ დააკავშიროთ ელემენტები. ბრძანებების სია ცალკე შეგიძლიათ ნახოთ Command Interface ჩანართზე.
• ზედა მარჯვენა კუთხეში არის ხელმისაწვდომი ფორმის ატრიბუტებისა და ობიექტის ატრიბუტების სია (გახსენით ჯვარი ობიექტის ატრიბუტის გვერდით).
• ქვემოთ მოცემულია მიღებული ფორმის გადახედვა.

შეგიძლიათ გადაიტანოთ ხელმისაწვდომი დეტალები მარცხნივ და ის გახდება ფორმის ელემენტი (ფორმის ველი).

თუ თქვენ გჭირდებათ ღილაკის ან მენიუს ელემენტის დამატება - ბრძანებების ჩანართის მარჯვენა მხარეს, თქვენ უნდა შექმნათ ახალი ბრძანება. ეს არის შეფუთვა ფუნქციისთვის ფორმის მოდულში. გარდა იმისა, რომ მიუთითოთ რომელი ფუნქცია იქნება რეალურად გამოძახებული, შეგიძლიათ მივანიჭოთ წარმოდგენა - მაგალითად, სურათი, ასევე ხილვადობის დამოკიდებულება ფუნქციურ ვარიანტზე.

ბრძანებები ასევე გადაიტანეთ მარცხნივ. თუ მშობელი არის ბრძანების ზოლი, მაშინ ეს იქნება ბრძანების ზოლის ღილაკი - წინააღმდეგ შემთხვევაში მხოლოდ ღილაკი.

ფორმის ელემენტების სიაში (ველები) შეგიძლიათ არა მხოლოდ გადაიტანოთ ობიექტის/ფორმის ატრიბუტი, არამედ უბრალოდ დაამატოთ იგი (ღილაკი Add ან Ins). კერძოდ, შეგიძლიათ შექმნათ ახალი ფორმის ობიექტი - ჯგუფი.

ჯგუფი შეიძლება იყოს ბრძანების პანელი (კურსორი უნდა იყოს ფორმის ხაზზე). შემდეგ გადაიტანეთ ბრძანებები მასში და ისინი გახდებიან ღილაკები.

ჯგუფი შეიძლება იყოს "რეგულარული". შემდეგ ეს არის ველების დაჯგუფების საშუალება როგორც ვერტიკალურად, ასევე ჰორიზონტალურად. ჯგუფის სახელი შეიძლება წაიშალოს თვისებებში.

ჯგუფი შეიძლება იყოს პანელი (გვერდები). ზედა დამატებული ჯგუფი არის პანელი და ამ ტიპის ჩადგმული ჯგუფები არის გვერდები. ველები უკვე იტრიალებს გვერდებზე.

ფორმის არასაჭირო ელემენტები ამოღებულია სიაში ფორმის ელემენტების წაშლით.
ველის პოზიცია ფორმაზე განისაზღვრება ელემენტების სიაში თანმიმდევრობით (ვერტიკალური) ან ჯგუფების მიხედვით (ჰორიზონტალური). სიგანე და სიმაღლე მითითებულია ფორმის ელემენტის თვისებებში.

ფორმის ელემენტის თვისებები მნიშვნელოვნად გაფართოვდა და შეიცავს ბევრ სასარგებლო ნივთს - როგორც გარეგნობის კონტროლს (არჩევის და გასუფთავების ღილაკები), ასევე ნაგულისხმევი მნიშვნელობების შემოწმებას.

თავად ფორმის თვისებები, მისი ზომების ჩათვლით, მითითებულია ფორმის ძირეულ ელემენტში, იგივე სახელწოდებით Form.

მოვლენის დამმუშავებლები (მომხმარებლის ქმედებებზე რეაგირება) ახლა ორ ტიპად იყოფა. ძველი - როგორც ადრე, ისინი მითითებულია ფორმისა და ველების თვისებებში (მაგალითად, OnChange და OnOpening ფორმის). ახალი - გახდა ბრძანებები და გამოიყენება მენიუს ელემენტებისა და ღილაკებისთვის.

პლატფორმის 8.2 ვერსიიდან, 1C-მა დაიწყო ახალი პრინციპების გამოყენება ინტერფეისის შესაქმნელად და მონაცემთა ბაზასთან მომხმარებლის ინტერაქციისთვის. ახალ ტექნოლოგიას მართული აპლიკაცია ჰქვია. ყველაზე დიდი დამუშავება განიცადა ფორმების აგების მექანიზმებმა და 1C სერვერის მომხმარებელსა და მონაცემთა ბაზას შორის ურთიერთქმედების სქემა. ნორმალური რეჟიმი კვლავ მხარდაჭერილია პლატფორმის მიერ, მაგრამ დროთა განმავლობაში, ყველა 1C მომხმარებელი გადადის მართულ ფორმებზე.

ჩვეულებრივი მომხმარებლებისთვის, 1C დოკუმენტის მართული ფორმა განსხვავდება ჩვეულებრივისგან მხოლოდ გარეგნულად. დეველოპერისთვის ეს არის ახალი მექანიზმი თავისი წესებით, კანონებითა და პირობებით. ბევრმა სფერომ განიცადა ცვლილება, მაგრამ შემდეგი ინოვაციები საკვანძოდ ითვლება გამოცდილ 1C დეველოპერებს შორის:

• ფორმის სტრუქტურის დამოუკიდებელი ფორმირება და ველების განლაგება პლატფორმის მიერ. თუ ადრე დეველოპერები აღწერდნენ ველის პოზიციას პიქსელების მითითებით, ახლა მხოლოდ დაჯგუფების ტიპის დაზუსტებაა შესაძლებელი;
• ფორმა შედგება ფორმის მონაცემების გამოსახული ატრიბუტებისაგან, ხოლო ბრძანებებისაგან - შესრულებული პროცედურები და ფუნქციები;
• ფორმის კოდი შესრულებულია როგორც სერვერის, ასევე კლიენტის მხარეს. ყოველივე ამის შემდეგ, თავად ფორმა არის სერვერზე შექმნილი კონფიგურაციის ობიექტი და ნაჩვენებია კლიენტზე. ეს ნიშნავს, რომ ის აერთიანებს კლიენტისა და სერვერის ნაწილებს;
• კლიენტის მხრივ, მრავალი ტიპის მონაცემი მიუწვდომელი გახდა და ახლა არ არსებობს ინფორმაციის შეცვლის საშუალება ინფო ბაზაში;
• თითოეული პროცედურისა თუ ფუნქციისთვის უნდა იყოს მითითებული სპეციალური პარამეტრი - კომპილაციის დირექტივა. ის პასუხისმგებელია კოდის შესრულების ადგილზე და შეუძლია მიიღოს შემდეგი მნიშვნელობები:
  • კლიენტზე;
  • სერვერზე;
  • ServerWithoutContext-ზე;
  • OnClientOnServer;
  • კლიენტზე სერვერზე კონტექსტის გარეშე.

ბოლო პუნქტი განსაკუთრებით მწვავეა მართული ფორმების რეჟიმში. თუ დეველოპერს არ აქვს კარგად გათვითცნობიერებული დირექტივები ან კლიენტ-სერვერის ურთიერთქმედება, მაშინ მისთვის ძალიან რთული იქნება მართული ფორმის შექმნა. მართული ფორმების მშენებლობის ყველა ახალი პრინციპი 1C:Enterprise 8.3-ში გაერთიანებულია სამსაფეხურიანი არქიტექტურის ზოგადი კონცეფციით. მასში შედის კლიენტის კომპიუტერები, 1C სერვერი და DBMS, სადაც ინახება მონაცემები.

მართული ფორმის რედაქტირება კონფიგურატორში ასევე განსხვავებული გახდა. ბევრი ასპექტი შეიცვალა და 7.7 ვერსიის დეველოპერები, სადაც არ იყო მართული ფორმები, შეიძლება გაოცდნენ. შეიცვალა ფორმის დიზაინერის გარეგნობაც კი, რაც ჩანს კონფიგურაციის ობიექტის ნებისმიერი ფორმის გახსნით. ობიექტის გახსნისას ჩვენ ვხედავთ ფანჯარას, რომელიც იყოფა რამდენიმე ნაწილად:

1. ინტერფეისის ელემენტების ფორმა. ზედა მარცხენა მხარეს არის ფანჯარა, რომელშიც ჩამოთვლილია არჩეულ ფორმაზე გამოტანილი ყველა ველი, რომელიც უზრუნველყოფს პროგრამის ინტერაქციას მომხმარებელთან;
2. ფორმის დეტალები. ზედა მარჯვნივ არის ყველა მონაცემი, რომლითაც მუშაობს ფორმა. სწორედ მათში ინახება ინფორმაცია კლიენტის მხარეს;
3. მართული ფორმის ჩვენება. ქვემოთ ჩვენ ვხედავთ იერსახის გადახედვას ინტერფეისის ელემენტებზე დაყრდნობით;
4. ფორმის მოდული. განყოფილება, რომელიც შეიცავს ამ ფორმის მიერ გამოყენებულ პროცედურებსა და ფუნქციებს. აქ შეგიძლიათ იპოვოთ ალგორითმების კოდი პროგრამის როგორც მომხმარებელთან, ასევე მონაცემთა ბაზასთან ურთიერთქმედებისთვის.

1C-ის დეველოპერები აჟიტირებენ კლიენტებს, გადავიდნენ მართულ ფორმებზე, ამიტომ მართული ფორმების შემუშავების პრინციპების სწავლა დროის საკითხია. ამ ტიპის ფორმაზე მუშაობის დაწყებით, მიხვდებით, რომ ეს არის ნაბიჯი განვითარების სტანდარტიზაციისა და ერთიანი წესების დაცვისკენ. ამიტომ, მართულ ფორმებთან მუშაობის შესაძლებლობა 1C 8.3-ში ზრდის თქვენს დონეს, როგორც 1C დეველოპერს.

მართული ფორმების დიზაინის სახელმძღვანელო

უპირველეს ყოვლისა, 1C მართული რეჟიმის მექანიზმის გასაგებად, უნდა გახსოვდეთ, რომ ფორმა არსებობს როგორც სერვერზე, ასევე კლიენტზე. უფრო მეტიც, კლიენტზე ეს ობიექტი მხოლოდ პროგრამასთან მომხმარებლის ინტერფეისის გამოსახულებაა. ყველა გამოთვლა, ალგორითმი, გამოთვლა და დამუშავება უნდა მოხდეს მხოლოდ სერვერის მხარეს. ეს ნაკარნახევია არა მხოლოდ კლიენტზე მრავალი ფუნქციისა და პარამეტრის გამოყენების უუნარობით, არამედ შესრულების მოთხოვნებით.

სად ტარდება პროცედურა, შეგიძლიათ გაიგოთ დირექტივის სახელწოდებით, რომელიც უნდა დაიწეროს ყოველი პროცედურის წინ და ფუნქციონირდეს ფორმის მოდულში. ფორმულირება „კონტექსტის გარეშე“ მიუთითებს, რომ მართული ფორმის მონაცემები არ გადაეცემა ამ პროცედურას სერვერზე. ამრიგად, ასეთ პროცედურებში შეუძლებელი იქნება ალგორითმების დაწერა მომხმარებლის მიერ შეყვანილი მნიშვნელობების საფუძველზე. თუ ეს ფორმულირება არ არის მითითებული, მაშინ ფორმა მთლიანად გადაიცემა ყველა დეტალით და შეგიძლიათ მათზე წვდომა.

1C დეველოპერები დაჟინებით გვირჩევენ გამოიყენონ არაკონტექსტური სერვერის ზარები, შეძლებისდაგვარად შეამცირონ მათი რაოდენობა და შეეცადონ არ განახორციელონ გამოთვლები კლიენტზე. თეორიული ფონის გარეშე დამწყებ დეველოპერებს უჭირთ ყველა ამ წესის დაცვა და კოდის სწორად შეცვლა. სანამ დამოუკიდებლად დაიწყებთ მუშაობას, სასარგებლო იქნება მართული კონფიგურაციის ფორმის გახსნა, სინტაქსის დათვალიერება და კლიენტისა და სერვერის ურთიერთქმედება.

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

1C ფორმების შემუშავების ახალი წესები დიდ სარგებელს მოუტანს, თუ ყველა დეველოპერი დაიცავს მათ. უფრო მეტიც, ყველა იგრძნობს ცვლილებებს უკეთესობისკენ - როგორც პროგრამისტები, ასევე 1C-ში მომუშავე კომპანიები, ფრენჩაიზები და 1C დეველოპერები. მართული ფორმების სწორი მუშაობის ძირითადი შედეგები 1C-ში:

1. კონფიგურაციის შენარჩუნების სიმარტივე და გაზრდილი კოდის წაკითხვა. აქედან შეგვიძლია დავასკვნათ, რომ ერთი დეველოპერის მიერ დაწერილი ალგორითმი ყოველთვის შეიძლება გამოსწორდეს მეორე თანამშრომელს დიდი დროის დახარჯვის გარეშე;
2. კლიენტსა და სერვერზე გაშვებული კოდის გამიჯვნა. იმის გათვალისწინებით, თუ რამდენად განსხვავებულია თითოეული ამ მხარის ფუნქციონირება, მათი გამიჯვნა სწორი ნაბიჯი იქნება;
3. დეველოპერებს უფრო ღრმად ესმით პლატფორმის ლოგიკა, კლიენტ-სერვერის ურთიერთქმედება და მათ მიერ დაწერილი ალგორითმები. 8.0 და უფრო ადრეულ ვერსიებში ძალიან ხშირი იყო დოკუმენტების ან დირექტორიების ფორმების პოვნა, რომლებიც შემუშავებული იყო კლიენტ-სერვერის ნაწილის გაგების გარეშე;
4. კონფიგურაციის სიჩქარის გაზრდა და კლიენტის კომპიუტერებზე დატვირთვის შემცირება;
5. სამუშაო ადგილებისთვის კომპიუტერების შეძენის ღირებულების შემცირება მძლავრი კომპიუტერების შეძენის საჭიროების არარსებობის გამო.

მართული ფორმის არჩევამ, როგორც 1C გაშვების მთავარ რეჟიმს, შეიძლება ბევრი სიურპრიზი მოიტანოს. მაგრამ სწორი მიდგომით, ეს ნაბიჯი დიდ დივიდენდებს მოიტანს, ამიტომ უფრო და უფრო მეტი 1C მომხმარებელი მთელ რუსეთში გადაწყვეტს ამაზე. იმის გათვალისწინებით, რომ 1C კომპანია მომავალში იმედოვნებს მართული ფორმების განვითარებას, სარისკოა მოძველებულ ჩვეულებრივებზე დარჩენა.