Und Datenübertragungsobjekt zur Codestrukturierung, verwaltete Form in der 1C 8.2-Umgebung.

Einführung

Beginnen wir mit einer kurzen Beschreibung des Konzepts des „verwalteten Formulars“ und verwandter Konzepte der 1C-Plattform. Plattformexperten können diesen Abschnitt überspringen.

Wurde 2008 verfügbar eine neue Version Plattform 1C: Enterprise 8.2 (im Folgenden als Managed Application bezeichnet), die die gesamte Arbeitsschicht mit der Schnittstelle vollständig verändert. Dazu gehören die Befehlsschnittstelle und Formulare sowie das Fenstersystem. Dies ändert nicht nur das Entwicklungsmodell der Benutzeroberfläche in der Konfiguration, sondern schlägt auch eine neue Architektur für die Trennung der Funktionalität zwischen der Client-Anwendung und dem Server vor.
Die verwaltete Anwendung unterstützt die folgenden Arten von Clients:

Thick Client (normaler und verwalteter Startmodus)
Dünner Kunde
Web-Client

Eine verwaltete Anwendung verwendet Formulare, die darauf aufbauen neue Technologie. Sie werden gerufen Verwaltete Formulare. Um den Übergang zu erleichtern, werden auch ältere Formulare (sogenannte reguläre Formulare) unterstützt, aber ihre Funktionalität wird nicht entwickelt und sie sind nur im Rich-Client-Startmodus verfügbar.
Hauptunterschiede verwalteter Formulare für den Entwickler:

Deklarative, nicht „pixelweise“ Beschreibung der Struktur. Die konkrete Platzierung der Elemente erfolgt automatisch beim Anzeigen des Formulars durch das System.
Alle Funktionen des Formulars sind im Formular beschrieben Einzelheiten und Befehle. Details sind die Daten, mit denen das Formular arbeitet, und Befehle sind die ausgeführten Aktionen.
Das Formular wird sowohl auf dem Server als auch auf dem Client ausgeführt.
Im Kontext des Clients sind fast alle Anwendungstypen nicht verfügbar, und dementsprechend ist es unmöglich, die Daten in der Infobase zu ändern.
Für jede Methoden- oder Formularvariable muss sie angegeben werden Kompilierungsrichtlinie A, das den Ausführungsort (Client oder Server) und den Zugriff auf den Kontext des Formulars angibt.

Hier sind die Anweisungen zum Kompilieren von Formularmethoden:

&BeiKunde
&Auf dem Server
&OnServerWithoutContext
&Auf dem ClientAuf dem ServerWithoutContext

Lassen Sie uns das Obige veranschaulichen. Der Screenshot zeigt ein Beispiel für ein verwaltetes Formular und sein Modul im Entwicklungsmodus. Finden Sie deklarative Beschreibungen, Requisiten, Kompilierungsanweisungen usw.

Alle weiteren Diskussionen werden sich um die rechte Seite der Abbildung drehen, darum, wie der Modulcode strukturiert wird und welche Prinzipien Ihnen erlauben, eine effektive Client-Server-Interaktion zu implementieren.

Lassen Sie uns das Problem definieren

Mehrere Jahre sind vergangen, seit die neue Version der 1C-Plattform aktiv genutzt wurde und viele Lösungen (Konfigurationen) sowohl von 1C als auch von seinen zahlreichen Partnern veröffentlicht wurden.
Haben Entwickler in dieser Zeit ein gemeinsames Verständnis der Prinzipien der Client-Server-Interaktion bei der Erstellung von Formularen entwickelt und hat sich die Herangehensweise an die Implementierung geändert? Softwaremodule in neuen architektonischen Realitäten?

Betrachten Sie die Codestruktur (Formmodul) in mehreren Formen derselben typischen Konfiguration und versuchen Sie, Muster zu finden.
Unter der Struktur verstehen wir Codeabschnitte (meistens sind dies Kommentarblöcke), die vom Entwickler zum Gruppieren von Methoden und Anweisungen zum Kompilieren dieser Methoden zugewiesen wurden.
Beispiel 1:
Abschnitt Ereignisbehandler Methode - auf dem Client Methode - auf dem Server Methode - auf dem Client Abschnitt der Dienstprozeduren und -funktionen Eingangssteuerungs-Hilfsfunktionen
Beispiel 2:
Serviceverfahren und -funktionen Zahlungsbelege Wertsachen Eventhandler
Beispiel 3:
Dienstprozeduren auf dem Server Dienstprozeduren auf dem Client Dienstprozeduren auf dem Server ohne Kontext Header-Event-Handler Command-Event-Handler
Beispiel 4:
Allzweck-Prozeduren Form-Event-Handler Prozeduren des Subsystems "Kontaktinformationen".
Tatsächlich fehlt die Codestruktur, oder um es milde auszudrücken, sie ist ähnlich wie in Forms 8.1:

Nicht informative Wörter "General, Service, Auxiliary".
Schüchterne Versuche, Client- und Servermethoden zu trennen.
Oft sind Methoden nach Oberflächenelementen "Arbeiten mit dem tabellarischen Teil Produkte, Kontaktinformationen" gruppiert.
Beliebige Anordnung von Methoden und Codegruppen. Beispielsweise können Event-Handler in einem Formular ganz oben stehen, in einem anderen ganz unten, in einem dritten gar nicht hervorgehoben werden und so weiter.
Und vergessen wir nicht, dass dies alles innerhalb derselben Konfiguration ist.
Ja, es gibt Konfigurationen, in denen die Wörter „General, Service, Auxiliary“ immer an denselben Stellen stehen, aber ...

Warum brauchen Sie eine Codestruktur?

Vereinfachung der Wartung.
Lernen vereinfachen.
Festlegung allgemeiner/wichtiger/erfolgreicher Prinzipien.
…Ihre Wahl

Warum hilft der vorhandene Entwicklungsstandard von 1C nicht?

Schauen wir uns die Prinzipien an, die auf den ITS-Disketten und in verschiedenen "Entwicklerhandbüchern ..." veröffentlicht sind und beim Schreiben eines verwalteten Formulars empfohlen werden.

Minimieren Sie die Anzahl der Serveraufrufe.
Maximale Rechenleistung auf dem Server.
Serveraufrufe ohne Kontext sind schneller als Kontextaufrufe.
Programm mit Client-Server-Interaktion im Auge.
usw.

Das sind Parolen, die absolut wahr sind, aber wie können sie verwirklicht werden? Wie kann man die Anzahl der Aufrufe minimieren, was bedeutet es, im Client-Server-Modus zu programmieren?

Designmuster oder Generationenweisheit

Die Client-Server-Interaktion wird seit Jahrzehnten in verschiedenen Softwaretechnologien verwendet. Die Antwort auf die im vorherigen Abschnitt skizzierten Fragen ist seit langem bekannt und lässt sich in zwei Grundprinzipien zusammenfassen.

Ferne Fassade(im Folgenden Remote Access Interface)
Datenübertragungsobjekt(im Folgenden als Data Transfer Object bezeichnet)

Wort an Martin Fowler, seine Beschreibung dieser Prinzipien:

… jedes Objekt, das potenziell für den Fernzugriff vorgesehen ist, haben muss Schnittstelle mit niedriger Granularität, wodurch die Anzahl der Aufrufe minimiert wird, die zum Durchführen eines bestimmten Verfahrens erforderlich sind. … Anstatt eine Rechnung und alle ihre Punkte separat anzufordern, ist es notwendig, alle Punkte der Rechnung in einem Aufruf zu lesen und zu aktualisieren. Dies betrifft die gesamte Struktur des Objekts ... Denken Sie daran: die Remote-Access-Schnittstelle enthält keine Domänenlogik.
... wenn ich eine fürsorgliche Mutter wäre, würde ich meinem Kind auf jeden Fall sagen: „Schreibe niemals Datenübertragungsobjekte!“ In den meisten Fällen sind Datenmigrationsobjekte nichts anderes als aufgeblähtes Feld… Der Wert dieses ekelhaften Monsters liegt allein in der Möglichkeit Übertragen mehrerer Informationen über das Netzwerk in einem Anruf- eine Technik, die für verteilte Systeme von großer Bedeutung ist.

Beispiele für Vorlagen auf der 1C-Plattform

Die API, die einem Entwickler beim Entwickeln eines verwalteten Formulars zur Verfügung steht, enthält viele Beispiele für diese Prinzipien.
Zum Beispiel die Methode OpenForm(), eine typische "grobe" Schnittstelle.
OpenParameters = Neue Struktur ("Parameter1, Parameter2, Parameter3", Wert1, Wert2, Wert3); Formular = OpenForm(FormularName, OpenParameters);
Vergleichen Sie mit dem v8.1-Stil.
Formular = GetForm(FormularName); Form.Parameter1 = Wert1; Form.Parameter2 = Wert2; Formular.Öffnen();

Im Kontext eines verwalteten Formulars ein Satz von "Datenübertragungsobjekten". Kann außeinandergehalten werden systemisch und Entwicklerdefiniert.
Systemmodelle modellieren ein Anwendungsobjekt auf dem Client in Form von einem oder mehreren Formulardatenelementen. Sie können sie nicht außerhalb der Bindung an die Formulardetails erstellen.

DataFormsStruktur
DataFormsCollection
DataFormStructureCollection
DataFormsTree

Die Konvertierung von Objekten des Datenübertragungssystems in Anwendungstypen und umgekehrt erfolgt nach folgenden Methoden:

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

Häufig wird bei der Anpassung einer bestehenden Lösung auf eine explizite Konvertierung zurückgegriffen. Methoden können Eingabeparameter wie ValueTable anstelle von FormDataCollection erwarten (Feature) oder die Methode wurde im Kontext eines Anwendungsobjekts definiert und steht für den direkten Aufruf aus einem Formular nicht mehr zur Verfügung.
Beispiel 1C v8.1:
// auf dem Client im Kontext des Formulars FillUsersCache(DepartmentReference)
Beispiel 1C v8.2:
// auf dem Server im Kontext des Formulars ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");

Datenübertragungsobjekte, deren Struktur vom Entwickler definiert wird, sind eine kleine Teilmenge der Typen, die sowohl auf dem Client als auch auf dem Server verfügbar sind. Am häufigsten werden als Parameter und Ergebnisse von Methoden einer "groben" Schnittstelle verwendet:

Primitive Typen (String, Zahl, Boolean)
Struktur
Konformität
Reihe
Verknüpfungen zu Anwendungsobjekten (eindeutige Kennung und Textdarstellung)

Beispiel: Die Methode akzeptiert eine Liste von Aufträgen, um den Status zu ändern, und gibt eine Beschreibung der Fehler an den Client zurück.
&OnServerWithoutContext Funktion ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [Auftrag][Fehlerbeschreibung] Für jeden Auftrag aus der Auftragsschleife StartTransaction(); Versuch DocOb = Order.GetObject(); …. andere Aktionen, evtl. nicht nur bei der Bestellung... Exception CancelTransaction(); Errors.Insert(Order, DescriptionError()); Ende des Versuchs; EndCycle; Rückgabefehler; EndFunction // ServerChangeOrderStatus()

Code strukturieren

Die Hauptziele, die das verwaltete Formularmodul widerspiegeln sollte, und Lösungsansätze.

Klare Trennung von Client- und Server-Code. Vergessen wir nicht, dass dies zum Zeitpunkt der Ausführung zwei interagierende Prozesse sind, bei denen sich die verfügbare Funktionalität erheblich unterscheidet.
Eine klare Auswahl der Remote-Access-Schnittstelle, welche Server-Methoden können vom Client aufgerufen werden und welche nicht? Die Namen der Remote-Interface-Methoden beginnen mit dem Präfix „Server“. Dadurch können Sie beim Lesen des Codes sofort den Übergang der Kontrolle zum Server sehen und die Verwendung von kontextbezogenen Hinweisen vereinfachen. Beachten Sie, dass die offizielle Empfehlung (ITS) Benennungsmethoden mit Postfixes vorschlägt, wie z. B. ChangeOrderStatusOnServer(). Um es noch einmal zu wiederholen: Nicht alle Servermethoden können vom Client aufgerufen werden, und daher ist die logische Zugänglichkeit wichtiger als der Ort der Kompilierung. Daher markieren wir mit dem Präfix „Server“ nur die Methoden, die dem Client zur Verfügung stehen, die Beispielmethode heißt ServerChangeOrderStatus().
Lesbarkeit. Geschmackssache, wir übernehmen die Bestellung, wenn das Modul mit den Verfahren zur Erstellung eines Formulars auf dem Server und Fernzugriffsmethoden beginnt.
Wartbarkeit. Die Stelle, an der neuer Code hinzugefügt werden soll, muss klar definiert sein. Wichtiger Punkt, die vom Methoden-Stub-Konfigurator automatisch erstellt werden, werden am Ende des Moduls hinzugefügt. Da Ereignishandler für Formularelemente meistens automatisch erstellt werden, wird der entsprechende Block zuletzt platziert, um nicht jeden Handler an eine andere Stelle im Modul zu ziehen.

Unten ist die Grundstruktur des Moduls, das die aufgelisteten Ziele umsetzt.

Grafische Option - zeigt deutlich den Hauptablauf der Ausführung.
Die Textversion ist ein Beispiel für ein Vorlagendesign für schnell einfügen Strukturen in ein neues Formularmodul.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datum=""/> // <Описание> // // ////////////////////////////////////////////////// / ////////////////////////////// // MODULVARIABLEN /////////////// / ///////////////////////////////////////////////// // ////////////// // AUF DEM SERVER //******* EREIGNISSE AUF DEM SERVER ******* &Auf dem Server Prozedur Bei ErstellungAuf dem Server( Failure, StandardProcessing) //Fügen Sie den Inhalt des Handlers EndProcedure ein //******* REMOTE ACCESS INTERFACE ******* //******** BUSINESS LOGIC ON THE SERVER **** *** ///////// ////////////////////////////////////// ///////////// ///////////////////// // GÄNGIGE CLIENT- UND SERVER-METHODEN ///////// /////////////// /////////////////////////////////// //////////////// //////// // AUF DEM CLIENT //******* GESCHÄFTSLOGIK AUF DEM CLIENT ******* //******* BEFEHLE ******* //******* EREIGNISSE AUF DEM CLIENT ****** /////////////// ////////////////// //////////////////////////////// ///////////////// / / HAUPTPROGRAMM OPERATOREN

Informationen zu verwalteten Formularen 1C (Anfang)

Dünner Kunde

Nirgendwo ist es dünner. Jetzt fragt die Client-Anwendung die Datenbank nicht ab (das ist Sache des Servers). Die Client-Anwendung zeigt einfach die Schnittstelle und die Daten an.

Es ist erwähnenswert, dass die Codestruktur aufgrund solcher Transformationen komplizierter geworden ist. Auf dem Client gibt es keine Referenzen, Objekte, Wertetabellen ... nur primitive Typen sind verfügbar (String, Datum, Boolean, Array, Struktur ...). Das bedeutet, dass der Programmierer jetzt darüber nachdenken muss, was er auf den Server bekommt und wie er es mit minimalen Kosten macht.

Client-Server-Interaktion

Ein neuer Ansatz für die Interaktion zwischen dem Client und dem Server ermöglichte es uns, ein neues Modell der Benutzeroberfläche zu erstellen. Nun ist die Schnittstelle deklariert(!) Schnittstellendesign beginnt mit Daten, mit Details und tabellarischen Teilen. Wenn Sie eine Requisite erstellen, müssen Sie darüber nachdenken, wie sie in der Benutzeroberfläche aussehen wird, ob sie benötigt wird, wie sie mit anderen Requisiten zusammenhängt ...

Kein Kontext (Zustand) auf dem Server

Der 1C-Server arbeitet nach dem Prinzip „stateless“ (engl. state-less). Das bedeutet, dass der Server nur auf Anfragen antwortet und gleichzeitig nichts zwischen zwei Anfragen speichert (dafür gibt es eine Zwischenspeicherung).

FormDataToValue,FormDataCollection,FormData...

Wir haben uns an den Server gewandt, er hat alles für uns erledigt, die Daten gelöscht und vergessen, dass wir gekommen sind. Alle Objekte namens "FormData" + "something there" helfen uns, unsere Daten zwischen zwei Serveraufrufen zu speichern.

Zwischenlagerung

Temporäre Speicherung ist ein besonderer Ort, an dem Sie (zusätzlich zu Formulardetails) den Status auf dem Server speichern können. Der Speicher kann Daten speichern, die auf dem Client nicht verfügbar sind (d. h. die nicht in den Formulardetails platziert werden können).

Um mit temporärem Speicher zu arbeiten, verwenden Sie die Methoden MoveToTempStorage() Syntax: PlaceToTempStorage(<Данные>, <Адрес>) Beschreibung: Speichert einen serialisierbaren Wert im temporären Speicher. Verfügbarkeit: Thin Client, Web Client, Server, Thick Client, externe Verbindung, mobile Anwendung (Client), mobile Anwendung (Server). Der Methodenaufruf ruft den Server auf.<Адрес>(optional) Typ: UniqueIdentifier; Linie. Die eindeutige ID des Formulars, in dessen Zwischenspeicher die Daten abgelegt und die neue Adresse zurückgegeben werden soll. Oder die Adresse im Zwischenspeicher, wo die Daten abgelegt werden sollen. Die Adresse muss vorher mit dieser Methode bezogen werden. Wird ein Formular-UniqueIdentifier oder eine gespeicherte Adresse übergeben, so wird der Wert nach dem Schließen des Formulars automatisch gelöscht. Wenn ein UniqueIdentifier übergeben wird, der kein eindeutiger Bezeichner für das Formular ist, wird der Wert gelöscht, wenn die Sitzung des Benutzers endet. Wenn der Parameter nicht angegeben ist, wird der platzierte Wert nach der nächsten Serveranforderung aus dem gemeinsam genutzten Modul, bei Kontext- und Nicht-Kontext-Serveraufrufen aus dem Formular, bei Serveraufrufen aus dem Befehlsmodul oder bei Formularabrufen gelöscht. Hinweis: Der in einer Sitzung erstellte temporäre Speicher ist von einer anderen Sitzung aus nicht zugänglich. Eine Ausnahme bildet die Möglichkeit, Daten von einem Hintergrundjob über die Zwischenspeicherung in die Sitzung zu übertragen, die den Hintergrundjob initiiert hat. Platzieren Sie für eine solche Übertragung in der übergeordneten Sitzung einen leeren Wert im temporären Speicher und übergeben Sie die Formularkennung. Übergeben Sie dann die empfangene Adresse über die Parameter des Hintergrundjobs an den Hintergrundjob. Außerdem, wenn diese Adresse im Parameter verwendet wird<Адрес>, wird das Ergebnis in die Sitzung kopiert, aus der der Hintergrundjob gestartet wurde. Daten, die in einem Hintergrundjob temporär gespeichert werden, sind in der übergeordneten Sitzung nicht verfügbar, bis der Hintergrundjob abgeschlossen ist. und GetFromTempStorage() Syntax: GetFromTempStorage(<Адрес>) Beschreibung: Ruft einen Wert aus dem temporären Speicher ab. Verfügbarkeit: Thin Client, Web Client, Server, Thick Client, externe Verbindung, mobile Anwendung (Client), mobile Anwendung (Server). Der Methodenaufruf ruft den Server auf. Hinweis: Das Ergebnis der Ausführung wird nicht zwischengespeichert, der Server wird bei jedem Aufruf der Methode aufgerufen.

Aufrufen des Servercodes

Jeder Aufruf des Servercodes serialisiert immer die übertragenen Daten. Alle Parameter werden in eine Zeichenfolge verpackt und über das Netzwerk übertragen. Das Ergebnis der Arbeit wird auch in serialisierter Form zurückübertragen, wo es dann in vertraute Objekte wiederhergestellt wird.

Zuordnung von Modul-Flags

Das Flag gibt an, wo der Modulcode kompiliert wird (auf dem Server, auf dem Client, in einer externen Verbindung)
Wenn ein Modul an mehreren Stellen kompiliert wird, dann ist es nur entsprechend den Flags sichtbar
Die Übertragung der Codeausführung ist nur möglich, wenn es im aktuellen Ausführungskontext kein aufgerufenes Modul gibt, es aber an anderer Stelle existiert (wenn das Modul nur auf dem Server existiert und nicht auf dem Client, dann wird ein Serveraufruf durchgeführt )

Serveraufruf-Flag

Beginnend mit der Plattform 1C:Enterprise 8.2 wurde das Flag „Serveraufruf“ hinzugefügt. Was nur hilft, die Bedingungen für den Übergang zu einer anderen Maschine zu "lösen". Wenn dieses Flag dem Modul zugewiesen ist, dann ist das Modul vom Client aus sichtbar, wenn nicht, dann führt ein Aufrufversuch vom Client zu einem Fehler. Der Modulcode wird nicht sichtbar sein, als ob er überhaupt nicht existiert.

Daher können Sie in einem normalen Thick-Client den Code nur dann an den Server übertragen, wenn Sie vom Client aus ein gemeinsames Modul aufrufen, für das:

Server-Kontrollkästchen aktiviert
Das Kontrollkästchen "Server anrufen" ist aktiviert
Alle "Client"-Kontrollkästchen entfernt

Mit dem Aufkommen der 1C Enterprise 8.2-Plattform hat sich der Entwicklungsmechanismus für Benutzeroberflächen erheblich verändert. Jetzt können Sie verwaltete Formulare und Anwendungen erstellen (Abbildung 1).

Bild 1

Zusätzlich wird ein neues System zum Trennen der Funktionalität zwischen der Client-Anwendung und dem Server vorgeschlagen.
Die verwaltete Anwendung unterstützt die folgenden Arten von Clients:

Thick Client (normaler und verwalteter Startmodus),
Dünner Kunde,
Web-Client.

Der Mechanismus zum Erstellen verwalteter Formulare unterscheidet sich erheblich von herkömmlichen Formularen. Verwaltete Formulare unterscheiden sich zunächst dadurch, dass sie aufgrund spezieller Einstellungen automatisch vom System erstellt werden und der Programmierer nicht mehr jedes Formular im Detail zeichnen muss. Alle Funktionen des Formulars werden in Form von Details und Befehlen beschrieben. Details sind die Daten, mit denen das Formular arbeitet, und Befehle sind die ausgeführten Aktionen. Für jede Methoden- oder Formularvariable muss eine Compilation-Direktive angegeben werden, die den Ausführungsort (Client oder Server) festlegt. Kompilierungsanweisungen können sein:

&BeimKunde,
&Auf dem Server,
&AufServerOhneKontext,
&Auf dem ClientAuf dem ServerWithoutContext.

Ein verwaltetes Formular unterscheidet sich auch in den Datentypen, mit denen es arbeitet, von einem regulären Formular. Wenn ein reguläres Formular mit den meisten von 1C:Enterprise bereitgestellten Typen funktioniert (einschließlich der Typen DirectoryObject, DocumentObject usw.), können in einem verwalteten Formular die folgenden Kategorien von Typen unterschieden werden:

Typen, die direkt im Formular verwendet werden, sind die Typen, die auf der Seite des Thin- und Web-Clients vorhanden sind (z. B. Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
Die Typen, die in spezielle Datentypen konvertiert werden, sind verwaltete Formulardatentypen. Solche Typen werden in der Liste der Formularattribute in Klammern angezeigt, zum Beispiel (CatalogObject.Products);
dynamische Liste.

Die Funktionsweise verwalteter Formulare weist folgende Besonderheiten auf (Abbildung 2):

Das Formular existiert sowohl auf dem Client als auch auf dem Server.

Es führt eine Client-Server-Interaktion durch (Übertragung von Daten und Designeigenschaften von Elementen).

Formular funktioniert nicht mit Anwendungsobjekten

Figur 2

Das Formular verwendet spezielle generische Objekte
Datenformulare(Figur 3).

Figur 3

Anwendungsobjekte funktionieren nur auf dem Server und nur während bestimmter Operationen.
Beim Öffnen eines Formulars:

Das Objekt wird aus der Datenbank gelesen,
Das Objekt wird in Formulardaten umgewandelt,
Das Objekt wird (aus dem Speicher) entfernt,
Die Formulardaten werden an den Client übergeben.

Bei der Aufnahme:

Formulardaten werden vom Client empfangen,
Die Formulardaten werden in ein Objekt umgewandelt,
Das Objekt wird in die Datenbank geschrieben,
Das Objekt wird (aus dem Speicher) entfernt.

In der letzten Lektion haben wir für einen regelmäßigen (fetten) Kunden nachgedacht. In der Plattformversion 1C 8.2. Sie verwenden neue Masken 1C 8.2. Sie werden verwaltete Formulare 1C 8.2 genannt.

Verwaltete Formulare 1C 8.2 ist die Zukunft von 1C. Sie unterscheiden sich von gewöhnlichen 1C 8.2-Formularen dadurch, dass sie aufgrund spezieller Einstellungen automatisch vom System generiert werden („normale“ Formulare werden einfach vom Programmierer nach Belieben gezeichnet).

Die Unterschiede in der Entwicklung verwalteter Formulare 1C 8.2 von den üblichen sind erheblich. Aus diesem Grund haben wir uns heute versammelt, um die Erstellung und Änderung verwalteter Formulare 1C 8.2 separat zu erörtern.

Verwaltete Formulare 1C 8.2

Wenn Sie zuvor 1C-Konfigurationen entwickelt haben, werden Sie beim Öffnen des 1C 8.2-Editors für verwaltete Formulare sofort verblüfft sein, dass es unmöglich ist, das 1C 8.2-Formular mit der Maus zu beeinflussen.

Sie können das 1C 8.2-Formular nicht ändern, Sie können das Element nicht verschieben, Sie können nicht einmal die Eigenschaften des Felds wie zuvor anzeigen - indem Sie auf das Feld im 1C 8.2-Formular doppelklicken.

Jetzt sind die Grundlage für die Entwicklung des 1C 8.2-Formulars nicht die Bindung von Feldern an Koordinaten im Formular, sondern spezielle Einstellungen. Basierend auf diesen Einstellungen generiert das System automatisch ein verwaltetes Formular 1C 8.2.

Die Einstellungen bestehen aus einer Liste von 1C 8.2-Formularelementen, die sich im Editor in der oberen linken Ecke befinden. Zu den Elementen des Formulars 1C 8.2 gehören:

Voraussetzungen
Befehle (neues Konzept 1C 8.2, kann wie Schaltflächen oder Menüelemente aussehen)
Gruppen (um Details und Befehle zu kombinieren).

Dementsprechend befinden sich die Einstellungen dieser Elemente nicht in den Eigenschaften der Felder, sondern in den Eigenschaften dieser Einstellungselemente (Rechtsklickmenü, Punkt Eigenschaften).

Wie verwaltete Formulare 1C 8.2 funktionieren

Das Arbeiten mit verwalteten Formularen 1C 8.2 ist für den Benutzer anders. Sie haben mehr Funktionen, sind aber ungewöhnlich für diejenigen, die schon lange mit 1C arbeiten.

Zunächst einmal unterscheidet sich die Position der üblichen Elemente auf dem Formular 1C 8.2. Die Befehlsleiste befindet sich immer oben.

Die linke Seite der Befehlsleiste ist anpassbar. Es enthält normalerweise so typische Schaltflächen wie Aufnehmen und Posten.

Die rechte Seite des Befehlsfelds ist das neue Standardmenü des 1C-Formulars Alle Aktionen. Mit diesem Menü können Sie das 1C 8.2-Formular nach Belieben verwalten, ähnlich wie Sie mit den Einstellungen im ACS-Bericht das Erscheinungsbild des Berichts erheblich ändern können.

Beliebige Menüpunkte 1C Alle Aktionen

Je nachdem, ob dieses Formular 1C 8.1 dem einen oder anderen gehört, ist das Menü mit Elementen gefüllt, mit denen Sie dieses Objekt verwalten können. Wenn es sich beispielsweise um ein Verzeichnislistenformular handelt, gibt es Befehle wie Erstellen oder Bearbeiten.

Element Menüliste anpassen 1C Alle Aktionen

Wenn auf dem Formular 1C 8.2 eine Liste vorhanden ist, enthält das Menü die Befehle Liste einrichten und Liste anzeigen.
Wenn Ihnen der Befehl Liste anzeigen bereits bekannt ist - Sie können damit eine beliebige Liste in 1C in Excel speichern / drucken, ist der zweite Befehl neu.

Wie Sie bereits bemerkt haben, gibt es in der Befehlsleiste der Listen keine Auswahlschaltflächen mehr. Stattdessen erschien die Schaltfläche Suchen, zu deren Arbeit (sowie zur derzeit deaktivierten Positionierung des Cursors in der Liste beim Tippen) - Beschwerden vorliegen.

Die Funktionalität des Suchen-Buttons ist natürlich nicht mit der Auswahl zu vergleichen, aber sie ist nicht verschwunden!
Sie befinden sich jetzt unter dem Menüpunkt „Liste anpassen“. Die Auswahl kann jetzt nach jedem Feld erfolgen, und zusätzlich können Sortierung und bedingte Formatierung auf die gleiche Weise wie in SKD-Berichten durchgeführt werden.

Item Change Menüform 1C Alle Aktionen

Mit dem Element Formular ändern können Sie auf ähnliche Weise nicht nur die Liste auf dem 1C 8.2-Formular, sondern auch das 1C 8.2-Formular selbst ändern.

Der Benutzer kann die Sichtbarkeit von Feldern auf dem 1C 8.2-Formular, Breite und Höhe, Aktivierung des Standardfelds beim Öffnen usw. unabhängig aktivieren oder deaktivieren.

Verwenden verwalteter Formulare 1C 8.2 und herkömmlicher Formulare 1C

Standardmäßig werden reguläre 1C-Formulare in Konfigurationen für einen dicken (normalen) 1C-Client verwendet, und verwaltete Formulare werden in Konfigurationen für einen Thin- und Web-1C-Client verwendet. Beide Formen von 1C können jedoch in jeder Konfiguration verwendet werden, auch gleichzeitig.

Dazu müssen Sie auch die Konfigurationseigenschaften (oberstes Element im Konfigurationsfenster) eingeben.

In den Konfigurationseigenschaften in 1C 8.2 wurden zwei neue Kontrollkästchen angezeigt, mit denen Sie die nicht standardmäßige Verwendung von 1C-Formularen aktivieren können.

Verwaltete Formulare erstellen 8.2

Das Hinzufügen eines neuen Formulars 1C 8.2 erfolgt auf die gleiche Weise wie zuvor - mit der Einfg-Taste auf der Tastatur oder der Schaltfläche Hinzufügen. Um einen bestehenden einzugeben, doppelklicken Sie darauf mit der Maus.

Standardmäßig wird das Formular (regulär oder verwaltet) erstellt, das in der Konfiguration festgelegt ist (siehe die Eigenschaft Hauptstartmodus in den Konfigurationseigenschaften).

Der Konstruktor fordert Sie auf, den Formulartyp auszuwählen - die Form eines Elements, eine Liste. Hier können Sie Befehlsleisten auf dem Formular hinzufügen oder entfernen. Meistens werden diese Einstellungen standardmäßig beibehalten.

Ein standardmäßig ausgefülltes Formular wird geöffnet - alle Details des 1C-Objekts, die ihm hinzugefügt wurden. Auf der zweiten Registerkarte des Konstruktors können Sie eine bestimmte Liste erforderlicher Felder abhaken.

Der Formulareditor besteht aus drei Abschnitten.

In der oberen linken Ecke befindet sich eine Liste von Formularelementen. Es besteht aus Feldern, Befehlen und Gruppen, mit denen Sie Elemente kombinieren können. Die Liste der Befehle kann separat auf der Registerkarte Befehlsschnittstelle angezeigt werden.
In der oberen rechten Ecke befindet sich eine Liste der verfügbaren Formularattribute und Objektattribute (öffnen Sie das Kreuz neben dem Objektattribut).
Unten sehen Sie eine Vorschau des resultierenden Formulars.

Sie können die verfügbaren Details nach links ziehen und sie werden zu einem Formularelement (einem Feld im Formular).

Wenn Sie eine Schaltfläche oder ein Menüelement hinzufügen möchten, müssen Sie auf der rechten Seite der Registerkarte „Befehle“ einen neuen Befehl erstellen. Dies ist ein Wrapper für eine Funktion in einem Formularmodul. Neben der Angabe, welche Funktion tatsächlich aufgerufen wird, können Sie eine Darstellung – beispielsweise ein Bild – sowie die Abhängigkeit der Sichtbarkeit von einer Funktionsoption zuweisen.

Befehle werden ebenfalls nach links gezogen. Wenn das übergeordnete Element eine Befehlsleiste ist, dann ist es eine Befehlsleistenschaltfläche – andernfalls nur eine Schaltfläche.

In der Liste der Formularelemente (Felder) können Sie das Attribut des Objekts/Formulars nicht nur ziehen, sondern auch einfach hinzufügen (Schaltfläche Hinzufügen oder Einfügen). Insbesondere können Sie ein neues Formularobjekt erstellen – eine Gruppe.

Die Gruppe kann ein Befehlsfeld sein (der Cursor muss sich in der Formularzeile befinden). Dann ziehen Sie Befehle hinein und sie werden zu Schaltflächen.

Die Gruppe kann "regulär" sein. Dann ist es eine Möglichkeit, Felder sowohl vertikal als auch horizontal zu gruppieren. Der Name der Gruppe kann in den Eigenschaften entfernt werden.

Die Gruppe kann ein Panel (Seiten) sein. Die oberste hinzugefügte Gruppe ist ein Panel, und verschachtelte Gruppen dieses Typs sind Seiten. Felder werden bereits auf die Seiten gezogen.

Unnötige Formularelemente werden durch Löschen der Formularelemente in der Liste entfernt.
Die Position des Feldes auf dem Formular wird durch die Reihenfolge in der Liste der Elemente (vertikal) oder durch Gruppen (horizontal) bestimmt. Breite und Höhe werden in den Eigenschaften des Formularelements eingestellt.

Die Eigenschaften der Formularelemente wurden stark erweitert und enthalten viele nützliche Dinge - sowohl die Steuerung des Aussehens (Auswahl- und Löschschaltflächen) als auch die Überprüfung der Standardwerte.

Die Eigenschaften des Formulars selbst, einschließlich seiner Abmessungen, werden am Stammelement des Formulars mit dem gleichen Namen Formular festgelegt.

Event-Handler (Antworten auf Benutzeraktionen) werden jetzt in zwei Typen unterteilt. Alte - wie bisher werden sie in den Eigenschaften des Formulars und der Felder angegeben (z. B. OnChange und OnOpening des Formulars). Neu - sind zu Befehlen geworden und werden für Menüpunkte und Schaltflächen verwendet.

Ab Plattformversion 8.2 begann 1C, neue Prinzipien für den Aufbau der Benutzeroberfläche und die Benutzerinteraktion mit der Datenbank zu verwenden. Die neue Technologie heißt Managed Application. Die Mechanismen zum Erstellen von Formularen und das Interaktionsschema zwischen dem Benutzer des 1C-Servers und der Datenbank wurden am stärksten verarbeitet. Der normale Modus wird weiterhin von der Plattform unterstützt, aber im Laufe der Zeit werden alle 1C-Benutzer zu verwalteten Formularen wechseln.

Für normale Benutzer unterscheidet sich die verwaltete Form des 1C-Dokuments nur im Aussehen von der üblichen. Für den Entwickler ist dies ein neuer Mechanismus mit eigenen Regeln, Gesetzen und Bedingungen. Viele Bereiche haben sich geändert, aber die folgenden Neuerungen gelten unter erfahrenen 1C-Entwicklern als Schlüssel:

Eigenständige Gestaltung der Formularstruktur und Platzierung der Felder durch die Plattform. Beschrieben frühere Entwickler die Position des Feldes durch die Angabe von Pixeln, kann jetzt nur noch die Art der Gruppierung angegeben werden;
Das Formular besteht aus Attributen, die die Formulardaten darstellen, und aus Befehlen – ausgeführten Prozeduren und Funktionen;
Der Formularcode wird sowohl auf der Server- als auch auf der Clientseite ausgeführt. Schließlich ist das Formular selbst ein Konfigurationsobjekt, das auf dem Server erstellt und auf dem Client angezeigt wird. Das bedeutet, dass es die Client- und Server-Teile kombiniert;
Auf der Client-Seite sind viele Datentypen nicht mehr verfügbar, und jetzt gibt es keine Möglichkeit mehr, die Daten in der Infobase zu ändern;
Für jede Prozedur oder Funktion muss eine spezielle Einstellung angegeben werden - eine Kompilierungsdirektive. Sie ist verantwortlich für den Ort, an dem der Code ausgeführt wird und kann folgende Werte annehmen:
- auf dem Client;
- Auf dem Server;
- Auf ServerWithoutContext;
- AufClientAufServer;
- Auf Client Auf Server Ohne Kontext.

Der letzte Punkt ist besonders akut im Modus verwalteter Formulare. Wenn ein Entwickler mit Anweisungen oder Client-Server-Interaktionen nicht vertraut ist, wird es für ihn äußerst schwierig, ein verwaltetes Formular zu erstellen. Alle neuen Prinzipien zum Erstellen verwalteter Formulare in 1C:Enterprise 8.3 werden durch das allgemeine Konzept einer dreistufigen Architektur vereint. Es umfasst Client-Computer, einen 1C-Server und ein DBMS, in dem Daten gespeichert werden.

Auch die Bearbeitung eines verwalteten Formulars im Konfigurator ist anders geworden. Viele Aspekte haben sich geändert und die Entwickler der Version 7.7, in der es keine verwalteten Formulare gab, könnten überrascht sein. Sogar das Erscheinungsbild des Formulardesigners hat sich geändert, was beim Öffnen eines der Formulare des Konfigurationsobjekts zu sehen ist. Beim Öffnen eines Objekts sehen wir ein Fenster, das in mehrere Abschnitte unterteilt ist:

Schnittstellenelemente bilden. Oben links befindet sich ein Fenster, das alle auf dem ausgewählten Formular angezeigten Felder auflistet, die die Interaktion des Programms mit dem Benutzer gewährleisten;
Formulardetails. Oben rechts sind alle Daten, mit denen das Formular arbeitet. In ihnen werden Informationen auf der Client-Seite gespeichert;
Anzeigen eines verwalteten Formulars. Unten sehen wir eine Vorschau des Aussehens basierend auf den Elementen der Benutzeroberfläche;
Formularmodul. Ein Abschnitt, der die von diesem Formular verwendeten Prozeduren und Funktionen enthält. Hier finden Sie den Code der Algorithmen für die Interaktion des Programms mit dem Benutzer und der Datenbank.

1C-Entwickler bewegen Kunden dazu, auf verwaltete Formulare umzusteigen, sodass das Erlernen der Prinzipien der Entwicklung verwalteter Formulare nur eine Frage der Zeit ist. Wenn Sie mit dieser Art von Formularen arbeiten, werden Sie verstehen, dass dies ein Schritt in Richtung Standardisierung der Entwicklung und Einhaltung einheitlicher Regeln ist. Daher erhöht die Fähigkeit, mit verwalteten Formularen in 1C 8.3 zu arbeiten, Ihr Niveau als 1C-Entwickler.

Richtlinien zum Entwerfen verwalteter Formulare

Um den Mechanismus des verwalteten 1C-Modus zu verstehen, sollten Sie zunächst daran denken, dass das Formular sowohl auf dem Server als auch auf dem Client vorhanden ist. Darüber hinaus ist dieses Objekt auf dem Client nur ein Abbild der Bmit dem Programm. Alle Berechnungen, Algorithmen, Berechnungen und Verarbeitungen müssen nur serverseitig erfolgen. Dies ergibt sich nicht nur aus der Unmöglichkeit, viele Funktionen und Parameter auf dem Client zu nutzen, sondern auch aus den Performance-Anforderungen.

Wo die Prozedur ausgeführt wird, erkennen Sie am Namen der Direktive, die vor jede Prozedur und Funktion im Formularmodul geschrieben werden muss. Der Wortlaut „Ohne Kontext“ weist darauf hin, dass die Daten auf dem verwalteten Formular nicht an diese Prozedur auf dem Server weitergegeben werden. Daher ist es bei solchen Verfahren nicht möglich, Algorithmen basierend auf den vom Benutzer eingegebenen Werten zu schreiben. Wird dieser Wortlaut nicht angegeben, so wird das Formular komplett mit allen Angaben übermittelt und Sie können darauf zugreifen.

1C-Entwickler empfehlen dringend, Nicht-Kontext-Serveraufrufe zu verwenden, ihre Anzahl so weit wie möglich zu reduzieren und zu versuchen, keine Berechnungen auf dem Client durchzuführen. Für unerfahrene Entwickler ohne theoretischen Hintergrund ist es schwierig, all diese Regeln einzuhalten und den Code korrekt zu ändern. Bevor Sie anfangen, alleine zu arbeiten, ist es hilfreich, ein verwaltetes Konfigurationsformular zu öffnen, sich die Syntax und die Interaktion von Client und Server anzusehen.

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

Die neuen Regeln für die Entwicklung von 1C-Formularen werden von großem Nutzen sein, wenn sich alle Entwickler daran halten. Darüber hinaus werden alle die Veränderungen zum Besseren spüren - sowohl Programmierer als auch Unternehmen, die in 1C arbeiten, sowie Franchisenehmer und 1C-Entwickler. Die Hauptfolgen des korrekten Betriebs verwalteter Formulare in 1C:

Einfache Konfigurationswartung und verbesserte Lesbarkeit des Codes. Daraus können wir schließen, dass ein von einem Entwickler geschriebener Algorithmus immer ohne großen Zeitaufwand von einem anderen Mitarbeiter korrigiert werden kann;
Trennung von Code, der auf Client und Server ausgeführt wird. Angesichts der unterschiedlichen Funktionen, die auf jeder dieser Seiten verfügbar sind, wäre es der richtige Schritt, sie zu trennen.
Entwickler verfügen über ein tieferes Verständnis der Plattformlogik, der Client-Server-Interaktionen und der von ihnen geschriebenen Algorithmen. In den Versionen 8.0 und früher war es sehr üblich, Formen von Dokumenten oder Verzeichnissen zu finden, die entwickelt wurden, ohne den Client-Server-Teil zu verstehen;
Beschleunigung von Konfigurationen und Entlastung der Client-Computer;
Reduzierung der Anschaffungskosten von Computern für Arbeitsplätze, da keine leistungsstarken PCs angeschafft werden müssen.

Die Wahl eines verwalteten Formulars als Hauptstartmodus von 1C kann viele Überraschungen mit sich bringen. Aber mit dem richtigen Ansatz wird dieser Schritt große Dividenden bringen, sodass sich immer mehr 1C-Benutzer in ganz Russland dafür entscheiden. In Anbetracht der Tatsache, dass das 1C-Unternehmen in Zukunft auf die Entwicklung verwalteter Formulare setzt, ist es riskant, bei veralteten herkömmlichen Formularen zu bleiben.

1c 8.3 verwaltete Formularereignisse. Unter der Haube von Managed Forms