Dettagli del modulo gestito (1Cv8). Aggiunta e modifica a livello di codice di elementi di moduli gestiti Aggiunta di attributi a un modulo gestito

La piattaforma 1C:Enterprise consente di aggiungere e modificare a livello di codice elementi di un modulo gestito. Scopriamo perché questo potrebbe essere necessario.

La modifica del software del modulo può essere necessaria in diversi casi:

• In fase di finalizzazione delle configurazioni standard per facilitare la successiva procedura di aggiornamento. In questo caso verrà modificato solo il modulo del modulo. I moduli sono molto più facili da aggiornare rispetto ai moduli.
• Quando si implementano alcuni algoritmi comuni. Ad esempio, nel sottosistema "Divieto di modifica dei dettagli dell'oggetto", è possibile creare a livello di codice un pulsante per tutti gli oggetti collegati al sottosistema per abilitare la possibilità di modificare i dettagli.
• Quando si implementano alcuni algoritmi specifici. Ad esempio, nella directory Nomenclatura, vengono creati campi per modificare dettagli aggiuntivi.

In un modulo gestito è possibile aggiungere, modificare ed eliminare a livello di codice:

• requisiti;
• squadre locali;
• elementi.

Tutte queste operazioni sono possibili solo sul server.

Il rimodellamento programmatico presenta delle limitazioni:

• Puoi eliminare solo dettagli/comandi/elementi aggiunti a livello di codice. Non è possibile eliminare a livello di codice gli oggetti creati nel configuratore.
• Non è possibile assegnare un attributo come principale.

Modifica dei comandi del modulo

Per gestire la composizione dei comandi per un oggetto Modulo gestito c'è una collezione Squadre

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

Quantità ()

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

Eliminare (< Команда >)

La raccolta Teams è disponibile sia sul client che sul server. È possibile modificare la raccolta (metodi Add() e Elimina()) solo sul server. È possibile cercare e ottenere il numero di elementi (i metodi Find() e Count()) sia sul client che sul server.

Come esempio di lavoro con i comandi del modulo, creiamo un nuovo comando ChangeHistory con l'intestazione "ChangeHistory...", che chiamerà il gestore DisplayHistory(). La creazione avviene all'apertura del modulo.

&Sul server
Procedura Quando si crea sul server (errore, elaborazione standard)
Squadra = Squadre. Aggiungere( "Storia dei cambiamenti");
Squadra . Azione = ;
Squadra . Titolo = "Storia dei cambiamenti...";
Fine della procedura
&SuClient
Procedura Connectable_DisplayHistory(Command)
// comanda le azioni
Fine della procedura

Il gestore comandi deve trovarsi in un modulo e avere una direttiva di compilazione &OnClient.

Modifica dei dettagli del modulo

La lettura della composizione dei dettagli del modulo viene eseguita dalla funzione Ottieni dettagli(< Путь >) che restituisce una matrice di tipo FormAttributes. Il parametro della funzione specifica il percorso dell'attributo principale (come stringa). Se il parametro viene omesso o viene specificata una stringa vuota, vengono restituiti i dettagli di livello superiore.

La modifica dei dettagli viene eseguita utilizzando il metodo Modifica dettagli(<Aggiunti dettagli>, <Dettagli rimovibili>) oggetto Modulo gestito. Ai parametri Aggiunti dettagli E Dettagli rimovibili Vengono trasmessi array con elementi del tipo Attributi modulo.

Attenzione!

Il processo di modifica della composizione dei dettagli richiede molte risorse. Il modulo viene effettivamente ricreato. A questo proposito, il lavoro con i dettagli del modulo viene eseguito in modalità batch.

Creiamo un nuovo attributo del modulo con il nome Acquirente:

Dettagli aggiunti = Nuovo array;
Dettagli aggiunti. Aggiungi(Nuovi attributi del modulo(“Acquirente”, Nuova Descrizione Tipo (“Link Directory. Controparti”), “Cliente”));

// Cambiamenti nella composizione dei dettagli
);

Modifica degli elementi del modulo

Per controllare la composizione degli elementi di un oggetto Modulo gestito c'è una collezione Elementi. La raccolta prevede diverse modalità:

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

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

Quantità ()

Trovare (< Имя >)

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

Eliminare (< Элемент >)

La raccolta Items è disponibile sia sul client che sul server. Modificare una raccolta (Inserisci metodi () , Aggiungi (), Sposta () ed Elimina ()) sono disponibili solo sul server. È possibile cercare e ottenere il numero di elementi (i metodi Find() e Count()) sia sul client che sul server. Gli elementi della raccolta possono essere:

• GruppoForm;
• TabellaForma;
• Campo modulo;
• Pulsante modulo.

È possibile assegnare a livello di codice gestori di eventi agli elementi del modulo. Il metodo è destinato a questi scopi ImpostaAzione(< ИмяСобытия>, < Действие >) .

Diamo un'occhiata ad alcuni degli esempi più comuni nella pratica di lavorare con comandi, dettagli ed elementi del modulo.

Aggiunta di un comando e del relativo pulsante associato:

// Crea un comando
Squadra = Squadre. Aggiungere( "Storia dei cambiamenti");
Squadra . Azione = "Plug-in_DisplayHistory"; // Il modulo deve contenere una procedura con il nome specificato
Squadra . Intestazione = "Storia dei cambiamenti...";
// Crea un pulsante e associalo a un comando
Elemento = Articoli. Aggiungere( "Storia dei cambiamenti", Tipo("PulsanteModulo" ));
Element.CommandName = "Storia dei cambiamenti";

Aggiunta di un attributo e del campo di input associato:

// Descrizione dei dettagli aggiunti
Dettagli aggiunti = Nuovo array;
Dettagli aggiunti. Aggiungere(Nuovi oggetti del modulo (“Acquirente”, Nuova descrizione del tipo ( "DirectoryLink. Controparti"), "Cliente" ));
// Modifica la composizione dei dettagli
ModificaDettagli(Dettagli aggiunti);
// Creazione di un campo di input e connessione all'attributo
Elemento = Articoli. Aggiungi("Acquirente" , Tipo("CampoForma" ));
Elemento . Visualizza = Visualizzazione campo modulo. Campo di immissione;
Elemento . Percorso dei dati= "Acquirente";

Assegnazione di un gestore eventi a un elemento del modulo:

ArticoloCliente. Imposta azione("Quando cambia", "Connesso_BuyerOnChange");

&SuClient
Procedura Connesso_BuyerOnChange(Elemento)
// Azioni dell'evento
Fine della procedura

Attenzione!

Procedure impostate come gestori eventi dal codice utilizzando il metodo ImpostaAzione(), si consiglia di impostare il prefisso Connectable_.

Attenzione!

Puoi scaricare elaborazioni con esempi di ricerca programmatica e modifica di dettagli, comandi ed elementi di un modulo gestito.

Dettagli del modulo

Una serie di dettagli del modulo descrive la composizione dei dati visualizzati, modificati o archiviati nel modulo. Allo stesso tempo, i dettagli del modulo stesso non forniscono la possibilità di visualizzare e modificare i dati. Gli elementi del modulo (vedere la sezione "Elementi del modulo" di questo capitolo) associati ai dettagli del modulo vengono utilizzati per la visualizzazione e la modifica. L'insieme di tutti i dettagli del modulo verrà chiamato dati del modulo.

Importante! Va ricordato che, a differenza dei moduli normali, tutti i dati presenti in un modulo gestito devono essere descritti sotto forma di dettaglio. Non è consentito utilizzare variabili del modulo modulo come origini dati per gli elementi del modulo.

È possibile assegnare Dettagli del modulo di base, ovvero attributi che determineranno la funzionalità standard del modulo (estensione del modulo). Va ricordato che un modulo può avere solo un attributo principale.

Estensione del modulo– si tratta di proprietà, metodi e parametri aggiuntivi del form dell'oggetto ManagedForm, caratteristici dell'oggetto che costituisce l'elemento principale del form.

Durante il processo di sviluppo del modulo, puoi impostare esplicitamente la possibilità di visualizzare e modificare dettagli specifici del modulo, in termini di ruoli, utilizzando le proprietà Visualizza e Modifica (per maggiori dettagli, consulta la sezione "Impostazioni modulo basato sui ruoli" della sezione "Editor" " capitolo). Inoltre, la disponibilità di un particolare attributo nel modulo stesso può essere configurata utilizzando le opzioni funzionali (maggiori dettagli sulle opzioni funzionali possono essere trovati nel capitolo “Gestione dell'interfaccia di configurazione”).

Proprietà dell'attributo del modulo Dati salvatiè un segno che una modifica interattiva nei dettagli porterà al tentativo di bloccare i dati del modulo per la modifica, nonché all'impostazione automatica del flag di modifica del modulo.

Tipi di dati disponibili in un modulo gestito

Un modulo gestito differisce da un modulo normale anche per i tipi di dati con cui funziona. Se il modulo normale funziona con la maggior parte dei tipi forniti da 1C:Enterprise (inclusi i tipi DirectoryObject, DocumentObject, ecc.), nel modulo gestito si possono distinguere le seguenti categorie di tipi:

• i tipi utilizzati direttamente nel modulo sono quelli esistenti sul lato del thin client e del Web client (ad esempio, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);

• tipi che verranno convertiti in tipi di dati speciali: tipi di dati di moduli gestiti. Tali tipi vengono visualizzati nell'elenco dei dettagli del modulo tra parentesi, ad esempio (DirectoryObject.Products);

• lista dinamica (per maggiori dettagli vedere la sezione “Lista Dinamica” di questo capitolo).

Conversione di oggetti dell'applicazione in dati del modulo

Alcuni tipi di applicazioni (come DirectoryObject, ecc.) non esistono sul lato thin e Web client (vedere il capitolo sul concetto di applicazione gestita per maggiori dettagli). Pertanto, per rappresentare tali tipi di applicazioni nel modulo, la piattaforma ha introdotto tipi di dati speciali progettati per funzionare nei moduli gestiti. Questa funzionalità di un'applicazione gestita rende necessario convertire gli oggetti dell'applicazione in dati formati (e viceversa).

Vengono utilizzati i seguenti tipi di dati:

• Form DataStructure – contiene un insieme di proprietà di tipo arbitrario. Le proprietà possono essere altre strutture, raccolte o strutture con raccolte. Questo tipo è rappresentato, ad esempio, nella forma DirectoryObject.

• Una FormDataCollection è un elenco di valori tipizzati, simile a un array. Si accede a un elemento della raccolta tramite indice o identificatore. In alcuni casi l'accesso tramite ID potrebbe non essere disponibile. Ciò è dovuto al tipo di oggetto applicazione rappresentato da questa raccolta. L'identificatore può essere qualsiasi numero intero. Questo tipo è rappresentato, ad esempio, sotto forma di una parte tabellare.

• Il modulo DataStructureWithCollection è un oggetto rappresentato contemporaneamente come struttura e raccolta. Può essere trattato come una qualsiasi di queste entità. Questo tipo rappresenta, ad esempio, un insieme di record in un modulo.

• Form DataTree – un oggetto progettato per archiviare dati gerarchici.

Un oggetto dell'applicazione è rappresentato da uno o più elementi dati del modulo. In generale, la gerarchia e la composizione dei dati del modulo dipendono dalla complessità e dall'interconnessione degli oggetti dell'applicazione del modulo gestito.

Ad esempio, un documento contenente una parte tabellare sarà rappresentato da un oggetto di tipo FormDataStructure (il documento stesso), a cui è subordinato un oggetto di tipo FormDataCollection (parte tabellare del documento).

Importante! Quando si sviluppa una configurazione, è importante ricordare che gli oggetti applicazione sono disponibili solo sul server, mentre gli oggetti dati del modulo possono essere utilizzati sia sul server che sul client.

Passaggio di dati tra le parti client e server di un modulo gestito

Infatti possiamo dire che i dati del form sono una rappresentazione unificata dei dati provenienti da vari oggetti applicativi con cui il form lavora in modo uniforme e che sono presenti sia sul server che sul client. Cioè, il modulo contiene una sorta di "proiezione" dei dati dell'oggetto dell'applicazione sotto forma di tipi di dati propri ed esegue la conversione tra di essi, se necessario. Tuttavia, se lo sviluppatore della configurazione implementa il proprio algoritmo di elaborazione dati, deve eseguire la conversione dei dati (da tipi specializzati a tipi di applicazione e viceversa) in modo indipendente.

Quando si modificano i dettagli del modulo in un editor specializzato (per maggiori dettagli vedere la sezione “Dettagli del modulo” del capitolo “Editor”), è possibile influenzare il trasferimento dei dati tra il client e il server mentre il modulo è in esecuzione. A questo scopo viene utilizzata la colonna dell'editor dei dettagli. Usalo sempre. L'effetto di questa proprietà differisce per tre tipi di attributi:

• Per un attributo subordinato a una lista dinamica (colonna della lista dinamica):
  • la proprietà è abilitata: l'attributo viene sempre letto dal database e incluso nei dati del modulo;
  • La proprietà è disabilitata: l'attributo viene letto dal database e incluso nei dati del modulo solo quando è presente un elemento del modulo attualmente visibile associato all'attributo o al suo attributo subordinato.

• Per gli oggetti di scena subordinati alla raccolta di movimento:
  • la proprietà è abilitata – i movimenti dei documenti vengono letti dal database e saranno presenti nel modulo dati;
  • La proprietà è disabilitata: i movimenti del documento non verranno letti dal database e non saranno inclusi nei dati del modulo (se non è presente alcun elemento del modulo che faccia riferimento ai movimenti del documento).

• Altri dettagli del modulo:
  • la proprietà è abilitata: l'attributo sarà presente nei dati del modulo, indipendentemente dal fatto che esista o meno almeno un elemento del modulo associato all'attributo o al suo attributo subordinato;
  • La proprietà è disabilitata: l'attributo sarà presente nei dati del modulo solo se è presente un elemento del modulo associato all'attributo o al suo attributo subordinato. A differenza degli attributi dell'elenco dinamico, qui la visibilità dell'elemento associato all'attributo non ha importanza.

Nota. Va ricordato che la proprietà impostata sull'attributo genitore influenza tutti gli attributi subordinati. Ad esempio, se la proprietà Usa è sempre cancellata per la parte tabellare del documento, allora il sistema considera che questa proprietà sia cancellata anche per tutti i dettagli subordinati (nonostante lo stato effettivo della proprietà).

Metodi per convertire i dati dell'oggetto dell'applicazione in dati del modulo

Per convertire gli oggetti dell'applicazione nei dati del modulo e viceversa, esiste una serie di metodi globali:

• ValoreInFormData(),
• FormDataInValue(),
• CopiaFormData().

Importante! I metodi che funzionano con gli oggetti dell'applicazione sono disponibili solo nelle procedure server. Il metodo per copiare valori tra i dati del modulo è disponibile sia sul server che sul client, poiché non richiede oggetti dell'applicazione come parametri.

Quando si convertono i dati del modulo in un oggetto dell'applicazione, è necessario considerare la loro compatibilità.

• ValueInFormData() – converte un oggetto di tipo applicazione in dati del modulo;
• FormDataInValue() – converte i dati del modulo in un oggetto di tipo applicazione;
• CopyFormData() – copia i dati del modulo che hanno una struttura compatibile. Restituisce True se la copia ha avuto successo oppure False se la struttura dell'oggetto è incompatibile.

Nota. Quando si eseguono azioni standard (apertura di un modulo, esecuzione di un comando di scrittura standard, ecc.) di un modulo con i dettagli principali, la conversione viene eseguita automaticamente.

Diamo un esempio di come utilizzare la trasformazione dei dati nei tuoi algoritmi.

&ProceduraOnServer durante la creazioneOnServer(Errore, Elaborazione standard)

ObjectProduct = Directory.Products.FindByName("Caffettiera").GetObject(); ValoreInFormData(OggettoArticolo, Oggetto);

Fine della procedura

&Scrittura procedura sul client()

ScriviSuServer();

Fine della procedura

Procedura &OnServer WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); OggettoItem.Write();

Fine della procedura

L'oggetto ManagedForm dispone anche di metodi disponibili sul server:

• ValueFormAttribute() – converte un oggetto di tipo applicazione nell'attributo del modulo specificato.
• FormAttributeVValue() – converte un attributo dei dati del modulo in un oggetto di tipo applicazione.

L'utilizzo di questi metodi è solitamente più conveniente poiché contengono, ad esempio, informazioni sul tipo di attributo del modulo. Inoltre, il metodo Form AttributesValue() imposta la corrispondenza tra i dati del modulo e l'oggetto, che viene utilizzato durante la generazione dei messaggi. Puoi leggere ulteriori informazioni al riguardo nel capitolo "Funzionalità di navigazione del servizio".

Diamo un esempio dell'utilizzo di questi metodi.

&Procedura OnServer RicalcolaOnServer()

// Converte l'attributo Object in un oggetto applicazione. Documento = Valore Attributi Modulo("Oggetto"); // Esegue il ricalcolo utilizzando il metodo definito nel modulo del documento. Document.Recalculate(); // Converte nuovamente l'oggetto dell'applicazione in un oggetto di scena. ValueÂFormAttributes(Documento, "Oggetto");

Fine della procedura

Interfaccia software

ModuloDataTree

• FindById
• Ottieni articoli

Descrizione:

Progettato per modellare un albero nei dati del modulo gestito.

Questo oggetto può essere serializzato su/da XDTO. Il tipo XDTO corrispondente a un determinato oggetto è definito nello spazio dei nomi. Nome del tipo XDTO:

Ottieni articoli

Sintassi:

OttieniArticoli()

Valore di ritorno:

Tipo: modulo DataCollection di elementi dell'albero.

Descrizione:

Ottiene una raccolta di elementi dell'albero di primo livello.

Disponibilità: client, server, thin client, web client.

FindById

Sintassi:

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

Opzioni:

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

Tipo: numero. Identificatore dell'elemento dell'albero.

Valore di ritorno:

Tipo:FormDataTreeElement.

Descrizione:

Ottiene un elemento della raccolta in base all'ID.

Disponibilità: client, server, thin client, web client.

ElementoDataTreeForm

Proprietà:

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

• GetId (GetId)
• OttieniParent
• Ottieni articoli
• Proprietà

Descrizione:

Elemento dell'albero dati del modulo.

FormDataTreeItemCollection

Elementi della raccolta: DataFormTreeElement

Per un oggetto è possibile attraversare la collezione utilizzando l'operatore For Each... From... Loop. L'attraversamento seleziona gli elementi della collezione. È possibile accedere ad un elemento di raccolta utilizzando l'operatore [...]. L'indice dell'elemento viene passato come argomento.

• Inserire
• Aggiungere
• Indice (IndexOf)
• Contare
• Chiaro
• Ottenere
• Mossa
• Eliminare

Descrizione:

Collezione di elementi in legno.

Disponibilità: client, server, thin client, web client.

Guarda anche:

• FormDataTreeElement, metodo GetElements
• DataFormTree, metodo GetItems

Caratteristiche di lavorare con un albero dei valori

Aggiornamento dell'albero

C'è un problema cascate piattaforme durante l'aggiornamento dell'albero.

Se un nodo nell'albero è stato espanso ed è stato selezionato un nodo subordinato, allora quando si aggiorna l'albero con la funzione ValoreInFormData la piattaforma cade.

Soluzione: è necessario cancellare l'albero prima dell'aggiornamento.

Per esempio:

&Sulla procedura server ClearTree(elements) Per ogni elemento da elements Loop ClearTree(element.GetElements()); FineCiclo; elementi.Clear(); Fine della procedura

&Sulla procedura server Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Fine della procedura

&Procedura OnClient OnDateOnChange(Element) Fill ConceptTree(); Fine della procedura

E oggetto di trasferimento dati per strutturare il codice, forma controllata nell'ambiente 1C 8.2.

introduzione

Nel 2008 è diventata disponibile una nuova versione della piattaforma 1C: Enterprise 8.2 (di seguito denominata Applicazione gestita), che modifica completamente l'intero livello di lavoro con l'interfaccia. Ciò include l'interfaccia di comando, i moduli e il sistema a finestre. Allo stesso tempo, non solo cambia il modello per lo sviluppo dell'interfaccia utente nella configurazione, ma viene proposta anche una nuova architettura per separare le funzionalità tra l'applicazione client e il server.
L'applicazione gestita supporta i seguenti tipi di client:

• Thick client (modalità di avvio normale e gestita)
• Cliente sottile
• Cliente Web

• Descrizione dichiarativa, non “pixel per pixel” della struttura. Il posizionamento specifico degli elementi viene eseguito automaticamente dal sistema quando viene visualizzato il modulo.
• Tutte le funzionalità del modulo sono descritte come dettagli E squadre. I dettagli sono i dati con cui funziona il modulo e i comandi sono le azioni da eseguire.
• Il modulo viene eseguito sia sul server che sul client.
• Nel contesto client quasi tutti i tipi di applicazioni non sono disponibili e di conseguenza è impossibile modificare i dati nell'infobase.
• Per ogni metodo o variabile del modulo è necessario specificarlo direttiva di compilazione, definendo il percorso di esecuzione (client o server) e l'accesso al contesto del modulo.

• &SuClient
• &Sul server
• &OnServerSenza contesto
• &OnClientOnServerSenza contesto

Tutte le ulteriori discussioni riguarderanno il lato destro dell'illustrazione, come strutturare il codice del modulo e quali principi ti permetteranno di implementare un'efficace interazione client-server.

Definiamo il problema

Diamo un'occhiata alla struttura del codice (modulo del modulo) in diversi moduli della stessa configurazione standard e proviamo a trovare dei modelli.
Per struttura intendiamo sezioni di codice (molto spesso si tratta di blocchi di commenti) assegnate dallo sviluppatore a metodi di gruppo e direttive di compilazione per questi metodi.
Esempio 1:
Sezione dei gestori eventi Metodo - sul client Metodo - sul server Metodo - sul client Sezione delle procedure e funzioni del servizio Funzioni di controllo degli input ausiliari
Esempio 2:
Procedure e funzioni del servizio Documenti di pagamento Valori Gestori di eventi
Esempio 3:
Procedure di servizio sul server Procedure di servizio sul client Procedure di servizio sul server senza contesto Gestori di eventi di intestazione Gestori di eventi di comando
Esempio 4:
Procedure di uso generale Gestori di eventi del modulo Procedure del sottosistema “informazioni di contatto”.
In sostanza, manca la struttura del codice o, per usare un eufemismo, è simile a quella del Forms 8.1:

• Parole non informative “Generale, Servizio, Ausiliario”.
• Tentativi timidi di separare i metodi client e server.
• I metodi sono spesso raggruppati per elementi dell'interfaccia "Lavorare con la parte tabellare Prodotti, Informazioni di contatto".
• Disposizione arbitraria di metodi e gruppi di codici. Ad esempio, i gestori di eventi potrebbero essere in alto in un modulo, in basso in un altro, non evidenziati affatto in un terzo, ecc.
• E non dimentichiamo che tutto questo è all'interno di un'unica configurazione.
• Sì, ci sono configurazioni in cui le parole “Generale, Servizio, Ausiliario” sono sempre negli stessi posti ma...

Perché hai bisogno della struttura del codice?

• Semplificazione della manutenzione.
• Semplifica l'apprendimento.
• Registrare principi generali/importanti/di successo.
• ...la tua opzione

Perché lo standard di sviluppo esistente di 1C non aiuta?

• Ridurre al minimo il numero di chiamate al server.
• Massimo calcolo sul server.
• Le chiamate al server non contestuali sono più veloci di quelle contestuali.
• Programma pensando alla comunicazione client-server.
• e così via.

Design pattern o saggezza generazionale

• Facciata remota(di seguito denominata Interfaccia di accesso remoto)
• Oggetto di trasferimento dati(di seguito denominato Oggetto di trasferimento dati)

• … Ogni oggetto potenzialmente destinato all'accesso remoto deve avere interfaccia a bassa granularità, che ridurrà al minimo il numero di chiamate necessarie per eseguire una determinata procedura. ... Invece di richiedere una fattura e tutte le sue voci separatamente, è necessario leggere e aggiornare tutte le voci della fattura in un'unica richiesta. Ciò influisce sull'intera struttura dell'oggetto... Ricorda: interfaccia di accesso remoto non contiene la logica del dominio.
• ...se fossi una madre premurosa, direi sicuramente a mio figlio: "Non scrivere mai oggetti di trasferimento dati!" Nella maggior parte dei casi, gli oggetti di trasferimento dati non sono altro che set da campo gonfio... Il valore di questo mostro disgustoso risiede esclusivamente nella possibilità trasmettere più informazioni sulla rete in una chiamata- una tecnica di grande importanza per i sistemi distribuiti.

Esempi di modelli nella piattaforma 1C

Nel contesto di un modulo gestito, sono presenti numerosi "oggetti di trasferimento dati". Puoi selezionare sistemico E definito dallo sviluppatore.
Quelli di sistema modellano un oggetto applicativo sul client, sotto forma di uno o più elementi dati del modulo. È impossibile crearli senza fare riferimento ai dettagli del modulo.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureWithCollection
• DataShapesTree

• ValoreInFormData()
• ModuloDataValore()
• CopiaFormData()
• ValoreInFormProps()
• ValoreAttributiForma()

Gli oggetti di trasferimento dati, la cui struttura è determinata dallo sviluppatore, sono un piccolo sottoinsieme dei tipi disponibili sia sul client che sul server. Molto spesso, come parametri e risultati dei metodi di un'interfaccia "grossolana" vengono utilizzati i seguenti:

• Tipi primitivi (stringa, numero, booleano)
• Struttura
• Corrispondenza
• Vettore
• Collegamenti agli oggetti dell'applicazione (identificatore univoco e rappresentazione testuale)

Strutturare il codice

• Chiara separazione del codice client e server. Non dimentichiamo che al momento dell'esecuzione si tratta di due processi interagenti, ognuno dei quali ha funzionalità disponibili significativamente diverse.
• Chiara identificazione dell'interfaccia di accesso remoto, quali metodi server possono essere richiamati dal client e quali no? I nomi dei metodi di interfaccia remota iniziano con il prefisso "Server". Ciò consente di vedere immediatamente il trasferimento del controllo al server durante la lettura del codice e semplifica l'uso dell'aiuto contestuale. Tieni presente che la raccomandazione ufficiale (ITS) suggerisce metodi di denominazione con suffissi, ad esempio ChangeOrderStatusOnServer(). Ripetiamo però che non tutti i metodi server possono essere chiamati dal client, e quindi è più importante l'accessibilità logica, piuttosto che il luogo di compilazione. Pertanto con il prefisso “Server” contrassegniamo solo i metodi disponibili al client chiamiamo il metodo di esempio ServerChangeOrderStatus();
• Leggibilità. Questione di gusti, accettiamo l'ordine quando il modulo inizia con le procedure per creare un modulo sul server e le modalità di accesso remoto.
• Manutenibilità. Deve esserci una posizione chiara per l'aggiunta del nuovo codice. Un punto importante è che i modelli di metodo creati automaticamente dal configuratore vengono aggiunti alla fine del modulo. Poiché i gestori eventi per gli elementi del modulo vengono spesso creati automaticamente, il blocco corrispondente viene posizionato per ultimo, in modo da non trascinare ciascun gestore in un'altra posizione nel modulo.

• Opzione grafica: mostra chiaramente il flusso principale di esecuzione.
• L'opzione testo è un esempio di modello di progettazione per inserire rapidamente una struttura in un nuovo modulo modulo.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Data=""/> // <Описание> // // /////////////////////////////////////////////// // /////////////////////////// // VARIABILI DEL MODULO ///////////////// // ///////////////////////////////////////////// //// ////////// // SUL SERVER //******* EVENTI SUL SERVER ******* &Sulla procedura del server quando viene creata sul server (errore, elaborazione standard) / /Inserire il contenuto del gestore Fine procedura //******* INTERFACCIA DI ACCESSO REMOTO ******* //******* LOGICA BUSINESS SUL SERVER ******* ///////// //////////////////////////////////////// /////// //////////////////// // METODI COMUNI DI CLIENT E SERVER /////////////// /////// ////////////////////////////////////////// ///// //////// // SUL CLIENTE //******* LOGICA AZIENDALE SUL CLIENTE ******* //******* TEAM * ****** //******** EVENTI CLIENTI ******* /////////////////////////// ///// //////////////////////////////////////////// // / / PRINCIPALI OPERATORI DEL PROGRAMMA

Domande correlate

• Opzioni di implementazione dell'interfaccia di accesso remoto. Asincronia, livello di dettaglio...
• Memorizzazione nella cache. 1C ha preso una decisione architettonica infruttuosa, introducendo la memorizzazione nella cache solo a livello di metodi di chiamata di moduli comuni e non fornendo funzionalità di controllo (tempo di pertinenza, ripristino su richiesta).
• Chiamate al server implicite. Non dimenticare le caratteristiche tecnologiche: molte operazioni “innocue” sul client provocano il contatto della piattaforma con il server.

Il modulo viene controllato tramite diversi elementi del modulo, posizionati gerarchicamente nella scheda Elementi progettista di forme. L'elemento più importante è la forma stessa, che si trova in cima alla gerarchia degli elementi, e gli altri elementi sono subordinati ad essa.

Tutti gli elementi del modulo possono essere divisi in cinque gruppi: campi, elementi di raggruppamento, pulsanti, decorazioni e tabelle. Nei miei articoli analizzerò ciascuno dei gruppi. In questo articolo inizieremo a studiare uno dei tipi di elemento di campo: campo di immissione, ma prima impareremo come aggiungere un elemento al modulo.

Aggiunta di elementi a un modulo

Questo viene fatto in modo abbastanza semplice: devi selezionare l'elemento Modulo nella finestra Elementi di progettazione del modulo e fare clic sul pulsante "Aggiungi". Successivamente si aprirà una finestra in cui è necessario selezionare il tipo di elemento desiderato

Dopo la selezione, nella finestra apparirà l'elemento desiderato Elementi.

Elemento del modulo gestito Campo

Diamo un'occhiata a un elemento del modulo gestito Campo. Questo elemento è necessario per inserire informazioni nel modulo. E anche per visualizzare qualsiasi informazione. Dopo aver aggiunto questo elemento al modulo, la tavolozza delle proprietà dell'elemento del modulo si aprirà sulla destra. Per ora, dovresti essere interessato a due proprietà: DataPath e View.

Nella proprietà DataPath, lo sviluppatore può associare un elemento del modulo all'attributo del modulo desiderato. Tieni presente che dopo che l'elemento è stato aggiunto Campo di immissione sul modulo non veniva visualizzato sul modulo stesso. Ciò è accaduto perché il nostro nuovo elemento non è associato a . Ad esempio, ho creato diversi attributi nel modulo di elaborazione con diversi tipi primitivi e un attributo con un tipo di riferimento.

Ora colleghiamo il nostro elemento del modulo aggiunto di recente con uno dei dettagli; per fare ciò, selezioniamo l'attributo desiderato dalla proprietà PathKData dell'elemento.

Successivamente, le proprietà DataPath e View verranno compilate e l'elemento stesso verrà visualizzato nella visualizzazione del modulo.

Presta attenzione alla proprietà dell'elemento Visualizzazione. Questa proprietà definisce la funzionalità del campo di input. È possibile selezionare diversi valori per questa proprietà.

A seconda del valore selezionato, verrà determinata la funzionalità. Nelle immagini sopra il valore selezionato è – campo di immissione, cioè. possiamo inserire qualsiasi valore in questo campo di input e se selezioniamo un valore campo etichetta, non saremo in grado di inserire nulla.

Questo valore della proprietà Visualizzazione I campi di input sono comodi da selezionare quando è necessario solo mostrare le informazioni della guida all'utente.

Ora aggiungiamo un nuovo elemento del modulo con type Campo di immissione e collegalo con gli oggetti di scena DettagliData attraverso la già familiare proprietà DataPath

Come puoi vedere, l'aspetto del campo di input è cambiato, e cambierà anche l'eventuale scelta dei valori per la proprietà View.

Pertanto, concludiamo che la funzionalità del campo di input dipende dal tipo di attributo.

Per oggetti di scena con tipo Booleano Saranno disponibili i seguenti valori della proprietà Visualizza.

E per gli attributi con un tipo di riferimento, saranno disponibili altri valori della proprietà View.

Un lavoro più dettagliato con gli elementi del modulo utilizzando esempi pratici è riportato nel libro “Nozioni di base sullo sviluppo in 1C: Taxi. Sviluppo di applicazioni gestite in 12 passaggi".

A volte sembra che imparare il linguaggio di programmazione in 1C sia complicato e difficile. In effetti, programmare in 1C è semplice. I miei libri ti aiuteranno a padroneggiare rapidamente e facilmente la programmazione in 1C: e "Nozioni di base sullo sviluppo in 1C: Taxi"

Impara a programmare in 1C con l'aiuto del mio libro “Programmare in 1C in 11 passi”

1. Nessun termine tecnico complicato.
2. Oltre 700 pagine di materiale pratico.
3. Ogni attività è accompagnata da un disegno (screenshot).
4. Una raccolta di problemi per i compiti.
5. Il libro è scritto in un linguaggio chiaro e semplice, per un principiante.

Questo libro è adatto a chi ha già iniziato a programmare e sta riscontrando alcune difficoltà con questo argomento e a chi programma da molto tempo, ma non ha mai lavorato con i moduli gestiti 1C.

1. Senza termini tecnici complessi;
2. Più di 600 pagine di materiale pratico;
3. Ogni esempio è accompagnato da un disegno (screenshot);
4. Il libro viene inviato via email in formato PDF. Può essere aperto su qualsiasi dispositivo!

Codice promozionale per uno sconto del 15% - 48PVXHeYu

Se questa lezione ti ha aiutato a risolvere qualche problema, ti è piaciuta o l'hai trovata utile, allora puoi sostenere il mio progetto donando qualsiasi importo:

Puoi pagare manualmente:

Yandex.Money - 410012882996301
Web Money - R955262494655

Unisciti ai miei gruppi.