ფორმის ძირითადი დეტალები. მართული ფორმის დეტალები (1Cv8) 1c მართული ფორმები ამატებენ დეტალებს პროგრამულად

ფორმის დეტალები

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

Მნიშვნელოვანი!უნდა გვახსოვდეს, რომ ჩვეულებრივი ფორმებისგან განსხვავებით, ყველა მონაცემი მართულ ფორმაში უნდა იყოს აღწერილი დეტალების სახით. დაუშვებელია ფორმის მოდულის ცვლადების გამოყენება, როგორც მონაცემთა წყარო ფორმის ელემენტებისთვის.

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

ფორმის გაფართოება– ეს არის ManagedForm ობიექტის დამატებითი თვისებები, მეთოდები და ფორმის პარამეტრები, დამახასიათებელი ობიექტისთვის, რომელიც არის ფორმის მთავარი ელემენტი.

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

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

მონაცემთა ტიპები ხელმისაწვდომია მართულ ფორმაში

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

• ტიპები, რომლებიც პირდაპირ გამოიყენება ფორმაში, არის ის ტიპები, რომლებიც არსებობს თხელი და ვებ კლიენტის მხარეს (მაგალითად, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);

• ტიპები, რომლებიც გარდაიქმნება მონაცემთა სპეციალურ ტიპებად - მართული ფორმის მონაცემთა ტიპებად. ასეთი ტიპები ნაჩვენებია ფორმის დეტალების სიაში ფრჩხილებში, მაგალითად (DirectoryObject.Products);

• დინამიური სია (დამატებითი ინფორმაციისთვის იხილეთ ამ თავის განყოფილება „დინამიური სია“).

აპლიკაციის ობიექტების ფორმის მონაცემებად გადაქცევა

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

გამოიყენება მონაცემთა შემდეგი ტიპები:

• Form DataStructure – შეიცავს თვითნებური ტიპის თვისებების ერთობლიობას. თვისებები შეიძლება იყოს სხვა სტრუქტურები, კოლექციები ან სტრუქტურები კოლექციებით. ეს ტიპი წარმოდგენილია, მაგალითად, DirectoryObject სახით.

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

• ფორმა 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();

პროცედურის დასასრული

&OnServer პროცედურა WriteOnServer()

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

პროცედურის დასასრული

ManagedForm ობიექტს ასევე აქვს სერვერზე ხელმისაწვდომი მეთოდები:

• ValueВFormAttribute() – გარდაქმნის აპლიკაციის ტიპის ობიექტს მითითებულ ფორმის ატრიბუტად.
• FormAttributeVValue() – გარდაქმნის ფორმის მონაცემების ატრიბუტს აპლიკაციის ტიპის ობიექტად.

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

მოდით მოვიყვანოთ ამ მეთოდების გამოყენების მაგალითი.

&OnServer პროცედურა RecalculateOnServer()

// გარდაქმნის Object ატრიბუტს აპლიკაციის ობიექტად. Document = Form AttributesValue("ობიექტი"); // ახორციელებს ხელახალი გამოთვლას დოკუმენტის მოდულში განსაზღვრული მეთოდის გამოყენებით. Document.Recalculate(); // გარდაქმნის აპლიკაციის ობიექტს საყრდენად. ValueВFormAttributes (დოკუმენტი, „ობიექტი“);

პროცედურის დასასრული

პროგრამული ინტერფეისი

FormDataTree

• FindById
• GetItems

აღწერა:

შექმნილია ხის მოდელირებისთვის მართული ფორმის მონაცემებით.

ამ ობიექტის სერიალიზაცია შესაძლებელია/XDTO-დან. ამ ობიექტის შესაბამისი XDTO ტიპი განისაზღვრება სახელთა სივრცეში. XDTO ტიპის სახელი:

GetItems

Სინტაქსი:

GetItems ()

დაბრუნების ღირებულება:

ტიპი: Form DataCollection of Tree Elements.

აღწერა:

იღებს ზედა დონის ხის ელემენტების კოლექციას.

ხელმისაწვდომობა: კლიენტი, სერვერი, თინ კლიენტი, ვებ კლიენტი.

FindById

Სინტაქსი:

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

Პარამეტრები:

<Идентификатор>(აუცილებელია)

ტიპი: ნომერი. ხის ელემენტის იდენტიფიკატორი.

დაბრუნების ღირებულება:

ტიპი:FormDataTreeElement.

აღწერა:

იღებს კოლექციის ელემენტს ID-ით.

ხელმისაწვდომობა: კლიენტი, სერვერი, თინ კლიენტი, ვებ კლიენტი.

FormDataTreeItem

Თვისებები:

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

• GetId (GetId)
• GetParent
• GetItems
• საკუთრება

აღწერა:

მონაცემთა ხის ელემენტის ფორმა.

FormDataTreeItemCollection

კოლექციის ელემენტები: DataFormTreeElement

ობიექტისთვის შესაძლებელია კოლექციის გავლა ოპერატორის გამოყენებით For each... 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(); პროცედურის დასასრული

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

ფორმის პროგრამული მოდიფიკაცია შეიძლება საჭირო გახდეს რამდენიმე შემთხვევაში:

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

მართულ ფორმაში შეგიძლიათ პროგრამულად დაამატოთ, შეცვალოთ და წაშალოთ:

• რეკვიზიტები;
• ადგილობრივი გუნდები;
• ელემენტები.

ყველა ეს ოპერაცია შესაძლებელია მხოლოდ სერვერზე.

პროგრამულ გადაფორმებას აქვს შეზღუდვები:

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

ფორმის ბრძანებების შეცვლა

ობიექტისთვის ბრძანებების კომპოზიციის მართვა მართული ფორმაარის კოლექცია გუნდები

დამატება (< ИмяКоманды >)

რაოდენობა ()

იპოვე (< ИмяКоманды >)

წაშლა (< Команда >)

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

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

&სერვერზე
Პროცედურა WhenCreatingOnServer (მარცხი, სტანდარტული დამუშავება)
გუნდი = გუნდები. დამატება( "ცვლილებების ისტორია");
გუნდი . მოქმედება = ;
გუნდი . სათაური = "ცვლილებების ისტორია...";
პროცედურის დასასრული
&OnClient
Პროცედურა Connectable_DisplayHistory (ბრძანება)
// ბრძანების მოქმედებები
პროცედურის დასასრული

ბრძანების დამმუშავებელი უნდა იყოს განთავსებული ფორმაზე და ჰქონდეს &OnClient კომპილაციის დირექტივა.

ფორმის დეტალების შეცვლა

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

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

ყურადღება!

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

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

AddedDetails = ახალი მასივი;
დამატებულია დეტალები. დამატება (ახალი ფორმის ატრიბუტები(„მყიდველი“, ახალი ტიპის აღწერა („DirectoryLink. Counterparties“), „კლიენტი“));

// ცვლილებები დეტალების შემადგენლობაში
);

ფორმის ელემენტების შეცვლა

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

ჩასმა (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

დამატება (< Имя>, < ТипЭлемента>, < Родитель >)

რაოდენობა ()

იპოვე (< Имя >)

გადაადგილება (< Элемент>, < Родитель>, < МестоРасположения >)

წაშლა (< Элемент >)

Items კოლექცია ხელმისაწვდომია როგორც კლიენტზე, ასევე სერვერზე. კოლექციის შეცვლა (ჩასმა მეთოდები () , დამატება () , გადატანა () და წაშლა () ) ხელმისაწვდომია მხოლოდ სერვერზე. თქვენ შეგიძლიათ მოძებნოთ და მიიღოთ ელემენტების რაოდენობა (Find () და Count () მეთოდები) როგორც კლიენტზე, ასევე სერვერზე. კოლექციის ელემენტები შეიძლება იყოს:

• FormGroup;
• FormTable;
• FormField;
• ფორმის ღილაკი.

თქვენ შეგიძლიათ პროგრამულად მიანიშნოთ მოვლენის დამმუშავებლები ელემენტების ფორმირებისთვის. მეთოდი განკუთვნილია ამ მიზნებისათვის SetAction (< ИмяСобытия>, < Действие >) .

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

ბრძანების და მასთან დაკავშირებული ღილაკის დამატება:

// შექმენით ბრძანება
გუნდი = გუნდები. დამატება( "ცვლილებების ისტორია");
გუნდი . მოქმედება = "Plug-in_Display History"; // ფორმა უნდა შეიცავდეს პროცედურას მითითებული სახელით
გუნდი . სათაური = "ცვლილებების ისტორია...";
// შექმენით ღილაკი და დააკავშირეთ იგი ბრძანებასთან
ელემენტი = ნივთები. დამატება( "ცვლილებების ისტორია", Type("FormButton" ));
ელემენტი.CommandName = "ცვლილებების ისტორია";

ატრიბუტის და მასთან დაკავშირებული შეყვანის ველის დამატება:

// დამატებული დეტალების აღწერა
AddedDetails = ახალი მასივი;
დამატებულია დეტალები. დამატება(New Form Props ("მყიდველი", ახალი ტიპის აღწერა ( "DirectoryLink. კონტრაგენტები"), "კლიენტი" ));
// დეტალების შემადგენლობის შეცვლა
დეტალების შეცვლა (დამატებულია დეტალები);
// შეყვანის ველის შექმნა და ატრიბუტებთან დაკავშირება
ელემენტი = ნივთები. Add("Buyer" , Type("FormField" ));
ელემენტი . ხედი = FormFieldView. შესვლის ველი;
ელემენტი . PathToData= "მყიდველი" ;

მოვლენის დამმუშავებლის მინიჭება ფორმის ელემენტზე:

საქონელი კლიენტი. SetAction("როდესაც ის იცვლება", "Connected_BuyerOnChange");

&OnClient
Პროცედურა Connected_BuyerOnChange(ელემენტი)
// ღონისძიების მოქმედებები
პროცედურის დასასრული

ყურადღება!

პროცედურები, რომლებიც დაყენებულია მოვლენის დამმუშავებლად კოდიდან მეთოდის გამოყენებით SetAction (), რეკომენდებულია პრეფიქსი Connectable_-ის დაყენება.

ყურადღება!

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

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

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

1. განსაზღვრავს მონაცემთა წყაროს მთლიანი ფორმისთვის
2. განსაზღვრავს პლატფორმის სტანდარტულ შესაძლებლობებს ფორმასთან მუშაობისთვის ძირითად ატრიბუტში მითითებული ტიპის მონაცემებით
3. ობიექტის დეტალებზე პროგრამულად წვდომის შესაძლებლობა ლოკალური ფორმის კონტექსტიდან
4. უზრუნველყოფს ობიექტის დეტალების ვიზუალიზაციას ფორმის დიალოგზე
5. 2 და 3 სწორია
6. 1 და 2 სწორია

სწორი პასუხი არის ნომერი ექვსი, იხილეთ ზემოთ.

1C გამოცდის 10.06 კითხვა: პლატფორმის პროფესიონალი. რისთვის არის საჭირო ფორმის დეტალები?

1. მონაცემების შინაარსის აღსაწერად, რომელიც ნაჩვენებია, რედაქტირებულია ან ინახება ფორმაში
2. მონაცემების ჩვენება და რედაქტირება ფორმაში
3. 1 და 2 სწორია

სწორი პასუხი არის მესამე - ორივე.

1C გამოცდის 10.07 შეკითხვა: პლატფორმის პროფესიონალი. ძირითადი ატრიბუტების მინიჭება თვითნებური კონტროლირებადი ფორმისთვის...

1. ფორმის ატრიბუტების თვისებებში უნდა მონიშნოთ ჩამრთველი „ძირითადი დეტალები“.
2. თქვენ უნდა შეავსოთ ფორმის „მონაცემების“ თვისება საჭირო ფორმის ატრიბუტის არჩევით

სწორი პასუხი მეორეა:

1C გამოცდის 10.08 კითხვა: პლატფორმის პროფესიონალი. ძირითადი დეტალების მინიჭება თვითნებურ რეგულარულ ფორმაზე...

1. ფორმა უნდა გახდეს მთავარი, ძირითადი დეტალები განისაზღვრება ავტომატურად
2. ფორმის ატრიბუტების თვისებებში უნდა მონიშნოთ ჩამრთველი „ძირითადი დეტალები“.
3. თქვენ უნდა გადახვიდეთ მენიუში "რედაქტირება", "ძირითადი დეტალები" და აირჩიოთ სასურველი მნიშვნელობა
4. თქვენ უნდა შეავსოთ ფორმის „მონაცემების“ თვისება საჭირო ფორმის ატრიბუტის არჩევით

მეოთხე სწორი პასუხია:

ძირითადი დეტალები ხაზგასმულია თამამად:

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

1. Ეს შეუძლებელია
2. ეს შესაძლებელია ფორმის ატრიბუტის თვისებისთვის შესაბამისი მნიშვნელობის მინიჭებით
3. ეს შესაძლებელია მხოლოდ პროგრამულად, "ფორმის" ობიექტზე წვდომისას
4. ეს შესაძლებელია შესაბამისი ფორმის თვისების სხვა მნიშვნელობის დამატებით

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

1C გამოცდის 10.113 შეკითხვა: პლატფორმის პროფესიონალი. ნახატზე წარმოდგენილი ფორმის რომელი დეტალია მთავარი?

1. ვალუტის განაკვეთების სია
2. DirectoryObject
3. დირექტორიის ფორმებს არ აქვთ ძირითადი დეტალები
4. დირექტორია ფორმებს აქვს ყველა ძირითადი დეტალი

მეორე სწორი პასუხი არის თამამად.

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

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

ელემენტების დამატება ფორმაში

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

შერჩევის შემდეგ ფანჯარაში გამოჩნდება სასურველი ელემენტი ელემენტები.

მართული ფორმის ელემენტი ველი

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

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

ახლა მოდით დავაკავშიროთ ჩვენი ახლახან დამატებული ფორმის ელემენტი ერთ-ერთ დეტალთან. ამისათვის აირჩიეთ სასურველი ატრიბუტი ელემენტის PathKData თვისებიდან.

ამის შემდეგ შეივსება DataPath და View თვისებები და თავად ელემენტი გამოჩნდება ფორმის ხედში.

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

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

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

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

როგორც ხედავთ, შეყვანის ველის გარეგნობა შეიცვალა და ასევე შეიცვლება View თვისების მნიშვნელობების შესაძლო შერჩევა.

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

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

ხოლო მითითების ტიპის მქონე ატრიბუტებისთვის ხელმისაწვდომი იქნება View თვისების სხვა მნიშვნელობები.

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

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

ისწავლეთ პროგრამირება 1C-ში ჩემი წიგნის „პროგრამირება 1C-ში 11 ნაბიჯში“ დახმარებით

1. არ არის რთული ტექნიკური პირობები.
2. 700-ზე მეტი გვერდის პრაქტიკული მასალა.
3. თითოეულ დავალებას ახლავს ნახატი (სკრინშოტი).
4. საშინაო დავალების პრობლემების კრებული.
5. წიგნი დაწერილია გასაგები და მარტივი ენით - დამწყებთათვის.

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

1. რთული ტექნიკური ტერმინების გარეშე;
2. 600-ზე მეტი გვერდის პრაქტიკული მასალა;
3. თითოეულ მაგალითს ახლავს ნახატი (სკრინშოტი);
4. წიგნი იგზავნება ელექტრონული ფოსტით PDF ფორმატში. იხსნება ნებისმიერ მოწყობილობაზე!

პრომო კოდი 15% ფასდაკლებით - 48PVXHeYu

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

შეგიძლიათ გადაიხადოთ ხელით:

Yandex.Money - 410012882996301
ვებ ფული - R955262494655

შემოუერთდი ჩემს ჯგუფებს.

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

შესავალი

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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) შეცდომები = New Match(); // [ბრძანება][შეცდომის აღწერა] ყოველი შეკვეთისთვის Orders From Orders Cycle StartTransaction(); სცადეთ DocOb = Order.GetObject(); …. სხვა ქმედებები, შესაძლებელია არა მხოლოდ შეკვეთით... გამონაკლისი CancelTransaction(); Errors.Insert(Order, ErrorDescription()); ბოლო მცდელობა; საბოლოო ციკლი; დაბრუნების შეცდომა; EndFunction // ServerChangeOrderStatus()

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

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

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

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

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

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

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

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

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