Obiekt transferu danych do strukturyzacji kodu, formularz zarządzany w środowisku 1C 8.2.

Wstęp

Zacznijmy od krótkiego opisu koncepcji „formularza zarządzanego” i powiązanych koncepcji platformy 1C. Eksperci platformy mogą pominąć tę sekcję.

Stał się dostępny w 2008 roku nowa wersja platforma 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. To nie tylko zmienia model tworzenia interfejsu użytkownika w konfiguracji, ale także proponuje nową architekturę rozdziału funkcjonalności między aplikacją kliencką a serwerem.
Aplikacja zarządzana obsługuje następujące typy klientów:

• Gruby klient (tryb uruchamiania normalnego i zarządzanego)
• Cienki klient
• Klient WWW

Zarządzana aplikacja używa formularzy zbudowanych na Nowa technologia. Nazywają się Zarządzane formularze. Dla ułatwienia przejścia obsługiwane są również starsze formularze (tzw. zwykłe formularze), ale ich funkcjonalność nie jest rozwijana i są dostępne tylko w trybie uruchamiania bogatego klienta.
Główne różnice między zarządzanymi formularzami dla dewelopera:

• Deklaratywny, a nie „pikselowy” opis struktury. Konkretne rozmieszczenie elementów jest wykonywane automatycznie przez system podczas wyświetlania formularza.
• Wszystkie funkcjonalności formularza są opisane w formularzu Detale oraz polecenia. Szczegóły to dane, z którymi współpracuje formularz, a polecenia to wykonywane akcje.
• Formularz jest wykonywany zarówno na serwerze, jak i na kliencie.
• W kontekście klienta prawie wszystkie typy aplikacji są niedostępne, a co za tym idzie nie ma możliwości zmiany danych w infobazie.
• Dla każdej metody lub zmiennej formularza należy ją określić dyrektywa kompilacji A, który określa, czy miejsce wykonania (klient lub serwer) i dostęp do kontekstu formularza.

Oto dyrektywy dotyczące kompilowania metod formularza:

• &U klienta
• &Na serwerze
• &Na serwerze bez kontekstu
• &U klientaNa serwerzebezkontekstu

Zilustrujmy powyższe. Zrzut ekranu pokazuje przykład zarządzanego formularza i jego modułu w trybie deweloperskim. Znajdź opis deklaratywny, rekwizyty, dyrektywy kompilacji itp.

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

Zdefiniujmy problem

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

Rozważ strukturę kodu (moduł formularza) w kilku formach o tej samej typowej konfiguracji i spróbuj znaleźć wzorce.
Pod strukturą rozumiemy sekcje kodu (najczęściej są to bloki komentarzy) przydzielone przez programistę do grupowania metod oraz dyrektywy do kompilacji tych metod.
Przykład 1:
Sekcja obsługi zdarzeń Metoda – na kliencie Metoda – na serwerze Metoda – na kliencie Sekcja procedur i funkcji serwisowych Funkcje pomocnicze kontroli wejść
Przykład 2:
Procedury i funkcje serwisowe Dokumenty płatnicze Przedmioty wartościowe Obsługa zdarzeń
Przykład 3:
Procedury serwisowe na serwerze Procedury serwisowe na kliencie Procedury serwisowe na serwerze bez kontekstu Programy obsługi zdarzeń nagłówka Programy obsługi zdarzeń poleceń
Przykład 4:
Procedury ogólnego przeznaczenia Formularze obsługi zdarzeń Procedury podsystemu „informacje kontaktowe”.
W rzeczywistości brakuje struktury kodu lub, delikatnie mówiąc, jest ona podobna do tej, która była w formularzach 8.1:

• Nieinformacyjne słowa „Ogólne, Służbowe, Pomocnicze”.
• Nieśmiałe próby rozdzielenia metod klienta i serwera.
• Często metody są pogrupowane według elementów interfejsu „Praca z częścią tabelaryczną Produkty, Informacje kontaktowe”.
• Dowolny układ metod i grup kodu. 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 są podświetlone w trzecim i tak dalej.
• I nie zapominajmy, że to wszystko jest w tej samej konfiguracji.
• Owszem, są konfiguracje, w których słowa „General, Service, Auxiliary” są zawsze w tych samych miejscach, ale…

Dlaczego potrzebujesz struktury kodu?

• Uproszczenie konserwacji.
• Uprość naukę.
• Ustalenie ogólnych/ważnych/skutecznych zasad.
• … Twoja opcja

Dlaczego istniejący standard programistyczny z 1C nie pomaga?

Przyjrzyjmy się zasadom opublikowanym na dyskach ITS oraz w różnych „Przewodnikach programisty…”, zalecanych przy pisaniu zarządzanego formularza.

• Zminimalizuj liczbę wywołań serwera.
• Maksymalna moc obliczeniowa na serwerze.
• Wywołania serwera bez kontekstu są szybsze niż wywołania kontekstowe.
• Program z myślą o interakcji klient-serwer.
• itp.

To są hasła absolutnie prawdziwe, ale jak je urzeczywistnić? Jak zminimalizować ilość wywołań, co to znaczy programować w trybie klient-serwer?

Wzorce projektowe lub mądrość pokoleniowa

Interakcja klient-serwer jest stosowana w różnych technologiach oprogramowania od dziesięcioleci. Odpowiedź na pytania przedstawione w poprzedniej części jest znana od dawna i streszcza się w dwóch podstawowych zasadach.

• Zdalna fasada(zwany dalej interfejsem zdalnego dostępu)
• Obiekt przesyłania danych(dalej zwany obiektem przesyłania danych)

Słowo do Martina Fowlera, jego opis tych zasad:

• … musi posiadać każdy obiekt potencjalnie przeznaczony do zdalnego dostępu interfejs o niskiej ziarnistości, co zminimalizuje liczbę połączeń wymaganych do wykonania określonej procedury. … Zamiast prosić o fakturę i wszystkie jej punkty z osobna, należy przeczytać i zaktualizować wszystkie punkty faktury w jednym wezwaniu. Wpływa to na całą strukturę obiektu... Pamiętaj: interfejs zdalnego dostępu nie zawiera logiki domeny.
• ... gdybym była troskliwą matką, zdecydowanie powiedziałabym mojemu dziecku: „Nigdy nie pisz obiektów do przesyłania danych!” W większości przypadków obiekty migracji danych to nic innego jak nadęty zestaw pól… Wartość tego obrzydliwego potwora polega wyłącznie na możliwości przesyłać wiele elementów informacji przez sieć w jednym połączeniu- technika, która ma ogromne znaczenie dla systemów rozproszonych.

Przykłady szablonów na platformie 1C

Interfejs API dostępny dla programisty podczas tworzenia zarządzanego formularza zawiera wiele przykładów tych zasad.
Na przykład metoda OpenForm(), typowy „zgrubny” interfejs.
OpenParameters = New Structure("Parametr1, Parametr2, Parametr3", Wartość1, Wartość2, Wartość3); Form = OpenForm(FormName, OpenParameters);
Porównaj ze stylem v8.1.
Formularz = GetForm(NazwaFormularza); Forma.Parametr1 = Wartość1; Formularz.Parametr2 = Wartość2; Formularz.Otwórz();

W kontekście zarządzanego formularza zestaw „obiektów przesyłania danych”. Można wyróżnić systemowe oraz zdefiniowany przez programistę.
Systemowe modelują obiekt aplikacji na kliencie, w postaci jednego lub więcej elementów danych formularza. Nie można ich utworzyć poza powiązaniem ze szczegółami formularza.

• DataFormsStruktura
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

Konwersja obiektów systemu przesyłania danych do typów aplikacji i odwrotnie odbywa się następującymi metodami:

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

Często podczas dostosowywania istniejącego rozwiązania stosowana jest jawna konwersja. Metody mogą oczekiwać (feature) parametrów wejściowych, takich jak ValueTable zamiast 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 FillUsersCache(DepartmentReference)
Przykład 1C v8.2:
// na serwerze w kontekście formularza ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Obiekt");

Obiekty migracji danych, których strukturę definiuje 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” stosuje się:

• Typy pierwotne (string, number, boolean)
• Struktura
• Konformizm
• szyk
• Linki do obiektów aplikacji (unikalny identyfikator i reprezentacja tekstowa)

Przykład: metoda przyjmuje listę zleceń do zmiany statusu i zwraca klientowi opis błędów.
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [zamówienie][opis błędu] Dla każdego zamówienia z pętli zamówień StartTransaction(); Próba DocOb = Order.GetObject(); …. inne akcje, być może nie tylko z rozkazem... Wyjątek CancelTransaction(); Errors.Insert(Order, DescriptionError()); koniec próby; koniec cyklu; Błąd powrotu; EndFunction // ServerChangeOrderStatus()

Strukturyzacja kodu

Główne cele, które powinien odzwierciedlać moduł zarządzanych formularzy i podejścia do rozwiązania.

• Wyraźne oddzielenie kodu klienta i serwera. Nie zapominajmy, że w momencie wykonania są to dwa współdziałające ze sobą procesy, w każdym z których dostępna funkcjonalność znacznie się różni.
• Czytelny wybór interfejsu zdalnego dostępu, które metody serwera można wywoływać z klienta, a które nie? Nazwy metod interfejsu zdalnego zaczynają się od przedrostka „Serwer”. Pozwala to na natychmiastowe zobaczenie przejścia kontroli na serwer podczas czytania kodu i upraszcza korzystanie z podpowiedzi kontekstowych. Należy zauważyć, że oficjalne zalecenie (ITS) sugeruje nazewnictwo metod z przyrostkami, takie jak ChangeOrderStatusOnServer(). Jednak, powtarzając, nie wszystkie metody serwera można wywołać z klienta, dlatego dostępność logiczna jest ważniejsza niż lokalizacja kompilacji. Dlatego przedrostkiem „Server” zaznaczamy tylko metody dostępne dla klienta, przykładowa metoda będzie się nazywać ServerChangeOrderStatus().
• Czytelność. Kwestia gustu, przyjmujemy zamówienie, gdy moduł zaczyna się od procedur tworzenia formularza na serwerze i metod zdalnego dostępu.
• Łatwość konserwacji. Miejsce dodania nowego kodu musi być jasno określone. Ważny punkt, które są automatycznie tworzone przez konfigurator kodu pośredniczącego metody, są dodawane na końcu modułu. Ponieważ procedury obsługi zdarzeń elementu 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 przedstawiono podstawową strukturę modułu realizującego wymienione cele.

• Opcja graficzna - wyraźnie pokazuje główny przebieg wykonania.
• Wersja tekstowa jest przykładem projektu szablonu dla szybki wkład struktury do nowego modułu formularza.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Data =""/> // <Описание> // // ///////////////////////////////////// / ////////////////////////////// // ZMIENNE MODUŁU /////////////// ///////////////////////////////////// // ////////////// // NA SERWERZE //******* ZDARZENIA NA SERWERZE ******* &Na serwerze Procedura Podczas tworzeniaNa serwerze( Failure, Standard Processing) //Wstaw zawartość procedury obsługi EndProcedure //******* INTERFEJS ZDALNEGO DOSTĘPU ******* //******* LOGIKA BIZNESOWA NA SERWERZE **** *** ///////////////////////////////// ///////////// ///////////////////// // WSPÓLNE METODY KLIENTA I SERWERA ///////// ///////////////////////////////////// //////////////// //////// // NA KLIENCIE //******* LOGIKA BIZNESOWA NA KLIENCIE ******* //******** POLECENIA ******* //******* ZDARZENIA NA KLIENCIE ****** ////////////// /////////////////////////////////////////// ///////////////// / / OPERATORZY GŁÓWNYCH PROGRAMÓW

Powiązane pytania

Podsumowując, przedstawiamy kilka obszarów, o których warto pomyśleć podczas programowania interakcji klient-serwer.

• Opcje implementacji interfejsu zdalnego dostępu. Asynchroniczność, ziarnistość...
• buforowanie. 1C podjął niefortunną decyzję architektoniczną, wprowadzając buforowanie tylko na poziomie wywoływania metod wspólnych modułów i nie zapewniając opcji kontroli (aktualizacja czasu, reset na żądanie).
• Niejawne wywołania serwera. Nie zapomnij o funkcjach technologicznych, wiele „nieszkodliwych” operacji na kliencie prowokuje platformę do uzyskania dostępu do serwera.

11.12.2016

Informacje o formularzach zarządzanych 1C (początek)

Cienki klient

Nigdzie nie ma cieńszego. Teraz aplikacja kliencka nie wysyła zapytań do bazy danych (jest to sprawa serwera). Aplikacja kliencka po prostu wyświetla interfejs i dane.

Warto zauważyć, że w wyniku takich przekształceń struktura kodu stała się bardziej skomplikowana. Na kliencie nie ma referencji, obiektów, tabeli wartości... dostępne są tylko typy pierwotne (string, date, boolean, array, structure...). Oznacza to, że programista musi teraz zastanowić się, co umieścić na serwerze i jak to zrobić minimalnym kosztem.

Interakcja klient-serwer

Nowe podejście do interakcji między klientem a serwerem pozwoliło nam stworzyć nowy model interfejsu użytkownika. Teraz interfejs jest zadeklarowany (!) projektowanie interfejsu rozpoczyna się od danych, szczegółów i sekcji tabelarycznych. Tworząc rekwizyt trzeba pomyśleć jak będzie wyglądał w interfejsie, czy będzie wymagany, jak jest powiązany z innymi rekwizytami...

Brak kontekstu (stanu) na serwerze

Serwer 1C działa na zasadzie „bezpaństwowej” (angielski bezpaństwowy). Oznacza to, że serwer odpowiada tylko na żądania, a jednocześnie nie przechowuje niczego pomiędzy dwoma żądaniami (w tym celu istnieje pamięć tymczasowa).

FormDataToValue,FormDataCollection,FormData...

Zwróciliśmy się do serwera, zrobił dla nas wszystko, usunął dane i zapomniał, że przyszliśmy. Wszystkie obiekty o nazwach „FormData” + „coś tam” pomogą nam zachować nasze dane pomiędzy dwoma wywołaniami serwera.

Tymczasowe przechowywanie

Magazyn tymczasowy to specjalne miejsce, w którym (oprócz danych formularza) można zapisać stan na serwerze. Magazyn może przechowywać dane, które nie są dostępne na kliencie (czyli takie, których nie można umieścić w szczegółach formularza).

Aby pracować z magazynem tymczasowym, użyj metod MoveToTempStorage() Składnia: PlaceToTempStorage(<Данные>, <Адрес>) Opis: Przechowuje wartość możliwą do serializacji w pamięci tymczasowej. Dostępność: cienki klient, klient WWW, serwer, gruby klient, połączenie zewnętrzne, aplikacja mobilna (klient), aplikacja mobilna (serwer). Wywołanie metody wywołuje serwer.<Адрес>(opcjonalnie) Typ: UniqueIdentifier; Linia. Unikalny identyfikator formularza, w którym czasowo mają zostać umieszczone dane i ma zostać zwrócony nowy adres. Lub adres w magazynie tymczasowym, pod którym dane mają zostać umieszczone. Adres należy uzyskać wcześniej tą metodą. Jeśli zostanie przekazany formularz UniqueIdentifier lub adres w magazynie, wartość zostanie automatycznie usunięta po zamknięciu formularza. Jeśli zostanie przekazany UniqueIdentifier, który nie jest unikalnym identyfikatorem formularza, wartość zostanie usunięta po zakończeniu sesji użytkownika. Jeśli parametr nie zostanie określony, umieszczona wartość zostanie usunięta po kolejnym żądaniu serwera z modułu współdzielonego, po wywołaniu serwera kontekstowego i niekontekstowego z formularza, po wywołaniu serwera z modułu poleceń lub po pobraniu formularza. Uwaga: Magazyn tymczasowy utworzony w jednej sesji nie jest dostępny z innej sesji. Wyjątkiem jest możliwość przesyłania danych z zadania w tle do sesji, która zainicjowała zadanie w tle przy użyciu magazynu tymczasowego. W przypadku takiego przelewu w sesji nadrzędnej umieść pustą wartość w magazynie tymczasowym, przekazując identyfikator formularza. Następnie przekaż otrzymany adres do zadania w tle poprzez parametry zadania w tle. Ponadto, jeśli ten adres jest używany w parametrze<Адрес>, wynik zostanie skopiowany do sesji, z której uruchomiono zadanie w tle. Dane umieszczone w magazynie tymczasowym w zadaniu w tle nie będą dostępne z sesji nadrzędnej, dopóki zadanie w tle nie zostanie zakończone. i GetFromTempStorage() Składnia: GetFromTempStorage()<Адрес>) Opis: Pobiera wartość z magazynu tymczasowego. Dostępność: cienki klient, klient WWW, serwer, gruby klient, połączenie zewnętrzne, aplikacja mobilna (klient), aplikacja mobilna (serwer). Wywołanie metody wywołuje serwer. Uwaga: Wynik wykonania nie jest buforowany, serwer jest wywoływany za każdym razem, gdy wywoływana jest metoda.

Kod serwera wywołującego

Każde wywołanie kodu serwera zawsze serializuje przesyłane dane. Wszystkie parametry są pakowane w postaci łańcuchów i przesyłane przez sieć. Wynik pracy jest również przenoszony z powrotem w formie serializowanej, gdzie jest następnie odtwarzany w znanych obiektach.

Przypisanie flag modułów

• Flaga wskazuje, gdzie zostanie skompilowany kod modułu (na serwerze, na kliencie, w połączeniu zewnętrznym)
• Jeśli moduł jest kompilowany w wielu miejscach, będzie widoczny tylko zgodnie z flagami
• Przekazanie wykonania kodu jest możliwe tylko wtedy, gdy w bieżącym kontekście wykonania nie ma wywoływanego modułu, ale istnieje on gdzie indziej (jeśli moduł istnieje tylko na serwerze, a nie ma go na kliencie, to zostanie wywołany serwer)

Flaga wywołania serwera

Począwszy od platformy 1C:Enterprise 8.2, dodano flagę „wywołanie serwera”. Co po prostu pomaga „rozwiązać” warunki przejścia na inną maszynę. Jeśli ta flaga jest przypisana do modułu, to moduł będzie widoczny od klienta, jeśli nie, to próba wywołania od klienta zakończy się błędem. Kod modułu nie będzie widoczny, tak jakby w ogóle nie istniał.

Tak więc w zwykłym grubym kliencie możesz przenieść kod na serwer tylko wtedy, gdy wywołasz wspólny moduł od klienta, dla którego:

• Pole wyboru serwera zaznaczone
• Pole wyboru „Połącz serwer” jest zaznaczone
• Usunięto wszystkie pola wyboru „klienta”.

Wraz z pojawieniem się platformy 1C Enterprise 8.2 mechanizm rozwoju interfejsu użytkownika znacznie się zmienił. Teraz możesz tworzyć zarządzane formularze i aplikacje (rysunek 1).

Obrazek 1

Ponadto zaproponowano nowy system rozdzielania funkcjonalności między aplikacją kliencką a serwerem.
Aplikacja zarządzana obsługuje następujące typy klientów:

• Gruby klient (tryb uruchamiania normalnego i zarządzanego),
• cienki klient,
• Klient WWW.

Mechanizm tworzenia formularzy zarządzanych znacznie różni się od formularzy konwencjonalnych. Przede wszystkim formularze zarządzane różnią się tym, że są tworzone automatycznie przez system na podstawie specjalnych ustawień, teraz programista nie musi szczegółowo rysować każdego formularza. Cała funkcjonalność formularza jest opisana w postaci szczegółów i poleceń. Szczegóły to dane, z którymi współpracuje formularz, a polecenia to wykonywane akcje. Dla każdej metody lub zmiennej formularza musi być określona dyrektywa kompilacji, która określa miejsce wykonania (klient lub serwer). Dyrektywy kompilacji mogą być:

• &U klienta,
• &Na serwerze,
• &Na serwerzeBezkontekstu,
• &U klientaNa serwerzebezkontekstu.

Formularz zarządzany różni się również od zwykłego formularza typami danych, z którymi współpracuje. Jeśli zwykły formularz działa z większością typów dostarczonych przez 1C:Enterprise (w tym typy DirectoryObject, DocumentObject itp.), W zarządzanym formularzu można wyróżnić następujące kategorie typów:

• typy, które są bezpośrednio używane w formularzu, to typy, które istnieją po stronie cienkiego klienta i klienta internetowego (na przykład Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
• typy, które zostaną przekonwertowane na specjalne typy danych, są typami danych formularzy zarządzanych. Takie typy są wyświetlane na liście atrybutów formularza w nawiasach, na przykład (CatalogObject.Products);
• lista dynamiczna.

Funkcjonowanie formularzy zarządzanych ma następujące cechy charakterystyczne (Rysunek 2):

• Formularz istnieje zarówno na kliencie, jak i na serwerze.

Wykonuje interakcję klient-serwer (przesyłanie danych i właściwości projektowych elementów).

• Formularz nie działa z obiektami aplikacji

Rysunek 2

Formularz wykorzystuje specjalne obiekty generyczne
Formularze danych(Rysunek 3).


Rysunek 3

Obiekty aplikacji działają tylko na serwerze i tylko podczas określonych operacji.
Podczas otwierania formularza:

• Obiekt jest odczytywany z bazy danych,
• Obiekt jest konwertowany na dane formularza,
• Obiekt jest usuwany (z pamięci),
• Dane z formularza są przekazywane do klienta.

Podczas nagrywania:

• Dane formularza są odbierane od klienta,
• Dane formularza są konwertowane na obiekt,
• Obiekt jest zapisywany do bazy danych,
• Obiekt jest usuwany (z pamięci).

W ostatniej lekcji rozważaliśmy zwykłego (grubego) klienta. W wersji platformy 1C 8.2. Używają nowych formularzy ekranowych 1C 8.2. Nazywa się je formularzami zarządzanymi 1C 8.2.

Zarządzane formularze 1C 8.2 to przyszłość 1C. Różnią się od zwykłych formularzy 1C 8.2 tym, że są generowane automatycznie przez system na podstawie specjalnych ustawień („zwykłe” formularze są po prostu rysowane przez programistę do woli).

Różnice w rozwoju formularzy zarządzanych 1C 8.2 od zwykłych są znaczące. Dlatego zebraliśmy się dzisiaj, aby osobno omówić tworzenie i modyfikację formularzy zarządzanych 1C 8.2.

Zarządzane formularze 1C 8.2

Jeśli wcześniej opracowywałeś konfiguracje 1C, po otwarciu edytora formularzy zarządzanych 1C 8.2 od razu będziesz zdezorientowany faktem, że w ogóle nie można wpływać na formularz 1C 8.2 za pomocą myszy.

Nie możesz zmienić formularza 1C 8.2, nie możesz przenieść elementu, nie możesz nawet wyświetlić właściwości pola jak poprzednio - klikając dwukrotnie pole na formularzu 1C 8.2.

Teraz podstawą do opracowania formularza 1C 8.2 nie jest wiązanie pól ze współrzędnymi w formularzu, ale specjalne ustawienia. System automatycznie generuje zarządzany formularz 1C 8.2 na podstawie tych ustawień.

Ustawienia składają się z listy elementów formularza 1C 8.2 znajdujących się w edytorze w lewym górnym rogu. Elementy formularza 1C 8.2 obejmują:

• Przybory
• Polecenia (nowa koncepcja 1C 8.2, może wyglądać jak przyciski lub elementy menu)
• Grupy (do łączenia szczegółów i poleceń).

W związku z tym ustawienia tych elementów nie znajdują się we właściwościach pól, ale we właściwościach tych elementów ustawień (menu prawego przycisku myszy, element Właściwości).

Jak działają formularze zarządzane 1C 8.2

Praca z formularzami zarządzanymi 1C 8.2 jest inna dla użytkownika. Mają więcej funkcji, ale są niezwykłe dla tych, którzy pracują z 1C od dłuższego czasu.

Przede wszystkim różni się lokalizacja zwykłych elementów w formularzu 1C 8.2. Pasek poleceń jest zawsze na górze.

Lewą stronę paska poleceń można dostosować. Zwykle zawiera takie typowe przyciski, jak Nagraj i Wyślij.

Prawa strona panelu poleceń to nowe standardowe menu formularza 1C Wszystkie akcje. To menu pozwala zarządzać formularzem 1C 8.2 według własnego uznania, podobnie jak ustawienia w raporcie ACS pozwalają znacząco zmienić wygląd raportu.

Dowolne pozycje menu 1C Wszystkie akcje

W zależności od tego, czy ten formularz 1C 8.1 należy do jednego, czy drugiego, menu jest wypełnione elementami, które pozwalają zarządzać tym obiektem. Na przykład, jeśli jest to formularz listy katalogów, pojawią się polecenia takie jak Utwórz lub Edytuj.

Pozycja Dostosuj listę menu 1C Wszystkie akcje

Jeśli w formularzu 1C 8.2 znajduje się lista, menu zawiera polecenie Ustaw listę i Wyświetl listę.
Jeśli polecenie Lista wyjściowa jest już Ci znane - pozwala zapisać dowolną listę w 1C w Excelu / wydrukować ją, to drugie polecenie jest nowe.

Jak już zauważyłeś, na pasku poleceń list nie ma już przycisków wyboru. Zamiast tego pojawił się przycisk Znajdź, do którego działa (a także do wyłączonego teraz pozycjonowania kursora na liście podczas pisania) - są skargi.

Funkcjonalność przycisku Znajdź oczywiście nie jest porównywalna z wyborami, ale nigdzie nie zniknęły!
Znajdują się one teraz w pozycji menu Dostosuj listę. Selekcji można teraz dokonać według dowolnego pola, a dodatkowo sortowanie i formatowanie warunkowe można wykonać w taki sam sposób, jak w raportach SKD.

Pozycja Zmień formularz menu 1C Wszystkie akcje

Pozycja formularza Zmień pozwala w podobny sposób zmienić nie tylko listę w formularzu 1C 8.2, ale także sam formularz 1C 8.2.

Użytkownik może niezależnie włączać lub wyłączać widoczność pól w formularzu 1C 8.2, szerokość i wysokość, aktywację domyślnego pola podczas otwierania itp.

Korzystanie z formularzy zarządzanych 1C 8.2 i konwencjonalnych formularzy 1C

Domyślnie zwykłe formularze 1C są używane w konfiguracjach grubego (zwykłego) klienta 1C, a formularze zarządzane są używane w konfiguracjach cienkiego i internetowego klienta 1C. Jednak obie formy 1C mogą być używane w dowolnej konfiguracji, w tym jednocześnie.

W tym celu należy również wejść we właściwości konfiguracyjne (górny element w oknie konfiguracyjnym).

We właściwościach konfiguracji w 1C 8.2 pojawiły się dwa nowe pola wyboru, które pozwalają włączyć niestandardowe użycie formularzy 1C.

Tworzenie formularzy zarządzanych 8.2

Dodanie nowego formularza 1C 8.2 odbywa się w taki sam sposób jak poprzednio - za pomocą przycisku Ins na klawiaturze lub przycisku Dodaj. Aby wprowadzić istniejący, kliknij go dwukrotnie myszą.

Domyślnie zostanie utworzony formularz (zwykły lub zarządzany) ustawiony w konfiguracji (patrz właściwość Główny tryb uruchamiania we właściwościach konfiguracji).

Konstruktor poprosi o wybór typu formularza - forma elementu, lista. Tutaj możesz dodawać lub usuwać paski poleceń na formularzu. Najczęściej te ustawienia są domyślnie pozostawione bez zmian.

Otwiera się formularz wypełniony domyślnie - wszystkie szczegóły obiektu 1C, które są do niego dodane. Możesz zaznaczyć konkretną listę wymaganych pól na drugiej zakładce konstruktora.

Edytor formularzy składa się z trzech sekcji.

• W lewym górnym rogu znajduje się lista elementów formularza. Składa się z pól, poleceń i grup, które umożliwiają łączenie elementów. Listę poleceń można przeglądać oddzielnie na karcie Interfejs poleceń.
• W prawym górnym rogu znajduje się lista dostępnych atrybutów formularza oraz atrybutów obiektu (otwórz krzyżyk obok atrybutu Obiekt).
• Poniżej znajduje się podgląd wynikowego formularza.

Możesz przeciągnąć dostępne szczegóły w lewo i stanie się to elementem formularza (polem na formularzu).

Jeśli chcesz dodać przycisk lub element menu - po prawej stronie zakładki Polecenia musisz utworzyć nowe Polecenie. To jest opakowanie dla funkcji w module formularza. Oprócz określenia, która funkcja zostanie faktycznie wywołana, można przypisać reprezentację - na przykład obraz, a także zależność widoczności od opcji funkcjonalnej.

Polecenia są również przeciągane w lewo. Jeśli rodzic jest paskiem poleceń, będzie to przycisk paska poleceń - w przeciwnym razie tylko przycisk.

Na liście elementów formularza (pól) można nie tylko przeciągnąć atrybut obiektu/formularza, ale także po prostu go dodać (przycisk Dodaj lub Ins). W szczególności możesz utworzyć nowy obiekt formularza - Grupę.

Grupą może być panel poleceń (kursor musi znajdować się w wierszu Formularz). Następnie przeciągasz do niego polecenia i stają się one przyciskami.

Grupa może być „zwykła”. Następnie jest to sposób na grupowanie pól zarówno w pionie, jak iw poziomie. Nazwę grupy można usunąć we właściwościach.

Grupą może być panel (strony). Najwyżej dodaną grupą jest panel, a zagnieżdżonymi grupami tego typu są strony. Pola są już przeciągane na strony.

Zbędne elementy formularza są usuwane poprzez usunięcie elementów formularza z listy.
Położenie pola na formularzu określa kolejność elementów na liście (pionowo) lub grupami (poziomo). Szerokość i wysokość ustawia się we właściwościach elementu formularza.

Właściwości elementu formularza zostały znacznie rozbudowane i zawierają wiele przydatnych rzeczy - zarówno kontrolę wyglądu (przyciski wyboru i czyszczenia), jak i sprawdzanie wartości domyślnych.

Właściwości samego formularza, w tym jego wymiary, są ustawiane w elemencie głównym formularza o tej samej nazwie Form.

Programy obsługi zdarzeń (odpowiedzi na akcje użytkownika) dzielą się teraz na dwa typy. Stare - tak jak poprzednio, określa się je we właściwościach formularza i pól (np. OnChange i OnOpening the form). Nowość — stały się poleceniami i są używane w pozycjach menu i przyciskach.

Od wersji platformy 8.2 1C zaczął stosować nowe zasady budowania interfejsu i interakcji użytkownika z bazą danych. Nowa technologia nazywa się Managed Application. Największemu przetworzeniu uległy mechanizmy konstruowania formularzy i schemat interakcji między użytkownikiem serwera 1C a bazą danych. Tryb normalny jest nadal obsługiwany przez platformę, ale z czasem wszyscy użytkownicy 1C przejdą na zarządzane formularze.

Dla zwykłych użytkowników zarządzana forma dokumentu 1C różni się od zwykłego tylko wyglądem. Dla dewelopera jest to nowy mechanizm z własnymi zasadami, prawami i warunkami. Wiele obszarów uległo zmianie, ale następujące innowacje są uważane za kluczowe wśród doświadczonych programistów 1C:

• Samodzielne tworzenie struktury formularza i rozmieszczenie pól przez platformę. Jeśli wcześniej programiści opisywali położenie pola, określając piksele, teraz możliwe jest jedynie określenie typu grupowania;
• Formularz składa się z atrybutów reprezentujących dane formularza oraz poleceń - procedur i wykonywanych funkcji;
• Kod formularza jest wykonywany zarówno po stronie serwera, jak i klienta. W końcu sam formularz jest obiektem konfiguracyjnym tworzonym na serwerze i wyświetlanym na kliencie. Oznacza to, że łączy w sobie część klienta i serwera;
• Po stronie klienta wiele typów danych stało się niedostępnych i teraz nie ma możliwości zmiany danych w infobazie;
• Dla każdej procedury lub funkcji należy określić specjalne ustawienie — dyrektywę kompilacji. Odpowiada za miejsce wykonania kodu i może przyjmować następujące wartości:
  • na kliencie;
  • na serwerze;
  • Na serwerze bez kontekstu;
  • na kliencie na serwerze;
  • Na kliencie na serwerze bez kontekstu.

Ostatni punkt jest szczególnie dotkliwy w trybie zarządzanych formularzy. Jeśli programista nie jest dobrze zorientowany w dyrektywach lub interakcji klient-serwer, stworzenie zarządzanego formularza będzie mu niezwykle trudne. Wszystkie nowe zasady budowania formularzy zarządzanych w 1C:Enterprise 8.3 łączy ogólna koncepcja architektury trójwarstwowej. Obejmuje komputery klienckie, serwer 1C i DBMS, w którym przechowywane są dane.

Inna stała się również edycja formularza zarządzanego w konfiguratorze. Wiele aspektów uległo zmianie i twórcy wersji 7.7, w której nie było formularzy zarządzanych, mogą być zaskoczeni. Zmienił się nawet wygląd projektanta formularzy, co można zobaczyć otwierając dowolny formularz obiektu konfiguracyjnego. Podczas otwierania obiektu widzimy okno podzielone na kilka sekcji:

1. Elementy interfejsu formularza. W lewym górnym rogu znajduje się okno z listą wszystkich pól wyświetlanych na wybranym formularzu, które zapewniają interakcję programu z użytkownikiem;
2. Szczegóły formularza. W prawym górnym rogu znajdują się wszystkie dane, z którymi współpracuje formularz. To w nich przechowywane są informacje po stronie klienta;
3. Wyświetlanie zarządzanego formularza. Poniżej widzimy podgląd wyglądu w oparciu o elementy interfejsu;
4. Moduł formularza. Sekcja zawierająca procedury i funkcje używane przez ten formularz. Tutaj znajdziesz kod algorytmów interakcji programu zarówno z użytkownikiem, jak i bazą danych.

Deweloperzy 1C zachęcają klientów do przejścia na formularze zarządzane, więc poznanie zasad tworzenia formularzy zarządzanych jest kwestią czasu. Rozpoczynając pracę z tego typu formularzem zrozumiesz, że jest to krok w kierunku standaryzacji rozwoju i przestrzegania jednolitych zasad. Dlatego możliwość pracy z formularzami zarządzanymi w 1C 8.3 zwiększa Twój poziom jako programisty 1C.

Wytyczne dotyczące projektowania formularzy zarządzanych

Przede wszystkim, aby zrozumieć mechanizm trybu zarządzanego 1C, należy pamiętać, że formularz istnieje zarówno na serwerze, jak i na kliencie. Ponadto na kliencie obiekt ten jest jedynie obrazem interfejsu interakcji użytkownika z programem. Wszelkie obliczenia, algorytmy, obliczenia i przetwarzanie muszą odbywać się wyłącznie po stronie serwera. Jest to podyktowane nie tylko brakiem możliwości korzystania z wielu funkcji i parametrów na kliencie, ale także wymaganiami wydajnościowymi.

Możesz dowiedzieć się, gdzie procedura jest wykonywana, po nazwie dyrektywy, która musi być napisana przed każdą procedurą i funkcją w module formularza. Sformułowanie „Bez kontekstu” oznacza, że ​​dane w formularzu zarządzanym nie zostaną przekazane do tej procedury na serwerze. Tym samym w takich procedurach nie będzie możliwe pisanie algorytmów na podstawie wartości wprowadzonych przez użytkownika. Jeśli to sformułowanie nie jest określone, formularz jest przesyłany w całości ze wszystkimi szczegółami i możesz uzyskać do nich dostęp.

Programiści 1C zdecydowanie zalecają używanie wywołań serwera bez kontekstu, zmniejszając ich liczbę tak bardzo, jak to możliwe i starając się nie wykonywać obliczeń na kliencie. Początkującym programistom bez zaplecza teoretycznego trudno jest zastosować się do wszystkich tych zasad i poprawnie zmienić kod. Zanim zaczniesz pracować samodzielnie, warto otworzyć formularz konfiguracji zarządzanej, przyjrzeć się składni i interakcji klienta z serwerem.

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

Nowe zasady opracowywania formularzy 1C będą bardzo korzystne, jeśli wszyscy programiści będą ich przestrzegać. Co więcej, wszyscy odczują zmiany na lepsze - zarówno programiści, jak i firmy pracujące w 1C, a także franczyzobiorcy i programiści 1C. Główne konsekwencje prawidłowego działania formularzy zarządzanych w 1C:

1. Łatwość utrzymania konfiguracji i zwiększona czytelność kodu. Z tego możemy wywnioskować, że algorytm napisany przez jednego programistę zawsze może zostać poprawiony przez innego pracownika bez poświęcania dużej ilości czasu;
2. Separacja kodu działającego na kliencie i serwerze. Biorąc pod uwagę, jak różna jest funkcjonalność dostępna po każdej z tych stron, rozdzielenie ich byłoby właściwym posunięciem;
3. Deweloperzy lepiej rozumieją logikę platformy, interakcje klient-serwer oraz pisane przez siebie algorytmy. W wersjach 8.0 i wcześniejszych bardzo często można było znaleźć formularze dokumentów lub katalogów opracowane bez zrozumienia części klient-serwer;
4. Zwiększenie szybkości konfiguracji i zmniejszenie obciążenia komputerów klienckich;
5. Obniżenie kosztów zakupu komputerów do zakładów pracy ze względu na brak konieczności zakupu wydajnych komputerów.

Wybór zarządzanego formularza jako głównego trybu uruchamiania 1C może przynieść wiele niespodzianek. Ale przy odpowiednim podejściu ten krok przyniesie duże dywidendy, więc decyduje się na to coraz więcej użytkowników 1C w całej Rosji. Biorąc pod uwagę fakt, że firma 1C liczy na rozwój zarządzanych formularzy w przyszłości, ryzykowne jest pozostawanie na przestarzałych konwencjonalnych.