Do ‘s en Don’ ts: Webdynpro Context.

volgens mij zijn deze regels gericht op verbetering van de prestaties.

ik heb enkele opmerkingen over een aantal van deze regels:

• zonder enige vereiste(gebruik in meerdere controllers) maak geen Context in Component controller niveau, indien nodig maak lokale contexten, bijvoorbeeld, in weergaven

de component controller is uw centrale hub voor uw context. Als u op enig moment een contextknooppunt hebt dat over meerdere weergaven wordt gedeeld, moet u het knooppunt in de component controller maken en toewijzen aan andere weergaven.

knooppunten die specifiek zijn voor een bepaalde weergave kunnen direct in de weergavecontext worden aangemaakt, maar voor leesbaarheid en uniformiteit kies ik er vaak voor om al mijn contextknooppunten en leveringsmethoden te centraliseren in de component controller.

• gebruik singleton nodes als nestings (master detail) nodig zijn

Singleton nodes zijn goed voor de prestaties, omdat u slechts één instantie van uw node in het geheugen hebt, in plaats van meerdere instanties voor elk (inactief) ouder object. Echter, je beter weten wat je doet, want als je in de situatie komt waar je meerdere actieve ouder elementen nodig hebt (rij repeater, geneste tabellen, bomen, multiselectietabellen…) de singleton node zal uw toepassing te dumpen.

als u het principe van singleton nodes niet goed kent, of als prestaties geen probleem zijn, gebruik dan geen singleton nodes.

• geen dynamische attributen gebruiken (IF_WD_CONTEXT_NODE_INFO – >ADD_ATTRIBUTE)

als u statisch gedefinieerde contextattributen kunt gebruiken, gebruikt u statische attributen. Er zullen echter situaties zijn waarin je dynamisch je context moet creëren. In die gevallen hebt u geen andere keuze dan het toevoegen van dynamische attributen. Ik ben het er echter mee eens dat je dynamisch contextprogrammeren (en dynamisch zichtprogrammeren) zoveel mogelijk moet vermijden.

• gebruik data met context structuur voor BIND_TABLE

geen harde eis, intern gebruiken de bind operaties een move-corresponderende en houden de oorspronkelijke tabel in een schaduw variabele. Hoewel de move-overeenkomstige is naar verluidt slecht voor de prestaties. (Ik zeg naar verluidt, want Ik heb tests van mezelf gedaan en kon geen significant verschil vinden)

• de context alleen bijwerken als de gegevens daadwerkelijk moeten worden bijgewerkt

hangt af van wat u bedoelt met bijwerken?

• maak geen lange contexttoewijzingsketens.

?

• gebruik de Context Change Log functies om gebruikersinvoer te detecteren. Dit heeft bijzondere prestatievoordelen, terwijl een gebruiker van de toepassing wijzigt slechts een kleine hoeveelheid gegevens in een weergave, terwijl het weergeven van een grote hoeveelheid gemengde gegevens.

waar. De context changelog kan zeer krachtig zijn bij gebruik op een dynamische manier.

maar het is ook erg geavanceerd. Ik heb een fragment om alle wijzigingen in een context door te nemen, de gegevens toe te wijzen aan de juiste variabele in de assistentieklasse (veld in structuur, of veld in een rij in een interne tabel) en dynamisch een handler methode aan te roepen (als die bestaat). Ik deelde dit fragment met een heleboel zeer bekwame ontwikkelaars. Up – to-date, slechts 2 daadwerkelijk begrepen wat het deed, en waren in staat om het toe te passen op hun eigen componenten.

de regels die u noemt zijn interessant genoeg, maar zoals Steve al zei, Wilt u misschien het doel en het onderliggende idee toelichten.

Proost!