Cosa fare e cosa non fare: Contesto Webdynpro.

Mi sembra che queste regole siano finalizzate al miglioramento delle prestazioni.

Ho alcune osservazioni su un paio di queste regole:

• Senza alcun requisito (uso in più controller) non creare contesto a livello di controller componente, se necessario creare contesti locali, ad esempio, in viste

Il controller componente è il tuo hub centrale per il tuo contesto. Se in qualsiasi momento si dispone di un nodo di contesto condiviso su più viste, è necessario creare il nodo nel controller del componente e mapparlo ad altre viste.

I nodi specifici per una determinata vista possono essere creati direttamente sul contesto della vista, ma per leggibilità e uniformità, spesso scelgo di centralizzare tutti i miei nodi di contesto e fornire metodi nel controller del componente.

• Utilizzare i nodi singleton se sono necessari nesting (dettaglio master)

I nodi Singleton sono buoni per le prestazioni, perché si mantiene solo un’istanza del nodo in memoria, piuttosto che avere più istanze per ogni oggetto genitore (inattivo). Tuttavia, è meglio sapere cosa stai facendo perché se ti trovi nella situazione in cui hai bisogno di più elementi padre attivi (ripetitore di righe, tabelle nidificate, alberi, tabelle multiselection…) il nodo singleton scaricherà la tua applicazione.

Se non si conosce bene il principio dei nodi singleton o quando le prestazioni non sono un problema, non utilizzare i nodi singleton.

• Non utilizzare attributi dinamici (IF_WD_CONTEXT_NODE_INFO-> ADD_ATTRIBUTE)

Se è possibile utilizzare gli attributi di contesto definiti staticamente, utilizzare gli attributi statici. Ci saranno tuttavia situazioni in cui devi creare dinamicamente il tuo contesto. In questi casi, non hai altra scelta che aggiungere attributi dinamici. Sono comunque d’accordo sul fatto che è necessario evitare il più possibile la programmazione dinamica del contesto (e la programmazione dinamica della vista).

• Utilizzare i dati con la struttura del contesto per BIND_TABLE

Non è un requisito difficile, internamente, le operazioni di bind utilizzano un corrispondente allo spostamento e mantengono la tabella originale in una variabile shadow. Anche se la mossa corrispondente è riferito male per le prestazioni. (Dico riferito, perché ho fatto test di me stesso e non ho trovato alcuna differenza significativa)

• Aggiorna il contesto solo se i dati devono effettivamente essere aggiornati

Dipende da cosa intendi con aggiornamento?

• Non creare lunghe catene di mappatura del contesto.

?

• Utilizzare le funzioni di registro delle modifiche di contesto per rilevare l’input dell’utente. Questo ha particolari vantaggi in termini di prestazioni, mentre un utente dell’applicazione modifica solo una piccola quantità di dati in una vista durante la visualizzazione di una grande quantità di dati misti.

Vero. Il changelog di contesto può essere molto potente se utilizzato in modo dinamico.

Ma è anche molto avanzato. Ho uno snippet per passare attraverso tutte le modifiche in un contesto, assegnare i dati alla variabile appropriata nella classe assistance (campo in struttura o campo in una riga in una tabella interna) e chiamare dinamicamente un metodo del gestore (se ne esiste uno). Ho condiviso questo frammento con un sacco di sviluppatori altamente qualificati. Fino ad oggi, solo 2 ha effettivamente capito cosa ha fatto e sono stati in grado di applicarlo sui propri componenti.

Le regole menzionate sono abbastanza interessanti, ma come Steve ha menzionato, potresti voler approfondire lo scopo e l’idea sottostante.

Salute!