Grunnleggende detaljer om skjemaet. Administrerte skjemadetaljer (1Cv8) 1c administrerte skjemaer legger til detaljer programmatisk
Skjemadetaljer
Et sett med skjemadetaljer beskriver sammensetningen av dataene som vises, redigeres eller lagres i skjemaet. Samtidig gir ikke selve skjemadetaljene muligheten til å vise og redigere data. Skjemaelementer (se delen "Skjemaelementer" i dette kapittelet) knyttet til skjemadetaljer brukes til visning og redigering. Settet med alle skjemadetaljer vil bli kalt skjemadata.
Viktig! Det må huskes at, i motsetning til vanlige skjemaer, må alle data i et administrert skjema beskrives i form av detaljer. Det er ikke tillatt å bruke skjemamodulvariabler som datakilder for skjemaelementer.
Det er mulig å tildele Grunnleggende skjemadetaljer, dvs. attributter som vil bestemme standardfunksjonaliteten til skjemaet (skjemautvidelse). Det bør huskes at et skjema bare kan ha ett hovedattributt.
Skjemautvidelse– dette er tilleggsegenskaper, metoder og skjemaparametere til ManagedForm-objektet, karakteristiske for objektet som er hovedelementet i skjemaet.
Under skjemautviklingsprosessen kan du eksplisitt angi muligheten til å vise og redigere spesifikke skjemadetaljer, når det gjelder roller, ved å bruke egenskapene Vis og Rediger (for mer informasjon, se delen "Rollebaserte skjemainnstillinger" i "Redaktører" ” kapittel). I tillegg kan tilgjengeligheten til et bestemt attributt i selve skjemaet konfigureres ved hjelp av funksjonelle alternativer (mer informasjon om funksjonelle alternativer finnes i kapittelet "Konfigurasjonsgrensesnittadministrasjon").
Skjemaattributt egenskap Lagrede data er et tegn på at en interaktiv endring i detaljene vil føre til et forsøk på å blokkere skjemadataene for redigering, samt til automatisk innstilling av skjemamodifikasjonsflagget.
Datatyper tilgjengelig i administrert form
Et administrert skjema skiller seg også fra et vanlig skjema i hvilke typer data det fungerer med. Hvis normalformen fungerer med de fleste typene som 1C:Enterprise tilbyr (inkludert typene DirectoryObject, DocumentObject, etc.), kan følgende kategorier av typer skilles i det administrerte skjemaet:
- typer som brukes direkte i skjemaet er de typene som finnes på siden av tynn- og webklienten (for eksempel Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
- typer som vil bli konvertert til spesielle datatyper – administrerte skjemadatatyper. Slike typer vises i listen over skjemadetaljer i parentes, for eksempel (DirectoryObject.Products);
- dynamisk liste (for mer informasjon, se delen "Dynamisk liste" i dette kapittelet).
Konvertering av applikasjonsobjekter til skjemadata
Noen applikasjonstyper (som DirectoryObject osv.) eksisterer ikke på tynn- og webklientsiden (se kapittelet Managed Application Concept for flere detaljer). Derfor, for å representere slike applikasjonstyper i skjemaet, har plattformen introdusert spesielle datatyper designet for å fungere i administrerte skjemaer. Denne funksjonen til en administrert applikasjon gjør det nødvendig å konvertere applikasjonsobjekter til skjemadata (og omvendt).
Følgende datatyper brukes:
- Form DataStructure – inneholder et sett med egenskaper av en vilkårlig type. Egenskaper kan være andre strukturer, samlinger eller strukturer med samlinger. Denne typen er representert for eksempel i skjemaet DirectoryObject.
- En FormDataCollection er en liste over innskrevne verdier som ligner på en matrise. Et samlingselement er tilgjengelig med indeks eller identifikator. Tilgang med ID er kanskje ikke tilgjengelig i noen tilfeller. Dette er på grunn av typen applikasjonsobjekt som er representert av denne samlingen. Identifikatoren kan være et hvilket som helst heltall. Denne typen er representert for eksempel i form av en tabelldel.
- Form DataStructureWithCollection er et objekt som er representert som en struktur og en samling på samme tid. Det kan behandles som alle disse enhetene. Denne typen representerer for eksempel et sett med poster i et skjema.
- Form DataTree – et objekt designet for å lagre hierarkiske data.
Et applikasjonsobjekt er representert av enten ett eller flere skjemadataelementer. Generelt avhenger hierarkiet og sammensetningen av skjemadata av kompleksiteten og sammenkoblingen av applikasjonsobjektene til det administrerte skjemaet.
For eksempel vil et dokument som inneholder en tabelldel representeres av et objekt av typen FormDataStructure (selve dokumentet), som et objekt av typen FormDataCollection (tabelldelen av dokumentet) er underordnet.
Viktig! Når du utvikler en konfigurasjon, er det viktig å huske at applikasjonsobjekter kun er tilgjengelige på serveren, mens skjemadataobjekter kan brukes både på serveren og klienten.
Sende data mellom klient- og serverdelen av et administrert skjema
Faktisk kan vi si at skjemadata er en enhetlig representasjon av data fra ulike applikasjonsobjekter som skjemaet fungerer jevnt med og som finnes både på serveren og klienten. Det vil si at skjemaet inneholder noen "projeksjon" av applikasjonsobjektdata i form av egne datatyper og utfører konvertering mellom dem om nødvendig. Imidlertid, hvis konfigurasjonsutvikleren implementerer sin egen databehandlingsalgoritme, må han utføre datakonvertering (fra spesialiserte typer til applikasjonstyper og omvendt) uavhengig.
Når du redigerer skjemadetaljer i en spesialisert editor (for flere detaljer, se delen "Skjemadetaljer" i kapittelet "Redaktører"), er det mulig å påvirke overføringen av data mellom klienten og serveren mens skjemaet kjører. Kolonnen til detaljredaktøren brukes til dette. Bruk alltid. Effekten av denne egenskapen er forskjellig for tre typer attributter:
- For et attributt underordnet en dynamisk liste (dynamisk listekolonne):
- egenskap aktivert – attributtet leses alltid fra databasen og inkluderes i skjemadataene;
- egenskapen er deaktivert - attributtet leses fra databasen og inkluderes i skjemadataene bare når det er et synlig skjemaelement knyttet til attributtet eller dets underordnede attributt.
- For rekvisitter underordnet bevegelsessamlingen:
- egenskapen er aktivert – dokumentbevegelser leses fra databasen og vil være til stede i skjemadataene;
- egenskapen er deaktivert - dokumentbevegelser vil ikke bli lest fra databasen og vil ikke inkluderes i skjemadataene (hvis det ikke er noe skjemaelement som refererer til dokumentbevegelser).
- Andre skjemadetaljer:
- egenskapen er aktivert – attributtet vil være til stede i skjemadataene, uavhengig av om det er minst ett skjemaelement som er knyttet til attributtet eller dets underordnede attributt;
- egenskapen er deaktivert - attributtet vil bare være til stede i skjemadataene hvis det er et skjemaelement knyttet til attributtet eller dets underordnede attributt. I motsetning til dynamiske listeattributter, spiller ikke synligheten til elementet knyttet til attributtet noen rolle her.
Merk. Det bør huskes at egenskapen satt på overordnet attributt påvirker alle underordnede attributter. For eksempel, hvis Bruk-egenskapen alltid er ryddet for den tabellformede delen av dokumentet, vurderer systemet at denne egenskapen også er ryddet for alle underordnede detaljer (til tross for den faktiske tilstanden til eiendommen).
Metoder for å konvertere applikasjonsobjektdata til skjemadata
For å konvertere applikasjonsobjekter til skjemadata og tilbake, er det et sett med globale metoder:
- ValueInFormData(),
- FormDataInValue(),
- CopyFormData().
Viktig! Metoder som fungerer med applikasjonsobjekter er bare tilgjengelige i serverprosedyrer. Metoden for å kopiere verdier mellom skjemadata er tilgjengelig på serveren og på klienten, siden den ikke krever applikasjonsobjekter som parametere.
Når du konverterer skjemadata til et applikasjonsobjekt, må du vurdere deres kompatibilitet.
- ValueInFormData() – konverterer et applikasjonstypeobjekt til skjemadata;
- FormDataInValue() – konverterer skjemadata til et applikasjonstypeobjekt;
- CopyFormData() – kopierer skjemadata som har en kompatibel struktur. Returnerer True hvis kopieringen var vellykket, eller False hvis objektstrukturen er inkompatibel.
Merk. Når du utfører standardhandlinger (åpner et skjema, utfører en standard skrivekommando, etc.) av et skjema med hoveddetaljene, utføres konverteringen automatisk.
La oss gi et eksempel på hvordan du bruker datatransformasjon i dine egne algoritmer.
ObjectProduct = Directories.Products.FindByName("Kaffekanne").GetObject(); ValueInFormData(ObjectItem, Object);
Slutt på prosedyre
&OnClient Prosedyre Write()
WriteOnServer();
Slutt på prosedyre
&OnServer-prosedyre WriteOnServer()
ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();
Slutt på prosedyre
ManagedForm-objektet har også metoder tilgjengelig på serveren:
- ValueВFormAttribute() – konverterer et applikasjonstypeobjekt til det angitte skjemaattributtet.
- FormAttributeVValue() – konverterer et skjemadataattributt til et objekt av en applikasjonstype.
Å bruke disse metodene er vanligvis mer praktisk, siden de for eksempel har informasjon om typen skjemadetaljer. I tillegg setter Form AttributesValue()-metoden samsvaret mellom skjemadataene og objektet, som brukes når meldinger genereres. Du kan lese mer om dette i kapitlet "Tjenestenavigasjonsfunksjoner".
La oss gi et eksempel på bruk av disse metodene.
// Konverterer Object-attributtet til et applikasjonsobjekt. Document = Form AttributesValue("Objekt"); // Utfører omberegning ved hjelp av metoden definert i dokumentmodulen. Document.Recalculate(); // Konverterer applikasjonsobjektet tilbake til en prop. ValueВFormAttributes(Dokument, "Objekt");
Slutt på prosedyre
Programvaregrensesnitt
FormDataTree
- FinnById
- GetItems
Beskrivelse:
Designet for å modellere et tre i administrerte skjemadata.
Dette objektet kan serialiseres til/fra XDTO. XDTO-typen som tilsvarer dette objektet er definert i navneområdet. XDTO-typenavn:
GetItems
Syntaks:
GetItems()
Returverdi:
Type: Skjema Datasamling av treelementer.
Beskrivelse:
Får en samling treelementer på toppnivå.
Tilgjengelighet: klient, server, tynnklient, webklient.
FinnById
Syntaks:
FindById(<Идентификатор>)
Alternativer:
<Идентификатор>(obligatorisk)
Type: Antall. Treelementidentifikator.
Returverdi:
Type: FormDataTreeElement.
Beskrivelse:
Får et samlingselement etter ID.
Tilgjengelighet: klient, server, tynnklient, webklient.
FormDataTreeItem
Egenskaper:
<Имя свойства> (<Имя свойства>)
- GetId (GetId)
- GetParent
- GetItems
- Eiendom
Beskrivelse:
Skjemadatatreelement.
FormDataTreeItemCollection
Samlingselementer: DataFormTreeElement
For et objekt er det mulig å krysse samlingen ved å bruke operatoren For hver... Fra... Loop. Traverseringen velger elementene i samlingen. Det er mulig å få tilgang til et samlingselement ved å bruke [...]-operatøren. Indeksen til elementet sendes som et argument.
- Sett inn
- Legg til
- Indeks (IndexOf)
- Telle
- Klar
- Få
- Bevege seg
- Slett
Beskrivelse:
Samling av treelementer.
Tilgjengelighet: klient, server, tynnklient, webklient.
Se også:
- FormDataTreeElement, GetElements-metoden
- DataFormTree, metode GetItems
Funksjoner ved å jobbe med et verditre
Treoppdatering
Det er et problem faller plattformer ved oppdatering av treet.
Hvis en node i treet har blitt utvidet og en underordnet node er valgt, så når du oppdaterer treet med funksjonen ValueInFormData plattformen faller.
Løsning: Du må tømme treet før du oppdaterer.
For eksempel:
&På serverprosedyren ClearTree(elements) For hvert element fra elementene Loop ClearTree(element.GetElements()); EndCycle; elementer.Clear(); Slutt på prosedyre
&På serverprosedyren Fyll konsepttre() dConcepts = srProperties.Byg konsepttre(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Slutt på prosedyre
&OnClient-prosedyre OnDateOnChange(Element) Fill ConceptTree(); Slutt på prosedyre
1C:Enterprise-plattformen lar deg legge til og endre elementer i et administrert skjema programmatisk. La oss finne ut hvorfor dette kan være nødvendig.
Programvareendring av skjemaet kan være nødvendig i flere tilfeller:
- Ved ferdigstillelse av standardkonfigurasjoner for å lette den påfølgende oppdateringsprosedyren. I dette tilfellet vil bare skjemamodulen bli endret. Moduler er mye enklere å oppdatere enn skjemaer.
- Når du implementerer noen vanlige algoritmer. For eksempel, i undersystemet «Forbud mot redigering av objektdetaljer», kan en knapp opprettes programmatisk for alle objekter som er koblet til undersystemet for å aktivere muligheten til å redigere detaljer.
- Når du implementerer noen spesifikke algoritmer. For eksempel, i nomenklaturkatalogen, opprettes felt for redigering av tilleggsdetaljer.
I et administrert skjema kan du programmatisk legge til, endre og slette:
- nødvendigheter;
- lokale lag;
- elementer.
Alle disse operasjonene er kun mulig på serveren.
Programmatisk omforming har begrensninger:
- Du kan bare slette programmert lagt til detaljer/kommandoer/elementer. Du kan ikke programmere slette objekter som er opprettet i konfiguratoren.
- Du kan ikke tilordne et attributt som hovedattributt.
Endre skjemakommandoer
For å administrere sammensetningen av kommandoer for et objekt ManagedForm det er en samling Lag
Legg til (< ИмяКоманды >)
Mengde ()
Finne (< ИмяКоманды >)
Slett (< Команда >)
Teams-samlingen er tilgjengelig på både klienten og serveren. Du kan endre samlingen (Add() og Delete()-metodene bare på serveren. Du kan søke etter og få antall elementer (Finn () og Count () metodene) både på klienten og på serveren.
Som et eksempel på arbeid med skjemakommandoer, la oss lage en ny ChangeHistory-kommando med overskriften "ChangeHistory...", som vil kalle opp behandleren Vis historikk(). Opprettelsen skjer når skjemaet åpnes.
&På server
Fremgangsmåte WhenCreatingOnServer(Failure, StandardProcessing)
Team = Lag. Legg til( "Endringers historie");
Team . Handling = ;
Team . Tittel = "Endringers historie...";
Slutt på prosedyre
&På klient
Fremgangsmåte Connectable_DisplayHistory(Command)
// kommando handlinger
Slutt på prosedyre
Kommandobehandleren må være plassert på et skjema og ha et &OnClient-kompileringsdirektiv.
Endring av skjemadetaljer
Lesing av sammensetningen av skjemadetaljene utføres av funksjonen Få detaljer(< Путь >) returnerer en matrise av typen FormAttributes. Funksjonsparameteren spesifiserer banen til det overordnede attributtet (som en streng). Hvis parameteren utelates eller en tom streng er spesifisert, returneres toppnivådetaljene.
Endring av detaljene gjøres ved hjelp av metoden Endre detaljer(<Lagt til detaljer>, <Avtakbare detaljer>) gjenstand ManagedForm. Til parametere Lagt til detaljer Og Avtakbare detaljer Matriser med elementer av typen Form Attributes blir overført.
Merk følgende!
Prosessen med å endre sammensetningen av detaljer er ganske ressurskrevende. Skjemaet blir faktisk gjenskapt. I denne forbindelse utføres arbeid med skjemadetaljer i batchmodus.
La oss lage et nytt skjemaattributt med navnet Kjøper:
AddedDetails = New Array;
Lagt til detaljer. Legg til (Nye skjemaattributter("Kjøper", Ny Typebeskrivelse ("DirectoryLink. Motparter"), "Kunde"));// Endringer i sammensetningen av detaljer
);
Endre skjemaelementer
For å kontrollere sammensetningen av elementer i et objekt ManagedForm det er en samling Elementer. Samlingen har flere metoder:
Sett inn (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Legg til (< Имя>, < ТипЭлемента>, < Родитель >)
Mengde ()
Finne (< Имя >)
Bevege seg(< Элемент>, < Родитель>, < МестоРасположения >)
Slett (< Элемент >)
Varesamlingen er tilgjengelig på både klienten og serveren. Endre en samling (Sett inn metoder () , Legg til () , Flytt () og Slett () ) er kun tilgjengelig på serveren. Du kan søke etter og få antall elementer (Finn () og Count () metodene) både på klienten og på serveren. Samlingselementer kan være:
- FormGroup;
- FormTable;
- FormField;
- Skjemaknapp.
Du kan programmatisk tildele hendelsesbehandlere til skjemaelementer. Metoden er beregnet for disse formålene SetAction(< ИмяСобытия>, < Действие >) .
La oss se på noen av de vanligste eksemplene på arbeid med kommandoer, detaljer og skjemaelementer.
Legge til en kommando og tilhørende knapp:
// Lag en kommando
Team = Lag. Legg til( "Endringers historie");
Team . Handling = "Plug-in_DisplayHistory"; // Skjemaet må inneholde en prosedyre med det angitte navnet
Team . Overskrift = "Endringers historie...";
// Lag en knapp og tilknytt den til en kommando
Element = Varer. Legg til( "Endringers historie", Type("FormButton" ));
Element.CommandName = "Endringers historie";
Legge til et attributt og det tilhørende inndatafeltet:
// Beskrivelse av de tilføyde detaljene
AddedDetails = New Array;
Lagt til detaljer. Legg til(Nye skjemarekvisitter ("Kjøper", ny typebeskrivelse ( "DirectoryLink. Motparter"), "Klient" ));
// Endre sammensetningen av detaljer
ChangeDetails(Lagt til detaljer);
// Opprette et inndatafelt og koble til attributtet
Element = Varer. Add("Kjøper" , Type("FormField" ));
Element . Vis = FormFieldView. Innføringsfelt;
Element . PathToData= "Kjøper" ;
Tilordne en hendelsesbehandler til et skjemaelement:
Varekunde. SetAction("Når det endres" , "Connected_BuyerOnChange");
&På klient
Fremgangsmåte Connected_BuyerOnChange(Element)
// Hendelseshandlinger
Slutt på prosedyre
Merk følgende!
Prosedyrer som er satt som hendelsesbehandlere fra kode ved hjelp av metoden SetAction(), anbefales det å sette prefikset Connectable_.
Merk følgende!
Du kan laste ned behandlingen med eksempler på programmatisk søking og endring av detaljer, kommandoer og elementer i et administrert skjema.
Skjemadetaljene sikrer tilknytningen til dataene. I dette tilfellet kan én (og bare én) av detaljene utpekes som den viktigste; det er kanskje ikke nødvendigvis datatypen vi trekker skjemaet til. Men oppførselen til skjemaet vil avhenge av datatypen til hovedattributtet. I tillegg til å endre oppførselen til skjemaet, endres konteksten til skjemamodulen. Sammen med metodene og egenskapene til skjemaet, blir metodene og egenskapene til objektet, som er verdien av hovedattributtet, tilgjengelige i det. Det er viktig at skjemaer av typen Free Form ikke har grunnleggende detaljer. I dette tilfellet bestemmes skjemaets oppførsel kun av brukerens innstillinger. La oss vurdere spørsmål om de grunnleggende detaljene.
Oppgave 10.05 av eksamen 1C: Plattformprofesjonell. Hva brukes hovedformattributtet til?
- Definerer datakilden for skjemaet som helhet
- Definerer standardfunksjonene til plattformen for å jobbe med skjemaet med data av typen spesifisert i hovedattributtet
- For å gi muligheten til å programmere tilgang til objektdetaljer fra den lokale skjemakonteksten
- Gir visualisering av objektdetaljer i skjemadialogen
- 2 og 3 er riktige
- 1 og 2 er riktige
Riktig svar er nummer seks, se ovenfor.
Oppgave 10.06 av eksamen 1C: Plattformprofesjonell. Hva trengs skjemadetaljene til?
- For å beskrive innholdet i dataene som vises, redigeres eller lagres i et skjema
- For å vise og redigere data i et skjema
- 1 og 2 er riktige
Riktig svar er det tredje - begge.
Oppgave 10.07 av eksamen 1C: Plattformprofesjonell. For å tildele grunnleggende attributter til en vilkårlig kontrollert form...
- Du må merke av for "Grunnleggende detaljer" i egenskapene til skjemaattributtene
- du må fylle ut "Data"-egenskapen til skjemaet ved å velge det nødvendige skjemaattributtet
Det riktige svaret er det andre:
Oppgave 10.08 av eksamen 1C: Plattformprofesjonell. For å tildele hoveddetaljene til en vilkårlig vanlig form...- skjemaet må gjøres til det viktigste, hoveddetaljene bestemmes automatisk
- Du må merke av for "Grunnleggende detaljer" i egenskapene til skjemaattributtene
- du må gå til "Rediger"-menyen, "Grunnleggende detaljer" og velge ønsket verdi
- du må fylle ut "Data"-egenskapen til skjemaet ved å velge det nødvendige skjemaattributtet
Det fjerde riktige svaret er:
Hoveddetaljene er uthevet med fet skrift:
Oppgave 10.09 av eksamen 1C: Plattformprofesjonell. Hvis det er ett hovedformattributt, er det mulig å legge til et annet hovedattributt?- Dette er umulig
- Det er mulig ved å tilordne riktig verdi til formattributt-egenskapen
- Det er bare mulig programmatisk når du får tilgang til "Form"-objektet
- Dette er mulig ved å legge til en annen verdi til den tilsvarende skjemaegenskapen
Det riktige svaret er det første, det er strengt tatt ett hovedkrav, fordi forbindelsen med objektet må være entydig.
Oppgave 10.113 av eksamen 1C: Plattformprofesjonell. Hvilken av detaljene i skjemaet presentert i figuren er den viktigste?
- Liste over valutakurser
- DirectoryObject
- Katalogskjemaer har ikke grunnleggende detaljer
- Katalogskjemaer har alle grunnleggende detaljer
Skjemaet styres gjennom ulike skjemaelementer, som er plassert hierarkisk på fanen Elementer skjemadesigner. Det viktigste elementet er selve formen, som er plassert øverst i elementhierarkiet, og de resterende elementene er underordnet det.
Alle skjemaelementer kan deles inn i fem grupper: felt, grupperingselementer, knapper, dekorasjoner og tabeller. I artiklene mine vil jeg analysere hver av gruppene. I denne artikkelen vil vi begynne å studere en av typene feltelementer - inntastingsfelt, men før det lærer vi hvordan du legger til et element i skjemaet.
Legge til elementer i et skjema
Dette gjøres ganske enkelt: du må velge elementet Skjema i vinduet Form Design Elements og klikk på "Legg til"-knappen. Etter dette åpnes et vindu der du må velge ønsket elementtype
Etter valg vil ønsket element vises i vinduet Elementer.
Administrert skjemaelement Felt
La oss se på et administrert skjemaelement Felt. Dette elementet er nødvendig for å legge inn informasjon på skjemaet. Og også for å vise all informasjon. Etter at du har lagt til dette elementet i skjemaet, åpnes egenskapspaletten for skjemaelementer til høyre. Foreløpig bør du være interessert i to egenskaper – DataPath og View.
I DataPath-egenskapen kan utvikleren knytte et skjemaelement til ønsket skjemaattributt. Vær oppmerksom på at etter at elementet er lagt til Innføringsfelt på skjemaet ble det ikke vist på selve skjemaet. Dette skjedde fordi vårt nye element ikke er knyttet til . For eksempel opprettet jeg flere attributter på behandlingsskjemaet med forskjellige primitive typer og ett attributt med en referansetype.
La oss nå koble vårt nylig tillagte skjemaelement med en av detaljene. For å gjøre dette, velg ønsket attributt fra elementets PathKData-egenskap.
Etter dette vil egenskapene DataPath og View fylles ut, og selve elementet vises i skjemavisningen.
Vær oppmerksom på elementegenskapen Utsikt. Denne egenskapen bestemmer funksjonaliteten til inndatafeltet. Du kan velge forskjellige verdier for denne eiendommen.
Avhengig av den valgte verdien, vil funksjonaliteten bli bestemt. I figurene ovenfor er den valgte verdien – inntastingsfelt, dvs. vi kan legge inn alle verdier i dette inndatafeltet, og hvis vi velger en verdi etikettfelt, da kan vi ikke legge inn noe.
Denne eiendomsverdien Utsikt Inndatafelt er praktisk å velge når du bare trenger å vise hjelpeinformasjon til brukeren.
La oss nå legge til et nytt skjemaelement med type Innføringsfelt og koble den til rekvisittene Detaljer Dato gjennom den allerede kjente for oss DataPath-egenskapen
Som du kan se, har utseendet til inndatafeltet endret seg, og det mulige utvalget av verdier for Vis-egenskapen vil også endres.
Dermed konkluderer vi med at funksjonaliteten til inndatafeltet avhenger av typen attributt.
For rekvisitter med type boolsk Følgende View-egenskapsverdier vil være tilgjengelige.
Og for attributter med en referansetype vil andre verdier for View-egenskapen være tilgjengelige.
Mer detaljert arbeid med skjemaelementer ved bruk av praktiske eksempler er gitt i boken «Grunnleggende for utvikling i 1C: Taxi. Administrert applikasjonsutvikling i 12 trinn".
Noen ganger virker det som om å lære programmeringsspråket i 1C er komplisert og vanskelig. Faktisk er programmering i 1C enkelt. Bøkene mine vil hjelpe deg raskt og enkelt å mestre programmering i 1C: og "Grunnleggende utvikling i 1C: Taxi"
Lær programmering i 1C ved hjelp av boken min "Programmering i 1C i 11 trinn"
- Ingen kompliserte faguttrykk.
- Over 700 sider med praktisk materiale.
- Hver oppgave er ledsaget av en tegning (skjermdump).
- En samling av problemer for lekser.
- Boken er skrevet i et klart og enkelt språk – for en nybegynner.
Denne boken passer for de som allerede har begynt å programmere og opplever visse vanskeligheter med dette emnet og for de som har programmert lenge, men aldri har jobbet med 1C administrerte skjemaer.
- Uten komplekse tekniske termer;
- Mer enn 600 sider med praktisk materiale;
- Hvert eksempel er ledsaget av en tegning (skjermbilde);
- Boken sendes på e-post i PDF-format. Kan åpnes på alle enheter!
Kampanjekode for 15% rabatt - 48PVXHeYu
Hvis denne leksjonen hjalp deg med å løse et problem, du likte det eller fant det nyttig, kan du støtte prosjektet mitt ved å donere et hvilket som helst beløp:
Du kan betale manuelt:
Yandex.Money - 410012882996301
Web Money - R955262494655
Bli med i gruppene mine.
Og dataoverføringsobjekt til kodestrukturering, kontrollert form i 1C 8.2-miljøet.
Introduksjon
La oss starte med en kort beskrivelse av konseptet "administrert form" og relaterte konsepter til 1C-plattformen. Plattformkjennere vil kanskje hoppe over denne delen.I 2008 ble det tilgjengelig en ny versjon av 1C-plattformen: Enterprise 8.2 (heretter referert til som den administrerte applikasjonen), som fullstendig endrer hele arbeidslaget med grensesnittet. Dette inkluderer kommandogrensesnittet, skjemaer og vindussystemet. Samtidig endres ikke bare modellen for å utvikle brukergrensesnittet i konfigurasjonen, men det foreslås også en ny arkitektur for å skille funksjonalitet mellom klientapplikasjonen og serveren.
Den administrerte applikasjonen støtter følgende typer klienter:
- Tykk klient (normal og administrert oppstartsmodus)
- Tynn klient
- Nettklient
De viktigste forskjellene på administrerte skjemaer for en utvikler:
- Deklarativ, ikke "piksel for piksel" beskrivelse av strukturen. Den spesifikke plasseringen av elementer utføres automatisk av systemet når skjemaet vises.
- All funksjonalitet i skjemaet er beskrevet som detaljer Og lag. Detaljer er dataene som skjemaet fungerer med, og kommandoer er handlingene som skal utføres.
- Skjemaet kjører både på serveren og klienten.
- I klientsammenheng er nesten alle applikasjonstyper utilgjengelige, og følgelig er det umulig å endre dataene i infobasen.
- For hver metode eller skjemavariabel må den spesifiseres kompileringsdirektiv, definerer utførelsesstedet (klient eller server) og tilgang til skjemakonteksten.
- &På klient
- &På server
- &PåServerUten kontekst
- &OnClientOnServerUten kontekst
Alle videre diskusjoner vil handle om høyre side av illustrasjonen, om hvordan du strukturerer modulkoden og hvilke prinsipper som vil tillate deg å implementere effektiv klient-server-interaksjon.
La oss definere problemet
Det har gått flere år siden den nye versjonen av 1C-plattformen tas aktivt i bruk og mange løsninger (konfigurasjoner) har blitt sluppet av både 1C og dets mange partnere.Har utviklere i løpet av denne tiden utviklet en felles forståelse av prinsippene for klient-server-interaksjon når de lager skjemaer, og har tilnærmingen til implementering av programvaremoduler endret seg i de nye arkitektoniske realitetene?
La oss se på kodestrukturen (skjemamodul) i flere former av samme standardkonfigurasjon og prøve å finne mønstre.
Med struktur mener vi deler av kode (oftest er dette kommentarblokker) som er tildelt av utvikleren til å gruppere metoder og kompileringsdirektiver for disse metodene.
Eksempel 1:
Seksjon av hendelsesbehandlere Metode - på klienten Metode - på serveren Metode - på klienten Seksjon av tjenesteprosedyrer og funksjoner Hjelpeinngangskontrollfunksjoner
Eksempel 2:
Tjenesteprosedyrer og funksjoner Betalingsdokumenter Verdier Hendelsesbehandlere
Eksempel 3:
Tjenesteprosedyrer på serveren Tjenesteprosedyrer på klienten Tjenesteprosedyrer på serveren uten kontekst Header hendelsesbehandlere Kommando hendelsesbehandlere
Eksempel 4:
Generelle prosedyrer Skjemahendelsesbehandlere Prosedyrer for undersystemet "kontaktinformasjon".
I hovedsak mangler kodestrukturen, eller for å si det mildt, den ligner på det som var i Forms 8.1:
- Ikke-informative ord "Generelt, Service, Auxiliary".
- Nøysomme forsøk på å skille klient- og servermetoder.
- Metoder er ofte gruppert etter grensesnittelementer "Arbeid med tabelldelen Produkter, kontaktinformasjon".
- Vilkårlig ordning av metoder og kodegrupper. For eksempel kan hendelsesbehandlere være øverst i en form, nederst i en annen, ikke uthevet i det hele tatt i en tredje osv.
- Og la oss ikke glemme at alt dette er innenfor én konfigurasjon.
- Ja, det er konfigurasjoner der ordene "General, Service, Auxiliary" alltid er på de samme stedene, men...
Hvorfor trenger du kodestruktur?
- Forenkling av vedlikehold.
- Forenkle læring.
- Registrere generelle/viktige/vellykkede prinsipper.
- ...ditt alternativ
Hvorfor hjelper ikke den eksisterende utviklingsstandarden fra 1C?
La oss se på prinsippene som er publisert på ITS-disker og i forskjellige "utviklerveiledninger..." som anbefales når du skriver et administrert skjema.- Minimer antall serveranrop.
- Maksimal databehandling på serveren.
- Ikke-kontekstuelle serveranrop er raskere enn kontekstuelle.
- Program med klient-server-kommunikasjon i tankene.
- og så videre.
Designmønstre eller generasjonsvisdom
Klient-server-interaksjon har blitt brukt i ulike programvareteknologier i flere tiår. Svaret på spørsmålene skissert i forrige avsnitt har lenge vært kjent og er oppsummert i to grunnleggende prinsipper.- Ekstern fasade(heretter referert til som Remote Access Interface)
- Dataoverføringsobjekt(heretter referert til som dataoverføringsobjekt)
- … Hvert objekt som potensielt er beregnet for ekstern tilgang må ha grensesnitt med lav granularitet, som vil minimere antallet anrop som kreves for å utføre en bestemt prosedyre. ... I stedet for å be om en faktura og alle dens varer separat, må du lese og oppdatere alle fakturaposter i én forespørsel. Dette påvirker hele strukturen til objektet...Husk: fjerntilgangsgrensesnitt inneholder ikke domenelogikk.
- ...hvis jeg var en omsorgsfull mor, ville jeg definitivt sagt til barnet mitt: "Aldri skriv dataoverføringsobjekter!" I de fleste tilfeller er dataoverføringsobjekter ikke annet enn oppblåst feltsett... Verdien av dette ekle monsteret ligger utelukkende i muligheten overføre flere deler av informasjon over nettverket i en samtale- en teknikk som er av stor betydning for distribuerte systemer.
Eksempler på maler i 1C-plattformen
Applikasom er tilgjengelig for utvikleren ved utvikling av et administrert skjema, inneholder mange eksempler på disse prinsippene.For eksempel OpenForm()-metoden, et typisk "grovt" grensesnitt.
OpeningParameters = New Structure("Parameter1, Parameter2, Parameter3", Verdi1, Verdi2, Verdi3); Form = OpenForm(FormName, OpeningParameters);
Sammenlign med stilen som ble tatt i bruk i v8.1.
Form = GetForm(FormName); Form.Parameter1 = Verdi1; Form.Parameter2 = Verdi2; Form.Open();
I sammenheng med et administrert skjema er det mange "dataoverføringsobjekter". Du kan velge systematisk Og utviklerdefinert.
Systemer modellerer et applikasjonsobjekt på klienten, i form av ett eller flere skjemadataelementer. Det er umulig å lage dem uten referanse til skjemadetaljene.
- DataFormsStructure
- DataFormsCollection
- DataFormStructureWithCollection
- DataShapesTree
- ValueInFormData()
- FormDataValue()
- CopyFormData()
- ValueInFormAttributes()
- FormAttributesValue()
Eksempel 1C v8.1:
// på klienten i sammenheng med skjemaet FillUserCache(DepartmentLink)
Eksempel 1C v8.2:
// på serveren i sammenheng med skjemaet ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");
Dataoverføringsobjekter, hvis struktur bestemmes av utvikleren, er en liten delmengde av typene som er tilgjengelige på både klienten og serveren. Oftest brukes følgende som parametere og resultater av metoder for et "grovt" grensesnitt:
- Primitive typer (streng, tall, boolsk)
- Struktur
- Korrespondanse
- Array
- Lenker til applikasjonsobjekter (unik identifikator og tekstrepresentasjon)
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [ordre][feilbeskrivelse] For hver ordre fra ordre syklus StartTransaction(); Prøv DocOb = Order.GetObject(); …. andre handlinger, mulig ikke bare med ordren... Unntak CancelTransaction(); Errors.Insert(Order, ErrorDescription()); Sluttforsøk; EndCycle; Returner feil; EndFunction // ServerChangeOrderStatus()
Strukturere koden
Hovedmålene som modulen for administrert skjema skal reflektere og tilnærminger til løsningen.- Tydelig skille mellom klient- og serverkode. La oss ikke glemme at på utførelsestidspunktet er dette to interaksjonsprosesser, som hver har betydelig forskjellig tilgjengelig funksjonalitet.
- Tydelig identifikasjon av grensesnittet for ekstern tilgang, hvilke servermetoder kan kalles fra klienten og hvilke kan ikke? Navnene på metoder for eksternt grensesnitt begynner med prefikset "Server". Dette lar deg umiddelbart se overføringen av kontroll til serveren mens du leser koden, og forenkler bruken av kontekstuell hjelp. Merk at den offisielle anbefalingen (ITS) foreslår navngivningsmetoder med postfikser, for eksempel ChangeOrderStatusOnServer(). Vi gjentar imidlertid at ikke alle servermetoder kan kalles fra klienten, og derfor er logisk tilgjengelighet viktigere enn kompileringsplassering. Derfor, med prefikset "Server" merker vi bare metodene som er tilgjengelige for klienten; la oss kalle eksempelmetoden ServerChangeOrderStatus().
- Lesbarhet. En smakssak, vi aksepterer bestillingen når modulen begynner med prosedyrene for å lage et skjema på serveren og fjerntilgangsmetoder.
- Vedlikeholdbarhet. Det må være et tydelig sted for å legge til ny kode. Et viktig poeng er at metodemaler opprettet automatisk av konfiguratoren legges til på slutten av modulen. Siden hendelsesbehandlere for skjemaelementer oftest opprettes automatisk, er den tilsvarende blokken plassert sist, for ikke å dra hver behandler til et annet sted i modulen.
- Grafisk alternativ – viser tydelig hovedflyten for utførelse.
- Tekstalternativet er et eksempel på en maldesign for raskt å sette inn en struktur i en ny skjemamodul.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Date=""/> // <Описание> // // ////////////////////////////////////////////// //////////////////////////// MODULVARIABLER /////////////////// /////////////////////////////////////////////// ////////// // PÅ SERVEREN //******* HENDELSER PÅ SERVEREN ******* &På serverprosedyren når den ble opprettet på serveren (feil, standardbehandling) / /Sett inn innholdet i behandleren Slutt på prosedyren //******* FJERNTILGANGGRENSESNITT ******* //******* FORRETNINGSLOGIKK PÅ SERVEREN ******* ///////// ///////////////////////////////////// /////// ////////////////////// FELLES METODER FOR KLIENT OG SERVER ///////////////// /////// /////////////////////////////////////// ///// //////// // PÅ KLIENTEN //******* FORRETNINGSLOGIKK PÅ KLIENTEN ******* //******* TEAM * ****** //******* KLIENTHENDELSER ******* ///////////////////////// ///// ///////////////////////////////////////// // / / HOVEDPROGRAMOPERATORER
Relaterte spørsmål
Avslutningsvis vil vi skissere flere områder som er nyttige å tenke på ved programmering av klient-server-interaksjon.- Alternativer for implementering av grensesnitt for ekstern tilgang. Asynkroni, detaljnivå...
- Buffer. 1C tok en mislykket arkitektonisk avgjørelse, og introduserte caching bare på nivået for kallemetoder for vanlige moduler og ga ikke kontrollfunksjoner (relevanstid, tilbakestilling på forespørsel).
- Implisitte serveranrop. Ikke glem teknologiske funksjoner; mange "ufarlige" operasjoner på klienten provoserer plattformen til å kontakte serveren.
