Moduły platformy 1C:Enterprise 8.3, 8.2
Moduły ogólne
Funkcje, które są zadeklarowane z flagą „eksport” w takim module mogą być wywoływane z dowolnego miejsca w konfiguracji. Wywołanie jest wykonywane przez CommonModuleName.FunctionName().
Takie moduły nie mają sekcji zmiennej.
Wykonanie wspólnych modułów zależy od parametrów ustawionych w ich właściwościach:
Flaga „Globalny”
Jeśli ta flaga jest ustawiona, kontekst takiego modułu staje się globalny. Oznacza to, że podczas uzyskiwania dostępu do jego funkcji eksportu nie trzeba podawać nazwy modułu. Jednak nazwy funkcji eksportu muszą być unikalne w kontekście konfiguracji globalnej.
Zgłoś „Serwer”
Funkcje takiego modułu można realizować na serwerze.
Flaga „Klient (zwykła aplikacja)”
Funkcje takiego modułu mogą być wykonywane na kliencie w trybie normalnej aplikacji.
Flaga „Klient (aplikacja zarządzana)”
Funkcje takiego modułu mogą być wykonywane na kliencie w trybie aplikacji zarządzanej.
Flaga wywołania serwera
Flaga jest dostępna dla modułów z ustawioną flagą „Serwer”. Umożliwia klientowi wywołanie funkcji eksportu tego modułu (które zostaną wykonane na serwerze).
Flaga „Połączenie zewnętrzne”
Funkcje eksportu takiego modułu można wywołać po podłączeniu z zewnętrznego źródła.
Flaga „Uprzywilejowany”
W module z tą flagą sprawdzanie uprawnień będzie wyłączone. Nadaje się do produktywności lub czynności administracyjnych.
Opcja ponownego użycia
Jeśli włączysz tę opcję, zwracane wartości funkcji eksportu będą buforowane natychmiast po pierwszym wywołaniu. Buforowanie możliwe jest na czas trwania połączenia (czas wykonania określonej procedury) lub na czas trwania sesji użytkownika.
Moduł aplikacji
Zaprojektowany do obsługi zdarzeń rozpoczęcia i zakończenia aplikacji. Istnieją dwa typy: dla aplikacji zwykłych i zarządzanych.
Nie należy go przeciążać, ponieważ wpływa to na czas uruchamiania aplikacji.
moduł sesji
Specjalny moduł służący do inicjalizacji parametrów sesji. Potrzebne, aby nie duplikować kodu w różnych modułach aplikacji.
Należy go używać ostrożnie, ponieważ moduł można wykonać kilka razy, a także bez dalszego uruchamiania bazy. Działa przed modułami aplikacji.
Z poważaniem (nauczyciel i programista).
Artykuł przedstawia krótka recenzja oraz funkcje funkcjonalności takie jak Ponowne wykorzystanie wartości zwracanych przez współdzielone moduły.
Problemy podczas pracy z 1C
Często podczas pracy z programem 1C wymagane jest uzyskanie wartości przechowywanych w bazie danych, nie zmieniają się one przez lata. Przykładem może być wartość stałych. Ta grupa wartości może warunkowo obejmować poszukiwanie jednego z elementów katalogu lub poszukiwanie węzła planu wymiany za pomocą kodu, a także konieczność uzyskania wartości szczegółów obiektów.
Takie problemy rozwiązuje się szybko i prosto za pomocą następujących typów konstrukcji:
Jeśli DocumentDate > Constants.Regulation1137StartDate.Get() Wtedy
Ale za każdym razem, gdy ten kod jest wykonywany, następuje dostęp do bazy danych.
Wielu programistów używa następującej metody do zwalniania bazy danych. Wykonują tylko jedno żądanie do bazy wiedzy i buforują dane, których mogą potrzebować. Jednak ta metoda nie zwalnia baz danych do żądanej wartości. Przyczyny tego mogą być następujące:
· nie do końca jasny cykl wykonania kodu (np. podczas grupowego przesłania dokumentów);
Uzyskanie ścisłego zestawu danych wymaganych nie w ten moment czasami niemożliwe lub trudne;
· wykorzystanie już zbuforowanych danych w różnych formularzach/wywołaniach.
Moduł z ponowne użycie zwracaj wartości
W rozwiązaniu opisanych powyżej problemów pomoże wykorzystanie modeli z ponownym wykorzystaniem wartości zwrotów. Co to jest? Jest to wspólny moduł klienta lub serwera, w którym funkcja „Na wywołanie” lub „Na sesję” powinna być ustawiona na wartości zwracane ponownie. Wszystkie operacje i funkcje bezpośrednio w module są opisane jak poprzednio.
Niewątpliwą zaletą tej metody jest to, że zwrot wartości z pamięci podręcznej następuje bez faktycznego wykonania kodu funkcji. Dzieje się tak przy wszystkich kolejnych wywołaniach funkcji eksportu tych modułów. Ten sam efekt można zaobserwować podczas pomiaru wydajności.
Po wykonaniu kodu zwrócone wartości są buforowane przez wartości przekazanych parametrów. Tak więc dzieje się to bezpośrednio, gdy kod jest wykonywany
Węzeł1 = NaszModuł.GetExchangeNodeWithAccounting("0001");
Węzeł2 = NaszModuł.GetExchangeNodeWithAccounting("0002");
Zarówno jedno, jak i drugie wywołanie prowadzi do wykonania odpowiedniej operacji i zwraca różne odwołania. Natomiast węzły o kodzie 0001 lub 0002 zostaną zwrócone już podczas kolejnych wywołań, bez powodowania powtórnej operacji i tym samym bez dostępu do bazy danych.
Wartości będą buforowane osobno w każdej sesji, zarówno na kliencie, jak i na serwerze (w zależności od tego, czy połączenie zostało wykonane z modułu klienta czy serwera). Wszystko będzie działać bezbłędnie, jeśli pojawią się jakieś osobliwości w ustawieniach praw dostępu lub jakakolwiek inna zależność od otrzymanej wartości.
Kilka ALE
Jak w przypadku każdej reguły, istnieją wyjątki od tej metody. Nie należy określać złożone typy w parametrach funkcji, które są wystarczająco proste, takie jak Data, Liczba, Na czas nieokreślony i tak dalej. Nie należy próbować określać jako parametrów, na przykład struktury, obiektu lub tabeli wartości. Otrzymasz wynik za pierwszym razem, ale za drugim razem nic sensownego nie wyjdzie.
Zwracana wartość może być dowolnego typu.
Ponadto nie zapomnij zwrócić uwagi na rozmiar buforowanych danych, ponieważ pamięć serwera, choć ogromna, nie jest nieograniczona.
Funkcja lub błąd od 1C
Wartości, które są ponownie wykorzystywane, mają ciekawą cechę. Możemy założyć, że jest to funkcja lub błąd, ale w każdym razie warto zwrócić na to uwagę.
Po wpisaniu następującego kodu:
ValueStructure1 = OurModule.GetAttributesValuesStructure(ObjectReference);
ValueStructure1.Name = "Nowa nazwa";
ValueStructure2 = OurModule.GetAttributesValuesStructure(ObjectReference);
w ValueStructure2.Name pojawi się dokładnie nowa nazwa. Można to wykorzystać do aktualizacji wartości, które faktycznie zmieniły się w bazie danych, ale nie wiadomo, jak długo można to zrobić. Bo przy tworzeniu standardowych rozwiązań nie da się tego zrobić.
Jeśli dane w pamięci podręcznej zostały zmienione
Jeśli buforowane wartości w bazie danych uległy zmianie, istnieje tylko jeden sposób na ich wykorzystanie - metoda UpdateReusedValues. W takim przypadku wartości ustawień wszystkich funkcji są resetowane we wszystkich modułach. Nie ma możliwości aktualizacji o niektóre wartości parametrów, ani funkcji, ani modułów.
Jak żądanie jest składane w pętli
Jeśli nie chcesz używać funkcji, która ponownie wykorzystuje zwracane wartości, oto kilka bardziej kreatywnych sposobów rozwiązania problemu.
· Uniwersalne procedury, które zwracają szczegóły dowolnych linków.
· Tworzenie procedur zwracających wartości stałych po ich nazwie. Nawiasem mówiąc, takie procedury są w standardowych wersjach.
· Zwróć głośność nieco większą niż potrzeba, aby zmniejszyć liczbę połączeń. Na przykład, jeśli chcesz uzyskać kurs kilku walut jednocześnie, pożądane jest wywołanie funkcji wyłącznie według daty bez wybierania walut. Po otrzymaniu wszystkich stawek określ, która waluta jest teraz potrzebna, a która nie.
· Stworzenie procedury, która wykona zapytanie z jednoczesnym buforowaniem otrzymanego wyniku (parametry przychodzące - tekst zapytania, kilka nazw parametrów i wartości).
Jest jeszcze jedna metoda, o której chciałbym omówić bardziej szczegółowo. Ta metoda opiera się na wykorzystaniu funkcji zawierającej wywołanie bazy danych, przy czym zwracana wartość jest ponownie wykorzystywana bezpośrednio w pętli, czyli rodzaj zapytania w pętli. W niektórych przypadkach ta konstrukcja może poprawić wydajność. Musi być spełniony warunek: musi być mała liczba różne znaczenia parametry wejściowe napotkane w pętli, a większość kombinacji została już odebrana co najmniej raz wcześniej w tej sesji. Należy pamiętać, że uzyskanie z góry określonego zestawu kombinacji wszystkich wartości parametrów wejściowych jest niezwykle trudne, a próby uzyskania wartości dla wszystkich możliwych kombinacji mogą prowadzić do odczytania zbyt dużej ilości danych z bazy.
Podaliśmy tylko przykładowe funkcje i metody. Dlatego przed ich użyciem oceń warunki, w jakich będzie działał Twój kod.
Drukuj (Ctrl+P)
Obiekty znajdujące się w gałęzi drzewa konfiguracyjnego Moduły wspólne przeznaczone są do przechowywania tekstów funkcji i procedur, które można wywołać z dowolnego innego modułu konfiguracyjnego.
UWAGA! Moduł ogólny może zawierać tylko definicje procedur i funkcji.
Procedury i funkcje wspólnego modułu, które mają w nagłówku słowo kluczowe Export, należą do części składowe kontekst globalny. Więcej informacji na temat pisania procedur we wspólnym module można znaleźć w sekcjach „Format tekstów źródłowych modułu programu” i „Operatorzy” pomocy językowej 1C:Enterprise.
Aby edytować wspólny moduł, na palecie właściwości obiektu typu Moduły wspólne w oknie Konfiguracja, we właściwości Moduł kliknij odnośnik Otwórz. Tekst modułu ogólnego zostanie wydany do edycji w edytorze tekstu 1C:Enterprise w trybie edycji tekstu modułu programu.
Wspólny moduł, będący częścią konfiguracji, jest zapisywany tylko jako część konfiguracji.
Właściwość Global określa, czy wyeksportowane metody modułu udostępnionego są częścią kontekstu globalnego.
Jeśli właściwość Global jest ustawiona na True, to wyeksportowane metody współdzielonego modułu są dostępne jako metody kontekstu globalnego.
Jeśli właściwość Global jest ustawiona na False, wówczas właściwość jest tworzona w kontekście globalnym o nazwie odpowiadającej nazwie modułu współdzielonego w metadanych. Ta właściwość jest tylko do odczytu. Wartość tej właściwości to obiekt GenericModule. Za pośrednictwem tego obiektu dostępne są wyeksportowane metody tego wspólnego modułu. Zatem dostęp do metod nieglobalnych modułów współdzielonych wygląda tak: XXXXX.YYYYY, gdzie XXXXX to nazwa właściwości odpowiadającej kontekstowi modułu współdzielonego, a YYYYY to nazwa wyeksportowanej metody modułu współdzielonego.
Przykład:
WorkWithTradeEquipment.ConnectBarcodeScanner();
Różne konteksty i wspólne moduły
Korzystając z właściwości wspólnych modułów i instrukcji preprocesora, możesz zorganizować wykonywanie różnych metod wspólnych modułów w żądanym kontekście.
Każda właściwość wspólnego modułu odpowiada za możliwość kompilacji (i wykonania) wspólnego modułu w określonym kontekście.
Dostępne są następujące właściwości, które odpowiadają za kontekst, w jakim dostępne są metody współdzielonego modułu:
● Klient (aplikacja zwykła)– metody wspólnego modułu będą dostępne dla grubego klienta w normalnym trybie aplikacji;
● – wspólne metody modułów będą dostępne dla cienkiego klienta, klienta WWW, a także dla grubego klienta w
tryb aplikacji zarządzanej;
● Serwer - metody wspólnego modułu będą dostępne na serwerze;
● Połączenie zewnętrzne– metody wspólnego modułu będą dostępne w połączeniu zewnętrznym.
Jeśli w tym samym czasie ustawionych jest wiele właściwości, oznacza to, że metody współdzielonego modułu będą dostępne w wielu kontekstach.
Jeśli współdzielony moduł ma ustawioną właściwość Serwer i dowolną inną właściwość, oznacza to, że współdzielony moduł będzie jednocześnie dostępny na serwerze i wybranym kliencie. Jednocześnie trzeba zrozumieć, że w rzeczywistości będzie to kilka wariantów skompilowanego kodu (według liczby wybranych klientów i dla samego serwera).
W takim przypadku, jeśli metoda znajdująca się w takim wspólnym module zostanie wywołana od strony klienta, to zostanie użyta klientowa kopia wspólnego modułu, a jeśli z serwera, to zostanie użyta kopia serwerowa. W takim przypadku za pomocą dyrektyw preprocesora (więcej szczegółów tutaj) można „chronić” serwer przed kodem, którego nie można na nim wykonać.
Rozważ przykład. We wspólnym module znajduje się metoda (która może być wykonana na cienkim kliencie i na serwerze), która zachowuje się nieco inaczej po stronie cienkiego klienta i po stronie serwera. Zobaczmy, jak można to zrobić:
#Jeśli ThinClient to
// Pokaż ostrzeżenie
PokażAlertUżytkownika(„Na kliencie”);
#Koniec, jeśli
Koniec procedury
Wtedy po stronie serwera kod będzie wyglądał tak:
Procedura Metoda wspólnego modułu() Eksport
// Tutaj trafiają różne ważne kody
Koniec procedury
A po stronie cienkiego klienta kod będzie wyglądał tak:
Procedura CommonModule Metoda() Eksport
// Tutaj trafiają różne ważne kody
// Pokaż ostrzeżenie
ShowUserAlert("Na kliencie");
Koniec procedury
Istnieje kilka sposobów przeniesienia kontroli z klienta na serwer:
● wywołać metodę wspólnego modułu serwera;
● w formularzu lub module poleceń wywołaj metodę poprzedzoną dyrektywami kompilacji &Na serwerze, &na serwerze bez kontekstu
Nie jest jednak możliwe wywoływanie metod wspólnych modułów klienta (które nie mają ustawionej właściwości Server) oraz metod klienta modułu formularza lub modułu poleceń z procedur serwera. Kontrola powróci do klienta po zakończeniu zewnętrznego wywołania metody serwera.
Wyjątkiem są metody modułu formularza i modułu poleceń, które poprzedzone są dyrektywami kompilacji &U klientaNa serwerze, &U klientaNa serwerzeBezKontekstu
Należy również wspomnieć o następujących punktach:
● Jeśli udostępniony moduł jest dostępny dla więcej niż jednego klienta, podczas pisania kodu należy wziąć pod uwagę maksymalne ograniczenia, jakie mogą nałożyć klienci, lub użyć instrukcji preprocesora, aby „odizolować” kod klienta.
● Instrukcje preprocesora mają również sens, gdy wspólny moduł ma wiele kontekstów wykonania, takich jak połączenie zewnętrzne i cienki klient lub (częściej) klient i serwer. W takim przypadku instrukcje preprocesora zawijają interaktywny kod, którego nie można użyć na serwerze, ale jest możliwy na kliencie (patrz przykład powyżej).
Aby uzyskać więcej informacji na temat instrukcji preprocesora i dyrektyw kompilacji, zobacz sekcję Wykonywanie procedur i funkcji w Pomocy języka 1C:Enterprise.
Właściwość Wywołanie serwera kontroluje, czy wyeksportowane metody wspólnego modułu serwera mogą być wywoływane z kodu klienta.
Jeśli właściwość jest ustawiona, wyeksportowane metody modułu współdzielonego po stronie serwera są dostępne do wywołania przez klienta. Jeżeli właściwość nie jest ustawiona, to wyeksportowane metody można wywoływać tylko z metod serwerowych (zarówno metod wspólnych modułów serwera, jak i metod serwerowych modułu formularza i modułów poleceń).
Rada . Zaleca się ustawienie właściwości Server Invocation na False w przypadkach, gdy wspólny moduł po stronie serwera zawiera metody, których nie chcesz wywoływać z klienta (na przykład ze względów bezpieczeństwa).
Notatka. Jeśli właściwości są ustawione w tym samym czasie Klient (aplikacja zwykła), Klient (aplikacja zarządzana), Połączenie zewnętrzne, wówczas właściwość Call Server zostanie automatycznie zresetowana. Jeśli ustawiona jest właściwość Serwer połączeń, właściwości są automatycznie resetowane Klient (aplikacja zwykła), Klient (aplikacja zarządzana) oraz Połączenie zewnętrzne jeśli te właściwości zostały ustawione w tym samym czasie.
Nieruchomość Uprzywilejowany ma na celu wyłączenie kontroli dostępu podczas wykonywania metod wspólnego modułu.
NOTATKA. Jeśli nieruchomość Uprzywilejowany jest ustawiona, wtedy właściwość Serwer jest automatycznie ustawiana dla wspólnego modułu, a pozostałe właściwości są resetowane ( Klient (aplikacja zwykła), Klient (aplikacja zarządzana) oraz b połączenie zewnętrzne). Uprzywilejowany moduł współdzielony może działać tylko na serwerze.
Ponowne wykorzystanie zwracanych wartości
Jeśli udostępniony moduł nie jest globalny, dostępna staje się właściwość Reuse return values. Ta właściwość może przyjmować następujące wartości:
● Nie używaj — zwracane wartości nie są ponownie wykorzystywane do funkcji w tym współdzielonym module.
● Na połączenie i na sesję — współdzielony moduł wykorzystuje metodę wykrywania ponownego wykorzystania danych. Istota tej metody polega na tym, że podczas wykonywania kodu system zapamiętuje parametry i wynik działania funkcji po pierwszym wywołaniu funkcji. Gdy funkcja zostanie ponownie wywołana z tymi samymi parametrami, zwracana jest przechowywana wartość (z pierwszego wywołania) bez wykonywania samej funkcji. Jeśli funkcja zmieni wartości parametrów podczas jej wykonywania, to ponowne wywołanie funkcji tego nie zrobi.
Można wyróżnić następujące cechy zapisywania wyników połączeń:
● jeżeli funkcja jest wykonywana na serwerze i wywoływana z kodu serwera, to wartości parametrów i wynik wywołania są pamiętane dla bieżącej sesji po stronie serwera;
● jeśli funkcja jest wykonywana na grubym lub cienkim kliencie, to wartości parametrów i wyniki wywołań są przechowywane po stronie klienta;
● jeżeli funkcja jest wykonywana po stronie serwera i wywoływana z kodu klienta, to wartości parametrów wywołania są zapamiętywane zarówno po stronie klienta, jak i po stronie serwera (dla bieżącej sesji).
Zapisane wartości są usuwane:
● jeśli właściwość jest ustawiona na Na czas trwania połączenia:
● po stronie serwera – gdy kontrola jest zwrócona z serwera;
● po stronie klienta – gdy kończy się procedura lub funkcja 1C:Enterprise najwyższego poziomu (wywoływana przez system z interfejsu, a nie z innej procedury lub funkcji 1C:Enterprise);
● jeśli właściwość modułu współdzielonego jest ustawiona na Na czas trwania sesji:
● po stronie serwera – na koniec sesji;
● po stronie klienta – gdy aplikacja kliencka jest zamknięta.
Zapisane wartości zostaną usunięte:
● na serwerze, grubym kliencie, połączeniu zewnętrznym, cienkim kliencie i kliencie WWW z normalną szybkością połączenia - 20 minut po obliczeniu zapisanej wartości lub 6 minut po ostatnim użyciu;
● w cienkim kliencie i kliencie WWW z niską prędkością połączenia - 20 minut po obliczeniu zapisanej wartości;
● gdy brakuje pamięci RAM w procesie pracy serwera;
● przy ponownym uruchomieniu przepływu pracy;
● Gdy klient przełącza się na inny przepływ pracy.
Po skasowaniu wartości wywołanie wyeksportowanej funkcji jest wykonywane jak w pierwszym wywołaniu.
Ta właściwość wspólnych modułów nie wpływa na wykonywanie procedur – procedury są zawsze wykonywane.
Jeśli udostępniony moduł ma ustawione ponowne wykorzystanie zwracanej wartości, istnieje szereg ograniczeń dotyczących typów parametrów eksportowanej funkcji. Typami parametrów mogą być tylko:
● Typy pierwotne ( Undefined, NULL, Boolean, Number, String, Date).
● Wszelkie odniesienia do obiektów bazy danych.
● Struktury o wartościach właściwości powyższych typów. W tym przypadku tożsamość parametrów jest kontrolowana „przez zawartość” struktur.
Jeśli wyeksportowana funkcja zwraca dowolny obiekt, w rzeczywistości zwraca odwołanie do obiektu przechowywanego w pamięci podręcznej. Jeśli stan obiektu zmieni się po otrzymaniu tej referencji, to kolejne wywołanie tej samej funkcji zwróci referencję do już zmienionego obiektu bez faktycznego wykonania funkcji. To zachowanie będzie trwało do momentu usunięcia przechowywanej wartości (z dowolnego powodu). Innymi słowy, zmiana stanu obiektu uzyskanego w wyniku wywołania funkcji ze współdzielonego modułu z ponownym wykorzystaniem zwracanych wartości nie jest podstawą do faktycznego wywołania funkcji. Należy również pamiętać, że pamięć podręczna zwracanych obiektów jest obojętna dla
stan trybu uprzywilejowanego w momencie wywołania funkcji ze zwracanymi wartościami ponownie wykorzystanymi. Ta funkcja może prowadzić do następna funkcja zachowania:
● Rzeczywiste wykonanie wywołania funkcji z ponownym wykorzystaniem zwracanej wartości (pierwsze wywołanie) zostało wykonane z włączonym trybem uprzywilejowanym.
● Podczas wykonywania funkcji otrzymano obiekt, którego nie można odebrać przy wyłączonym trybie uprzywilejowanym.
● Kolejne wywołania funkcji były wykonywane bez ustawiania trybu uprzywilejowanego.
● Jednak dopóki pamięć podręczna zwróconych obiektów nie zostanie wyczyszczona lub dopóki nie zostanie wykonane ponowne wywołanie, funkcja zwróci formalnie niedostępny obiekt.
● Odwrotne zachowanie jest również prawdziwe, gdy pierwsze wywołanie jest wykonywane bez ustawienia trybu uprzywilejowanego, a tryb uprzywilejowany nie zwraca obiektu, który mógłby zostać uzyskany w trybie uprzywilejowanym.
Jeśli wspólny moduł ma właściwość Ponowne wykorzystanie zwracanych wartości jest ustawiony na Na czas trwania sesji, to wartości zwracane przez funkcje takiego modułu nie mogą używać wartości typu Menedżer tabel tymczasowych.
Jeśli funkcja współdzielonego modułu, z ustawionym reuse, jest wywoływana z tego samego współdzielonego modułu (na przykład o nazwie SharedModule ), to należy pamiętać o następującej funkcji: jeśli funkcja jest wywoływana przez nazwę MyFunction() , to funkcja będzie wykonywana przy każdym wywołaniu funkcji . Aby użyć przechowywanych wartości, funkcja musi być wywoływana przy użyciu jej w pełni kwalifikowanej nazwy:
GeneralModule.MyFunction().
Metoda kontekstu globalnego usuwa wszystkie ponownie użyte wartości, zarówno po stronie serwera, jak i klienta, niezależnie od tego, gdzie wywoływana jest metoda. Po wykonaniu metody Aktualizuj wartości wielokrotnego użytku() pierwsze wywołanie funkcji zostanie wykonane całkowicie.
Artykuł kontynuuje cykl „Pierwsze kroki w rozwoju na 1C”, szczegółowo omawia następujące kwestie:
- Co moduł oprogramowania A z jakich sekcji się składa?
- Do czego służy moduł aplikacji? Dlaczego są dwa? Kiedy to się zaczyna? Jakie są szczegóły pracy?
- Jakie zdarzenia są związane ze startem systemu, jak i gdzie je obsłużyć?
- Do czego służy zewnętrzny moduł połączeniowy? Kiedy i jak z niego korzystać?
- Kiedy używany jest moduł sesji?
- Co to są moduły współdzielone? Jakie są jego właściwości i zasady działania? Dlaczego warto korzystać z właściwości Reuse Return Values?
- Kiedy używany jest moduł formularza i jakie zdarzenia można w nim obsłużyć?
- Do czego służy moduł obiektowy? Z jakich sekcji się składa? Jak wyświetlić dostępne zdarzenia modułu?
- Jakie są subtelności pracy z modułami menedżera wartości (dla stałych) i modułami zestawu rekordów (dla rejestrów)?
- Jaka jest różnica między modułem obiektu a modułem menedżera? Kiedy należy użyć tego ostatniego?
Zastosowanie
Artykuł dotyczy platformy 1C:Enterprise 8.3.4.496. Materiał dotyczy również aktualnych wydań platformy.
Moduły w 1C:Enterprise 8.3
Moduły to te obiekty, które zawierają kod programu.
Na Platformie istnieje dość duża liczba typów modułów, z których każdy ma swój własny cel i funkcje.
Każdy wiersz kodu musi znajdować się w module. Istnieją moduły ogólnego przeznaczenia i moduły obiektowe. Niektóre moduły mogą być kompilowane zarówno na kliencie, jak i na serwerze, a niektóre tylko na serwerze.
Moduł może składać się z kilku sekcji. Sekcja deklaracji zmiennych opisuje zmienne lokalne tego modułu, których można później użyć w dowolnej procedurze.
W ramach każdej procedury można uzyskać dostęp do zmiennej modułu. Dodatkowo w ramach samej procedury może znajdować się inna deklaracja zmiennej o tej samej nazwie. Będzie to zmienna lokalna dla tej procedury.
Pomimo tej samej nazwy, są to dwie różne zmienne: jedna jest używana wewnątrz konkretnej procedury, a druga poza nią.
W niektórych modułach zmienne mogą być ustawione na lokalizację kompilacji (dostępność) na serwerze lub na kliencie. Na przykład:
Po sekcji deklaracji zmiennych następuje sekcja procedur i funkcji, która określa lokalne metody modułu. Niektóre moduły wymagają określenia, gdzie procedura lub funkcja zostanie skompilowana.
W zasadzie dyrektywę kompilacji można pominąć. W tym przypadku domyślną dyrektywą kompilacji jest Server. Jednak dla wygody analizy kodu programu zaleca się jednoznaczne wskazanie, gdzie ta procedura zostanie skompilowana. Kolejność, w jakiej opisane są procedury, nie ma znaczenia.
Na końcu modułu, po opisie wszystkich procedur i funkcji, znajduje się sekcja programu głównego, która może zawierać kilka operatorów inicjujących zmienne lokalne modułu formularza. Ta sekcja jest wykonywana podczas uzyskiwania dostępu do modułu.
Na przykład podczas otwierania formularza elementu w pierwszej kolejności wykonywana jest sekcja programu głównego modułu formularzy.
Należy zauważyć, że sekcja deklaracji zmiennych i sekcja programu głównego nie istnieją dla wszystkich modułów (tj. sekcje te są nieprawidłowe w niektórych modułach). Sekcja opisująca procedurę i funkcję może istnieć w dowolnym module.
Moduł aplikacji
Ten moduł jest przeznaczony do obsługi zdarzeń uruchamiania i zamykania aplikacji. Na przykład po uruchomieniu aplikacji możesz pobrać kursy walut z Internetu. Na końcu aplikacji możesz upewnić się, że użytkownik ma zamiar zakończyć pracę.
Również w module aplikacji znajdują się specjalne handlery, które pozwalają przechwytywać zdarzenia zewnętrzne ze sprzętu.
Mogą to być zdarzenia z czytnika kart magnetycznych, rejestrator skarbowy. Z tymi zdarzeniami też można sobie poradzić w jakiś sposób.
Należy zauważyć, że to właśnie interaktywne uruchomienie systemu jest śledzone w module aplikacji.
Moduł aplikacji nie będzie działał, jeśli program 1C zostanie uruchomiony, na przykład w trybie połączenia komunikacyjnego. W takim przypadku okno programu nie jest tworzone.
Należy zauważyć, że w Platformie 8.3 istnieją dwa różne moduły aplikacji: moduł aplikacji zarządzanych i moduł aplikacji zwykłych. Zdarzenia modułu aplikacji zarządzanych są uruchamiane po uruchomieniu cienkich i grubych klientów zarządzanej aplikacji i klienta WWW.
Moduł Aplikacja ogólna działa, gdy Gruby Klient jest uruchomiony w trybie Aplikacja ogólna, który ma zwykły interfejs poleceń w postaci menu główne.
Jeśli aplikacja jest uruchomiona i Zarządzany, a w trybie Aplikacja ogólna, to konieczne jest opisanie procedur obsługi jak dla modułu zarządzana aplikacja, a dla modułu Aplikacja ogólna.
Moduł zarządzana aplikacja można wybrać z menu kontekstowego głównego węzła konfiguracji.
Ten moduł można również otworzyć z palety właściwości głównego elementu konfiguracji.
Aby otworzyć moduł Aplikacja ogólna, należy zapoznać się z ustawieniami konfiguracyjnymi (polecenie Opcje w menu Usługa).
Otworzy się formularz Opcje. Zakładka Ogólny tryb edycji konfiguracji musi być określony Aplikacja zarządzana oraz Aplikacja ogólna.
W takim przypadku moduł Aplikacja ogólna można również otworzyć z właściwości węzła głównego.
Lista zdarzeń, na które można przetworzyć Zarządzany oraz Aplikacja ogólna ten sam.
W tym module możesz umieścić sekcję deklaracji zmiennych, sekcję opisującą dowolne procedury i funkcje oraz sekcję dotyczącą programu głównego. Ale oprócz dowolnych procedur i funkcji, w module mogą znajdować się specjalne procedury obsługi zdarzeń.
Listę dostępnych handlerów można wyświetlić, wywołując listę procedur i funkcji bieżącego modułu, gdy moduł jest otwarty.
Otwarte okno Procedury i funkcje wyświetla wszystkie procedury i funkcje tego modułu, a także zdarzenia, dla których nie utworzono jeszcze obsługi.
Z uruchomieniem systemu związane są dwa zdarzenia („przed” i „o”). Dwa zdarzenia związane z zamknięciem systemu („przed” i „o”). A także przetwarzanie zdarzenia zewnętrznego (na przykład zdarzenia wyposażenia sklepu).
Kiedy procedura obsługi zdarzenia „przed” jest wykonywana, uważa się, że akcja jeszcze się nie odbyła. Kiedy procedura obsługi zdarzenia „on” jest wykonywana, akcja już się odbyła.
Wydarzenie Przed uruchomieniem systemu występuje w momencie uruchomienia Enterprise 8.3, ale sama aplikacja nie pojawiła się jeszcze na ekranie. To zdarzenie ma taki parametr jak Odmowa.
Jeśli ten parametr jest ustawiony na Prawdziwe, aplikacja się nie uruchomi. Wydarzenie Podczas uruchamiania systemu zakłada, że akcja została już podjęta, okno zostało już utworzone i w tym przypadku możemy np. wyświetlić jakiś specjalny formularz. Nie możesz już odmówić uruchomienia.
Podobnie przed zamknięciem systemu aplikacja jest nadal otwarta i możesz jej nie zamykać. Gdy system został zamknięty, okno aplikacji było już zamknięte. Możliwe jest tylko wykonanie dodatkowych czynności, takich jak usunięcie niektórych plików lub wysłanie wiadomości e-mail.
W module zarządzana aplikacja dyrektywy do kompilacji procedur i funkcji nie są określone, ponieważ moduł jest kompilowany w całości po stronie Klienta. Oznacza to, że w procedurach i funkcjach modułu nie będziemy mogli uzyskać bezpośredniego dostępu np. do podręczników.
Jeśli z modułu zarządzana aplikacja musisz wykonać połączenie z serwerem, a następnie w tym celu musisz utworzyć specjalne z wywieszoną flagą .
W module Aplikacja ogólna nie ma takich ograniczeń, ponieważ ten moduł zostanie skompilowany podczas ładowania Grubego Klienta. Prawie wszystkie typy danych są dostępne w grubym kliencie.
Procedury, funkcje i zmienne modułu aplikacji można określić jako eksport.
Ponieważ moduł jest kompilowany w całości na kliencie, oznacza to, że w procedurach klienta możemy uzyskać dostęp do tej metody i tej właściwości.
Na przykład z modułu formularza jakiegoś obiektu można wywołać procedurę lub funkcję modułu aplikacji. Zaleca się jednak używanie modułów ogólnych do opisu ogólnych algorytmów. Głównym celem modułu aplikacji jest obsługa punktu początkowego i końcowego.
Analogicznie do modułu aplikacji, moduł ten jest przeznaczony do obsługi zdarzenia otwarcia programu i zdarzenia zamknięcia.
W przeciwieństwie do modułu aplikacji, który jest inicjowany w momencie interaktywnego uruchomienia aplikacji, moduł połączenia zewnętrznego pracuje w trybie com-connection, tj. gdy tworzony jest obiekt 1C:Enterprise 8 i nawiązywane jest połączenie z określoną bazą danych.
Ten moduł zawiera wydarzenia: Podczas uruchamiania systemu oraz podczas zamykania systemu.
Zewnętrzny moduł połączenia można otworzyć za pomocą menu kontekstowego na poziomie głównego obiektu konfiguracyjnego lub palety właściwości węzła głównego.
Sam proces łączenia zewnętrznego jest procesem programowej pracy z bazą danych, a nie interaktywną. W związku z tym w tej chwili nie można używać formularzy dialogowych, wyświetlać komunikatów ostrzegawczych, ponieważ nie ma interfejsu użytkownika.
W module połączenia zewnętrznego można opisać zmienne eksportu i metody eksportu, które będą dostępne po stronie, w której występuje połączenie zewnętrzne do 1C:Enterprise 8.3.
Ponieważ w połączeniu zewnętrznym nie ma interfejsu użytkownika, moduł połączenia zewnętrznego jest w całości kompilowany na serwerze.
moduł sesji
Ten moduł jest potrzebny do zainicjowania parametrów sesji. Parametry sesji to szybkie zmienne globalne, których wartości są dostępne w dowolnym miejscu konfiguracji.
Moduł sesji można otworzyć z menu kontekstowego lub z palety właściwości węzła głównego.
Zdarzenie jest dostępne w module sesji Ustawienia SesjiParametry.
Po uruchomieniu aplikacji ta procedura nazywana jest pierwszą. Parametry sesji są potrzebne do działania dowolnej aplikacji: zarówno uruchomionej interaktywnie, jak i uruchomionej w trybie połączenia zewnętrznego.
Moduł sesji opisuje różne akcje inicjujące parametry sesji w zależności od różnych warunków.
Ten moduł z reguły opisuje kilka procedur, które są wywoływane z procedury Ustawienia SesjiParametry. Dlatego wszystkie te procedury są rozdzielone w osobny moduł.
Moduł sesji zawsze działa w trybie uprzywilejowanym. Oznacza to, że podczas uzyskiwania dostępu do bazy danych nie zostanie wykonane sprawdzenie uprawnień. Moduł sesji jest kompilowany na Serwerze, tj. możliwe jest wywoływanie dowolnych metod serwerowych (w tym odczytywanie wartości z bazy danych).
W module sesji można zdefiniować tylko procedury i funkcje, tj. nie ma sekcji deklaracji zmiennych ani sekcji programu głównego. Nie można deklarować metod eksportu w module sesji.
Jeżeli przy starcie systemu konieczne jest wykonanie jakichś akcji na Serwerze, np. utworzenie elementu jakiegoś katalogu, to opcjonalnie można skorzystać z Modułu Sesji, ponieważ jest kompilowany na serwerze i jest zawsze niezawodnie wykonywany podczas uruchamiania systemu. Należy jednak wziąć pod uwagę następujące punkty:
- procedura Ustawienia SesjiParametry jest wykonywany nie tylko podczas uruchamiania systemu, ale także podczas uzyskiwania dostępu do niezainicjowanych parametrów sesji. Tych. handler SetSessionParameters może być wielokrotnie wywoływany podczas wykonywania aplikacji;
- jeżeli liczba elementów w tablicy parametrów sesji jest równa zero (tablica wymaganych parametrów ma typ danych Undefined), to jest to moment uruchomienia aplikacji;
- ponieważ moduł sesji działa w trybie uprzywilejowanym i nie będzie kontroli dostępu, należy być bardzo ostrożnym podczas pracy z obiektami bazy danych, ponieważ użytkownik może uzyskać dostęp do danych, których nie należy mu udostępniać;
- po uruchomieniu systemu nie wiadomo jeszcze na pewno, czy aplikacja zostanie uruchomiona. W takim przypadku dodatkowe akcje można wykonać w procedurze obsługi zdarzeń zdarzenia SetSessionParameters.
Moduły te są opisami niektórych ogólnych algorytmów, tj. procedury i funkcje, które można wywołać z różnych miejsc.
Logicznie powiązane metody można pogrupować w różne moduły wspólne. Te moduły są tworzone w gałęzi Ogólne.
Możesz dodać dowolną liczbę współdzielonych modułów. Aby metody Common Module były dostępne w innym miejscu konfiguracji, muszą być zdefiniowane za pomocą słowo kluczowe Eksport. Procedury klienta wspólnych modułów będą dostępne na kliencie, a procedury serwera na serwerze.
W modułach Common dostępna jest tylko sekcja opisująca procedury i funkcje. Tych. w module Common nie można deklarować zmiennych ani opisywać sekcji programu głównego.
Jeśli potrzebna jest zmienna globalna, można użyć parametrów sesji lub zmiennych eksportu modułu aplikacji.
W przypadku modułów Common możesz ustawić kilka parametrów, które wpłyną na zachowanie tego modułu. Jeżeli właściwość Global jest ustawiona dla modułu Common, to metody eksportu zadeklarowane w tym module będą bezpośrednio dostępne z zewnątrz, bez żadnych dodatkowych instrukcji.
Tych. ten Moduł ogólny będzie uczestniczyć w tworzeniu globalnego kontekstu konfiguracji.
Nieruchomość Światowy dla wspólnych modułów mogą być przydatne. Nie należy jednak używać go uniwersalnie dla wszystkich popularnych modułów.
Tych , które są oznaczone Światowy, zostanie skompilowany podczas uruchamiania systemu. Im więcej takich modułów, tym wolniej uruchomi się program.
Jeśli flaga Światowy dla Moduł ogólny nie jest określony, to kompilacja tego modułu zostanie wykonana w momencie pierwszego wywołania tego modułu (czyli po uruchomieniu systemu).
Dodatkowo użycie globalnych modułów współdzielonych wpływa na zrozumienie kodu. Wywoływanie metod nieglobalnego modułu współdzielonego odbywa się poprzez nazwę Moduł ogólny oraz nazwę metody, na przykład:
Moduł Kalkulacji Kosztów Alokacja Kosztów Pośrednich();
Jednocześnie nazwy modułów ogólnych powinny odzwierciedlać treść opisanych w nich procedur. Określenie nazwy modułu wspólnego podczas wywoływania procedury ułatwia zrozumienie kodu.
Do Moduł ogólny w Paleta właściwości właściwość można ustawić Uprzywilejowany.
Prawa dostępu nie są kontrolowane w module uprzywilejowanym. Jest to konieczne, jeśli w Moduł ogólny wymagane jest masowe przetwarzanie danych, pozyskiwanie danych z bazy.
Kontrola dostępu wydłuża czas dostępu do bazy danych, a algorytmy zbiorcze często muszą działać tak szybko, jak to możliwe.
Na przykład operacja wymagająca dużej ilości zasobów to kalkulacja wynagrodzenie. Trzeba to zrobić jak najszybciej. W tym celu algorytmy obliczające płace są umieszczane w uprzywilejowanej pozycji .
Jednocześnie wszelkie procedury zapewniające wypełnienie dokumentów płacowych są poza nimi Wspólne moduły. To właśnie w tych procedurach wykonywana jest kontrola dostępu.
W ten sposób można osiągnąć znaczny wzrost wydajności. Dotyczy to zwłaszcza przypadku wykorzystania mechanizmu różnicowania dostępu wiersz po wierszu do rekordów tabel.
Jeśli moduł Common jest uprzywilejowany, procedury tego modułu mogą być kompilowane tylko na serwerze.
Zdarzają się sytuacje, w których jakiś obiekt powinien być niedostępny dla użytkownika, na przykład pewien katalog. Ale przy wykonywaniu dowolnego dokumentu konieczne jest odwołanie się do tego przewodnika.
Tych. istnieje potrzeba tymczasowego rozszerzenia uprawnień użytkownika, a następnie przywrócenia ich do stanu pierwotnego. Ten efekt można uzyskać za pomocą uprzywilejowanego Wspólne moduły.
Aby to zrobić, w uprzywilejowanym Moduł ogólny konieczne jest wszczęcie procedury dostępu do niezbędnych danych.
Ta procedura zostanie wywołana z odpowiedniego dokumentu. Tych. w momencie wywołania tej procedury użytkownik faktycznie otrzymuje rozszerzone uprawnienia.
Do Wspólne moduły możliwe jest określenie lokalizacji kompilacji. Flagi służą do określenia, czy moduł wspólny będzie dostępny na kliencie (aplikacja zarządzana), na serwerze w trybie połączenia zewnętrznego.
Dodatkowo w przypadku przełączenia trybu edycji konfiguracji na aplikację zarządzaną i aplikację zwykłą, możliwy będzie jeszcze jeden kontekst kompilacji - Klient (aplikacja normalna).
Istnieją więc cztery opcje funkcjonowania programu. W zależności od uruchomionej aplikacji, w zależności od pracy na Kliencie lub Serwerze, niektóre moduły Wspólne będą dostępne lub niedostępne.
Oprócz możliwości określenia flag kompilacji, możliwe jest określenie dyrektyw kompilacji dla procedur i funkcji znajdujących się w module Common.
Jeśli dyrektywa kompilacji jest określona dla metody, to chociaż moduł Generic jest dostępny we wszystkich określonych kontekstach, dostępność konkretnej metody będzie ograniczona przez dyrektywę kompilacji.
W takim przypadku nie można uzyskać dostępu do procedury w kontekście, który nie jest ogólnie dostępny dla całego modułu.
Jeśli dyrektywa kompilacji nie jest określona dla procedury (funkcji), zostanie ona skompilowana we wszystkich kontekstach zdefiniowanych dla modułu.
Tych. w efekcie zostanie sporządzonych wiele kopii procedury. Wybór konkretnej skompilowanej instancji zależy od tego, gdzie procedura jest wywoływana (zgodnie z zasadą najbliższego wywołania). Jednocześnie należy wziąć pod uwagę, że kod takiej procedury musi być napisany z uwzględnieniem jej dostępności we wszystkich kontekstach zdefiniowanych dla modułu.
Wspólne moduły, które są dostępne w kilku różnych kontekstach jednocześnie, służą głównie do tworzenia procedur dostępnych w kilku kontekstach.
Podczas tworzenia modułu Generic dobrą praktyką jest nie określanie dyrektyw kompilacji. Tych. dostępność procedur i funkcji powinna być określona przez właściwości samego modułu.
Przy takim podejściu procedury klienta będą zlokalizowane w oddzielnych modułach wspólnych, a procedury serwera będą zlokalizowane w oddzielnych modułach wspólnych.
W praktyce rzadko używa się modułów, które mają ustawionych wiele flag kompilacji. Oto kilka typowych akcji dostępnych zarówno na kliencie, jak i na serwerze. Zwykle są to proste obliczenia.
Ważny! Możliwe jest uzyskanie dostępu do metod serwera eksportu modułu współdzielonego z klienta, ale tylko wtedy, gdy ten moduł współdzielony jest skompilowany tylko na serwerze. Jednocześnie specjalny checkbox ma na celu zapewnienie dostępu ze strony Klienta. .
W przypadku nieglobalnych modułów Common możliwe jest buforowanie wartości zwracanych przez funkcje. Tych. system może zapamiętać wynik jego wykonania już po pierwszym wywołaniu funkcji. Jeśli ta funkcja zostanie wywołana ponownie z tymi samymi parametrami, system zwróci wartość już z pamięci podręcznej.
Celem tego mechanizmu jest przyspieszenie powtórnych połączeń. Aby skonfigurować to zachowanie, musisz Paleta właściwości moduł, aby ustawić odpowiednią wartość dla właściwości Reuse return values.
Domyślnie ta właściwość jest ustawiona na Nie używaj. Inne możliwe wartości: pamięć podręczna W czasie rozmowy, lub Na czas trwania sesji.
Ta właściwość ma sens tylko dla tych funkcji, których wynik zależy wyłącznie od parametrów wejściowych. Ten mechanizm jest dostępny tylko dla nieglobalnych modułów Common.
Jeżeli zostanie wybrana wartość odpowiedniego parametru Na czas trwania wywołania, to pamięć podręczna będzie aktywna tak długo, jak będzie wykonywana procedura, z której została wywołana metoda modułu Common. Jeśli wartość to Na czas trwania sesji, pamięć podręczna jest warunkowo uważana za aktywną podczas pracy użytkownika.
Istnieją jednak pewne ograniczenia czasowe. Pamięć podręczna jest czyszczona automatycznie 20 minut po zbuforowaniu wartości.
Moduł formularzy
Ten moduł jest przeznaczony do przetwarzania działań użytkownika. Na przykład opisz algorytm reakcji programu po naciśnięciu przycisku. Lub np. w momencie wpisywania wartości w polu od razu sprawdź poprawność.
Oprócz zdarzeń związanych z kontrolkami formularza (przyciski, pola wejściowe), istnieją zdarzenia związane bezpośrednio z samym formularzem.
Na przykład możesz obsłużyć zdarzenie otwarcia formularza i wykonać inicjalizację. Możesz również obsłużyć zdarzenie zamknięcia formularza i sprawdzić, czy użytkownik wpisał wszystko poprawnie.
Istnieją formularze zarządzane i formularze normalne. Moduły danych formularza różnią się przede wszystkim tym, że zarządzany moduł formularza jest wyraźnie rozdzielony na kontekst. Każda procedura (funkcja) musi mieć dyrektywę kompilacji. W swojej normalnej formie cały kod jest używany na Kliencie.
W module formularza zarządzanego można deklarować procedury i funkcje, deklarować zmienne i opisywać sekcję programu głównego.
Kod programu głównego programu zostanie wykonany w momencie inicjalizacji formularza, czyli kiedy użytkownik go otworzy. Rysunek przedstawia listę standardowych zdarzeń dla formularza zarządzanego.
Lista zarządzanych zdarzeń formularza jest również widoczna na liście właściwości samego formularza. Ta lista jest wywoływana w edytorze formularzy zarządzanych.
W zarządzany formularz możesz obsłużyć zdarzenie zapisu elementu. Zdarzenie to występuje tylko dla form obiektów (podręczniki, dokumenty i kilka innych). Jeśli formularz nie jest powiązany z konkretnym obiektem, nie występuje zdarzenie zapisu.
W przypadku modułu zwykłego formularza lista standardowych zdarzeń jest nieco mniejsza, ponieważ w formie zarządzanej wiele zdarzeń jest wykonywanych parami (jedno jest wykonywane na Kliencie, a drugie na Serwerze). W zwykłej formie cały kod jest wykonywany na Kliencie.
Moduł obiektowy
Moduły te są typowe dla katalogów, dokumentów, planów rodzajów obliczeń, planów kont i wielu innych obiektów. Moduł obiektowy przeznaczony jest do obsługi standardowych zdarzeń. Na przykład zdarzenie wprowadzenia elementu katalogu, zdarzenie zapisania elementu, usunięcia, zaksięgowania dokumentu itp.
W zasadzie zdarzenie write istnieje również w module formularzy. Jednak zdarzenie write w module Formularz ma miejsce podczas pisania interaktywnego, podczas pracy z określonym formularzem.
Zdarzenie write w module Object zostanie wywołane przy każdym zapisie z dowolnej formy danego obiektu. Ponadto, jeśli obiekt jest napisany programowo, w takim przypadku zostanie uruchomione zdarzenie modułu obiektu.
W zdarzeniu zapisu modułu Object można osadzić wszystkie kontrole poprawności zapisywanych danych, ponieważ ta procedura zadziała w momencie absolutnie dowolnego zapisu.
Moduł tego obiektu można wywołać poprzez menu kontekstowe, z Palety Właściwości obiektu oraz z okna edycji obiektu.
Poniższy rysunek przedstawia listę dostępnych zdarzeń modułu katalogu.
W module Object można umieścić sekcję deklaracji zmiennych, opisać dowolne funkcje, które mogą być powiązane ze zdarzeniem lub nie, a także sekcję programu głównego.
W głównej sekcji programu możesz na przykład zainicjować zmienne lokalne tego modułu. Ten kod programu zostanie wykonany, gdy uzyskany zostanie dostęp do tego modułu obiektowego.
Należy zauważyć, że wszystkie procedury modułu obiektowego są kompilowane na serwerze. W związku z tym dyrektywy kompilacji nie są wymagane dla procedur i funkcji modułu Object. Niektóre obiekty konfiguracyjne nie posiadają modułów obiektowych.
Wynika to z cech samych obiektów. Takie obiekty obejmują Stałe oraz Rejestry. Do Stały nie ma modułu obiektowego, ale istnieje bardzo podobny moduł o nazwie Moduł menedżera wartości.
W Moduł menedżera wartości poradzisz sobie z nagrywaniem zdarzeń Stałe i przetwarzanie czeków napełniania.
Cały kontekst modułu jest wykonywany na serwerze.
Dla rejestrów dostępny jest moduł Recordset.
Ten moduł ma również możliwość obsługi zdarzeń zapisu i sprawdzania populacji.
W modułach obiektowych, modułach menedżera wartości (dla stałych) i modułach zestawu rekordów (dla rejestrów) można opisać metody, które mogą być eksportowane, a metody te będą dostępne z zewnątrz.
Tych. Oprócz używania stałych metod klasy obiektów, możesz tworzyć dodatkowe metody dla obiektu w module Object. Ten moduł powinien opisywać odpowiednią procedurę za pomocą słowa kluczowego Eksport.
Wtedy będzie można odwołać się do tej procedury z zewnątrz. Co więcej, ta metoda będzie wyświetlana w podpowiedzi kontekstowej. Nowe metody w podpowiedzi kontekstowej są podświetlone na niebiesko (niebieska ikona p() do procedur i f() dla funkcji).
Podobnie możesz utworzyć nową właściwość, deklarując zmienną za pomocą słowa kluczowego Eksport. Do tej nieruchomości można również wejść z zewnątrz.
Dzięki temu możliwe jest rozszerzenie funkcjonalności obiektów (dodawanie nowych metod i nowych właściwości). Właściwości są dynamiczne i nie są przechowywane w bazie danych.
Jeśli potrzebujesz użyć właściwości dla obiektu, który będzie przechowywany w bazie danych, powinieneś utworzyć atrybut obiektu.
Moduł menedżera
Moduł ten istnieje dla wielu obiektów (katalogów, dokumentów, rejestrów itp.). Moduł jest otwierany przez menu kontekstowe obiektu lub przez Paleta właściwości lub przez okno edycji.
W module menedżera możesz nadpisać niektóre standardowe zdarzenia, na przykład in Przetwarzanie Odbieranie danychWybór, gdy element jest wybrany ze słownika, możesz wykonać dodatkowe filtrowanie lub sprawdzanie.
Dodatkowo możesz utworzyć dodatkowe metody w module menedżera i określić, że są to metody eksportu. W takim przypadku możliwy jest dostęp do tych metod z zewnątrz.
Aby wykonać to połączenie, musisz uzyskać typ danych Menedżer katalogów.
Różnica pomiędzy metodami eksportu Modułu Menedżera i Modułu Object polega na tym, że aby wywołać metodę modułu Object, musisz najpierw pobrać sam obiekt (czyli jakoś uzyskać link, a następnie przekonwertować go na link obiekt).
Następnie dostępne będą zmienne eksportu i metody modułu Object. W przypadku modułu menedżera wywołanie jest prostsze, na przykład:
Katalogi.Konta.Nazwa metody
To są dwa różne apele. Konwertuj z referencji na obiekt (metoda Pobierz obiekt) jest dość poważną czynnością dla systemu, ponieważ po odebraniu obiektu odczytywane są absolutnie wszystkie dane tego obiektu, co może być dość długie.
Druga różnica polega na tym, że Moduł obiektu przywoływana w kontekście konkretnego elementu. W związku z tym możemy założyć, że ma on zastosowanie do tego elementu (w większości przypadków jest to określona logika).
Jeśli chodzi o Moduł Menedżera, opisuje on pewne ogólne działania dla grupy lub dla wszystkich elementów katalogu lub jakiegoś dokumentu. Na przykład, jeśli chcesz wydrukować element referencyjny, możesz użyć modułu Object.
Ale w Module Managera możliwe jest wykonanie bardziej uniwersalnego mechanizmu, który wydrukuje między innymi grupę elementów.
Ponadto dostęp do modułu obiektu jest nadal dłuższą czynnością. Dlatego lepiej jest rozwiązać ten problem w module menedżera.
To kończy naszą znajomość modułów w konfiguracji systemu 1C:Enterprise. Jeśli zsumujemy wszystkie powyższe, to najważniejsze są następujące wnioski:
- Moduł oprogramowania jest częścią konfiguracji, która może zawierać tylko tekst we wbudowanym języku 1C
- Moduły programu są klasyfikowane według typów, które zbadaliśmy w tym artykule. Każdy widok jest zdefiniowany przez jego umiejscowienie i dostępny kontekst programowania.
- Struktura modułu składa się z kilku sekcji, które ułożone są w określonej kolejności. Skład sekcji zależy od rodzaju modułu.
Zauważ też, że celowo pominęliśmy jeden rodzaj modułu, a mianowicie moduł poleceń. Nie przedstawia niczego godnego uwagi i sugerujemy zapoznanie się z jego funkcjonalnością.
Do tej pory cały kod naszego programu rozważaliśmy fragmentarycznie z zastosowanego rozwiązania i z reguły pisaliśmy go w jakiejś własnej, małej konfiguracji testowej. Czy zdajesz sobie sprawę, że „nie możesz po prostu wziąć tego” i zacząć edytować kod typowej konfiguracji? Nie? W następnym artykule wyjaśnimy to wszystko!
