Pārvaldītās veidlapas informācija (1Cv8). Programmatiska pārvaldīto formu elementu pievienošana un mainīšana Atribūtu pievienošana pārvaldītai formai

Platforma 1C:Enterprise ļauj programmatiski pievienot un mainīt pārvaldītās veidlapas elementus. Noskaidrosim, kāpēc tas varētu būt vajadzīgs.

Veidlapas programmatūras modifikācija var būt nepieciešama vairākos gadījumos:

  • Pabeidzot standarta konfigurācijas, lai atvieglotu turpmāko atjaunināšanas procedūru. Šajā gadījumā tiks mainīts tikai veidlapas modulis. Moduļus ir daudz vieglāk atjaunināt nekā veidlapas.
  • Ieviešot dažus izplatītus algoritmus. Piemēram, apakšsistēmā “Objektu detaļu rediģēšanas aizliegums” visiem apakšsistēmai pievienotajiem objektiem programmatiski var izveidot pogu, lai iespējotu iespēju rediģēt detaļas.
  • Īstenojot dažus konkrētus algoritmus. Piemēram, direktorijā Nomenklatūra tiek izveidoti lauki papildu informācijas rediģēšanai.

Pārvaldītā formā varat programmatiski pievienot, mainīt un dzēst:

  • rekvizīti;
  • vietējās komandas;
  • elementi.

Visas šīs darbības ir iespējamas tikai serverī.

Programmatiskajai pārveidošanai ir ierobežojumi:

  • Varat dzēst tikai programmatiski pievienoto informāciju/komandas/elementus. Konfiguratorā izveidotos objektus nevar programmatiski izdzēst.
  • Jūs nevarat piešķirt atribūtu kā galveno.

Veidlapu komandu maiņa

Lai pārvaldītu objekta komandu sastāvu ManagedForm ir kolekcija Komandas

    Pievienot (< ИмяКоманды >)

    Daudzums ()

    Atrast (< ИмяКоманды >)

    Dzēst (< Команда >)

Teams kolekcija ir pieejama gan klientā, gan serverī. Kolekciju (metodes Add() un Delete()) var mainīt tikai serverī. Varat meklēt un iegūt elementu skaitu (metodes Find () un Count ()) gan klientā, gan serverī.

Kā piemēru darbam ar veidlapu komandām izveidosim jaunu komandu ChangeHistory ar virsrakstu “ChangeHistory...”, kas izsauks apdarinātāju. DisplayHistory(). Izveidošana notiek, kad tiek atvērta veidlapa.

&Serverī
Procedūra KadCreatingOnServer (kļūme, standarta apstrāde)
Komanda = Komandas. Pievienot( "Izmaiņu vēsture");
Komanda . Darbība = ;
Komanda . Nosaukums = "Izmaiņu vēsture...";
Procedūras beigas
&OnClient
Procedūra Connectable_DisplayHistory(komanda)
// komandu darbības
Procedūras beigas

Komandu apstrādātājam ir jāatrodas veidlapā, un tam ir jābūt &OnClient kompilācijas direktīvai.

Veidlapas informācijas maiņa

Veidlapas detaļu kompozīcijas nolasīšanu veic funkcija Iegūstiet informāciju(< Путь >), atgriežot FormAttributes tipa masīvu. Funkcijas parametrs norāda ceļu uz vecāku atribūtu (kā virkni). Ja parametrs ir izlaists vai ir norādīta tukša virkne, tiek atgriezta augstākā līmeņa informācija.

Detaļu maiņa tiek veikta, izmantojot metodi Mainīt detaļas(<Pievienotas detaļas>, <Noņemamas detaļas>) objektu ManagedForm. Uz parametriem Pievienotas detaļas Un Noņemamas detaļas Tiek pārsūtīti masīvi ar Form Attributes tipa elementiem.

Uzmanību!

Detaļu kompozīcijas maiņas process ir diezgan resursietilpīgs. Veidlapa faktiski tiek atjaunota. Šajā sakarā darbs ar veidlapas detaļām tiek veikts pakešu režīmā.

Izveidosim jaunu formas atribūtu ar nosaukumu Pircējs:


AddedDetails = jauns masīvs;
Pievienotas detaļas. Pievienot(jauni veidlapas atribūti(“Pircējs”, Jauna tipa apraksts (“DirectoryLink. Darījuma partneri”), “Klients”));

// Detaļu kompozīcijas izmaiņas
);

Formas elementu maiņa

Lai kontrolētu objekta elementu sastāvu ManagedForm ir kolekcija Elementi. Kolekcijai ir vairākas metodes:

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

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

    Daudzums ()

    Atrast (< Имя >)

    Kustēties(< Элемент>, < Родитель>, < МестоРасположения >)

    Dzēst (< Элемент >)

Preču kolekcija ir pieejama gan klientā, gan serverī. Modificēt kolekciju (Ievietot metodes () , Pievienot () , Pārvietot () un Dzēst () ) ir pieejami tikai serverī. Varat meklēt un iegūt elementu skaitu (metodes Find () un Count ()) gan klientā, gan serverī. Kolekcijas elementi var būt:

  • FormGroup;
  • FormTable;
  • FormField;
  • Veidlapas poga.

Veidlapas elementiem varat programmatiski piešķirt notikumu apdarinātājus. Metode ir paredzēta šiem mērķiem SetAction(< ИмяСобытия>, < Действие >) .

Apskatīsim dažus no visbiežāk sastopamajiem piemēriem darbam ar komandām, detaļām un veidlapas elementiem.

Komandas un ar to saistītās pogas pievienošana:

// Izveidojiet komandu
Komanda = Komandas. Pievienot( "Izmaiņu vēsture");
Komanda . Darbība = "Plug-in_DisplayHistory"; // Veidlapā jābūt procedūrai ar norādīto nosaukumu
Komanda . Virsraksts = "Izmaiņu vēsture...";
// Izveidojiet pogu un saistiet to ar komandu
Elements = Preces. Pievienot( "Izmaiņu vēsture", Tips("FormButton" ));
Element.CommandName = "Izmaiņu vēsture";

Atribūta un saistītā ievades lauka pievienošana:

// Pievienotās informācijas apraksts
AddedDetails = jauns masīvs;
Pievienotas detaļas. Pievienot(Jaunas veidlapas rekvizīti (“Pircējs”, jauna veida apraksts ( "DirectoryLink. Darījuma partneri"), "Klients" ));
// Detaļu kompozīcijas maiņa
Mainīt detaļas (pievienota informācija);
// Ievades lauka izveide un savienošana ar atribūtiem
Elements = Preces. Add("Pircējs" , Tips("Veidlapas lauks" ));
Elements . Skats = FormFieldView. Ieejas lauks;
Elements . PathToData= "Pircējs" ;

Notikumu apstrādātāja piešķiršana veidlapas elementam:

PreceCustomer. SetAction("Kad tas mainās", "Connected_BuyerOnChange");

&OnClient
Procedūra Connected_BuyerOnChange(Elements)
// Pasākumu darbības
Procedūras beigas

Uzmanību!

Procedūras, kas tiek iestatītas kā notikumu apstrādātāji no koda, izmantojot metodi SetAction(), ieteicams iestatīt prefiksu Connectable_.

Uzmanību!

Varat lejupielādēt apstrādi ar programmatiskās meklēšanas piemēriem un pārvaldītās formas detaļu, komandu un elementu mainīšanu.

Veidlapas informācija

Veidlapas informācijas kopa apraksta veidlapā parādīto, rediģēto vai saglabāto datu sastāvu. Tajā pašā laikā pašas veidlapas detaļas nenodrošina iespēju attēlot un rediģēt datus. Veidlapas elementi (skatiet šīs nodaļas sadaļu “Veidlapas elementi”), kas saistīti ar veidlapas informāciju, tiek izmantoti attēlošanai un rediģēšanai. Visas veidlapas informācijas kopa tiks saukta par veidlapas datiem.

Svarīgs! Jāatceras, ka atšķirībā no parastajām formām visi dati pārvaldītajā formā ir jāapraksta detaļu veidā. Veidlapas moduļu mainīgos nav atļauts izmantot kā datu avotus veidlapas elementiem.

Ir iespējams piešķirt Veidlapas pamatinformācija, t.i., atribūti, kas noteiks formas standarta funkcionalitāti (veidlapas paplašinājums). Jāatceras, ka veidlapai var būt tikai viens galvenais atribūts.

Veidlapas paplašinājums– tie ir ManagedForm objekta papildu rekvizīti, metodes un formas parametri, kas raksturīgi objektam, kas ir formas galvenais elements.

Veidlapas izstrādes procesa laikā varat skaidri iestatīt iespēju skatīt un rediģēt konkrētu veidlapas informāciju lomu izteiksmē, izmantojot rekvizītus Skatīt un rediģēt (sīkāku informāciju skatiet sadaļas "Redaktori" sadaļā "Uz lomu veidlapas iestatījumi". ” nodaļa). Turklāt konkrēta atribūta pieejamību pašā formā var konfigurēt, izmantojot funkcionālās opcijas (sīkāku informāciju par funkcionālajām opcijām var atrast nodaļā “Konfigurācijas interfeisa pārvaldība”).

Veidlapas atribūta īpašums Saglabātie dati ir zīme, ka interaktīva detaļu maiņa novedīs pie mēģinājuma bloķēt veidlapas datus rediģēšanai, kā arī pie automātiskas formas modifikācijas karoga iestatīšanas.

Datu veidi pieejami pārvaldītā formā

Pārvaldītā veidlapa atšķiras no parastās arī ar to datu veidiem, ar kuriem tā darbojas. Ja parastā forma darbojas ar lielāko daļu veidu, ko nodrošina 1C: Enterprise (ieskaitot tipus DirectoryObject, DocumentObject utt.), tad pārvaldītajā formā var izdalīt šādas tipu kategorijas:

  • Veidlapā tieši izmantotie veidi ir tie veidi, kas pastāv plānā un Web klienta pusē (piemēram, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • veidi, kas tiks pārveidoti par īpašiem datu tipiem — pārvaldīto veidlapu datu tipi. Šādi veidi tiek parādīti veidlapas detaļu sarakstā iekavās, piemēram (DirectoryObject.Products);
  • dinamiskais saraksts (sīkāku informāciju skatiet šīs nodaļas sadaļā “Dinamiskais saraksts”).

Lietojumprogrammu objektu konvertēšana veidlapas datos

Daži lietojumprogrammu veidi (piemēram, DirectoryObject utt.) neeksistē plānā un tīmekļa klienta pusē (sīkāku informāciju skatiet sadaļā Pārvaldītās lietojumprogrammas koncepcija). Tāpēc, lai attēlotu šādus lietojumprogrammu veidus formā, platforma ir ieviesusi īpašus datu tipus, kas paredzēti darbam pārvaldītajās formās. Šī pārvaldītās lietojumprogrammas funkcija rada nepieciešamību pārveidot lietojumprogrammu objektus datu formā (un otrādi).

Tiek izmantoti šādi datu veidi:

  • Form DataStructure – satur patvaļīga tipa rekvizītu kopu. Rekvizīti var būt citas struktūras, kolekcijas vai struktūras ar kolekcijām. Šis tips ir attēlots, piemēram, formā DirectoryObject.
  • FormDataCollection ir drukātu vērtību saraksts, kas līdzīgs masīvam. Kolekcijas elementam var piekļūt, izmantojot indeksu vai identifikatoru. Dažos gadījumos piekļuve ar ID var nebūt pieejama. Tas ir saistīts ar lietojumprogrammas objekta veidu, ko pārstāv šī kolekcija. Identifikators var būt jebkurš vesels skaitlis. Šis tips ir attēlots, piemēram, tabulas daļas veidā.
  • Form DataStructureWithCollection ir objekts, kas vienlaikus tiek attēlots kā struktūra un kolekcija. To var uzskatīt par jebkuru no šīm vienībām. Šis tips apzīmē, piemēram, ierakstu kopu formā.
  • Form DataTree – objekts, kas paredzēts hierarhisku datu glabāšanai.

Lietojumprogrammas objektu attēlo viens vai vairāki formas datu elementi. Kopumā veidlapas datu hierarhija un sastāvs ir atkarīgs no pārvaldītās formas lietojumprogrammu objektu sarežģītības un savstarpējās savienojamības.

Piemēram, dokuments, kurā ir tabulas daļa, tiks attēlots ar FormDataStructure tipa objektu (pats dokuments), kuram ir pakārtots FormDataCollection tipa objekts (dokumenta tabulas daļa).

Svarīgs! Izstrādājot konfigurāciju, ir svarīgi atcerēties, ka lietojumprogrammu objekti ir pieejami tikai serverī, savukārt veidlapu datu objektus var izmantot gan serverī, gan klientā.

Datu pārsūtīšana starp pārvaldītās formas klienta un servera daļām

Faktiski mēs varam teikt, ka veidlapas dati ir vienots dažādu lietojumprogrammu objektu datu attēlojums, ar kuriem forma darbojas vienmērīgi un kuri atrodas gan serverī, gan klientā. Tas nozīmē, ka veidlapā ir noteikta lietojumprogrammas objektu datu “projicēšana” savu datu tipu veidā un, ja nepieciešams, tiek veikta starp tiem konvertēšana. Taču, ja konfigurācijas izstrādātājs ievieš savu datu apstrādes algoritmu, tad datu konvertēšana (no specializētajiem tipiem uz lietojumprogrammu tipiem un otrādi) viņam jāveic neatkarīgi.

Rediģējot veidlapas detaļas specializētā redaktorā (sīkāku informāciju skatīt nodaļas “Redaktori” sadaļā “Veidlapas detaļas”), iespējams ietekmēt datu pārsūtīšanu starp klientu un serveri, kamēr forma darbojas. Šim nolūkam tiek izmantota informācijas redaktora kolonna. Vienmēr lietojiet. Šī īpašuma ietekme atšķiras trīs veidu atribūtiem:

  • Atribūtam, kas pakārtots dinamiskam sarakstam (dinamiskā saraksta kolonna):
    • property enabled – atribūts vienmēr tiek nolasīts no datu bāzes un iekļauts formas datos;
    • rekvizīts ir atspējots - atribūts tiek nolasīts no datu bāzes un iekļauts veidlapas datos tikai tad, ja ir šobrīd redzams formas elements, kas saistīts ar atribūtu vai tā pakārtoto atribūtu.
  • Kustību kolekcijai pakārtotajiem rekvizītiem:
    • rekvizīts ir iespējots – dokumentu kustības tiek nolasītas no datu bāzes un būs klāt veidlapas datos;
    • rekvizīts ir atspējots - dokumentu kustības netiks nolasītas no datu bāzes un netiks iekļautas veidlapas datos (ja nav formas elementa, kas atsaucas uz dokumentu pārvietošanu).
  • Cita veidlapas informācija:
    • rekvizīts ir iespējots – atribūts būs klāt formas datos neatkarīgi no tā, vai ir vai nav vismaz viens formas elements, kas ir saistīts ar atribūtu vai tā pakārtoto atribūtu;
    • rekvizīts ir atspējots - atribūts formas datos būs tikai tad, ja ar atribūtu vai tā pakārtoto atribūtu ir saistīts formas elements. Atšķirībā no dinamiskā saraksta atribūtiem, ar atribūtu saistītā elementa redzamībai šeit nav nozīmes.

Piezīme. Jāatceras, ka vecāka atribūtam iestatītais rekvizīts ietekmē visus pakārtotos atribūtus. Piemēram, ja rekvizīts Use vienmēr tiek notīrīts dokumenta tabulas daļai, tad sistēma uzskata, ka šis rekvizīts tiek notīrīts arī visām pakārtotajām detaļām (neskatoties uz rekvizīta faktisko stāvokli).

Metodes lietojumprogrammu objektu datu konvertēšanai formas datos

Lai lietojumprogrammu objektus pārvērstu veidlapas datos un atpakaļ, ir globālu metožu kopa:

  • ValueInFormData(),
  • FormDataInValue(),
  • CopyFormData().

Svarīgs! Metodes, kas darbojas ar lietojumprogrammu objektiem, ir pieejamas tikai servera procedūrās. Vērtību kopēšanas metode starp veidlapas datiem ir pieejama serverī un klientā, jo tai nav nepieciešami lietojumprogrammu objekti kā parametri.

Pārvēršot veidlapas datus lietojumprogrammas objektā, jāņem vērā to saderība.

  • ValueInFormData() – pārvērš lietojumprogrammas tipa objektu formas datos;
  • FormDataInValue() – pārvērš veidlapas datus lietojumprogrammas tipa objektā;
  • CopyFormData() – kopē veidlapas datus, kuriem ir saderīga struktūra. Atgriež True, ja kopēšana bija veiksmīga, vai False, ja objekta struktūra nav saderīga.

Piezīme. Veicot standarta darbības (veidlapas atvēršana, standarta komandas Write izpilde u.c.) formā ar galvenajām detaļām, konvertēšana tiek veikta automātiski.

Sniegsim piemēru, kā izmantot datu transformāciju savos algoritmos.

&OnServerProcedure, kad CreateOnServer (kļūme, standarta apstrāde)

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

Procedūras beigas

&OnClient rakstīšanas procedūra()

WriteOnServer();

Procedūras beigas

&OnServer procedūra WriteOnServer()

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

Procedūras beigas

Objektam ManagedForm serverī ir pieejamas arī metodes:

  • ValueВFormAttribute() – pārvērš lietojumprogrammas tipa objektu norādītajā formas atribūtā.
  • FormAttributeVValue() – pārvērš formas datu atribūtu par lietojumprogrammas tipa objektu.

Šo metožu izmantošana parasti ir ērtāka, jo tajās ir, piemēram, informācija par veidlapas informācijas veidu. Turklāt metode Form AttributesValue() nosaka atbilstību starp formas datiem un objektu, kas tiek izmantots ziņojumu ģenerēšanai. Vairāk par to varat lasīt sadaļā “Pakalpojumu navigācijas iespējas”.

Sniegsim šo metožu izmantošanas piemēru.

&OnServer procedūra RecalculateOnServer()

// Pārvērš atribūtu Object par lietojumprogrammas objektu. Dokuments = Form AttributesValue("Objekts"); // Veic pārrēķinu, izmantojot dokumentu modulī definēto metodi. Document.Recalculate(); // Pārvērš lietojumprogrammas objektu atpakaļ par rekvizītu. ValueВFormAttributes (dokuments, “Objekts”);

Procedūras beigas

Programmatūras interfeiss

FormDataTree

  • FindById
  • GetItems

Apraksts:

Paredzēts, lai modelētu koku pārvaldītās formas datos.

Šo objektu var serializēt uz/no XDTO. Šim objektam atbilstošais XDTO tips ir definēts nosaukumvietā. XDTO tipa nosaukums:

GetItems

Sintakse:

GetItems ()

Atgriešanas vērtība:

Tips: Form DataCollection of Tree Elements.

Apraksts:

Iegūst augstākā līmeņa koku elementu kolekciju.

Pieejamība: klients, serveris, plāns klients, tīmekļa klients.

FindById

Sintakse:

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

Iespējas:

<Идентификатор>(obligāti)

Veids: numurs. Koka elementa identifikators.

Atgriešanas vērtība:

Tips: FormDataTreeElement.

Apraksts:

Iegūst kolekcijas elementu pēc ID.

Pieejamība: klients, serveris, plāns klients, tīmekļa klients.

FormDataTreeItem

Īpašības:

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

  • GetId (GetId)
  • GetParent
  • GetItems
  • Īpašums

Apraksts:

Veidlapas datu koka elements.

FormDataTreeItemCollection

Kolekcijas elementi: DataFormTreeElement

Objektam ir iespējams šķērsot kolekciju, izmantojot operatoru Katram... No... Cikls. Caurskatā tiek atlasīti kolekcijas elementi. Ir iespējams piekļūt kolekcijas elementam, izmantojot [...] operatoru. Elementa indekss tiek nodots kā arguments.

  • Ievietot
  • Pievienot
  • Indekss (IndexOf)
  • Skaitīt
  • Skaidrs
  • gūt
  • Kustēties
  • Dzēst

Apraksts:

Koka elementu kolekcija.

Pieejamība: klients, serveris, plāns klients, tīmekļa klients.

Skatīt arī:

  • FormDataTreeElement, GetElements metode
  • DataFormTree, metode GetItems

Iezīmes darbam ar vērtību koku

Koka atjauninājums

Ir problēma kritieni platformas, atjauninot koku.

Ja kāds mezgls kokā ir izvērsts un izvēlēts pakārtots mezgls, tad koku atjauninot ar funkciju ValueInFormData platforma nokrīt.

Risinājums: pirms atjaunināšanas ir jānotīra koks.

Piemēram:

&Servera procedūrā ClearTree(elements) Katram elementam no elementiem Loop ClearTree(element.GetElements()); EndCycle; elementi.Clear(); Procedūras beigas

&Servera procedūrā Aizpildiet jēdzienu koku() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Procedūras beigas

&OnClient procedūra OnDateOnChange(Element) Fill ConceptTree(); Procedūras beigas

Un datu pārsūtīšanas objekts koda strukturēšanai, kontrolēta forma 1C 8.2 vidē.

Ievads

Sāksim ar īsu jēdziena "pārvaldītā forma" un saistīto 1C platformas jēdzienu aprakstu. Platformas pazinēji var vēlēties izlaist šo sadaļu.

2008. gadā kļuva pieejama jauna platformas 1C versija: Enterprise 8.2 (turpmāk tekstā — pārvaldītā lietojumprogramma), kas pilnībā maina visu saskarnes darba slāni. Tas ietver komandu saskarni, veidlapas un logu sistēmu. Tajā pašā laikā mainās ne tikai lietotāja interfeisa izstrādes modelis konfigurācijā, bet arī tiek piedāvāta jauna arhitektūra funkcionalitātes nodalīšanai starp klienta lietojumprogrammu un serveri.
Pārvaldītā lietojumprogramma atbalsta šādus klientu veidus:

  • Biezais klients (parasts un pārvaldīts palaišanas režīms)
  • Plāns klients
  • Web klients
Pārvaldītajā lietojumprogrammā tiek izmantotas veidlapas, kas veidotas, izmantojot jaunu tehnoloģiju. Viņus sauc Pārvaldītās veidlapas. Lai atvieglotu pāreju, tiek atbalstītas arī iepriekšējās formas (tā sauktās regulārās formas), taču to funkcionalitāte nav attīstīta un tās ir pieejamas tikai biezā klienta palaišanas režīmā.
Galvenās pārvaldīto formu atšķirības izstrādātājam:
  • Deklaratīva, nevis “pikseļu pa pikseļa” struktūras apraksts. Konkrēto elementu izvietojumu sistēma veic automātiski, kad tiek parādīta forma.
  • Visa veidlapas funkcionalitāte ir aprakstīta kā detaļas Un komandas. Detaļas ir dati, ar kuriem veidlapa darbojas, un komandas ir veicamās darbības.
  • Veidlapa darbojas gan serverī, gan klientā.
  • Klienta kontekstā gandrīz visi lietojumprogrammu veidi nav pieejami, un attiecīgi nav iespējams mainīt datus informācijas bāzē.
  • Katrai metodei vai formas mainīgajam tas ir jānorāda apkopošanas direktīva, definējot izpildes vietu (klientu vai serveri) un piekļuvi veidlapas kontekstam.
Uzskaitīsim norādījumus veidlapu metožu sastādīšanai:
  • &OnClient
  • &Serverī
  • &OnServerBez konteksta
  • &OnClientOnServerBez konteksta
Ļaujiet mums ilustrēt iepriekš minēto. Ekrānuzņēmumā ir parādīts pārvaldītas formas un tās moduļa piemērs izstrādes režīmā. Atrodiet deklaratīvo aprakstu, rekvizītus, apkopošanas norādījumus utt.

Visas turpmākās diskusijas būs par ilustrācijas labo pusi, par to, kā strukturēt moduļa kodu un kādi principi ļaus īstenot efektīvu klienta-servera mijiedarbību.

Definēsim problēmu

Ir pagājuši vairāki gadi, kopš aktīvi tiek izmantota jaunā 1C platformas versija, un gan 1C, gan tā daudzie partneri ir izlaiduši daudzus risinājumus (konfigurācijas).
Vai šajā laikā izstrādātājiem ir izveidojusies vienota izpratne par klienta un servera mijiedarbības principiem, veidojot formas, un vai jaunajās arhitektūras realitātēs ir mainījusies pieeja programmatūras moduļu ieviešanai?

Apskatīsim koda struktūru (veidlapas moduli) vairākās vienas standarta konfigurācijas formās un mēģināsim atrast modeļus.
Ar struktūru mēs domājam koda sadaļas (visbiežāk tie ir komentāru bloki), ko izstrādātājs ir piešķīris šo metožu grupu metožu un kompilācijas direktīvām.
1. piemērs:
Notikumu apstrādātāju sadaļa Metode - uz klienta Metode - uz servera Metode - uz klienta Servisa procedūru un funkciju sadaļa Ievades palīgfunkcijas
2. piemērs:
Pakalpojuma procedūras un funkcijas Maksājumu dokumenti Vērtības Notikumu apstrādātāji
3. piemērs:
Servisa procedūras serverī Servisa procedūras klientam Servisa procedūras serverī bez konteksta Galvenes notikumu apstrādātāji komandu notikumu apstrādātāji
4. piemērs:
Vispārējas nozīmes procedūras Veidlapu notikumu apstrādātāji “Kontaktinformācijas” apakšsistēmas procedūras
Būtībā trūkst koda struktūras vai, maigi izsakoties, tā ir līdzīga tai, kas bija Forms 8.1:

  • Neinformatīvi vārdi “Vispārīgi, Serviss, Palīgs”.
  • Kautrīgi mēģinājumi nodalīt klienta un servera metodes.
  • Metodes bieži tiek grupētas pēc saskarnes elementiem “Darbs ar tabulas daļu Produkti, Kontaktinformācija”.
  • Patvaļīga metožu un kodu grupu sakārtošana. Piemēram, notikumu apdarinātāji var būt augšā vienā formā, apakšā citā, bet trešajā vispār nav izcelti utt.
  • Un neaizmirsīsim, ka tas viss ir vienā konfigurācijā.
  • Jā, ir konfigurācijas, kurās vārdi “General, Service, Auxiliary” vienmēr ir vienās un tajās pašās vietās, bet...
Kāpēc jums ir nepieciešama koda struktūra?
  • Apkopes vienkāršošana.
  • Vienkāršojiet mācīšanos.
  • Vispārīgo/svarīgo/veiksmīgo principu pierakstīšana.
  • ...jūsu variants
Kāpēc nepalīdz esošais izstrādes standarts no 1C?
Apskatīsim ITS diskos un dažādos “Izstrādātāju ceļvežos...” publicētos principus, kas ir ieteicami, rakstot pārvaldītu formu.
  • Samaziniet servera zvanu skaitu.
  • Maksimālais skaitļošanas apjoms serverī.
  • Nekontekstuālie servera izsaukumi ir ātrāki nekā kontekstuālie izsaukumi.
  • Programma ar klienta un servera saziņu prātā.
  • un tā tālāk.
Tie ir saukļi, kas ir absolūti patiesi, bet kā tos īstenot? Kā samazināt zvanu skaitu, ko nozīmē programmēt klients-servera režīmā?

Dizaina modeļi vai paaudžu gudrība

Klienta un servera mijiedarbība dažādās programmatūras tehnoloģijās ir izmantota gadu desmitiem. Atbilde uz iepriekšējā sadaļā izklāstītajiem jautājumiem ir zināma jau sen un ir apkopota divos pamatprincipos.
  • Tālvadības fasāde(turpmāk tekstā kā attālās piekļuves interfeiss)
  • Datu pārsūtīšanas objekts(turpmāk Datu pārsūtīšanas objekts)
Vārds no Martina Faulera, viņa apraksta par šiem principiem:
  • Katram objektam, kas potenciāli paredzēts attālinātai piekļuvei, ir jābūt zemas precizitātes interfeiss, kas samazinās zvanu skaitu, kas nepieciešams noteiktas procedūras veikšanai. ... Tā vietā, lai pieprasītu rēķinu un visas tā preces atsevišķi, jums ir jāizlasa un jāatjaunina visas rēķina pozīcijas vienā pieprasījumā. Tas ietekmē visu objekta struktūru...Atcerieties: attālās piekļuves interfeiss nesatur domēna loģiku.
  • ...ja es būtu gādīga mamma, noteikti savam bērnam teiktu: "Nekad nerakstiet datu pārraides objektus!" Vairumā gadījumu datu pārraides objekti ir nekas vairāk kā uzpūsts lauka komplekts... Šī pretīgā briesmoņa vērtība slēpjas tikai iespējamībā vienā zvanā pārsūtīt vairākas informācijas daļas tīklā- metode, kas ir ļoti svarīga izplatītajām sistēmām.
1C platformas veidņu piemēri
Lietojumprogrammu saskarnē, kas izstrādātājam pieejama, izstrādājot pārvaldītu veidlapu, ir daudz šo principu piemēru.
Piemēram, OpenForm() metode, tipiska “aptuvena” saskarne.
OpeningParameters = New Structure("Parametrs1, Parametrs2, Parametrs3", Vērtība1, Vērtība2, Vērtība3); Form = OpenForm(FormName, OpeningParameters);
Salīdziniet ar stilu, kas pieņemts v8.1.
Form = GetForm(FormName); Form.Parameter1 = Vērtība1; Form.Parameter2 = Vērtība2; Form.Open();

Pārvaldītās veidlapas kontekstā ir daudz “datu pārsūtīšanas objektu”. Jūs varat izvēlēties sistēmisks Un izstrādātāja definēts.
Sistēmas modelē lietojumprogrammas objektu klientam viena vai vairāku formas datu elementu veidā. Tos nav iespējams izveidot bez atsauces uz veidlapas detaļām.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Sistēmas datu pārsūtīšanas objektu konvertēšana uz lietojumprogrammu veidiem un otrādi tiek veikta, izmantojot šādas metodes:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Pielāgojot esošu risinājumu, bieži tiek izmantota skaidra konvertēšana. Metodes var sagaidīt (izmantot līdzekļus) ievades parametrus, piemēram, ValueTable, nevis FormDataCollection, vai arī metode ir definēta lietojumprogrammas objekta kontekstā un ir kļuvusi nepieejama tiešam izsaukumam no veidlapas.
1C v8.1 piemērs:
// klientam veidlapas FillUserCache(DepartmentLink) kontekstā
1C v8.2 piemērs:
// serverī veidlapas ProcessingObject = Form AttributesValue("Object") kontekstā; ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Datu pārsūtīšanas objekti, kuru struktūru nosaka izstrādātājs, ir neliela to veidu apakškopa, kas ir pieejami gan klientā, gan serverī. Visbiežāk kā “rupjā” saskarnes metožu parametri un rezultāti tiek izmantoti:

  • Primitīvie veidi (virkne, skaitlis, Būla)
  • Struktūra
  • Sarakste
  • Masīvs
  • Saites uz lietojumprogrammu objektiem (unikāls identifikators un teksta attēlojums)
Piemērs: metode pieņem pasūtījumu sarakstu, lai mainītu statusu, un atgriež klientam kļūdu aprakstu.
&OnServerWithoutContext Funkcija ServerChangeOrderStatus(Pasūtījumi, JaunsStatuss) Errors = New Match(); // [pasūtījums][kļūdas apraksts] Katram pasūtījumam no pasūtījumiem Cycle StartTransaction(); Izmēģiniet DocOb = Order.GetObject(); …. citas darbības, kas iespējamas ne tikai ar pasūtījumu... Izņēmums CancelTransaction(); Errors.Insert(Pasūtījums, KļūdasApraksts()); EndAttempt; EndCycle; Atgriešanas kļūda; EndFunction // ServerChangeOrderStatus()

Koda strukturēšana

Galvenie mērķi, kas jāatspoguļo pārvaldītās formas modulī, un pieejas risinājumam.
  • Skaidra klienta un servera koda atdalīšana. Neaizmirsīsim, ka izpildes brīdī tie ir divi mijiedarbīgi procesi, kuriem katram ir ievērojami atšķirīga pieejamā funkcionalitāte.
  • Skaidra attālās piekļuves saskarnes identifikācija, kuras servera metodes var izsaukt no klienta un kuras nevar? Attālās saskarnes metožu nosaukumi sākas ar prefiksu "Serveris". Tas ļauj uzreiz redzēt kontroles nodošanu serverim, lasot kodu, un vienkāršo kontekstuālās palīdzības izmantošanu. Ņemiet vērā, ka oficiālais ieteikums (ITS) iesaka nosaukšanas metodes ar postfixes, piemēram, ChangeOrderStatusOnServer(). Tomēr mēs atkārtojam, ka ne visas servera metodes var izsaukt no klienta, un tāpēc svarīgāka ir loģiskā pieejamība, nevis kompilācijas vieta. Tāpēc ar prefiksu “Server” mēs atzīmējam tikai klientam pieejamās metodes; paraugmetodi sauksim ServerChangeOrderStatus().
  • Lasāmība. Gaumes lieta, mēs pieņemam pasūtījumu, kad modulis sākas ar veidlapas izveides procedūrām serverī un attālās piekļuves metodēm.
  • Uzturamība. Jauna koda pievienošanai ir jābūt skaidrai vietai. Svarīgi ir tas, ka konfiguratora automātiski izveidotās metožu veidnes tiek pievienotas moduļa beigām. Tā kā veidlapas elementu notikumu apdarinātāji visbiežāk tiek izveidoti automātiski, attiecīgais bloks atrodas pēdējais, lai katru apdarinātāju nepārvilktu uz citu moduļa vietu.
Zemāk ir norādīta moduļa pamatstruktūra, kas īsteno uzskaitītos mērķus.
  • Grafiskā iespēja – skaidri parāda galveno izpildes plūsmu.
  • Teksta opcija ir veidnes dizaina piemērs struktūras ātrai ievietošanai jaunā veidlapas modulī.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datums=""/> // <Описание> // // ////////////////////////////////////////////////// /////////////////////////// // MODUĻA MAINĪGIE ////////////////// // /////////////////////////////////////////////////// ////////// // SERVERĀ //******* NOTIKUMI SERVERĀ ******* &Par servera procedūru, kad tiek izveidota serverī (kļūme, standarta apstrāde) / /Ievietot apdarinātāja saturu Procedūras beigas //******* TĀLĀS PIEKĻUVES INTERFESS ******* //******** BIZNESA LOĢIKA SERVERĀ ******* /////////////////////////////////////////////////// /////// //////////////////// // KOPĒJĀS KLIENTA UN SERVERA METODES //////////////// /////// //////////////////////////////////////////// ///// //////// // PAR KLIENTU //******* BIZNESA LOĢIKA KLIENTA ****** //******** KOMANDA * ****** //******** KLIENTU PASĀKUMI ******* /////////////////////////// ///// ////////////////////////////////////////////// // / / GALVENIE PROGRAMMU OPERATORI

Saistīti jautājumi
Noslēgumā iezīmēsim vairākas jomas, par kurām ir lietderīgi padomāt, programmējot klienta-servera mijiedarbību.
  • Attālās piekļuves interfeisa ieviešanas iespējas. Asinhronija, detalizācijas pakāpe...
  • Kešatmiņa. 1C pieņēma neveiksmīgu arhitektūras lēmumu, ieviešot kešatmiņu tikai parasto moduļu izsaukšanas metožu līmenī un nenodrošinot vadības iespējas (atbilstības laiks, atiestatīšana pēc pieprasījuma).
  • Netieši servera izsaukumi. Neaizmirstiet par tehnoloģiskajām iezīmēm, daudzas klienta “nekaitīgas” darbības provocē platformu sazināties ar serveri.

Veidlapu kontrolē, izmantojot dažādus veidlapas elementus, kas cilnē atrodas hierarhiski Elementi formu dizainers. Vissvarīgākais elements ir pati forma, kas atrodas elementu hierarhijas augšgalā, un pārējie elementi ir tai pakārtoti.

Visus formas elementus var iedalīt piecās grupās: lauki, grupēšanas elementi, pogas, dekorācijas un tabulas. Savos rakstos es analizēšu katru no grupām. Šajā rakstā mēs sāksim pētīt vienu no lauka elementu veidiem - ievades lauks, bet pirms tam mēs uzzināsim, kā veidlapai pievienot elementu.

Elementu pievienošana veidlapai

Tas tiek darīts pavisam vienkārši: jums ir jāizvēlas elements Veidlapa logā Form Design Elements un noklikšķiniet uz pogas "Pievienot". Pēc tam tiks atvērts logs, kurā jums jāizvēlas vēlamais elementa veids

Pēc atlases logā parādīsies vēlamais elements Elementi.

Pārvaldītās formas elements Lauks

Apskatīsim pārvaldītās formas elementu Lauks. Šis elements ir nepieciešams, lai veidlapā ievadītu informāciju. Un arī, lai parādītu jebkādu informāciju. Pēc šī elementa pievienošanas formai labajā pusē tiks atvērta formas elementa rekvizītu palete. Pagaidām jūs interesē divi rekvizīti – DataPath un View.

Rekvizītā DataPath izstrādātājs var saistīt formas elementu ar vēlamo formas atribūtu. Lūdzu, ņemiet vērā, ka pēc elementa pievienošanas Ieejas lauks veidlapā tas netika parādīts pašā veidlapā. Tas notika tāpēc, ka mūsu jaunais elements nav saistīts ar . Piemēram, apstrādes formā es izveidoju vairākus atribūtus ar dažādiem primitīvajiem tipiem un vienu atribūtu ar atsauces veidu.

Tagad savienosim mūsu nesen pievienoto veidlapas elementu ar kādu no detaļām. Lai to izdarītu, elementa rekvizītā PathKData atlasiet vajadzīgo atribūtu.

Pēc tam tiks aizpildīti DataPath un View rekvizīti, un pats elements tiks parādīts veidlapas skatā.

Pievērsiet uzmanību elementa īpašībām Skatīt. Šis rekvizīts nosaka ievades lauka funkcionalitāti. Šim īpašumam varat izvēlēties dažādas vērtības.

Atkarībā no izvēlētās vērtības tiks noteikta funkcionalitāte. Iepriekš esošajos attēlos izvēlētā vērtība ir - ievades lauks, t.i. mēs varam ievadīt jebkuras vērtības šajā ievades laukā, un, ja mēs atlasām vērtību etiķetes lauks, tad mēs nevarēsim neko ievadīt.

Šī īpašuma vērtība Skatīt Ievades laukus ir ērti izvēlēties, kad lietotājam vienkārši jāparāda palīdzības informācija.

Tagad pievienosim jaunu formas elementu ar veidu Ieejas lauks un savienojiet to ar balstiem Sīkāka informācijaDatums izmantojot mums jau pazīstamo DataPath rekvizītu

Kā redzat, ievades lauka izskats ir mainījies, un mainīsies arī rekvizīta View iespējamā vērtību atlase.

Tādējādi mēs secinām, ka ievades lauka funkcionalitāte ir atkarīga no atribūta veida.

Par rekvizītus ar tipu Būla Būs pieejamas tālāk norādītās View rekvizītu vērtības.

Un atribūtiem ar atsauces veidu būs pieejamas citas rekvizīta View vērtības.

Detalizētāks darbs ar formas elementiem, izmantojot praktiskus piemērus, ir sniegts grāmatā “Attīstības pamati 1C: Taxi. Pārvaldīta lietojumprogrammu izstrāde 12 soļos".

Dažreiz šķiet, ka programmēšanas valodas apguve 1C ir sarežģīta un sarežģīta. Patiesībā programmēšana 1C formātā ir vienkārša. Manas grāmatas palīdzēs ātri un viegli apgūt programmēšanu 1C: un “Attīstības pamati 1C: Taxi”

Apgūstiet programmēšanu 1C, izmantojot manu grāmatu “Programmēšana 1C 11 soļos”

  1. Nav sarežģītu tehnisku terminu.
  2. Vairāk nekā 700 lappušu praktiska materiāla.
  3. Katram uzdevumam ir pievienots zīmējums (ekrānuzņēmums).
  4. Mājasdarbu uzdevumu krājums.
  5. Grāmata uzrakstīta skaidrā un vienkāršā valodā – iesācējam.

Šī grāmata ir piemērota tiem, kuri jau ir sākuši programmēt un saskaras ar zināmām grūtībām saistībā ar šo tēmu, kā arī tiem, kuri programmējuši jau ilgu laiku, bet nekad nav strādājuši ar 1C pārvaldītajām formām.

  1. Bez sarežģītiem tehniskiem terminiem;
  2. Vairāk nekā 600 lappušu praktiska materiāla;
  3. Katram piemēram ir pievienots zīmējums (ekrānuzņēmums);
  4. Grāmata tiek nosūtīta pa e-pastu PDF formātā. Var atvērt jebkurā ierīcē!

Reklāmas kods 15% atlaidei - 48PVXHeYu


Ja šī nodarbība jums palīdzēja atrisināt kādu problēmu, jums tā patika vai noderēja, tad varat atbalstīt manu projektu, ziedojot jebkuru summu:

Jūs varat maksāt manuāli:

Yandex.Money - 410012882996301
Tīmekļa nauda — R955262494655

Pievienojieties manām grupām.