1c est le module de l'application gérée où il est exécuté. Modules communs. Quoi utiliser

Bonjour à tous.
Aujourd'hui, nous allons considérer modules de la plateforme 1C Enterprise 8.2, il y en a plus que dans la version 8.1 et parfois ce n'est pas si facile à comprendre.
Exemple:

Si vous regardez l'aide 1C, vous verrez la définition suivante pour le module :
Un module est un programme dans le langage intégré du système 1C : Enterprise.

Et si c'est plus simple alors : B module 1C contient code exécutable, qui est nécessaire pour réagir en quelque sorte aux actions du système ou de l'utilisateur, lorsque les moyens visuels ne suffisent pas à décrire l'interaction des objets dans le configurateur. De plus, dans les modules du programme, vous pouvez décrire vos propres méthodes.

Toute ligne de code se trouve dans un module, c'est une différence par rapport à 1C7.7, où le code du programme pouvait être situé à la fois dans les cellules des tableaux de disposition et dans les propriétés des éléments de formulaire.

Listons les modules qui sont dans 1C 8.2

Modules de la plateforme 1C Enterprise 8.2:

Module application gérée
Module d'application régulier
Module de connexion externe
Module de séance
Modules communs
Module objet
Module de formulaire
Module gestionnaire d'objets
Module gestionnaire de valeur
Modules de jeux d'enregistrements

Les principales sections du module :
1. Section décrivant les variables locales de ce module, vous pouvez spécifier une directive de compilation (elle n'existe pas pour tous les modules).
2. Section décrivant les procédures et les fonctions. Si vous n'écrivez pas de directive de compilation, alors par défaut il s'agit de & AtServer, l'ordre des procédures et des fonctions n'a pas d'importance.
3. Section du programme principal du module (contient quelques opérateurs). Cette section est exécutée lors de l'accès à un module (elle n'existe pas pour tous les modules).

Tous les modules ne contiennent pas de sections de déclaration de variables et une section principale de programme.
Par exemple : module commun ou module de session.

Règles de compilation des modules :
1. Certains modules sont entièrement compilés côté client ou côté serveur. Toutes les méthodes qu'ils contiennent sont soit côté client, soit côté serveur. Un exemple de module client est un module d'application géré.
2. Certains modules peuvent combiner des méthodes client et serveur. Dans ce cas, pour chaque méthode, vous devez spécifier les directives de compilation - & AtClient ou & AtServer. Les modules de formulaires gérés en sont un exemple.

Classement des modules :
1. Salles de serveurs. Compilé uniquement côté serveur - module objet, module gestionnaire, module jeu d'enregistrements.
2. Côté client. Compilé uniquement sur le client, tel qu'un module d'application géré.
3. Combiné. Peut être compilé à la fois sur le serveur et sur le client - module de formulaire et modules communs.

Où les modules sont compilés :
1. Client léger (offre la possibilité d'utiliser un navigateur Web).
2. Serveur.
3. Client lourd.

Comme vous pouvez le voir, il n'y a pas si peu de modules, presque chaque objet de configuration a un module qui a son propre objectif.

Objectif de chaque module 1C 8.2

Gardes : Vous pensez acheter 1C Enterprise et vous ne savez pas auprès de qui ? La société LBS fait partie du top 20 1C : Franchisés. Il est engagé dans l'automatisation de la comptabilité basée sur les produits 1C. Achetez des produits 1C auprès de LBS et bénéficiez d'une assistance et d'un service 1C de haute qualité.

P.S. Riez de l'anecdote de Loukachenka))

Que sont les modules et à quoi sont-ils destinés exactement ? Le module contient le code du programme. De plus, il convient de noter que, contrairement à la plate-forme 7.7, où le code pouvait être situé à la fois dans les propriétés des éléments de formulaire et dans les cellules des tableaux de mise en page, dans la plate-forme 8.x, toute ligne de code doit être située dans n'importe quel module. Habituellement, un module se compose de trois sections - il s'agit d'une section décrivant les variables, une section décrivant les procédures et les fonctions, ainsi qu'une section du programme principal. Cette structure est typique pour presque tous les modules de plate-forme, à quelques exceptions près. Certains modules n'ont pas de section de déclaration de variable ni de section de programme principal. Par exemple, le module de session et tout module commun.

Le contexte d'exécution des modules, en général, est divisé en client et serveur. De plus, certains modules peuvent être compilés à la fois côté client et côté serveur. Et certains sont purement côté serveur ou côté client. Alors:

Module d'application

Le module est conçu pour capter les moments de lancement de l'application (chargement de la configuration) et sa fin. Et les procédures de contrôle peuvent être placées dans les événements correspondants. Par exemple, au début de l'application, mettez à jour toutes les données de configuration de référence, à la fin du travail, demandez si cela vaut la peine de le quitter, peut-être que la journée de travail n'est pas encore terminée. De plus, il intercepte les événements provenant d'équipements externes, par exemple commerciaux ou fiscaux. Il est à noter que le module applicatif intercepte les événements décrits uniquement en cas de lancement interactif. Celles. lorsque la fenêtre du programme elle-même est créée. Cela ne se produit pas si l'application est lancée en mode com-connexion.

Il existe deux modules d'application différents dans la plate-forme 8.2. Il s'agit d'un module d'application commune et d'un module d'application gérée. Ils sont déclenchés lors du lancement de divers clients. C'est ainsi que le module d'application gérée se déclenche lorsque le client Web, le client léger et le client lourd sont lancés en mode d'application gérée. Et le module applicatif normal est déclenché lorsque le client lourd est lancé en mode applicatif normal.

Toutes les sections peuvent être situées dans le module d'application - descriptions des variables, des procédures et des fonctions, ainsi que des descriptions du programme principal. Le module d'application est compilé côté client, ce qui nous limite considérablement dans la disponibilité de nombreux types de données. Vous pouvez étendre le contexte d'un module d'application à l'aide des méthodes des modules communs, pour lesquels la propriété « Appel serveur » est définie. Toutes les variables et méthodes marquées comme exportées seront disponibles dans n'importe quel module de configuration côté client. Cependant, aussi tentant soit-il, il ne devrait pas être publié ici. un grand nombre de méthodes. Plus il y a de code, plus le temps de compilation et, par conséquent, le temps de lancement de l'application, ce qui est très ennuyeux pour les utilisateurs.

Comme indiqué ci-dessus, le module d'application gère les événements de démarrage et d'arrêt de l'application. Pour gérer chacun de ces événements dans le module d'application, il existe une paire de gestionnaires Avant ... et Quand ... La différence entre eux est telle que lorsque le code est exécuté dans le gestionnaire Avant ..., l'action n'a pas encore été achevé et nous pouvons refuser de l'exécuter. Le paramètre Echec est prévu à cet effet. Dans les gestionnaires Lorsque .. l'action a déjà eu lieu, et nous ne pouvons pas refuser de lancer l'application ou de la quitter.

Module de connexion externe

Le but du module est le même que le but du module d'application. Il traite les points de début et de fin de l'application. Le module de connexion externe est déclenché au lancement de l'application en mode com-connexion. Le processus de jointure externe lui-même est un processus non interactif. Dans ce mode, le travail programmatique avec l'infobase a lieu et la fenêtre de l'application ne s'ouvre pas, ce qui impose certaines restrictions sur l'utilisation des méthodes destinées au travail interactif. Dans ce mode, vous ne pouvez pas utiliser les appels aux formulaires de dialogue, les messages d'avertissement, etc. Ils ne fonctionneront tout simplement pas.

Comme dans le module d'application, des sections décrivant les variables, les méthodes et une section du programme principal sont disponibles ici. Vous pouvez également déclarer des variables et des méthodes d'exportation. La différence est que dans le mode de connexion com, tout le travail avec l'infobase se produit du côté serveur, de sorte que le module de connexion externe est compilé exclusivement sur le serveur. Par conséquent, les variables d'exportation et les méthodes des modules clients courants ne sont pas disponibles.

Module de séance

Il s'agit d'un module hautement spécialisé et destiné uniquement à l'initialisation des paramètres de session. Pourquoi avez-vous eu besoin de créer votre propre module pour cela ? Cela est dû au fait que le processus d'initialisation peut nécessiter l'exécution d'un certain code, et en plus, l'application peut être lancée sous différents clients (ce qui conduit à l'exécution de divers modules applicatifs ou module de connexion externe), et les paramètres de session doit être initialisé dans n'importe quel mode de lancement. Par conséquent, un module supplémentaire était requis, qui est exécuté dans n'importe quel mode de lancement d'application.

Il existe un seul événement SessionParameterSetting dans le module de session, qui est exécuté en premier, avant même l'événement du module d'application BeforeSystemWorking. La section de déclaration de variable et la section de programme principal n'y sont pas disponibles. Et vous ne pouvez pas non plus déclarer de méthodes d'exportation. Le module est compilé côté serveur.

Ne soyez pas tenté que ce module soit exécuté à chaque lancement de l'application, et placez-y du code qui n'est pas directement lié à l'initialisation des paramètres de session. Cela est dû au fait que le gestionnaire SessionParameterSetting peut être appelé à plusieurs reprises pendant le fonctionnement du système. Par exemple, cela se produit lorsque nous accédons à des paramètres non initialisés. Et bien qu'il soit possible de saisir l'instant du premier lancement de cet événement (RequiredParameters est de type Undefined), il faut cependant noter que ce module est compilé en mode privilégié, c'est-à-dire il ne contrôle pas les droits d'accès. Et le deuxième point, nous ne pouvons toujours pas être sûrs à cent pour cent que le système sera lancé. Soudain, une panne se produit dans le module d'application, et nous essayons d'effectuer certaines actions avec la base de données.

Modules communs

Les modules sont destinés à décrire certains algorithmes courants qui seront appelés à partir d'autres modules de configuration. Le module général ne contient pas une section décrivant les variables et une section du programme principal. Dans celui-ci, vous pouvez déclarer des méthodes d'exportation, dont le contexte d'accessibilité sera déterminé par des indicateurs de compilation. Du fait que la section de déclaration des variables n'est pas disponible, vous ne pouvez pas définir de variables globales dans les modules communs. Pour ce faire, vous devez utiliser les fonctions de modules communs avec retour en cache ou d'un module d'application. Il convient de garder à l'esprit que même si la propriété de réutilisation d'un module commun est définie sur "Pour la durée de la session", alors dans ce cas la durée de vie des valeurs mises en cache ne dépasse pas 20 minutes à partir du moment du dernier y accéder.
Le comportement d'un module commun dépend des paramètres définis (globaux ou non, drapeaux de compilation différents, disponibilité d'un appel serveur, etc.). Dans cet article, nous ne considérerons pas toutes sortes de paramètres, ainsi que les caractéristiques comportementales et les pièges qui surviennent lors de la définition déraisonnable des indicateurs de propriété. Ceci est un sujet pour un article séparé. Attardons-nous sur quelques points qui doivent être suivis lors de la définition des drapeaux :

C'est une bonne règle de base de ne pas utiliser le drapeau mondial partout. Cela raccourcira le temps de lancement de l'application, ainsi qu'améliorera la lisibilité du code (bien sûr, si le module général a un nom significatif).
Il n'est pas conseillé d'utiliser plus d'un indicateur de compilation. Il n'y a pas tellement de méthodes qui doivent être exécutées dans différents contextes, et si de telles méthodes sont toujours nécessaires, alors un module commun distinct peut être distingué pour elles.
Le drapeau "Call Server" n'a de sens que si le module est compilé "On Server". Par conséquent, tous les autres indicateurs de compilation doivent être décochés pour éviter divers problèmes.
Si, dans les méthodes du module, il y a un traitement de masse des données, la lecture et l'écriture dans la base de données, alors pour augmenter la vitesse de travail, il est préférable de désactiver le contrôle d'accès en définissant le drapeau "Privilégié". Ce mode n'est disponible que pour les modules partagés compilés sur le serveur.

Module de formulaire

Il est conçu pour traiter les actions des utilisateurs, c'est-à-dire divers événements liés à la saisie des données et au traitement de l'exactitude de leur saisie. Un module de formulaire standard est entièrement compilé sur le client. Le module forme gérée est clairement délimité par le contexte d'exécution, donc toutes les variables et méthodes doivent avoir une directive de compilation. Si la directive n'est pas explicitement spécifiée, alors cette variable ou méthode sera compilée côté serveur. Dans le module formulaire, il y a des sections décrivant les variables et les méthodes, ainsi qu'une section du programme principal.

Module objet

Ce module est typique de nombreux objets de configuration et est destiné, dans le cas général, à traiter les événements des objets. Par exemple, événements d'enregistrement et de suppression d'objets, événement de publication de documents, etc.

Certains événements du module objet dupliquent les événements du module de formulaire. Par exemple, enregistrer des événements. Cependant, il faut comprendre que les événements du module formulaire seront exécutés exclusivement sur le formulaire spécifique de l'objet. En général, il peut y avoir plusieurs de ces formes. Et les événements du module objet seront appelés dans tous les cas, même à l'instant travail programmatique avec l'objet. Par conséquent, si vous devez exécuter du code dans tous les cas, il est préférable d'utiliser les événements du module objet pour cela.

Le module objet est compilé exclusivement sur le serveur. Dans celui-ci, vous pouvez définir des variables et des méthodes d'exportation qui seront disponibles dans d'autres modules de configuration. À l'aide de ces propriétés et méthodes, nous pouvons étendre considérablement les fonctionnalités de l'objet.

Module gestionnaire d'objets

Ce module existe pour de nombreux objets de configuration. L'objectif principal de ce module est de redéfinir l'événement de sélection standard qui se produit au moment de la saisie par ligne et d'étendre les fonctionnalités du gestionnaire. Le module est compilé côté serveur. Il est possible de définir des propriétés et des méthodes d'export. L'appel des méthodes d'export du gestionnaire ne nécessite pas la création de l'objet lui-même.

À tout ce qui précède, vous pouvez ajouter une image de certains des modules de configuration et des méthodes d'appels de méthode mutuelle en mode d'application gérée. La flèche indique la direction dans laquelle vous pouvez vous référer pour appeler la méthode correspondante. Comme vous pouvez le voir sur le diagramme, le contexte du serveur est complètement fermé. Mais à partir du contexte client, il est possible d'appeler des méthodes serveur.

Légende sur le schéma : О.М. Client - Module commun client ; O.M. Serveur - Module commun de serveur ; M.F. Client - Procédures client du module formulaire ; M.F. Serveur - Procédures serveur du module formulaire.

Imprimer (Ctrl + P)

Les objets situés dans la branche de l'arborescence de configuration des modules généraux sont destinés à contenir des textes de fonctions et de procédures qui peuvent être appelées depuis n'importe quel autre module de configuration.
ATTENTION! Un module commun ne peut contenir que des définitions de procédures et de fonctions.
Procédures et fonctions communes des modules dont les intitulés indiquent mot-clé Les exportations sont parmi composants contexte mondial. Vous pouvez en savoir plus sur la rédaction des procédures dans le module général dans les sections "Format des textes sources modules logiciels"Et" Opérateurs "de l'aide du langage embarqué.
Pour éditer un module commun, dans la palette de propriétés d'un objet de type Modules communs de la fenêtre Configuration, dans la propriété Module, cliquez sur le lien Ouvrir. Le texte du module général sera publié pour édition dans l'éditeur de texte du système 1C: Enterprise dans le mode d'édition du texte du module de programme.
Le module commun, faisant partie de la configuration, est stocké uniquement dans le cadre de la configuration.
La propriété Global détermine si les méthodes exportées du module partagé font partie du contexte global.
Si la propriété Global est définie sur True, les méthodes exportées du module commun sont disponibles en tant que méthodes du contexte global.
Si la propriété Global est définie sur False, une propriété est créée dans le contexte global avec un nom qui correspond au nom du module commun dans les métadonnées. Cette propriété est en lecture seule. La valeur de cette propriété est l'objet CommonModule. Les méthodes exportées de ce module commun sont disponibles via cet objet. Ainsi, l'appel des méthodes des modules communs non globaux ressemble à XXXXX.YYYYY, où XXXXX est le nom de la propriété correspondant au contexte du module commun, et YYYYY est le nom de la méthode exportée du module commun.
Exemple:

WorkSales Equipment.ConnectBarcode Scanner ();

Contexte différent et modules communs

En utilisant les propriétés des modules communs et des instructions de préprocesseur, vous pouvez organiser l'exécution de diverses méthodes de modules communs dans le contexte souhaité.
Chaque propriété d'un module commun est responsable de la compilation (et de l'exécution) d'un module commun dans un contexte particulier.
Les propriétés suivantes sont disponibles et sont responsables du contexte dans lequel les méthodes du module commun sont disponibles :
● Client (application régulière)- les méthodes du module commun seront disponibles pour le client lourd en mode applicatif normal ;
● - les méthodes du module commun seront disponibles pour le client léger, le client Web, ainsi que pour le client lourd dans
mode d'application géré ;
● Serveur - les méthodes du module commun seront disponibles sur le serveur ;
● Connexion externe- les méthodes du module commun seront disponibles dans connexion externe.
Si plusieurs propriétés sont définies en même temps, cela signifie que les méthodes du module commun seront disponibles dans plusieurs contextes.
Si un module commun a la propriété Serveur et une autre propriété définie, cela signifie que le module commun sera disponible simultanément sur le serveur et dans le client sélectionné. Il faut comprendre qu'en fait il s'agira de plusieurs versions du code compilé (selon le nombre de clients sélectionnés et pour le serveur lui-même).
De plus, si la méthode située dans un tel module commun est appelée du côté client, alors la copie client du module commun sera utilisée, et si du serveur - la copie du serveur. Dans ce cas, en utilisant des directives de préprocesseur (voir les détails ici), vous pouvez "protéger" le serveur du code qui ne peut pas être exécuté dessus.
Regardons un exemple. Dans un module commun (qui peut être exécuté sur client léger et sur le serveur) il existe une méthode qui a un comportement légèrement différent du côté client léger et du côté serveur. Voyons comment vous pouvez le faire :

# Si Client léger Alors
// Afficher un avertissement
Afficher l'alerte utilisateur(« Sur le client ») ;
#Fin si
Fin de la procédure
Ensuite, côté serveur, le code ressemble à ceci :
Procédure Méthode CommonModule() Exportation
// Divers codes importants vont ici
Fin de la procédure
Côté client léger, le code ressemblera à ceci :
ProcédureCommonModuleMethod () Exporter
// Divers codes importants vont ici
// Afficher un avertissement
ShowUserNotification (« sur le client »);
Fin de la procédure

Il existe plusieurs façons de transférer le contrôle du client au serveur :
● appeler une méthode du module commun du serveur ;
● dans un formulaire ou un module de commande, appeler une méthode précédée de directives de compilation & AuServeur, & AuServeurSansContexte

En même temps, il est impossible d'appeler des méthodes de modules communs clients (pour lesquels la propriété Serveur n'est pas définie) et des méthodes clientes d'un module de formulaire ou d'un module de commande à partir de procédures serveur. Le contrôle reviendra au client une fois l'appel le plus externe à la méthode serveur terminé.
L'exception concerne les méthodes du module de formulaire et du module de commande, qui sont précédées de directives de compilation. & OnClientOnServer, & OnClientOnServerSans Contexte
Les points suivants doivent également être mentionnés :
● Si un module commun est disponible pour plusieurs clients, lors de l'écriture du code, tenez compte des restrictions maximales que les clients peuvent imposer ou utilisez des instructions de préprocesseur pour « isoler » le code spécifique au client.
● Les instructions du préprocesseur ont également un sens lorsqu'un module commun a plusieurs contextes d'exécution, par exemple, une connexion externe et un client léger, ou (ce qui est beaucoup plus courant) un client et un serveur. Dans ce cas, les instructions du préprocesseur encadreront du code interactif non utilisable sur le serveur, mais possible sur le client (voir exemple ci-dessus).
Pour plus d'informations sur les instructions du préprocesseur et les directives de compilation, consultez la section Exécution des procédures et des fonctions de l'aide du langage intégré.
La propriété Call server est utilisée pour contrôler la possibilité d'appeler les méthodes exportées du module commun du serveur à partir du code client.
Si la propriété est définie, les méthodes exportées du module commun du serveur sont disponibles pour l'appel depuis le client. Si la propriété n'est pas définie, ces méthodes exportées ne peuvent être appelées qu'à partir de méthodes côté serveur (à la fois les méthodes des modules communs côté serveur et les méthodes côté serveur du module de formulaire et des modules de commande).
Conseils . Il est recommandé de définir la propriété Appeler le serveur sur False dans les cas où le module commun du serveur contient des méthodes que vous ne souhaitez pas appeler depuis le client (par exemple, pour des raisons de sécurité).
Noter... Si les propriétés sont définies en même temps Client (application régulière), Client (application gérée), Connexion externe, la propriété Appel serveur est automatiquement effacée. Si la propriété du serveur d'appel est définie, les propriétés sont automatiquement réinitialisées. Client (application régulière), Client (application gérée) et Connexion externe si ces propriétés étaient définies en même temps.
Propriété Privilégié est destiné à désactiver le contrôle d'accès lors de l'exécution des méthodes d'un module commun.
REMARQUE. Si la propriété Privilégié est défini, la propriété Server est automatiquement définie sur le module commun et le reste des propriétés est réinitialisé ( Client (application régulière), Client (application gérée) et en connexion externe). Un module partagé privilégié ne peut s'exécuter que sur le serveur.

Réutiliser les valeurs de retour

Si le module partagé n'est pas global, la propriété de réutilisation de la valeur de retour devient disponible. Cette propriété peut prendre les valeurs suivantes :
● Ne pas utiliser — La réutilisation de la valeur de retour n'est pas utilisée pour les fonctions de ce module commun.
● Au moment de l'appel et au moment de la session : la méthode de détermination de la réutilisation des données est utilisée pour le module commun. L'essence de cette méthode est que lors de l'exécution du code, le système se souvient des paramètres et du résultat de la fonction après le premier appel de la fonction. Lorsque la fonction est appelée à nouveau avec les mêmes paramètres, la valeur stockée est renvoyée (à partir du premier appel) sans exécuter la fonction elle-même. Si la fonction modifie les valeurs des paramètres lors de son exécution, l'appel répété de la fonction ne le fera pas.
Les caractéristiques suivantes de l'enregistrement des résultats d'appel peuvent être distinguées :
● si la fonction est exécutée sur le serveur et est appelée depuis le code serveur, alors les valeurs des paramètres et le résultat de l'appel sont stockés pour la session en cours côté serveur ;
● si la fonction est exécutée sur un client lourd ou léger, alors les valeurs des paramètres et les résultats des appels sont stockés côté client ;
● si la fonction est exécutée côté serveur et est appelée depuis le code client, alors les valeurs des paramètres d'appel sont mémorisées à la fois côté client et côté serveur (pour la session en cours).
Les valeurs stockées sont supprimées :
● si la propriété est définie sur Au moment de l'appel :
● côté serveur - lorsque le contrôle est rendu depuis le serveur ;
● côté client - lorsqu'une procédure ou fonction du langage embarqué de haut niveau (appelée par le système depuis l'interface, et non depuis une autre procédure ou fonction du langage embarqué) se termine ;
● si la propriété du module commun est définie sur Pour la durée de la session :
● côté serveur - en fin de session ;
● côté client - lorsque l'application cliente est fermée.
Les valeurs stockées seront supprimées :
● sur le serveur, dans le client lourd, dans la connexion externe, dans le client léger et dans le client Web à vitesse de connexion normale - 20 minutes après le calcul de la valeur stockée ou 6 minutes après la dernière utilisation.
● dans un client léger et un client web à faible vitesse de connexion - 20 minutes après calcul de la valeur stockée ;
● en cas de pénurie mémoire vive dans le workflow du serveur ;
● lors du redémarrage d'un workflow ;
● lorsqu'un client passe à un autre workflow.
Après suppression des valeurs, l'appel à la fonction exportée est effectué comme lors du premier appel.
Cette propriété des modules communs n'affecte pas l'exécution des procédures - les procédures sont toujours exécutées.

Si un module commun est configuré pour réutiliser les valeurs de retour, un certain nombre de restrictions sont imposées sur les types de paramètres des fonctions exportées. Les types de paramètres ne peuvent être que :
● Types primitifs ( Non défini, NULL, Booléen, Nombre, Chaîne, Date).
● Toute référence à des objets de base de données.
● Structures avec des valeurs de propriété des types ci-dessus. Dans ce cas, l'identité des paramètres est contrôlée « par le contenu » des structures.
Si la fonction exportée renvoie un objet, une référence à l'objet stocké dans le cache est en fait renvoyée. Si, après avoir reçu cette référence, il y a un changement dans l'état de l'objet, un appel ultérieur à la même fonction entraînera le retour d'une référence à l'objet déjà modifié sans réellement exécuter la fonction. Ce comportement continuera jusqu'à ce que la valeur stockée soit supprimée (pour une raison quelconque). En d'autres termes - changer l'état d'un objet obtenu à la suite de l'appel d'une fonction à partir d'un module commun avec réutilisation les valeurs de retour ne constituent pas la base de l'appel de fonction réel. Il faut aussi rappeler que le cache des objets retournés est indifférent à
l'état du mode privilégié au moment de l'appel de la fonction avec réutilisation des valeurs de retour. Cette caractéristique peut conduire à fonctionnalité suivante comportement:
● L'exécution proprement dite de l'appel de fonction avec réutilisation des valeurs de retour (premier appel) a été effectuée avec le mode privilégié activé.
● Lors de l'exécution de la fonction, un objet a été reçu qui ne peut pas être reçu avec le mode privilégié désactivé.
● Les appels de fonction suivants ont été effectués sans définir le mode privilégié.
● Cependant, jusqu'à ce que le cache des objets renvoyés soit vidé ou que l'appel réel soit répété, la fonction renvoie un objet formellement inaccessible.
● Le comportement inverse est également vrai, lorsque le premier appel est effectué sans définir le mode privilégié, et dans le mode privilégié l'objet qui aurait pu être reçu dans le mode privilégié n'est pas renvoyé.

Si un module commun a la propriété Réutiliser les valeurs de retour est mis à Pour la durée de la session, puis des valeurs du type Gestionnaire de tables temporaires.
Si une fonction d'un module commun, avec une réutilisation définie, est appelée depuis le même module commun (par exemple, avec le nom CommonModule), alors souvenez-vous de la particularité suivante : si la fonction est appelée par le nom MyFunction(), alors le la fonction sera exécutée à chaque fois que la fonction est appelée... Afin d'utiliser les valeurs stockées, la fonction doit être appelée par son nom complet :
CommonModule.MaFonction ().
La méthode de contexte global supprime toutes les valeurs réutilisables, côté serveur et côté client, quel que soit l'endroit où la méthode est appelée. Après avoir exécuté la méthode RefreshReusedValues () le premier appel à la fonction sera exécuté complètement.

Presque tous les objets de configuration ont un module gestionnaire, et pour la plupart des objets, un module objet. Souvent, les programmeurs novices ne comprennent pas la différence dans l'objectif de ces deux modules.

Comprendre la différence dans leur objectif vous permet d'écrire un code de programme plus structuré et, dans certains cas, d'économiser les ressources du serveur 1C et d'augmenter les performances de la solution appliquée.

Dans l'article, nous examinerons les différences fondamentales entre ces modules à la fois du côté théorique et sur un exemple pratique spécifique.

Théorie

Passons aux bases de la programmation orientée objet (POO) et faisons une analogie avec notre exemple. En POO, les méthodes des objets peuvent être divisées en statique et simple. Méthodes simples ne peut être appelé que pour un objet spécifique auquel nous avons accès dans le contexte actuel du code du programme. Les méthodes statiques n'ont pas d'accès direct aux données d'objet. Pour faire référence à un objet, vous devez d'abord en créer une instance. Il en va de même pour la plate-forme 1C : Enterprise 8.x.

Dans le module objet, la plateforme stocke des procédures et des fonctions qui ne peuvent être appelées que lorsque l'on travaille avec un objet spécifique, par exemple avec une rubrique de la rubrique "Nomenclature" du catalogue. Le module gestionnaire contient des procédures et des fonctions applicables à tous les objets de ce genre mais avec la création initiale d'une instance de cet objet. C'est-à-dire que pour modifier un élément de ce module, initialement pour faire référence à l'élément, exécutez la méthode "GetObject ()" puis travaillez avec elle.

Passons de la théorie à la pratique.

Entraine toi

Passons à exemple pratique... Supposons que l'on doive résoudre le problème de l'impression d'une liste de produits, l'utilisateur imprime le produit soit directement à partir d'un article de catalogue, soit à partir d'une forme de liste de produits. Considérez deux façons d'accomplir cette tâche.

Procédure d'impression dans le module objet

Dans le module de l'objet répertoire, ajoutez la fonction suivante :

// Passer la référence à l'élément de référence dans la fonction Fonction Imprimer les éléments sélectionnés (lien) Exporter TabDoc = Nouveau document tabulaire ; Disposition = Références. Des produits. Obtenir la mise en page ("Mise en page"); Demande = Nouvelle demande ; Enquête. Text = "SELECT | Produits ... Représentation AS Produit,| Des produits ... Supprimer la marque,| Des produits ... code de fournisseur |À PARTIR DE| Annuaire ... Produits AS Produits| O | Des produits ... Lien dans (& ArrayProducts)"; Request. SetParameter (" ArrayProducts ", Link); // Définir la sélection par lien

Le code du programme est entièrement généré par le concepteur d'impression. La seule chose à noter est la sélection par référence à la rubrique "Produits" du catalogue dans la demande. La référence est passée en paramètre à la fonction. Suite à l'appel de la fonction « Imprimer les éléments sélectionnés », le feuille de calcul avec un article rempli de marchandises.

Le code du programme d'appel de la méthode de l'objet "Imprimer les éléments sélectionnés" par la commande du formulaire "Imprimer" est représenté dans le listing suivant :

& Procédure d'impression client (commande) // Appel de la procédure serveur pour obtenir le tableur généré TabDoc = PrintServer (); // Affiche le tableur généré TabDoc. Montrer() ; EndProcedure & AtServer Fonction PrintServer () // Convertir l'objet formulaire en objet catalogue "Produits" pour appeler la fonction depuis le module objet ObjetBon = FormInValue ("Objet"); // On appelle la procédure du module objet, en lui passant un lien vers l'item courant du dictionnaire. Résultat // retour côté client Renvoyer l'élément d'objet. Imprimer les éléments sélectionnés (Objet. Lien); FinFonction

Ainsi, nous avons imprimé l'élément courant du répertoire, en travaillant avec son objet. Mais la tâche a été dit d'imprimer une liste de produits que l'utilisateur lui-même doit sélectionner. Lorsque vous travaillez avec un objet, donnez à l'utilisateur une telle opportunité façon simple ne semble pas possible. Il serait plus correct d'imprimer à partir de la liste des articles du catalogue "Produits".

Procédure d'impression dans le module gestionnaire

Ajoutez la procédure d'exportation suivante au module du gestionnaire d'annuaire :

// Passer un tableau de liens vers des produits Fonction Imprimer les éléments sélectionnés (tableau d'éléments) Exporter TabDocs = Nouveau document tabulaire ; Disposition = Références. Des produits. Obtenir la mise en page ("Mise en page"); Demande = Nouvelle demande ; Enquête. Text = "SELECT | Produits ... Représentation AS Produit,| Des produits ... Supprimer la marque,| Des produits ... code de fournisseur |À PARTIR DE| Annuaire ... Produits AS Produits| O | Des produits ... Lien dans (& ArrayProducts)"; Request. SetParameter (" Array of Goods ", Array of Goods); // Définir la sélection par tableau Résultat = Demande. Courir (); AreaHeader = Mise en page. GetScope ("Titre"); AreaFooter = Disposition. GetArea ("Sous-sol"); AreaTablesHead = Disposition. GetArea ("TableHead "); AreaFooterTables = Disposition. GetArea ("pied de table"); Zone DetailRecords = Disposition. GetArea ("Détails"); TabDoc. Dégager (); TabDoc. Affichage (ScopeHeader) ; TabDoc. Affichage (ScopeTableHat); TabDoc. StartAutoGroupLines (); Exemples d'enregistrements détaillés = résultat. Sélectionnez () ; Tandis que SampleDetailed Records. Next () Zone d'enregistrements détaillés de la boucle. Paramètres. Remplir (enregistrements détaillés de la sélection) ; TabDoc. Sortie (DetailRecordsArea, SelectionDetailRecords. Level ()); Fin de cycle ; TabDoc. EndAutoGroupLines (); TabDoc. Sortie (ScopeTableFootball) ; TabDoc. Affichage (AreaFooter) ; Retour de TabDoc ; FinFonction

La principale différence avec une fonction dans un module objet est le paramètre de fonction. Désormais, un tableau avec des liens vers les produits à imprimer est passé en paramètre.

Le code de programme du module de commande de formulaire "Imprimer" ressemble à ceci :

& Sur la procédure client Imprimer (commande) TabDoc = PrintServer (); TabDoc. Montrer() ; EndProcedure & AtServer Fonction PrintServer () // Passer un tableau de liens des produits sélectionnés dans la liste des répertoires // dans la fonction du module gestionnaire "PrintSelected Items" Annuaires de retour. Des produits. PrintSelectedProducts (Items. List. SelectedLines); FinFonction

Dans ce cas, le résultat de l'exécution de la commande en mode 1C : Entreprise sera le suivant :

Dans le cas de l'utilisation de la méthode du module gestionnaire, on peut accéder aux données du répertoire "Produits" sans obtenir d'objet pour chaque lien. Étant donné que l'obtention d'un objet signifie obtenir toutes les données de la base de données pour un élément de référence et mettre les données reçues dans la RAM, la mise en œuvre de la tâche de la deuxième manière aura un effet positif sur les performances. En effet, dans ce cas, on utilisera un minimum de ressources (RAM) de la machine serveur.

Que devez-vous utiliser ?

Comme toujours, tout dépend de la tâche spécifique. Si vous devez imprimer un document, une meilleure option consiste à utiliser le module de gestion. Si vous devez remplir un objet, par exemple, traitement externe remplissage sections tabulaires, alors dans ce cas, les procédures et les fonctions sont mieux placées dans le module objet, puisque leur travail implique exactement l'objet.

V configuration typique"Trade Management" version 11 est un module de gestion largement utilisé pour l'impression de documents. Si vous regardez la configuration "Manufacturing Enterprise Management", alors le module de gestion n'est pratiquement pas utilisé, car la configuration a été écrite dans les anciennes versions de la plate-forme, où ce mécanisme n'était pas entièrement pris en charge.

Configuration avec des exemples de l'article.

Modules de plate-forme 1C : Entreprise 8.3, 8.2

Modules communs

Les fonctions déclarées avec le drapeau "export" dans un tel module peuvent être appelées de n'importe où dans la configuration. L'appel est effectué via CommonModuleName.FunctionName().

Il n'y a pas de section variable dans de tels modules.

L'exécution des modules communs dépend des paramètres définis dans leurs propriétés :

Drapeau "Global"

Si ce drapeau est défini, alors le contexte d'un tel module devient global. C'est-à-dire que lorsque vous accédez à ses fonctions d'exportation, vous n'avez pas besoin de spécifier le nom du module. Mais les noms de ses fonctions d'exportation doivent être uniques dans le contexte de configuration globale.

Indicateur de serveur

Les fonctions d'un tel module peuvent être exécutées sur le serveur.

Indicateur client (application régulière)

Les fonctions d'un tel module peuvent être exécutées sur le client en mode applicatif normal.

Indicateur client (application gérée)

Les fonctions d'un tel module peuvent être exécutées sur le client en mode applicatif managé.

Indicateur d'appel de serveur

Le drapeau est disponible pour les modules avec le drapeau "Serveur" défini. Permet des appels sur le client aux fonctions d'export de ce module (à exécuter sur le serveur).

Indicateur de jointure externe

Les fonctions d'export d'un tel module peuvent être appelées lorsqu'il est connecté depuis une source externe.

Drapeau "Privilégié"

Dans un module avec un tel indicateur, la vérification des droits sera désactivée. Convient pour les actions de productivité ou d'administration.

Option de réutilisation

Si vous incluez ce paramètre, alors les valeurs de retour des fonctions d'exportation seront mises en cache immédiatement après le premier appel. La mise en cache est possible pour la durée d'un appel (temps d'exécution d'une certaine procédure) ou pour la durée d'une session utilisateur.

Module d'application

Conçu pour gérer les événements de démarrage et d'arrêt des applications. Il en existe deux types : pour les applications régulières et gérées.

Ne le surchargez pas, car cela affecte le temps de démarrage de l'application.

Module de séance

Un module spécial qui est utilisé pour initialiser les paramètres de session. Il est nécessaire afin de ne pas dupliquer le code dans différents modules d'application.

Il doit être utilisé avec précaution, car le module peut être exécuté plusieurs fois, et également être exécuté sans démarrer davantage la base. Exécuté avant les modules d'application.

Meilleures salutations, (enseignant et développeur).