Beschreibung der kontrollierten Formen UV 1s. StavAnalit

Wir alle wissen, dass das Unternehmen 1C viele verschiedene Versionen der 1C-Plattform hatte; wir werden uns nun für eine der neuesten Versionen zum Zeitpunkt des Schreibens dieses Artikels interessieren, das sind die Versionen 1C 8.2 und 1C 8.3. Wenn Sie mit beiden Versionen arbeiten mussten, dann höchstwahrscheinlich bemerkte Unterschiede in den Schnittstellen dieser Versionen, für Benutzer unterscheiden sie sich nur im Aussehen. Im Wesentlichen eine Wahl reguläre oder verwaltete Anwendung teilt dem System mit, welche Formulare angezeigt und ausgeführt werden sollen, regelmäßig oder kontrolliert, sowie welcher Anwendungsclient standardmäßig verwendet wird, dick oder dünn. Ausführlichere Informationen zu Clients finden Sie im Artikel „Was sind Thick- und Thin-Clients in 1C und welche Unterschiede gibt es?“

Reguläre 1C-Anwendung (reguläre Formulare, reguläre Schnittstelle, Version 1C 8.2)

In 1C 8.2 ist es nur möglich, zu arbeiten mit regulären Formen, im regulären Anwendungsmodus. Das Bild unten zeigt die Datenbank im Betriebsmodus „reguläre 1C-Anwendung“ (reguläre Formulare).

Verwaltete 1C-Anwendung (verwaltete Formulare, verwaltete Schnittstelle, Version 1C 8.3)

Auf der 1C 8.3-Plattform können wir sowohl mit regulären Formularen (im Kompatibilitätsmodus) als auch mit verwalteten Formularen arbeiten. Darüber hinaus Verwaltete Formulare verfügen über zwei Anzeigearten: Standard und Taxi. Unten ist ein Beispiel für eine 1C 8.3-Konfiguration mit standardmäßig verwalteten Formularen dargestellt. Anschließend wird die „Taxi“-Schnittstelle angezeigt.

Was ist der Unterschied zwischen einer regulären und einer verwalteten 1C-Anwendung?

Wie wir bereits herausgefunden haben Eine reguläre Anwendung und eine verwaltete Anwendung sind diese Arten des Startens eines 1C-Programms. Darüber hinaus abhängig vom Wert des 1C-Starttyps ( reguläre oder verwaltete Anwendung), wird standardmäßig eine bestimmte Schnittstelle geladen ( reguläre oder verwaltete Formen), daher gibt es so viele Synonyme für dieses Konzept. Wir möchten darauf hinweisen, dass die Unterschiede bei den Schnittstellen recht groß sind; die verwaltete Schnittstelle wurde komplett neu gestaltet. Im Prinzip sind das alle Unterschiede, die normale Benutzer des 1C-Programms sehen. Für Programmierer erfordert die verwaltete Schnittstelle das Schreiben von geändertem Code, da die Entwicklung bereits in 1C 8.3 und nicht in 1C 8.2 durchgeführt wird, was alle daraus resultierenden Konsequenzen mit sich bringt. Der Code muss außerdem in Client und Server unterteilt werden, dies wird durch entsprechende Anweisungen im Konfigurator angezeigt.

Mit der Einführung der 1C Enterprise 8.2-Plattform hat sich der Mechanismus zur Entwicklung der Benutzeroberfläche erheblich verändert. Es wurde möglich, verwaltete Formulare und Anwendungen zu erstellen (Abbildung 1).

Bild 1

Darüber hinaus wird ein neues System zur Aufteilung der Funktionalität zwischen der Clientanwendung 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. Verwaltete Formulare zeichnen sich zunächst dadurch aus, dass sie aufgrund spezieller Einstellungen automatisch vom System erstellt werden; der Programmierer muss nun nicht jedes Formular im Detail zeichnen. Die gesamte Funktionalität des Formulars wird in Form von Details und Befehlen beschrieben. Details sind die Daten, mit denen das Formular arbeitet, und Befehle sind die auszuführenden Aktionen. Für jede Methode oder Formularvariable muss eine Kompilierungsanweisung angegeben werden, die den Ausführungsort (Client oder Server) bestimmt. Kompilierungsanweisungen können wie folgt lauten:

&OnClient,
&Auf dem Server,
&OnServerWithoutContext,
&OnClientOnServerWithoutContext.

Ein verwaltetes Formular unterscheidet sich von einem regulären Formular auch durch die Datentypen, mit denen es arbeitet. Wenn die Normalform mit den meisten von 1C: Enterprise bereitgestellten Typen funktioniert (einschließlich der Typen DirectoryObject, DocumentObject usw.), dann können in der verwalteten Form die folgenden Typenkategorien 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, DirectoryLink.Products, GraphicScheme, TabularDocument);
Typen, die in spezielle Datentypen konvertiert werden – verwaltete Formulardatentypen. Solche Typen werden in der Liste der Formulardetails in Klammern angezeigt, zum Beispiel (DirectoryObject.Products);
dynamische Liste.

Die Funktionsweise kontrollierter Formen 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).

Das Formular funktioniert nicht mit Anwendungsobjekten

Figur 2

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

Figur 3

Anwendungsobjekte funktionieren nur auf dem Server und nur während der Ausführung bestimmter Vorgänge.
Beim Öffnen des Formulars:

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

Bei der Aufnahme:

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

Nehmen wir an, es gibt eine externe Verarbeitung, die für Version 8.1 geschrieben wurde. Ist es möglich, es in 8.2 auszuführen, sodass es mit seiner älteren, nicht verwalteten Form funktioniert? Die Verarbeitung ist nur einmal erforderlich, um Daten zu übertragen, und Sie möchten nicht nur einmal ein verwaltetes Formular dafür erstellen ...

Für die externe Verarbeitung (geöffnet aus einer separaten Datei) im verwalteten Modus wird die Verwendung regulärer Formulare nicht unterstützt. Wenn es also in einer Konfiguration im verwalteten Modus erforderlich ist, die Verarbeitung mit einem nicht verwalteten Formular zu starten, und Sie für diese Verarbeitung kein neues, verwaltetes Formular erstellen möchten, muss diese Verarbeitung zunächst in die Konfiguration einbezogen werden.

Reguläre (nicht verwaltete) Formulare können nur im Thick Client funktionieren. Thin- und Web-Clients unterstützen nur verwaltete Formulare.

Wenn Sie daher ein reguläres Verarbeitungsformular in der verwalteten Anwendungsschnittstelle öffnen müssen, ist dies nur in einem Thick-Client möglich, der im verwalteten Anwendungsmodus ausgeführt wird.

Am einfachsten ist es, den Thick Client im verwalteten Anwendungsmodus über den Konfigurator zu starten und dies in den Parametern anzugeben: Dienst – Optionen – 1C:Enterprise starten – Basic – Thick Client (verwaltete Anwendung).

Beachten Sie jedoch, dass das Starten von Clients im verwalteten Modus nur möglich ist, wenn in der Konfiguration die Kompatibilität mit Version 8.1 deaktiviert ist (Eigenschaft Kompatibilitätsmodus).

Dies reicht jedoch nicht aus, damit die Plattform die alte, nicht verwaltete Form der Verarbeitung erschließen kann.

Die Möglichkeit, reguläre Formulare in einem kontrollierten Modus zu verwenden, wird durch eine spezielle Konfigurationseigenschaft geregelt – Verwenden Sie normale Formulare in einer verwalteten Anwendung. Diese Eigenschaft muss festgelegt werden.

In der Kowird diese Eigenschaft nicht immer angezeigt, sondern nur, wenn in den Konfiguratorparametern der Konfigurationsbearbeitungsmodus Verwaltete Anwendung und reguläre Anwendung ausgewählt ist ( Service – Optionen – Allgemein).

Und schließlich muss das Objekt, dessen normale Form Sie im verwalteten Modus sehen möchten, über eine einzige Hauptobjektform verfügen, und diese Form muss normal und nicht verwaltet sein.

In anderen Fällen (wenn das Objekt kein Hauptformular hat oder das Objekt ein verwaltetes Hauptformular hat) generiert oder öffnet die Plattform standardmäßig das verwaltete Formular (falls vorhanden).

Das Hauptproblem besteht darin, dass im Laufe von 10 bis 15 Jahren bereits viel Code für gewöhnliche Formulare kompiliert wurde. Niemand möchte das alles auf dem Client-Server neu schreiben + viele Leute sind im Umgang mit der Schnittstelle geschult. Der obligatorische Übergang zu BP 3.0 ab dem nächsten Jahr löst bei Entwicklern und Buchhaltern Panik aus. Das Feedback wird sehr unangenehm sein. Darüber hinaus steigt die Hürde für den Berufseinstieg, das Programmieren wird schwieriger und Standardaufgaben sind noch schwieriger geworden. Was kostet der neue Algorithmus in Standarddokumenten? UV sieht gut aus, wenn Sie zwei bis drei Schaltflächen auf Dokumenten haben. UV eignet sich hervorragend für die Arbeit auf mobilen Geräten, aber nur 0,01 % der Unternehmen nutzen es. Sie müssen wechseln, wenn 1C nichts Neues einbringt, aber es wird langwierig und für alle schmerzhaft sein. Und die Unternehmen müssen das Geld selbst bezahlen.

Auch ich habe von kontrollierten Formen bisher nur Negatives erfahren, hier noch einige weitere Nachteile der Neuerung:

Nichts? Nun, ich bin ein paar Mal darauf gestoßen, zum Beispiel beim Schreiben und Anhängen eines externen Druckformulars an die ZUP-Konferenz. Die Verarbeitung dort ist ein ganzes Epos voller Anweisungen im Internet und seitenweise Code.
Auf einem Thick-Client gibt es eine Prozedur mit Parametern, d. h. Die Entwicklung ist eine Sache von Minuten.
und die Bremsen sind dünn, mit bloßem Auge sichtbar
Was die Möglichkeit betrifft, überschaubare Formulare vorzubereiten – das ist Kunst um der Kunst willen, aber wo liegt der praktische Sinn, insbesondere bei der Dateiversion?
Ich habe drei Jahre lang in UV modelliert, aber jetzt bin ich wieder zu einfachen Formen übergegangen, und glauben Sie mir, dieser Übergang war psychologisch ziemlich schwierig, aber das ist meine bewusste Entscheidung, denn was 1c in UV bietet, ist völlig UG…. Vielleicht schafft 1c in ein paar Jahren den Durchbruch, aber jetzt sucht sie nur noch nach dem Ort, an dem dieser Durchbruch gelingt ...
Das Öffnen von UVs im Konfigurator dauert deutlich länger.
Danach gleicht das Öffnen von Formularen in 8.1 dem Umsteigen von einem LKW in ein Flugzeug!
Es gibt mehr Probleme für alle, Benutzer sind schockiert über die neue Benutzeroberfläche (nicht jeder gibt es zu, aber bei kleineren Dingen sind sie viel dümmer), die Hälfte der Programmierer ist für Professionalität ungeeignet geworden, für den durchschnittlichen Spezialisten ist es schwieriger geworden einen Job finden und wie man ein Qualitätsprodukt herstellt. Und das coolste Marketingthema von UV ist, dass sie überall dort auftauchen, wo der Übergang mit einem einfachen Update erfolgt, aber jeder vergisst, dass man von Anfang an über die neuesten Versionen informiert sein muss! Aber grundsätzlich gefällt mir die Idee!
Ich weiß es nicht, meine Erfahrung zeigt das Gegenteil. Während die Booms in strengen Formen seit einigen Jahren automatisch zuschlagen, beginnt bei den neuen UV-Standards jeden Monat „Warum, wo ist 1C jetzt nach der Aktualisierung dieser Schaltfläche und warum funktioniert es jetzt nicht mehr“, was, wie Sie sehen, so ist , erhöht die Geschwindigkeit nicht.
- Es gibt mehr Code
- Der Code ist komplexer geworden
— Die Änderung von Standardversionen ist viel schwieriger
- Die Benutzer, denen ich UT11 gegeben habe, fanden keine Vorteile gegenüber 10.x
– aber sie fanden einige Verlangsamungen und einen Mangel an einigen Funktionen wie der Suche (aus irgendeinem Grund wollten sie eine Vorwärts-Rückwärts-Suche und keine Auswahl)
Meiner Meinung nach sind die Abstriche zugunsten des Web-Clients und der Tablets zu groß. Darüber hinaus habe ich persönlich noch keine echte Arbeit mit einem Web-Client gesehen, der den Fernzugriff erfolgreich nutzen muss
Das Client-Server-Chaos sollte zu einer Steigerung der Leistung und Skalierbarkeit führen, während gleichzeitig die Kosten einen Anstieg der Codierung mit sich bringen.
Allerdings erlebten nicht alle einen Anstieg, daher die Enttäuschung. Und gleichzeitig waren alle auf die Codierungskosten bedacht.
P.S. Eigentlich mag ich die kontrollierten, ich zeichne in aller Ruhe darauf. Aber die typischen sind pervers geworden.
Zu Hause (normaler Computer) führe ich mein Trinken nach den Vorgaben einzelner Unternehmer durch.
8.3, BP3, kariert. Der Haupteindruck ist, dass ich nicht arbeite, sondern die ganze Zeit warte. Hämorrhoidalreaktion. Der SALT für das Konto ist einfach erstaunlich – es wirkt wie eine Kontokarte für das Jahr in einer Mega-Holding.
UT11 ist eine wilde Bremse, Horror und im Allgemeinen ein Albtraum.
UT10 fliegt im Vergleich zu UT11.
Apropos UV - seit Jahren wimmelt es von Wanzen, alles ist schief, Spalten passen nie auf einen Bildschirm, Dehnung ist in vielen Fällen furchtbar.
Und ich kann noch viele Minuspunkte aufzählen, aber zu den Pluspunkten werde ich wahrscheinlich nichts sagen. Sie existieren einfach nicht.
Firmen haben sich gezielt für diese Formulare entschieden, weil die Entwicklung teurer ist, es keine Sonderangebote und keine normalen gibt.

Es gibt wenige Vorteile, aber natürlich gibt es sie...

Profis:

Die Antwort gibt es schon seit langem, was die UP gab:

Cross-Plattform-Client

Arbeiten an schlechten Kommunikationsleitungen
Möglichkeit, über einen Browser zu arbeiten (ohne einen Client zu installieren)

Und Datenübertragungsobjekt zur Codestrukturierung, kontrollierte 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. Plattformkenner sollten diesen Abschnitt vielleicht überspringen.

Im Jahr 2008 wurde eine neue Version der 1C-Plattform verfügbar: Enterprise 8.2 (im Folgenden als Managed Application bezeichnet), die die gesamte Arbeitsebene mit der Schnittstelle völlig verändert. Dazu gehören die Befehlsschnittstelle, Formulare und das Fenstersystem. Gleichzeitig ändert sich nicht nur das Modell zur Entwicklung der Benutzeroberfläche in der Konfiguration, sondern es wird auch eine neue Architektur zur Trennung der Funktionalität zwischen der Clientanwendung 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

Die verwaltete Anwendung verwendet Formulare, die auf neuer Technologie basieren. Sie heißen Verwaltete Formulare. Um den Übergang zu erleichtern, werden auch frühere Formulare (die sogenannten regulären Formulare) unterstützt, deren Funktionalität jedoch nicht weiterentwickelt wird und sie nur im Thick-Client-Startmodus verfügbar sind.
Die Hauptunterschiede verwalteter Formulare für einen Entwickler:

Deklarative, nicht „pixelweise“ Beschreibung der Struktur. Die konkrete Platzierung der Elemente erfolgt automatisch durch das System bei der Anzeige des Formulars.
Alle Funktionen des Formulars werden wie folgt beschrieben Einzelheiten Und Mannschaften. Details sind die Daten, mit denen das Formular arbeitet, und Befehle sind die auszuführenden Aktionen.
Das Formular läuft sowohl auf dem Server als auch auf dem Client.
Im Client-Kontext sind fast alle Anwendungstypen nicht verfügbar und dementsprechend ist es nicht möglich, die Daten in der Infobase zu ändern.
Für jede Methode oder Formularvariable muss diese angegeben werden Kompilierungsanweisung, Definieren des Ausführungsorts (Client oder Server) und Zugriff auf den Formularkontext.

Lassen Sie uns die Anweisungen zum Kompilieren von Formularmethoden auflisten:

&OnClient
&Auf dem Server
&OnServerWithout Context
&OnClientOnServerWithout Context

Lassen Sie uns das oben Gesagte veranschaulichen. Der Screenshot zeigt ein Beispiel eines verwalteten Formulars und seines Moduls im Entwicklungsmodus. Finden Sie die deklarative Beschreibung, Requisiten, Kompilierungsanweisungen usw.

Alle weiteren Diskussionen drehen sich um die rechte Seite der Abbildung, um die Strukturierung des Modulcodes und um die Prinzipien, mit denen Sie eine effektive Client-Server-Interaktion implementieren können.

Definieren wir das Problem

Es sind mehrere Jahre vergangen, seit die neue Version der 1C-Plattform aktiv genutzt wird 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 der Ansatz zur Implementierung von Softwaremodulen in den neuen architektonischen Realitäten verändert?

Schauen wir uns die Codestruktur (Formularmodul) in mehreren Formen derselben Standardkonfiguration an und versuchen, Muster zu finden.
Mit Struktur meinen wir Codeabschnitte (meistens handelt es sich dabei um Kommentarblöcke), die vom Entwickler den Gruppenmethoden und Kompilierungsanweisungen für diese Methoden zugewiesen werden.
Beispiel 1:
Abschnitt der Ereignishandler. Methode – auf dem Client. Methode – auf dem Server. Methode – auf dem Client. Abschnitt der Dienstprozeduren und -funktionen. Hilfsfunktionen zur Eingabesteuerung
Beispiel 2:
Serviceabläufe und Funktionen Zahlungsdokumente Werte Eventhandler
Beispiel 3:
Dienstprozeduren auf dem Server Dienstprozeduren auf dem Client Dienstprozeduren auf dem Server ohne Kontext Header-Ereignishandler Befehlsereignishandler
Beispiel 4:
Allzweckprozeduren Formular-Ereignishandler Prozeduren des Subsystems „Kontaktinformationen“.
Im Wesentlichen fehlt die Codestruktur, oder um es milde auszudrücken, sie ähnelt der in Forms 8.1:

Nicht informative Wörter „Allgemeines, Service, Hilfsprogramm“.
Scheue Versuche, Client- und Servermethoden zu trennen.
Methoden werden häufig nach Oberflächenelementen „Arbeiten mit dem tabellarischen Teil Produkte, Kontaktinformationen“ gruppiert.
Beliebige Anordnung von Methoden und Codegruppen. Event-Handler können beispielsweise in einem Formular oben stehen, in einem anderen unten, in einem dritten überhaupt nicht hervorgehoben usw.
Und vergessen wir nicht, dass dies alles in einer Konfiguration geschieht.
Ja, es gibt Konfigurationen, in denen die Worte „General, Service, Auxiliary“ immer an den gleichen Stellen stehen, aber...

Warum brauchen Sie eine Codestruktur?

Vereinfachung der Wartung.
Vereinfachen Sie das Lernen.
Aufzeichnen allgemeiner/wichtiger/erfolgreicher Grundsätze.
...Ihre Option

Warum hilft der bestehende Entwicklungsstandard von 1C nicht?

Schauen wir uns die auf ITS-Disketten und in verschiedenen „Entwicklerhandbüchern“ veröffentlichten Prinzipien an, die beim Schreiben eines verwalteten Formulars empfohlen werden.

Minimieren Sie die Anzahl der Serveraufrufe.
Maximale Rechenleistung auf dem Server.
Nicht kontextbezogene Serveraufrufe sind schneller als kontextbezogene.
Programm mit Blick auf die Client-Server-Kommunikation.
usw.

Das sind Slogans, die absolut wahr sind, aber wie setzt man sie um? Wie kann die Anzahl der Aufrufe minimiert werden? Was bedeutet es, im Client-Server-Modus zu programmieren?

Designmuster oder Generationenweisheit

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

Fernfassade(im Folgenden als Remote Access Interface bezeichnet)
Datenübertragungsobjekt(im Folgenden Datentransferobjekt genannt)

Ein Wort von Martin Fowler, seine Beschreibung dieser Prinzipien:

… Jedes potenziell für den Fernzugriff vorgesehene Objekt muss über Folgendes verfügen: Schnittstelle mit geringer Granularität, wodurch die Anzahl der Aufrufe minimiert wird, die zum Ausführen einer bestimmten Prozedur erforderlich sind. ... Anstatt eine Rechnung und alle ihre Positionen einzeln anzufordern, müssen Sie alle Rechnungspositionen in einer Anfrage lesen und aktualisieren. Dies wirkt sich auf die gesamte Struktur des Objekts aus... Denken Sie daran: RAS-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 Datentransferobjekte!“ In den meisten Fällen sind Datenübertragungsobjekte nichts anderes als aufgeblähter Feldsatz... Der Wert dieses ekelhaften Monsters liegt allein in der Möglichkeit Übertragen Sie mehrere Informationen in einem Anruf über das Netzwerk- eine Technik, die für verteilte Systeme von großer Bedeutung ist.

Beispiele für Vorlagen in der 1C-Plattform

Die Anwendungsprogrammierschnittstelle, die dem Entwickler bei der Entwicklung eines verwalteten Formulars zur Verfügung steht, enthält viele Beispiele dieser Prinzipien.
Zum Beispiel die OpenForm()-Methode, eine typische „raue“ Schnittstelle.
OpeningParameters = Neue Struktur("Parameter1, Parameter2, Parameter3", Wert1, Wert2, Wert3); Form = OpenForm(FormName, OpeningParameters);
Vergleichen Sie mit dem in Version 8.1 übernommenen Stil.
Form = GetForm(FormName); Form.Parameter1 = Wert1; Form.Parameter2 = Wert2; Form.Open();

Im Kontext eines verwalteten Formulars gibt es viele „Datenübertragungsobjekte“. Sie können auswählen systemisch Und Vom Entwickler definiert.
Systemmodelle modellieren ein Anwendungsobjekt auf dem Client in Form eines oder mehrerer Formulardatenelemente. Es ist unmöglich, sie ohne Bezugnahme auf die Formulardetails zu erstellen.

DataFormsStructure
DataFormsCollection
DataFormStructureWithCollection
DataShapesTree

Die Konvertierung von Systemdatenübertragungsobjekten in Anwendungstypen und umgekehrt erfolgt mit folgenden Methoden:

ValueInFormData()
FormDataValue()
CopyFormData()
ValueInFormAttributes()
FormAttributesValue()

Bei der Anpassung einer bestehenden Lösung kommt häufig eine explizite Konvertierung zum Einsatz. Methoden können Eingabeparameter wie ValueTable anstelle von FormDataCollection erwarten (Funktionen verwenden), oder die Methode wurde im Kontext eines Anwendungsobjekts definiert und ist für den direkten Aufruf aus dem Formular nicht mehr verfügbar.
Beispiel 1C v8.1:
// auf dem Client im Kontext des Formulars FillUserCache(DepartmentLink)
Beispiel 1C v8.2:
// auf dem Server im Kontext des Formulars ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueFormAttributes(ProcessingObject, "Object");

Datenübertragungsobjekte, deren Struktur vom Entwickler festgelegt wird, sind eine kleine Teilmenge der sowohl auf dem Client als auch auf dem Server verfügbaren Typen. Am häufigsten werden als Parameter und Ergebnisse von Methoden einer „vergröberten“ Schnittstelle verwendet:

Primitive Typen (String, Zahl, Boolescher Wert)
Struktur
Korrespondenz
Array
Links zu Anwendungsobjekten (eindeutige Kennung und Textdarstellung)

Beispiel: Die Methode akzeptiert eine Liste von Anweisungen zur Statusänderung und gibt eine Beschreibung der Fehler an den Client zurück.
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [Bestellung][Fehlerbeschreibung] Für jede Bestellung aus dem Auftragszyklus StartTransaction(); Versuchen Sie es mit DocOb = Order.GetObject(); …. andere Aktionen, nicht nur mit der Bestellung möglich... Exception CancelTransaction(); Errors.Insert(Order, ErrorDescription()); EndAttempt; EndCycle; Rückgabefehler; EndFunction // ServerChangeOrderStatus()

Den Code strukturieren

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

Klare Trennung von Client- und Servercode. Vergessen wir nicht, dass es sich zum Zeitpunkt der Ausführung um zwei interagierende Prozesse handelt, die jeweils über deutlich unterschiedliche verfügbare Funktionen verfügen.
Eindeutige Identifizierung der RAS-Schnittstelle, welche Servermethoden können vom Client aufgerufen werden und welche nicht? Die Namen von Remote-Schnittstellenmethoden beginnen mit dem Präfix „Server“. Dadurch können Sie beim Lesen des Codes sofort erkennen, wie die Kontrolle an den Server übertragen wird, und die Verwendung kontextbezogener Hilfe wird vereinfacht. Beachten Sie, dass die offizielle Empfehlung (ITS) die Benennung von Methoden mit Postfixen vorschlägt, beispielsweise ChangeOrderStatusOnServer(). Wir wiederholen jedoch, dass nicht alle Servermethoden vom Client aufgerufen werden können und daher die logische Zugänglichkeit wichtiger ist als der Kompilierungsspeicherort. Deshalb markieren wir mit dem Präfix „Server“ nur die Methoden, die dem Client zur Verfügung stehen; nennen wir die Beispielmethode ServerChangeOrderStatus().
Lesbarkeit. Geschmackssache, wir übernehmen den Auftrag, wenn das Modul mit den Verfahren zum Erstellen eines Formulars auf dem Server und den Fernzugriffsmethoden beginnt.
Wartbarkeit. Es muss ein klarer Ort zum Hinzufügen von neuem Code vorhanden sein. Ein wichtiger Punkt ist, dass vom Konfigurator automatisch erstellte Methodenvorlagen am Ende des Moduls hinzugefügt werden. Da Ereignishandler für Formularelemente meist automatisch erstellt werden, befindet sich der entsprechende Block an letzter Stelle, um nicht jeden Handler an eine andere Stelle im Modul zu ziehen.

Nachfolgend finden Sie den Grundaufbau des Moduls, das die aufgeführten Ziele umsetzt.

Grafische Option – zeigt deutlich den Hauptausführungsablauf.
Die Textoption ist ein Beispiel für einen Vorlagenentwurf zum schnellen Einfügen einer Struktur in ein neues Formularmodul.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datum=""/> // <Описание> // // ///////////////////////////////////////////// // ///////////////////////// // MODULVARIABLEN ///////////////// // /////////////////////////////////////////// //// ////////// // AUF DEM SERVER //******* EREIGNISSE AUF DEM SERVER ******* &Auf dem Server Prozedur bei Erstellung auf dem Server (Fehler, Standardverarbeitung) / /Fügen Sie den Inhalt des Handlers ein. Ende der Prozedur //******* REMOTE ACCESS INTERFACE ******* //******* GESCHÄFTSLOGIK AUF DEM SERVER ******* ///////// /////////////////////////////////////////////////////////////////////// /////// /////////////////// // GEMEINSAME METHODEN VON CLIENT UND SERVER /////////////// /////// ///////////////////////////////////////////////////////////////////////// ///// //////// // AUF DEM KUNDEN //******* GESCHÄFTSLOGIK AUF DEM KUNDEN ******* //******* TEAM * ****** //******* KUNDENVERANSTALTUNGEN ******* ///////////////////////// ///// /////////////////////////////////////////////////////////////////////////// // / / HAUPTPROGRAMMBETREIBER