1c problemy z zarządzanymi formularzami. Programowe dodawanie i modyfikowanie zarządzanych elementów formularza

W tym artykule poznamy główne aspekty pracy z zarządzanym formularzem w 1C 8.3. Co to jest forma i do czego służy? Formularz jest głównym obiektem, za pośrednictwem którego użytkownik współdziała z programem. Oznacza to, że za pomocą formularza użytkownik wprowadza informacje do programu, a także informacje wymagane dla użytkownika są wyświetlane w formularzu.

Głównym zadaniem programisty dowolnej formy (zarządzanej lub konwencjonalnej) jest zapewnienie użytkownikowi wygodnego mechanizmu interakcji z programem.

Platforma 1C ma możliwość generowania dowolnej formy obiektu, ale zazwyczaj przy opracowywaniu rozwiązań aplikacyjnych programiści samodzielnie konfigurują formularze.

Kwestie pracy z zarządzanymi formularzami w szczególności i ogólnie z zarządzaną aplikacją są szczegółowo omówione w książce „Podstawy rozwoju w 1C: Taxi. Tworzenie zarządzanej aplikacji w 12 krokach ”. Ta książka będzie prawdziwą pomocą dla tych, którzy dopiero rozpoczynają tworzenie zarządzanej aplikacji.

Książka „Podstawy programowania w 1C: Taxi” jest idealna dla tych, którzy już zaczęli programować i mają pewne trudności z tym tematem oraz dla tych, którzy programują od dłuższego czasu, ale nigdy nie pracowali z formularzami zarządzanymi przez 1C.

1. Żadnych skomplikowanych terminów technicznych;
2. Ponad 600 stron praktycznego materiału;
3. Każdemu przykładowi towarzyszy zdjęcie (zrzut ekranu);

15% rabat kod promocyjny - 48PVXHeYu

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

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

1. Żadnych skomplikowanych terminów technicznych.
2. Ponad 700 stron praktycznego materiału.
3. Każdemu zadaniu towarzyszy zdjęcie (zrzut ekranu).
4. Zbiór zadań do pracy domowej.
5. Książka jest napisana jasnym i prostym językiem - dla początkującego.
6. Książka jest wysyłana do e-mail w formacie PDF. Można go otworzyć na dowolnym urządzeniu!

Jeśli ta lekcja pomogła Ci rozwiązać jakiś problem, spodobała Ci się lub okazała się przydatna to możesz wesprzeć mój projekt przelewem dowolnej kwoty:

możesz zapłacić ręcznie:

Yandex.Money - 410012882996301
Pieniądze internetowe - R955262494655

Dołącz do moich grup.

Wszyscy wiemy, że 1C miało wiele różnych wersji platformy 1C, teraz będziemy zainteresowani niektórymi najnowszymi wersjami w momencie pisania tego tekstu, są to wersje 1C 8.2 i 1C 8.3. Jeśli musiałeś pracować w obu tych wersjach, najprawdopodobniej zauważyłem różnice w interfejsach tych wersjidla użytkowników różnią się tylko zewnętrznie. Zasadniczo wybór zwykła lub zarządzana aplikacja informuje system, które formularze mają być wyświetlane do uruchomienia, konwencjonalne lub zarządzanei który klient aplikacji będzie używany domyślnie, gruby czy cienki. Więcej informacji na temat klientów można znaleźć w artykule „Co to jest gruby i cienki klient w 1C, a także o ich różnicach”.

Zwykła aplikacja 1C (zwykłe formularze, zwykły interfejs, wersja 1C 8.2)

W 1C 8.2 możliwa jest tylko praca na zwykłych formularzach, w normalnym trybie aplikacji... Poniższy rysunek przedstawia podstawę w trybie „normalnej aplikacji 1C” (regularne formy).

Zarządzana aplikacja 1C (zarządzane formularze, zarządzany interfejs, wersja 1C 8.3)

Na platformie 1C 8.3 możemy pracować zarówno ze zwykłymi formularzami (w trybie zgodności), jak iz zarządzanymi. Ponadto formularze zarządzane mają dwa typy wyświetlania, standard i taxi... Przykład konfiguracji 1C 8.3 ze standardowymi formularzami zarządzanymi przedstawiono poniżej, a po nim interfejs „Taxi”.

Jaka jest różnica między zwykłą a zarządzaną aplikacją 1C?

Jak już się dowiedzieliśmy zwykła aplikacja i aplikacja zarządzana to takie rodzaje uruchamiania programu 1C... Ponadto, w zależności od wartości typu uruchomienia 1C ( zwykła lub zarządzana aplikacja), domyślnie określony interfejs ( regularne lub zarządzane formularze), stąd jest tak wiele synonimów tego pojęcia. Chcielibyśmy zauważyć, że różnice w interfejsach są dość znaczące, zarządzany interfejs został całkowicie przeprojektowany. Zasadniczo są to wszystkie różnice, które widzą zwykli użytkownicy programu 1C. Jeśli chodzi o programistów, zarządzany interfejs wymaga napisania zmodyfikowanego kodu, ponieważ prace nad nim trwają już w 1C 8.3, a nie w 1C 8.2, stąd wszystkie wynikające stąd konsekwencje. Kod należy również podzielić na klienta i serwer, jest to wskazane za pomocą odpowiednich dyrektyw w konfiguratorze.

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

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

• Podczas rewizji typowych konfiguracji w celu ułatwienia kolejnych aktualizacji. W takim przypadku tylko moduł formularza zostanie zmieniony. Moduły są znacznie łatwiejsze do aktualizacji niż formularze.
• Przy wdrażaniu niektórych ogólnych algorytmów. Na przykład w podsystemie „Zabroń edycji atrybutów obiektu” dla wszystkich obiektów podłączonych do podsystemu, tworzenie oprogramowania przyciski umożliwiające edycję szczegółów.
• Przy wdrażaniu określonych algorytmów. Na przykład w katalogu Nomenclature tworzone są pola umożliwiające edycję dodatkowych szczegółów.

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

• przybory;
• polecenia lokalne;
• elementy.

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

Programowa zmiana kształtu ma ograniczenia:

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

Zmiana poleceń formularza

Zarządzanie składem zespołów w obiekcie ManagedForm jest kolekcja Polecenia

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

Ilość ()

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

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

Kolekcja Teams jest dostępna zarówno na kliencie, jak i na serwerze. Zmiana kolekcji (metody Add () i Remove ()) może być wykonana 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 formularza, stwórzmy nowe polecenie ChangeHistory z nagłówkiem „Change History…”, które wywoła procedurę obsługi Pokaż historię(). Tworzenie jest wykonywane po otwarciu formularza.

& Na serwerze
Procedura OnCreateAtServer (awaria, StandardProcessing)
Zespół \u003d Polecenia. Dodaj ( "Zmieniać historię");
Zespół ... Action \u003d;
Zespół ... Tytuł \u003d "Zmieniać historię ...";
Koniec procedury
& Na kliencie
Procedura Connectable_DisplayHistory (Command)
// działania poleceń
Koniec procedury

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

Modyfikacja szczegółów formularza

Funkcja odczytuje skład atrybutów formularza Uzyskaj szczegółowe informacje(< Путь >), która zwraca tablicę typu Atrybut formularza. Parametr funkcji określa ścieżkę do właściwości nadrzędnych (jako ciąg znaków). Jeśli parametr zostanie pominięty lub zostanie określony pusty łańcuch, zwracane są właściwości najwyższego poziomu.

Zmiana szczegółów odbywa się metodą Zmodyfikuj szczegóły(<Dodano szczegóły>, <Wymienne atrybuty>) obiekt ManagedForm... W parametrach Dodano szczegóły i Wymienne atrybuty przenoszone są tablice z elementami typu Form Attribute.

Uwaga!

Proces zmiany składu szczegółów jest dość zasobochłonny. W rzeczywistości forma jest odtwarzana. W związku z tym praca z atrybutami formularza odbywa się w trybie wsadowym.

Utwórzmy nowy atrybut formularza o nazwie Customer:

AddedAttributes \u003d New Array;
Atrybuty do dodania. Dodaj (nowe rekwizyty formularzy(„Kupujący”, Nowy opis typów („DirectoryLink.Contractors”), „Klient”));

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

Modyfikowanie elementów formularza

Aby kontrolować kompozycję elementów obiektu ManagedForm jest kolekcja Elementy ... Zbiór ma kilka metod:

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

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

Ilość ()

Znaleźć (< Имя >)

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

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

Kolekcja Elements jest dostępna zarówno po stronie klienta, jak i serwera. Zmodyfikuj kolekcję (metody Insert () , Add (), Move () i Delete ()) można wykonać 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ć:

• Form Group;
• Tabela formularza;
• Pole formularza;
• Przycisk formularza.

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

Rozważmy kilka typowych przykładów pracy z poleceniami, właściwościami i elementami formularzy.

Dodawanie polecenia i skojarzonego z nim przycisku:

// Utwórz polecenie
Zespół \u003d Polecenia. Dodaj ( "Zmieniać historię");
Zespół ... Action \u003d „Connectable_DisplayHistory”; // Formularz musi mieć procedurę o określonej nazwie
Zespół ... Tytuł = "Zmieniać historię ...";
// Utwórz przycisk i połącz go z poleceniem
Element \u003d Przedmioty. Dodaj ( "Zmieniać historię", Typ („Przycisk formularza”));
Element.CommandName = "Zmieniać historię";

Dodawanie rekwizytów i powiązanego pola wejściowego:

// Opis dodanych szczegółów
AddedAttributes \u003d New Array;
Atrybuty do dodania. Dodać do(Nowe rekwizyty formularza („Kupujący”, Nowy opis typów ( „DirectoryLink. Wykonawcy”), "Klient" ));
// Zmień kompozycję szczegółów
EditAttributes (AddedAttributes);
// Utwórz pole wejściowe i łącze do właściwości
Element \u003d Pozycje. Dodaj ("Kupujący", Typ ("FormField"));
Element ... View \u003d FormFieldKind. Pole wejściowe;
Element ... Ścieżka danych \u003d "Kupujący";

Przypisywanie obsługi zdarzeń do elementu formularza:

Kupujący przedmiot. Ustaw akcję("Kiedy się zmieni", „Plugin_BuyerOnChange”);

& Na kliencie
Procedura Plugin_BuyerOnChange(Pozycja)
// Działania związane z wydarzeniami
Koniec procedury

Uwaga!

Procedury, które są ustawiane jako programy obsługi zdarzeń z kodu przy użyciu metody SetAction (), zaleca się ustawienie przedrostka Connect_.

Uwaga!

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

Formularze w 1C: Enterprise są przeznaczone do wyświetlania i edycji informacji zawartych w bazie danych. Formularze mogą należeć do określonych obiektów konfiguracyjnych lub istnieć oddzielnie od nich i być używane przez całe rozwiązanie aplikacji jako całość.

Na przykład plik referencyjny Nomenklatura może mieć kilka formularzy, które posłużą do określonych celów - edycja pozycji katalogu, wyświetlenie listy itp .:

Oprócz tego mogą istnieć formy ogólne, które nie należą do określonych obiektów konfiguracyjnych - formy ogólne.

Podstawowe formy

Każdy obiekt konfiguracyjny może służyć do wykonywania pewnych standardowych działań. Przykładowo, każdy katalog może wymagać wyświetlenia listy jego elementów, wyświetlenia poszczególnych pozycji katalogu, wyświetlenia grupy katalogów oraz wybrania pozycji i grup towarów z katalogu. W przypadku dowolnego dokumentu lista takich działań będzie znacznie mniejsza: przeglądanie listy dokumentów, wybieranie z listy dokumentów i przeglądanie oddzielnego dokumentu.

Aby zapewnić wykonanie takich standardowych akcji z danymi zastosowanych obiektów rozwiązania, dla każdego z nich istnieje zestaw podstawowych formularzy, które będą używane podczas wykonywania odpowiednich akcji. Dowolną z form podrzędnych temu obiektowi można przypisać do głównej. Na przykład plik referencyjny Nomenklaturamogą istnieć następujące podstawowe formy:

I na dokumencie Odbiór towarów i usługskład głównych form będzie inny:

Tak więc, jeśli użytkownik chce zobaczyć listę katalogów Nomenklatura lub lista dokumentów Odbiór towarów i usług, system otworzy odpowiedni formularz przypisany jako formularz listy dla tych obiektów.

Formularze generowane automatycznie

Ważną cechą systemu 1C: Enterprise 8 jest mechanizm automatycznie generowanych formularzy. Ten mechanizm uwalnia dewelopera od konieczności tworzenia wszystkich możliwych formularzy dla każdego z obiektów konfiguracyjnych. Wystarczy, że programista doda nowy obiekt konfiguracyjny, a sam system wygeneruje niezbędne formularze w niezbędnych momentach pracy użytkownika do wyświetlenia informacji zawartych w tym obiekcie.

Dlatego deweloper musi tworzyć własne formy obiektów zastosowanego rozwiązania tylko wtedy, gdy muszą one różnić się (inny projekt lub określone zachowanie) od formularzy generowanych automatycznie przez system.

Powiązanie formularza z danymi

Przynależność formularza do jednego lub innego obiektu konfiguracyjnego nie decyduje o składzie danych wyświetlanych w formularzu. Formularz należy na przykład do katalogu Nomenklatura, pozwala przypisać go do jednego z głównych formularzy tego katalogu, ale w żaden sposób nie określa, jakie dane ten formularz będzie wyświetlać i jakie będzie jego zachowanie.

W celu skojarzenia formularza z danymi wykorzystywane są szczegóły formularza, które wskazują listę danych wyświetlanych przez formularz. Wszystkie formularze same w sobie zachowują się tak samo, niezależnie od wyświetlanych danych. Jednak jeden z atrybutów formularza może być przypisany do niego jako główny (jest wyróżniony pogrubioną czcionką), w takim przypadku standardowe zachowanie formularza i jego właściwości zostaną uzupełnione w zależności od typu, jaki ma atrybut formularza głównego:

Na przykład, jeśli dokument jest przypisany jako główny atrybut formularza Odbiór towarów i usług, to po zamknięciu formularza system poprosi o potwierdzenie zapisania i wysłania tego dokumentu. Jeśli przypiszemy, powiedzmy, podręcznik jako główny atrybut formularza Nomenklatura, po zamknięciu formularza nie będzie takiej prośby o potwierdzenie.

Struktura formy

Główną cechą formularzy jest to, że nie są one szczegółowo rysowane przez programistę „piksel po pikselu”. Formularz w konfiguracji jest logicznym opisem składu formularza. A określone rozmieszczenie elementów jest wykonywane przez system automatycznie po wyświetleniu formularza.

Wyświetlana część formularza (widoczna dla użytkownika) jest opisana jako drzewo zawierające elementy formularza.

Elementy mogą być polami wejściowymi, polami wyboru, przyciskami radiowymi, przyciskami itp. Ponadto element może być grupą zawierającą inne elementy. Grupę można przedstawić jako panel z ramką, panel ze stronami (zakładkami), samą stronę, panel poleceń. Ponadto elementem może być tabela, która zawiera również elementy (kolumny). Struktura elementu opisuje, jak będzie wyglądać formularz.

Cała funkcjonalność formularza jest opisana w postaci rekwizytów i poleceń. Wymagania to dane, z którymi współpracuje formularz, a polecenia to wykonywane czynności. Dlatego programista w edytorze formularzy musi zawrzeć w formularzu niezbędne atrybuty i polecenia, utworzyć elementy formularza, które je wyświetlają oraz, jeśli to konieczne, ułożyć elementy w grupy.

Na podstawie tego logicznego opisu system automatycznie generuje wygląd formularze do wyświetlenia użytkownikowi. W takim przypadku system bierze pod uwagę różne właściwości wyświetlanych danych (np. Typ), aby jak najdogodniej ułożyć elementy formularza dla użytkownika.

Deweloper może wpłynąć na rozmieszczenie elementów o różnych ustawieniach. Potrafi określić kolejność elementów, określić żądaną szerokość i wysokość. Jednak to tylko niektóre dodatkowe informacjepomaganie systemowi w wyświetlaniu formularza.

W formularzach programista może używać nie tylko poleceń samego formularza, ale także poleceń globalnych używanych w interfejsie poleceń całej konfiguracji. Dodatkowo zaimplementowano możliwość tworzenia parametryzowalnych poleceń, które będą otwierać inne formularze w oparciu o konkretne dane aktualnego formularza. Na przykład może to być wywołanie raportu o saldach w magazynie, który jest aktualnie wybrany w postaci faktury.

I Data Transfer Object do strukturyzacji kodu, zarządzanej formy w środowisku 1C 8.2.

Wprowadzenie

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

W 2008 roku stał się dostępny nowa wersja platforma 1C: Enterprise 8.2 (zwana dalej Managed Application), która całkowicie zmienia całą warstwę pracy z interfejsem. Obejmuje to interfejs poleceń, formularze i system okien. To nie tylko zmienia model projektowy interfejsu użytkownika w konfiguracji, ale także proponuje nową architekturę dla oddzielenia funkcjonalności 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

W zarządzana aplikacja stosowane są formularze oparte na nowej technologii. Nazywają się Zarządzane formularze... Aby ułatwić przejście, obsługiwane są również starsze formularze (tak zwane zwykłe formularze), ale ich funkcjonalność nie ewoluuje i są dostępne tylko w trybie uruchamiania grubego klienta.
Główne różnice między formularzami zarządzanymi dla deweloperów to:

• Deklaratywny opis struktury, a nie piksel po pikselu. Określone rozmieszczenie elementów jest wykonywane przez system automatycznie po wyświetleniu formularza.
• Wszystkie funkcje formularza są opisane jako przybory i zespoły... Wymagania to dane, z którymi współpracuje formularz, a polecenia to wykonywane czynności.
• Formularz jest wykonywany zarówno na serwerze, jak i na kliencie.
• W kontekście klienta prawie wszystkie typy aplikacji są niedostępne, a zatem nie można zmienić danych w infobase.
• Dla każdej metody lub zmiennej formularza należy określić dyrektywa kompilacjiktóry określa, gdzie wykonanie (klient lub serwer) i dostęp do kontekstu formularza.

Wymieńmy dyrektywy do kompilowania metod formularzy:

• & Na kliencie
• & Na serwerze
• & OnServerWithoutContext
• & OnClientOnServerBez kontekstu

Zilustrujmy powyższe. Zrzut ekranu przedstawia przykład zarządzanego formularza i jego modułu w trybie programistycznym. Znajdź deklaratywny opis, właściwości, dyrektywy kompilacji itp.

Wszystkie dalsze rozważania będą dotyczyły prawej strony ilustracji, struktury kodu modułu i zasad, które pozwolą na efektywną interakcję 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 licznych partnerów.
Czy w tym czasie programiści wypracowali wspólne rozumienie zasad interakcji klient-serwer podczas tworzenia formularzy i czy podejście do wdrażania modułów oprogramowania zmieniło się w nowych realiach architektonicznych?

Rozważ strukturę kodu (moduł formularza) w kilku formach typowa konfiguracja i spróbuj znaleźć wzorce.
Przez strukturę rozumiemy sekcje kodu (najczęściej są to bloki komentarzy) przydzielone przez programistę do grupowania metod i dyrektyw do kompilowania tych metod.
Przykład 1:
Sekcja obsługi zdarzeń Metoda - na kliencie Metoda - na serwerze Metoda - na kliencie Sekcja procedur i funkcji usługowych Kontrola wejść Funkcje pomocnicze
Przykład 2:
Procedury i funkcje serwisowe Dokumenty płatnicze Wartości Obsługa zdarzeń
Przykład 3:
Procedury usług na serwerze Procedury usług na kliencie Procedury usług na serwerze bez kontekstu Programy obsługi zdarzeń nagłówka Procedury obsługi zdarzeń poleceń
Przykład 4:
Procedury ogólnego przeznaczenia Formularz obsługi zdarzeń Procedury dla podsystemu „informacje kontaktowe”
W rzeczywistości brakuje struktury kodu, lub delikatnie mówiąc, jest on podobny do tego, co było w formularzach 8.1:

• Nieinformacyjne słowa „Ogólne, serwisowe, pomocnicze”.
• Nieśmiałe próby oddzielenia metod klienta i serwera.
• Metody są często pogrupowane według elementów interfejsu „Praca z tabelaryczną sekcją Produkty, Informacje kontaktowe”.
• Dowolny układ metod i grup kodów. Na przykład, programy obsługi zdarzeń mogą być w jednej formie na górze, w innej na dole, w trzeciej w ogóle nieprzydzielonej itd.
• I nie zapominajmy, że to wszystko w jednej konfiguracji.
• Tak, są konfiguracje, w których słowa „Ogólne, serwisowe, pomocnicze” są zawsze w tych samych miejscach, ale ...

Dlaczego potrzebujesz struktury kodu?

• Uproszczenie konserwacji.
• Uproszczenie nauki.
• Ustalanie ogólnych / ważnych / dobrych zasad.
• ... twoja opcja

Dlaczego obecny standard rozwoju od 1C nie pomaga?

Przyjrzyjmy się zasadom opublikowanym na dyskach ITS oraz w różnych „Przewodnikach dla programistów ...”, które są zalecane podczas pisania zarządzanego formularza.

• Zminimalizuj liczbę połączeń z serwerem.
• Maksymalne obliczenia na serwerze.
• Niekontekstowe wywołania serwera są szybsze niż wywołania kontekstowe.
• Program z myślą o interakcji klient-serwer.
• itp.

To są absolutnie poprawne hasła, ale jak można je wdrożyć? Jak zminimalizować liczbę wywołań, co to znaczy programować w trybie klient-serwer?

Wzorce projektowe lub mądrość pokoleń

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

• Zdalna fasada (zwany dalej interfejsem zdalnego dostępu)
• Obiekt transferu danych (dalej „Obiekt do przesyłania danych”)

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

• … każdy obiekt potencjalnie przeznaczony do zdalnego dostępu musi mieć interfejs o niskiej szczegółowościaby zminimalizować liczbę połączeń wymaganych do wykonania określonej procedury. ... Zamiast żądać faktury i wszystkich jej pozycji osobno, musisz przeczytać i zaktualizować wszystkie pozycje faktury w jednym połączeniu. Ma to wpływ na całą strukturę obiektu… Pamiętaj: interfejs zdalnego dostępu nie zawiera logiki domeny.
• ... gdybym była troskliwą matką, zdecydowanie powiedziałabym swojemu dziecku: „Nigdy nie pisz obiektów do przesyłania danych!” W większości przypadków obiekty transferu danych to nic innego jak rozdęty zbiór pól ... Wartość tego obrzydliwego potwora polega wyłącznie na jego zdolności przesyłać kilka informacji przez sieć podczas jednego połączenia - odbiór, który ma bardzo ważne dla systemów rozproszonych.

Przykłady szablonów na platformie 1C

Interfejs API dostępny dla dewelopera podczas opracowywania formularza zarządzanego zawiera wiele przykładów tych zasad.
Na przykład metoda OpenForm (), typowy „zgrubny” interfejs.
Parametry otwarte \u003d Nowa struktura („Parametr1, Parametr2, Parametr3”, Wartość1, Wartość2, Wartość3); Form \u003d OpenForm (FormName, OpenParameters);
Porównaj ze stylem przyjętym w wersji 8.1.
Form \u003d GetForm (FormName); Form.Parameter1 \u003d Value1; Form.Parameter2 \u003d Value2; Form.Open ();

W kontekście zarządzanego formularza istnieje wiele obiektów migracji danych. Można wyróżnić systemowy i programista zdefiniowany.
Obiekty systemowe modelują na kliencie obiekt aplikacji w postaci jednego lub kilku elementów danych formularza. Nie można ich tworzyć poza wiązaniem z atrybutami formularza.

• DataFormsStructure
• DataFormsCollection
• DataShapesStructureCollection
• DataShapeTree

Konwersja obiektów systemowych transferu danych na stosowane typy i odwrotnie odbywa się metodami:

• ValueVDataForm ()
• FormDataValue ()
• CopyForm Data ()
• Atrybut ValueBForm ()
• PropsFormVValue ()

Często podczas adaptacji istniejącego rozwiązania stosowana jest jawna transformacja. Metody mogą oczekiwać (używać funkcji) parametrów wejściowych, takich jakValueTable zamiastFormDataCollection, lub metoda została zdefiniowana w kontekście obiektu aplikacji i nie jest już dostępna do bezpośredniego wywołania z formularza.
Przykład 1C v8.1:
// na kliencie w kontekście formularza FillUsersCache (OULink)
Przykład 1C v8.2:
// na serwerze w kontekście formularza ProcessingObject \u003d Form AttributeValue ("Object"); ProcessingObject.FillUserCache (DepartmentLink); ValueVFormAttribute (ProcessingObject, "Object");

Obiekty przesyłania danych zdefiniowane przez programistę to niewielki podzbiór typów dostępnych zarówno na kliencie, jak i na serwerze. Najczęściej używanymi parametrami i wynikami „zgrubnych” metod interfejsu są:

• Typy pierwotne (ciąg, liczba, wartość logiczna)
• Struktura
• Konformizm
• Szyk
• Odniesienia do obiektów aplikacji (unikalny identyfikator i reprezentacja tekstowa)

Przykład: metoda pobiera listę zleceń w celu zmiany statusu i zwraca klientowi opis błędów.
& OnServerWithoutContext ServerFunctionChangeOrderStatus (Orders, NewStatus) Errors \u003d Nowa zgodność(); // [zamówienie] [opis błędu] Dla każdego zamówienia z zamówień Rozpoczęcie cyklu Transakcja (); Attempt DocOb \u003d Order.GetObject (); … inne akcje, być może nie tylko przy zamówieniu ... Wyjątek CancelTransaction (); Errors.Insert (Order, DescriptionErrors ()); Koniec prób; Koniec cyklu; Zwracanie błędów; EndFunction // ServerChangeOrderStatus ()

Strukturyzacja kodu

Główne cele, które powinien odzwierciedlać moduł formularza zarządzanego, oraz podejście do rozwiązania.

• Jasne oddzielenie kodu klienta i serwera. Nie zapominajmy, że w momencie wykonania są to dwa oddziałujące ze sobą procesy, w każdym z których dostępna funkcjonalność znacznie się różni.
• Jasne określenie interfejsu dostępu zdalnego, które metody serwera można wywołać z klienta, a które nie? Nazwy metod interfejsu zdalnego zaczynają się od przedrostka serwera. Pozwala to podczas czytania kodu od razu zobaczyć przejście sterowania na serwer i upraszcza użycie podpowiedzi kontekstowych. Zauważ, że oficjalne zalecenie (ITS) sugeruje nazewnictwo metod z postfiksami, na przykład takie jak ChangeOrderStatusOnServer (). Jednak podsumowując, nie wszystkie metody po stronie 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ć ServerChangeOrdersStatus ().
• Czytelność. To kwestia gustu, zamówienie przyjmujemy w momencie rozpoczęcia modułu od procedur tworzenia formularza na serwerze i metod dostępu zdalnego.
• Konserwacja. Miejsce dodania nowego kodu musi być jasno określone. Co ważne, na końcu modułu dodawane są szablony metod tworzone automatycznie przez konfigurator. Ponieważ najczęściej procedury obsługi zdarzeń dla elementów formularza są tworzone automatycznie, odpowiedni blok znajduje się na końcu, aby nie przeciągać każdego modułu obsługi w inne miejsce w module.

Poniżej znajduje się plik podstawowa struktura moduł realizujący wymienione cele.

• Opcja graficzna - wyraźnie pokazuje główny przepływ wykonania.
• Wariant tekstowy jest przykładem projektu szablonu do szybkiego wstawiania konstrukcji do nowego modułu formularza.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="„Data \u003d”"/> // <Описание> // // //////////////////////////////////////////////// // //////////////////////////// // ZMIENNE MODUŁU //////////////// // //////////////////////////////////////////////// //// ////////// // NA SERWERZE // ******* ZDARZENIA NA SERWERZE ******* & Procedura AtServer OnCreateAtServer (Cancel, StandardProcessing) // Wstaw zawartość procedury obsługi EndProcedure // ******* INTERFEJS ZDALNEGO DOSTĘPU ******* // ******* LOGIKA BIZNESOWA NA SERWERZE ******* ///////// / ///////////////////////////////////////////////// /// ////////////////// // METODY KLIENTA OGÓLNEGO I SERWERA //////////////////////// /// ///////////////////////////////////////////////////// /// // NA KLIENTA // ******* LOGIKA BIZNESOWA NA KLIENTU ******* // ******* ZESPOŁY ******* // ** ***** WYDARZENIA U KLIENTA ******* ////////////////////////////// ///// ////////////////////////////////////////// / / OPERATORZY GŁÓWNEGO PROGRAMU

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... Asynchronia, szczegółowość ...
• Buforowanie. W 1C podjęli nieudaną decyzję architektoniczną, wprowadzając caching jedynie na poziomie wywoływania metod typowych modułów i nie zapewniając możliwości sterowania (czas trafności, reset na żądanie).
• Niejawne wywołania serwera... Nie zapomnij o cechach technologicznych, wiele „nieszkodliwych” operacji na kliencie prowokuje platformę do kontaktu z serwerem.