Podstawowe dane formularza. Szczegóły formularza zarządzanego (1Cv8) Formularze zarządzane 1c dodają szczegóły programowo

Szczegóły formularza

Zestaw szczegółów formularza opisuje skład danych wyświetlanych, edytowanych lub przechowywanych w formularzu. Jednocześnie same szczegóły formularza nie dają możliwości wyświetlania i edycji danych. Elementy formularza (patrz sekcja „Elementy formularza” w tym rozdziale) powiązane ze szczegółami formularza służą do wyświetlania i edycji. Zbiór wszystkich szczegółów formularza będzie nazywany danymi formularza.

Ważny! Należy pamiętać, że w odróżnieniu od zwykłych formularzy, wszystkie dane w zarządzanym formularzu muszą być opisane w formie detali. Niedopuszczalne jest wykorzystywanie zmiennych modułu formularza jako źródeł danych dla elementów formularza.

Istnieje możliwość przypisania Podstawowe szczegóły formularza, czyli atrybuty, które będą determinować standardową funkcjonalność formularza (rozszerzenie formularza). Należy pamiętać, że formularz może posiadać tylko jeden atrybut główny.

Rozszerzenie formularza– są to dodatkowe właściwości, metody i parametry formularza obiektu ManagedForm, charakterystyczne dla obiektu będącego głównym elementem formularza.

Podczas procesu tworzenia formularza możesz jawnie ustawić możliwość przeglądania i edytowania określonych szczegółów formularza pod względem ról, korzystając z właściwości Wyświetl i edytuj (więcej szczegółów znajdziesz w sekcji „Ustawienia formularza opartego na rolach” w „Edytorzy " rozdział). Dodatkowo dostępność konkretnego atrybutu w samym formularzu można skonfigurować za pomocą opcji funkcjonalnych (więcej szczegółów na temat opcji funkcjonalnych znajdziesz w rozdziale „Zarządzanie interfejsem konfiguracyjnym”).

Właściwość atrybutu formularza Zapisane dane to znak, że interaktywna zmiana szczegółów doprowadzi do próby zablokowania danych formularza do edycji, a także do automatycznego ustawienia flagi modyfikacji formularza.

Typy danych dostępne w formie zarządzanej

Formularz zarządzany różni się od zwykłego formularza również typami danych, z którymi współpracuje. Jeśli normalna forma działa z większością typów udostępnianych przez 1C:Enterprise (w tym z typami DirectoryObject, DocumentObject itp.), to w formie zarządzanej można wyróżnić następujące kategorie typów:

  • typy używane bezpośrednio w formularzu to typy, które istnieją po stronie klienta cienkiego i internetowego (na przykład Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • typy, które zostaną przekonwertowane na specjalne typy danych — typy danych z zarządzanych formularzy. Tego typu typy są wyświetlane na liście szczegółów formularza w nawiasach, np. (DirectoryObject.Products);
  • lista dynamiczna (więcej szczegółów można znaleźć w części „Lista dynamiczna” w tym rozdziale).

Konwertowanie obiektów aplikacji na dane formularza

Niektóre typy aplikacji (takie jak DirectoryObject itp.) nie istnieją po stronie klienta cienkiego i WWW (więcej szczegółów można znaleźć w rozdziale Koncepcja aplikacji zarządzanych). Dlatego też, aby reprezentować tego typu aplikacje w formularzu, platforma wprowadziła specjalne typy danych przeznaczone do pracy w zarządzanych formularzach. Ta cecha aplikacji zarządzanej powoduje konieczność konwersji obiektów aplikacji na dane (i odwrotnie).

Stosowane są następujące typy danych:

  • Formularz DataStructure – zawiera zestaw właściwości dowolnego typu. Właściwościami mogą być inne struktury, kolekcje lub struktury z kolekcjami. Ten typ jest reprezentowany na przykład w postaci DirectoryObject.
  • FormDataCollection to lista wpisanych wartości, podobna do tablicy. Dostęp do elementu kolekcji uzyskuje się poprzez indeks lub identyfikator. W niektórych przypadkach dostęp za pomocą identyfikatora może nie być możliwy. Wynika to z typu obiektu aplikacji reprezentowanego przez tę kolekcję. Identyfikator może być dowolną liczbą całkowitą. Ten typ jest reprezentowany na przykład w postaci części tabelarycznej.
  • Formularz DataStructureWithCollection to obiekt reprezentowany jednocześnie jako struktura i kolekcja. Można go traktować jak każdy z tych podmiotów. Ten typ reprezentuje na przykład zbiór rekordów w formularzu.
  • Form DataTree – obiekt przeznaczony do przechowywania danych hierarchicznych.

Obiekt aplikacji jest reprezentowany przez jeden lub więcej elementów danych formularza. Ogólnie rzecz biorąc, hierarchia i skład danych formularza zależą od złożoności i wzajemnych powiązań obiektów aplikacji zarządzanego formularza.

Przykładowo dokument zawierający część tabelaryczną będzie reprezentowany przez obiekt typu FormDataStructure (sam dokument), któremu podporządkowany zostanie obiekt typu FormDataCollection (część tabelaryczna dokumentu).

Ważny! Tworząc konfigurację należy pamiętać, że obiekty aplikacji dostępne są tylko na serwerze, natomiast obiekty danych formularzy mogą być wykorzystywane zarówno na serwerze jak i na kliencie.

Przesyłanie danych pomiędzy częścią klienta i serwera zarządzanego formularza

Właściwie można powiedzieć, że dane formularza to ujednolicona reprezentacja danych z różnych obiektów aplikacji, z którymi formularz współpracuje jednolicie i które są obecne zarówno na serwerze, jak i na kliencie. Oznacza to, że formularz zawiera pewną „projekcję” danych obiektu aplikacji w postaci własnych typów danych i w razie potrzeby dokonuje konwersji między nimi. Jeśli jednak twórca konfiguracji zaimplementuje własny algorytm przetwarzania danych, wówczas musi samodzielnie przeprowadzić konwersję danych (z typów specjalistycznych na typy aplikacji i odwrotnie).

Edytując szczegóły formularza w wyspecjalizowanym edytorze (więcej informacji znajdziesz w sekcji „Szczegóły formularza” w rozdziale „Edytory”), istnieje możliwość wpływania na przesyłanie danych pomiędzy klientem a serwerem w trakcie działania formularza. Służy do tego kolumna edytora szczegółów. Zawsze używaj. Efekt tej właściwości różni się w przypadku trzech typów atrybutów:

  • Dla atrybutu podrzędnego listy dynamicznej (kolumna listy dynamicznej):
    • właściwość włączona – atrybut jest zawsze odczytywany z bazy i uwzględniany w danych formularza;
    • właściwość jest wyłączona - atrybut jest odczytywany z bazy i uwzględniany w danych formularza tylko wtedy, gdy z atrybutem lub atrybutem podrzędnym powiązany jest aktualnie widoczny element formularza.
  • Dla rekwizytów podporządkowanych kolekcji ruchu:
    • właściwość jest włączona – ruchy dokumentów będą odczytywane z bazy danych i będą obecne w danych formularza;
    • właściwość jest wyłączona - ruchy dokumentu nie będą odczytywane z bazy danych i nie będą uwzględniane w danych formularza (jeżeli nie ma elementu formularza odwołującego się do ruchów dokumentu).
  • Pozostałe szczegóły formularza:
    • właściwość jest włączona – atrybut będzie obecny w danych formularza, niezależnie od tego, czy z atrybutem jest powiązany przynajmniej jeden element formularza, czy też nie jest on powiązany z atrybutem podrzędnym;
    • właściwość jest wyłączona - atrybut będzie obecny w danych formularza tylko wtedy, gdy z atrybutem lub jego atrybutem podrzędnym powiązany jest element formularza. W odróżnieniu od atrybutów list dynamicznych, widoczność elementu powiązanego z atrybutem nie ma tutaj znaczenia.

Notatka. Należy pamiętać, że właściwość ustawiona na atrybucie nadrzędnym wpływa na wszystkie atrybuty podrzędne. Na przykład, jeśli właściwość Użyj jest zawsze wyczyszczona dla tabelarycznej części dokumentu, system uznaje, że ta właściwość jest również wyczyszczona dla wszystkich podrzędnych szczegółów (pomimo rzeczywistego stanu właściwości).

Metody konwertowania danych obiektów aplikacji na dane formularzy

Aby przekonwertować obiekty aplikacji na dane formularza i odwrotnie, istnieje zestaw metod globalnych:

  • WartośćWFormieDane(),
  • DaneFormularzaWWartości(),
  • KopiujDaneFormularza().

Ważny! Metody pracujące z obiektami aplikacji dostępne są jedynie w procedurach serwera. Metoda kopiowania wartości pomiędzy danymi formularza jest dostępna na serwerze i na kliencie, ponieważ nie wymaga obiektów aplikacji jako parametrów.

Konwertując dane formularza na obiekt aplikacji, należy wziąć pod uwagę ich kompatybilność.

  • ValueInFormData() – konwertuje obiekt typu aplikacji na dane formularza;
  • FormDataInValue() – konwertuje dane z formularza na obiekt typu aplikacji;
  • CopyFormData() – kopiuje dane formularza, które mają zgodną strukturę. Zwraca True, jeśli kopiowanie się powiodło, lub False, jeśli struktura obiektu jest niezgodna.

Notatka. Podczas wykonywania standardowych akcji (otwarcie formularza, wykonanie standardowej komendy Zapisz itp.) formularza z głównymi szczegółami, konwersja odbywa się automatycznie.

Podajmy przykład wykorzystania transformacji danych we własnych algorytmach.

&OnServerProcedure podczas tworzenia na serwerze (awaria, przetwarzanie standardowe)

ObjectProduct = Directories.Products.FindByName("Kawa").GetObject(); ValueInFormData(ObjectItem, Obiekt);

Koniec procedury

&Zapis procedury na kliencie()

WriteOnServer();

Koniec procedury

Procedura &na serwerze WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); Przedmiot.Zapis();

Koniec procedury

Obiekt ManagedForm posiada także metody dostępne na serwerze:

  • Value – FormAttribute() – konwertuje obiekt typu aplikacji na określony atrybut formularza.
  • FormAttributeVValue() – konwertuje atrybut danych formularza na obiekt typu aplikacji.

Korzystanie z tych metod jest zwykle wygodniejsze, ponieważ zawierają one np. informację o rodzaju szczegółów formularza. Dodatkowo metoda Form AttributesValue() ustawia zgodność pomiędzy danymi formularza a obiektem, który jest używany podczas generowania komunikatów. Więcej na ten temat przeczytasz w rozdziale „Możliwości nawigacji serwisu”.

Podajmy przykład zastosowania tych metod.

Procedura &na serwerze Przelicz na serwerze()

// Konwertuje atrybut Object na obiekt aplikacji. Dokument = Wartość atrybutów formularza („Obiekt”); // Wykonuje przeliczenie metodą zdefiniowaną w module dokumentu. Dokument.Przelicz(); // Konwertuje obiekt aplikacji z powrotem na rekwizyt. Wartość–FormAttributes(Dokument, „Obiekt”);

Koniec procedury

Interfejs oprogramowania

Drzewo danych formularza

  • ZnajdźById
  • Pobierzprzedmioty

Opis:

Zaprojektowany do modelowania drzewa w formie zarządzanej danych.

Obiekt ten można serializować do/z XDTO. Typ XDTO odpowiadający temu obiektowi jest zdefiniowany w przestrzeni nazw. Nazwa typu XDTO:

Pobierzprzedmioty

Składnia:

Pobierz przedmioty()

Wartość zwracana:

Typ: Formularz DataCollection elementów drzewa.

Opis:

Pobiera kolekcję elementów drzewa najwyższego poziomu.

Dostępność: klient, serwer, cienki klient, klient sieciowy.

ZnajdźById

Składnia:

ZnajdźById(<Идентификатор>)

Opcje:

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

Typ: Numer. Identyfikator elementu drzewa.

Wartość zwracana:

Typ:FormDataTreeElement.

Opis:

Pobiera element kolekcji według identyfikatora.

Dostępność: klient, serwer, cienki klient, klient sieciowy.

Element drzewa danych formularza

Nieruchomości:

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

  • GetId (GetId)
  • PobierzParenta
  • Pobierzprzedmioty
  • Nieruchomość

Opis:

Element drzewa danych formularza.

Kolekcja FormDataTreeItem

Elementy kolekcji: DataFormTreeElement

Dla obiektu istnieje możliwość poruszania się po kolekcji za pomocą operatora For each... From... Loop. Przejście wybiera elementy kolekcji. Dostęp do elementu kolekcji można uzyskać za pomocą operatora [...]. Indeks elementu jest przekazywany jako argument.

  • Wstawić
  • Dodać
  • Indeks (IndexOf)
  • Liczyć
  • Jasne
  • Dostawać
  • Przenosić
  • Usuwać

Opis:

Kolekcja elementów drewnianych.

Dostępność: klient, serwer, cienki klient, klient sieciowy.

Zobacz też:

  • FormDataTreeElement, metoda GetElements
  • DataFormTree, metoda GetItems

Funkcje pracy z drzewem wartości

Aktualizacja drzewa

Tam jest problem spada platform podczas aktualizacji drzewa.

Jeżeli rozwinięto którykolwiek węzeł drzewa i wybrano węzeł podrzędny, wówczas przy aktualizacji drzewa za pomocą funkcji Dane wartości w formularzu platforma spada.

Rozwiązanie: Przed aktualizacją musisz wyczyścić drzewo.

Na przykład:

&Na serwerze Procedura ClearTree(elements) Dla każdego elementu z elementów Loop ClearTree(element.GetElements()); Koniec cyklu; elementy.Wyczyść(); Koniec procedury

&Na serwerze Wypełnianie drzewa koncepcji() dConcepts = srProperties.Build Drzewo koncepcji(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Koniec procedury

&OnClient Procedura OnDateOnChange(Element) Wypełnij ConceptTree(); Koniec procedury

Platforma 1C:Enterprise umożliwia programowe dodawanie i zmianę elementów zarządzanego formularza. Zastanówmy się, dlaczego może to być potrzebne.

Modyfikacja oprogramowania formularza może być wymagana w kilku przypadkach:

  • Podczas finalizowania standardowych konfiguracji, aby ułatwić późniejszą procedurę aktualizacji. W takim przypadku zmianie ulegnie jedynie moduł formularza. Moduły są znacznie łatwiejsze w aktualizacji niż formularze.
  • Podczas wdrażania niektórych popularnych algorytmów. Przykładowo w podsystemie „Zakaz edycji szczegółów obiektu” można programowo utworzyć dla wszystkich obiektów podłączonych do podsystemu przycisk umożliwiający edycję szczegółów.
  • Podczas wdrażania niektórych określonych algorytmów. Przykładowo w katalogu Nomenklatura tworzone są pola umożliwiające edycję dodatkowych szczegółów.

W formularzu zarządzanym możesz programowo dodawać, zmieniać i usuwać:

  • przybory;
  • zespoły lokalne;
  • elementy.

Wszystkie te operacje są możliwe tylko na serwerze.

Programowe przekształcanie ma ograniczenia:

  • Możesz usuwać tylko programowo dodane szczegóły/polecenia/elementy. Nie można programowo usuwać obiektów utworzonych w konfiguratorze.
  • Nie można przypisać atrybutu jako głównego.

Zmiana poleceń formularza

Aby zarządzać kompozycją poleceń dla obiektu Zarządzany formularz jest kolekcja Zespoły

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

    Ilość ()

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

    Usuwać (< Команда >)

Kolekcja Teams jest dostępna zarówno na kliencie, jak i na serwerze. Kolekcję (metody Add() i Delete()) można zmienić tylko na serwerze. Możesz wyszukiwać i pobierać liczbę elementów (metody Find () i Count ()) zarówno na kliencie, jak i na serwerze.

Jako przykład pracy z poleceniami formularzy utwórzmy nowe polecenie ChangeHistory z nagłówkiem „ChangeHistory...”, które wywoła procedurę obsługi Historia wyświetlania(). Utworzenie następuje w momencie otwarcia formularza.

&Na serwerze
Procedura WhenCreatingOnServer (awaria, przetwarzanie standardowe)
Zespół = Zespoły. Dodać( „Historia zmian”);
Zespół . Akcja = ;
Zespół . Tytuł = „Historia zmian…”;
Koniec procedury
&Na kliencie
Procedura Connectable_DisplayHistory (polecenie)
// polecenia akcji
Koniec procedury

Procedura obsługi poleceń musi znajdować się w formularzu i mieć dyrektywę kompilacji &OnClient.

Zmiana szczegółów formularza

Odczytanie składu szczegółów formularza odbywa się za pomocą funkcji Uzyskaj szczegóły(< Путь >) zwracającą tablicę typu FormAttributes. Parametr funkcji określa ścieżkę do atrybutu nadrzędnego (w postaci ciągu znaków). Jeśli parametr zostanie pominięty lub określono pusty ciąg znaków, zwracane są szczegóły najwyższego poziomu.

Zmiana szczegółów odbywa się za pomocą metody Zmień szczegóły(<Dodano szczegóły>, <Usuwalne detale>) obiekt Zarządzany formularz. Do parametrów Dodano szczegóły I Usuwalne detale Przesyłane są tablice z elementami typu Form Attributes.

Uwaga!

Proces zmiany składu detali wymaga dużych zasobów. Formularz jest aktualnie odtwarzany. W związku z tym praca ze szczegółami formularza odbywa się w trybie wsadowym.

Utwórzmy nowy atrybut formularza o nazwie Kupujący:


AddedDetails = Nowa tablica;
Dodano szczegóły. Dodaj (nowe atrybuty formularza(„Kupujący”, Opis Nowego Typu („DirectoryLink. Kontrahenci”), „Klient”);

// Zmiany w kompozycji szczegółów
);

Zmiana elementów formularza

Aby kontrolować skład elementów obiektu Zarządzany formularz jest kolekcja Elementy. Kolekcja ma kilka metod:

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

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

    Ilość ()

    Znajdować (< Имя >)

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

    Usuwać (< Элемент >)

Kolekcja Items jest dostępna zarówno na kliencie, jak i na serwerze. Zmodyfikuj kolekcję (Wstaw metody () , Dodaj (), Przenieś () i Usuń ()) są dostępne tylko na serwerze. Możesz wyszukiwać i pobierać liczbę elementów (metody Find () i Count ()) zarówno na kliencie, jak i na serwerze. Elementami kolekcji mogą być:

  • Grupa formularzy;
  • Tabela formularzy;
  • Pole formularza;
  • Przycisk formularza.

Można programowo przypisać procedury obsługi zdarzeń do elementów formularza. Do tych celów przeznaczona jest metoda UstawAkcję(< ИмяСобытия>, < Действие >) .

Przyjrzyjmy się niektórym z najczęstszych przykładów pracy z poleceniami, szczegółami i elementami formularzy.

Dodanie polecenia i powiązanego z nim przycisku:

// Utwórz polecenie
Zespół = Zespoły. Dodać( „Historia zmian”);
Zespół . Akcja = „Historia_wyświetlania wtyczki”; // Formularz musi zawierać procedurę o podanej nazwie
Zespół . Nagłówek = „Historia zmian…”;
// Utwórz przycisk i powiąż go z poleceniem
Element = Przedmioty. Dodać( „Historia zmian”, Type("FormButton" ));
Element.Nazwa Polecenia = „Historia zmian”;

Dodanie atrybutu i powiązanego pola wejściowego:

// Opis dodanych szczegółów
AddedDetails = Nowa tablica;
Dodano szczegóły. Dodać(Nowe rekwizyty formularza („Kupujący”, Nowy opis typu ( „DirectoryLink. Kontrahenci”), "Klient" ));
// Zmiana kompozycji szczegółów
Zmień szczegóły (dodano szczegóły);
// Tworzenie pola wejściowego i łączenie z atrybutami
Element = Przedmioty. Add("Kupujący" , Typ("PoleForm" ));
Element . Widok = FormFieldView. Pole wejściowe;
Element . Ścieżka do danych= „Kupujący”;

Przypisywanie obsługi zdarzeń do elementu formularza:

PozycjaKlient. Ustaw akcję(„Kiedy to się zmieni”, „Connected_BuyerOnChange”);

&Na kliencie
Procedura Connected_BuyerOnChange(Element)
// Akcje zdarzenia
Koniec procedury

Uwaga!

Procedury ustawione jako procedury obsługi zdarzeń z kodu przy użyciu metody UstawAkcję(), zaleca się ustawienie przedrostka Connectable_.

Uwaga!

Możesz pobrać obróbkę z przykładami programowego wyszukiwania i zmiany szczegółów, poleceń i elementów zarządzanego formularza.

Szczegóły formularza zapewniają jego powiązanie z danymi. W takim przypadku jeden (i tylko jeden) szczegół można oznaczyć jako główny; niekoniecznie musi to być typ danych, do którego rysujemy formularz. Jednak zachowanie formularza będzie zależeć od typu danych głównego atrybutu. Oprócz zmiany zachowania formularza zmienia się także kontekst modułu formularza. Wraz z metodami i właściwościami formularza stają się w nim dostępne metody i właściwości obiektu, który jest wartością głównego atrybutu. Ważne jest, aby formularze typu Free Form nie posiadały podstawowych szczegółów. W tym przypadku o zachowaniu formularza decydują wyłącznie ustawienia użytkownika. Rozważmy pytania dotyczące podstawowych szczegółów.

Pytanie 10.05 egzaminu 1C: Platform Professional. Do czego służy główny atrybut formularza?

  1. Definiuje źródło danych dla formularza jako całości
  2. Definiuje standardowe możliwości platformy do pracy z formularzem z danymi typu określonego w atrybucie głównym
  3. Aby zapewnić możliwość programowego dostępu do szczegółów obiektu z lokalnego kontekstu formularza
  4. Umożliwia wizualizację szczegółów obiektu w oknie dialogowym formularza
  5. 2 i 3 są prawidłowe
  6. 1 i 2 są prawidłowe

Prawidłowa odpowiedź to numer sześć, patrz wyżej.


Pytanie 10.06 egzaminu 1C: Platform Professional. Do czego potrzebne są dane formularza?
  1. Aby opisać zawartość danych wyświetlanych, edytowanych lub przechowywanych w formularzu
  2. Aby wyświetlić i edytować dane w formularzu
  3. 1 i 2 są prawidłowe

Prawidłowa odpowiedź jest trzecia – obie.

Pytanie 10.07 egzaminu 1C: Platform Professional. Aby przypisać podstawowe atrybuty do dowolnego kontrolowanego formularza...

  1. Należy zaznaczyć checkbox „Szczegóły podstawowe” we właściwościach atrybutów formularza
  2. należy wypełnić właściwość „Dane” formularza, wybierając wymagany atrybut formularza

Prawidłowa odpowiedź jest druga:

Pytanie 10.08 egzaminu 1C: Platform Professional. Aby przypisać główne szczegóły do ​​dowolnego, regularnego formularza...
  1. formularz musi być główny, główne szczegóły są ustalane automatycznie
  2. Należy zaznaczyć checkbox „Szczegóły podstawowe” we właściwościach atrybutów formularza
  3. musisz przejść do menu „Edycja”, „Podstawowe szczegóły” i wybrać żądaną wartość
  4. należy wypełnić właściwość „Dane” formularza, wybierając wymagany atrybut formularza

Czwarta prawidłowa odpowiedź to:

Główne szczegóły zostały wyróżnione pogrubioną czcionką:

Pytanie 10.09 egzaminu 1C: Platform Professional. Jeśli istnieje jeden główny atrybut formularza, czy można dodać kolejny główny atrybut?
  1. To jest niemożliwe
  2. Jest to możliwe poprzez przypisanie odpowiedniej wartości właściwości atrybutu formularza
  3. Jest to możliwe tylko programowo, podczas dostępu do obiektu „Formularz”.
  4. Jest to możliwe poprzez dodanie kolejnej wartości do odpowiedniej właściwości formularza

Prawidłowa odpowiedź jest pierwsza, jest ściśle jeden główny warunek, ponieważ związek z przedmiotem musi być jednoznaczny.

Pytanie 10.113 z egzaminu 1C: Platform Professional. Który ze szczegółów formy przedstawionych na rysunku jest najważniejszy?

  1. Lista kursów walut
  2. Obiekt katalogu
  3. Formularze katalogowe nie zawierają podstawowych danych
  4. Formularze katalogowe zawierają wszystkie podstawowe szczegóły
Druga prawidłowa odpowiedź to ta pogrubiona.

Sterowanie formularzem odbywa się poprzez różne elementy formularza, które są rozmieszczone hierarchicznie na zakładce Elementy projektant formularzy. Najważniejszym elementem jest sama forma, która znajduje się na szczycie hierarchii elementów, a pozostałe elementy są jej podporządkowane.

Wszystkie elementy formularza można podzielić na pięć grup: pola, elementy grupujące, przyciski, dekoracje i tabele. W moich artykułach będę analizował każdą z grup. W tym artykule zaczniemy badać jeden z typów elementów polowych - pole wejściowe, ale wcześniej dowiemy się jak dodać element do formularza.

Dodawanie elementów do formularza

Odbywa się to po prostu: musisz wybrać element Formularz w oknie Elementy projektu formularza i kliknij przycisk „Dodaj”. Następnie otworzy się okno, w którym należy wybrać żądany typ elementu

Po dokonaniu wyboru w oknie pojawi się żądany element Elementy.

Zarządzany element formularza Pole

Przyjrzyjmy się zarządzanemu elementowi formularza Pole. Element ten jest niezbędny do wprowadzenia informacji w formularzu. A także do wyświetlania wszelkich informacji. Po dodaniu tego elementu do formularza po prawej stronie otworzy się paleta właściwości elementu formularza. Na razie powinny Cię zainteresować dwie właściwości – DataPath i View.

We właściwości DataPath programista może powiązać element formularza z żądanym atrybutem formularza. Należy pamiętać, że po dodaniu elementu Pole wejściowe na formularzu nie był on wyświetlany na samym formularzu. Stało się tak, ponieważ nasz nowy element nie jest powiązany z . Na przykład utworzyłem kilka atrybutów w formularzu przetwarzania z różnymi typami pierwotnymi i jeden atrybut z typem referencyjnym.

Teraz połączmy nasz niedawno dodany element formularza z jednym ze szczegółów.W tym celu należy wybrać żądany atrybut z właściwości PathKData elementu.

Następnie zostaną wypełnione właściwości DataPath i View, a sam element zostanie wyświetlony w widoku formularza.

Zwróć uwagę na właściwości elementu Pogląd. Ta właściwość określa funkcjonalność pola wejściowego. Możesz wybrać różne wartości dla tej właściwości.

W zależności od wybranej wartości zostanie określona funkcjonalność. Na powyższych rysunkach wybrana wartość to – pole wejściowe, tj. możemy wprowadzić dowolne wartości w tym polu wejściowym i jeśli wybierzemy wartość pole etykiety, wtedy nie będziemy mogli nic wpisać.

Wartość tej właściwości Pogląd Pola wejściowe są wygodne do wyboru, gdy chcesz po prostu pokazać użytkownikowi informacje pomocy.

Dodajmy teraz nowy element formularza z typem Pole wejściowe i połącz go z rekwizytami SzczegółyData poprzez znaną nam już właściwość DataPath

Jak widać zmienił się wygląd pola wejściowego, zmieni się także możliwy wybór wartości dla właściwości View.

Dochodzimy zatem do wniosku, że funkcjonalność pola wejściowego zależy od rodzaju atrybutu.

Dla rekwizytów z typem Wartość logiczna Dostępne będą następujące wartości właściwości View.

Natomiast dla atrybutów z typem referencyjnym dostępne będą inne wartości właściwości View.

Bardziej szczegółową pracę z elementami formularza na praktycznych przykładach podano w książce „Podstawy rozwoju w 1C: Taxi. Zarządzanie tworzeniem aplikacji w 12 krokach”.

Czasami wydaje się, że nauka języka programowania w 1C jest skomplikowana i trudna. W rzeczywistości programowanie w 1C jest łatwe. Moje książki pomogą Ci łatwo i szybko opanować programowanie w 1C: oraz „Podstawy programowania w 1C: Taxi”

Naucz się programowania w 1C za pomocą mojej książki „Programowanie w 1C w 11 krokach”

  1. Żadnych skomplikowanych terminów technicznych.
  2. Ponad 700 stron praktycznych materiałów.
  3. Do każdego zadania dołączony jest rysunek (zrzut ekranu).
  4. Zbiór zadań do pracy domowej.
  5. Książka napisana jest jasnym i prostym językiem - dla osoby początkującej.

Ta książka jest odpowiednia dla tych, którzy już rozpoczęli programowanie i mają pewne trudności w tym temacie, oraz dla tych, którzy programują od dłuższego czasu, ale nigdy nie pracowali z formularzami zarządzanymi przez 1C.

  1. Bez skomplikowanych terminów technicznych;
  2. Ponad 600 stron praktycznych materiałów;
  3. Do każdego przykładu dołączony jest rysunek (zrzut ekranu);
  4. Książka wysyłana jest e-mailem w formacie PDF. Można otworzyć na dowolnym urządzeniu!

Kod promocyjny na 15% zniżki - 48PVXHeYu


Jeżeli ta lekcja pomogła Ci rozwiązać jakiś problem, spodobała Ci się lub okazała się przydatna, możesz wesprzeć mój projekt przekazując dowolną kwotę:

Możesz zapłacić ręcznie:

Yandex.Money - 410012882996301
Pieniądze internetowe — R955262494655

Dołącz do moich grup.

Oraz obiekt przesyłania danych do struktury kodu, kontrolowana forma w środowisku 1C 8.2.

Wstęp

Zacznijmy od krótkiego opisu koncepcji „formy zarządzanej” i powiązanych koncepcji platformy 1C. Koneserzy platform mogą pominąć tę sekcję.

W 2008 roku udostępniona została nowa wersja platformy 1C: Enterprise 8.2 (zwana dalej Aplikacją Zarządzaną), która całkowicie zmienia całą warstwę pracy z interfejsem. Obejmuje to interfejs poleceń, formularze i system okien. Jednocześnie zmienia się nie tylko model rozbudowy interfejsu użytkownika w konfiguracji, ale zaproponowana jest także nowa architektura rozdzielająca funkcjonalność pomiędzy aplikacją kliencką a serwerem.
Zarządzana aplikacja obsługuje następujące typy klientów:

  • Gruby klient (normalny i zarządzany tryb uruchamiania)
  • Cienki klient
  • Klient sieciowy
Zarządzana aplikacja wykorzystuje formularze zbudowane w oparciu o nową technologię. Nazywają się Formularze zarządzane. Aby ułatwić przejście, obsługiwane są także poprzednie formularze (tzw. Formularze Regularne), jednak ich funkcjonalność nie jest rozwijana i są one dostępne tylko w trybie uruchamiania grubego klienta.
Główne różnice zarządzanych formularzy dla programisty:
  • Deklaratywny, a nie „piksel po pikselu” opis struktury. Konkretne rozmieszczenie elementów następuje automatycznie po wyświetleniu formularza.
  • Cała funkcjonalność formularza opisana jest jako Detale I zespoły. Szczegóły to dane, z którymi współpracuje formularz, a polecenia to czynności, które należy wykonać.
  • Formularz działa zarówno na serwerze, jak i na kliencie.
  • W kontekście klienta prawie wszystkie typy aplikacji są niedostępne, w związku z czym niemożliwa jest zmiana danych w bazie danych.
  • Dla każdej metody lub zmiennej formularza należy ją określić dyrektywa kompilacji, określenie miejsca wykonania (klient lub serwer) i dostęp do kontekstu formularza.
Wymieńmy dyrektywy dotyczące kompilacji metod formularzy:
  • &Na kliencie
  • &Na serwerze
  • &Na serwerzeBez kontekstu
  • &OnClientOnServerBez kontekstu
Zilustrujmy powyższe. Zrzut ekranu przedstawia przykład zarządzanego formularza i jego modułu w trybie deweloperskim. Znajdź opis deklaratywny, właściwości, dyrektywy kompilacji itp.

Wszystkie dalsze dyskusje będą dotyczyć prawej strony ilustracji, tego, jak ustrukturyzować kod modułu i jakie zasady pozwolą na wdrożenie efektywnej interakcji klient-serwer.

Zdefiniujmy problem

Minęło kilka lat, odkąd nowa wersja platformy 1C jest aktywnie wykorzystywana i wiele rozwiązań (konfiguracji) zostało wydanych zarówno przez 1C, jak i jej wielu partnerów.
Czy przez ten czas programiści wypracowali wspólne rozumienie zasad interakcji klient-serwer podczas tworzenia formularzy i czy w nowych realiach architektonicznych zmieniło się podejście do wdrażania modułów oprogramowania?

Przyjrzyjmy się strukturze kodu (modułowi formularza) w kilku postaciach tej samej standardowej konfiguracji i spróbujmy znaleźć wzorce.
Przez strukturę rozumiemy fragmenty kodu (najczęściej są to bloki komentarzy) przydzielane przez programistę metodom grupującym i dyrektywom kompilacji dla tych metod.
Przykład 1:
Sekcja procedur obsługi zdarzeń Metoda - na kliencie Metoda - na serwerze Metoda - na kliencie Sekcja procedur i funkcji serwisowych Funkcje sterujące wejściami pomocniczymi
Przykład 2:
Procedury i funkcje serwisowe Dokumenty płatnicze Wartości Obsługa zdarzeń
Przykład 3:
Procedury serwisowe na serwerze Procedury serwisowe na kliencie Procedury serwisowe na serwerze bez kontekstu Obsługa zdarzeń nagłówkowych Obsługa zdarzeń poleceń
Przykład 4:
Procedury ogólnego przeznaczenia Obsługa zdarzeń formularzy Procedury podsystemu „informacje kontaktowe”.
Zasadniczo brakuje struktury kodu, lub delikatnie mówiąc, jest ona podobna do tej, która była w Forms 8.1:

  • Słowa niemające charakteru informacyjnego „Ogólne, służbowe, pomocnicze”.
  • Nieśmiałe próby oddzielenia metod klienta i serwera.
  • Metody są często pogrupowane według elementów interfejsu „Praca z częścią tabelaryczną Produkty, Informacje kontaktowe”.
  • Dowolny układ metod i grup kodów. Na przykład moduły obsługi zdarzeń mogą znajdować się na górze w jednym formularzu, na dole w innym, w ogóle nie podświetlone w trzecim itd.
  • I nie zapominajmy, że to wszystko w ramach jednej konfiguracji.
  • Tak, istnieją konfiguracje, w których słowa „Ogólne, Służbowe, Pomocnicze” są zawsze w tych samych miejscach, ale…
Dlaczego potrzebujesz struktury kodu?
  • Uproszczenie konserwacji.
  • Uprość naukę.
  • Zapisywanie ogólnych/ważnych/skutecznych zasad.
  • ...Twoja opcja
Dlaczego istniejący standard programistyczny od 1C nie pomaga?
Przyjrzyjmy się zasadom opublikowanym na dyskach ITS oraz w różnych „Przewodnikach programisty…”, które są zalecane przy pisaniu zarządzanego formularza.
  • Zminimalizuj liczbę wywołań serwera.
  • Maksymalna moc obliczeniowa na serwerze.
  • Niekontekstowe wywołania serwera są szybsze niż kontekstowe.
  • Program z myślą o komunikacji klient-serwer.
  • i tak dalej.
To hasła jak najbardziej prawdziwe, ale jak je wdrożyć? Jak zminimalizować liczbę połączeń, co oznacza programowanie w trybie klient-serwer?

Wzorce projektowe czyli mądrość pokoleniowa

Interakcja klient-serwer jest wykorzystywana w różnych technologiach oprogramowania od dziesięcioleci. Odpowiedź na pytania postawione w poprzedniej sekcji jest znana od dawna i streszcza się w dwóch podstawowych zasadach.
  • Zdalna fasada(zwany dalej Interfejsem Zdalnego Dostępu)
  • Obiekt przesyłania danych(zwany dalej Obiektem Przekazywania Danych)
Słowo od Martina Fowlera, jego opis tych zasad:
  • … Każdy obiekt potencjalnie przeznaczony do zdalnego dostępu musi posiadać interfejs o niskiej szczegółowości, co zminimalizuje liczbę wywołań wymaganych do wykonania określonej procedury. ... Zamiast żądać faktury i wszystkich jej pozycji osobno, musisz przeczytać i zaktualizować wszystkie pozycje faktury w jednym żądaniu. Ma to wpływ na całą strukturę obiektu... Pamiętaj: interfejs zdalnego dostępu nie zawiera logiki domeny.
  • ...gdybym była troskliwą mamą, zdecydowanie powiedziałabym mojemu dziecku: „Nigdy nie pisz obiektów do przesyłania danych!” W większości przypadków obiekty przesyłania danych to nic innego jak nadęty zestaw pól... Wartość tego obrzydliwego potwora leży wyłącznie w możliwości przesyłać wiele informacji przez sieć podczas jednego połączenia- technika mająca ogromne znaczenie w przypadku systemów rozproszonych.
Przykłady szablonów na platformie 1C
Interfejs programowania aplikacji dostępny dla programisty podczas tworzenia zarządzanego formularza zawiera wiele przykładów tych zasad.
Na przykład metoda OpenForm(), typowy „szorstki” interfejs.
OpeningParameters = Nowa struktura("Parametr1, Parametr2, Parametr3", Wartość1, Wartość2, Wartość3); Formularz = OpenForm(NazwaFormularza, Parametry Otwarcia);
Porównaj ze stylem przyjętym w wersji 8.1.
Formularz = GetForm(NazwaFormularza); Form.Parametr1 = Wartość1; Form.Parametr2 = Wartość2; Formularz.Open();

W kontekście zarządzanego formularza istnieje wiele „obiektów przesyłania danych”. Możesz wybrać systemowe I zdefiniowane przez programistę.
Systemowe modelują obiekt aplikacji na kliencie w postaci jednego lub większej liczby elementów danych formularza. Nie da się ich utworzyć bez odniesienia się do szczegółów formularza.

  • Struktura formularzy danych
  • Kolekcja DataForms
  • DataFormStructureWithCollection
  • Drzewo kształtów danych
Konwersja obiektów transferu danych systemowych na typy aplikacji i odwrotnie odbywa się za pomocą następujących metod:
  • WartośćWFormieDane()
  • WartośćDanychFormularza()
  • KopiujDaneFormularza()
  • ValueInFormAttributes()
  • Atrybuty formularzaWartość()
Często podczas dostosowywania istniejącego rozwiązania stosuje się konwersję jawną. Metody mogą oczekiwać (używać funkcji) parametrów wejściowych, takich jak ValueTable, a nie FormDataCollection, lub metoda została zdefiniowana w kontekście obiektu aplikacji i stała się niedostępna do bezpośredniego wywołania z formularza.
Przykład 1C v8.1:
// na kliencie w kontekście formularza FillUserCache(DepartmentLink)
Przykład 1C v8.2:
// na serwerze w kontekście formularza ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); Wartość–FormAttributes(Object Processing, „Obiekt”);

Obiekty przesyłania danych, których strukturę ustala programista, stanowią niewielki podzbiór typów dostępnych zarówno po stronie klienta, jak i serwera. Najczęściej jako parametry i wyniki metod interfejsu „zgrubnego” wykorzystuje się:

  • Typy pierwotne (string, number, boolean)
  • Struktura
  • Korespondencja
  • Szyk
  • Linki do obiektów aplikacji (unikalny identyfikator i reprezentacja tekstowa)
Przykład: metoda przyjmuje listę zleceń zmiany statusu i zwraca klientowi opis błędów.
Funkcja &OnServerWithoutContext ServerChangeOrderStatus(Zamówienia, NewStatus) Błędy = Nowe dopasowanie(); // [zamówienie] [opis błędu] Dla każdego zamówienia z cyklu StartTransaction(); Spróbuj DocOb = Order.GetObject(); …. inne akcje, możliwe nie tylko za pomocą zamówienia... Wyjątek CancelTransaction(); Errors.Insert(Order, ErrorDescription()); Zakończ próbę; Koniec cyklu; Błąd zwrotu; EndFunction // ServerChangeOrderStatus()

Strukturyzacja kodu

Główne cele, jakie powinien odzwierciedlać moduł formularza zarządzanego oraz podejścia do rozwiązania.
  • Wyraźne oddzielenie kodu klienta i serwera. Nie zapominajmy, że w momencie realizacji są to dwa oddziałujące na siebie procesy, z których każdy znacząco różni się dostępną funkcjonalnością.
  • Czytelna identyfikacja interfejsu zdalnego dostępu, które metody serwera można wywołać od klienta, a które nie? Nazwy metod interfejsu zdalnego zaczynają się od przedrostka „Serwer”. Dzięki temu w trakcie odczytywania kodu od razu widać przekazanie kontroli na serwer, a także ułatwia korzystanie z pomocy kontekstowej. Należy pamiętać, że oficjalna rekomendacja (ITS) sugeruje nazewnictwo metod z przyrostkami, na przykład ChangeOrderStatusOnServer(). Jednak powtórzmy, nie wszystkie metody serwera można wywołać z klienta, dlatego ważniejsza jest dostępność logiczna, a nie lokalizacja kompilacji. Dlatego przedrostkiem „Serwer” oznaczamy tylko metody dostępne dla klienta, nazwijmy przykładową metodę ServerChangeOrderStatus().
  • Czytelność. Kwestia gustu, zamówienie przyjmujemy gdy moduł zaczyna się od procedur tworzenia formularza na serwerze i metod zdalnego dostępu.
  • Łatwość konserwacji. Musi być jasne miejsce na dodanie nowego kodu. Co ważne, na końcu modułu dodawane są szablony metod tworzone automatycznie przez konfigurator. Ponieważ procedury obsługi zdarzeń dla elementów formularza są najczęściej tworzone automatycznie, odpowiedni blok jest umieszczany na końcu, aby nie przeciągać każdej procedury obsługi w inne miejsce w module.
Poniżej znajduje się podstawowa struktura modułu realizującego wymienione cele.
  • Opcja graficzna – wyraźnie pokazuje główny przebieg wykonania.
  • Opcja tekstowa jest przykładem projektu szablonu umożliwiającego szybkie wstawienie struktury do nowego modułu formularza.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Data=""/> // <Описание> // // /////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////////// ////////// // NA SERWERZE //********** ZDARZENIA NA SERWERZE ********** &Na serwerze Procedura w przypadku utworzenia na serwerze (awaria, przetwarzanie standardowe) ///////////// /wstaw zawartość procedury obsługi Koniec procedury //********** INTERFEJS ZDALNEGO DOSTĘPU ******* //********** LOGIKA BIZNESOWA NA SERWERZE ******* ///////// /////////////////////////////////////// /////// /////////////////// // WSPÓLNE METODY KLIENTA I SERWERA /////////////// /////// //////////////////////////////////////// ///// //////// // NA KLIENCIE //********** LOGIKA BIZNESOWA NA KLIENCIE ********** //********** ZESPÓŁ * ****** //********** WYDARZENIA KLIENTA ********** ////////////////////////// ///// ////////////////////////////////////////// // / / GŁÓWNE OPERATORY PROGRAMÓW

Powiązane pytania
Podsumowując, zarysujemy kilka obszarów, o których warto pomyśleć podczas programowania interakcji klient-serwer.
  • Opcje implementacji interfejsu zdalnego dostępu. Asynchronia, poziom szczegółowości...
  • Buforowanie. 1C podjął nieudaną decyzję architektoniczną, wprowadzając buforowanie tylko na poziomie wywoływania metod wspólnych modułów i nie zapewniając możliwości kontroli (czas istotności, resetowanie na żądanie).
  • Niejawne wywołania serwera. Nie zapomnij o funkcjach technologicznych, wiele „nieszkodliwych” operacji na kliencie prowokuje platformę do kontaktu z serwerem.


Powiązane publikacje