Dos och inte göra: Webdynpro sammanhang.

det ser ut för mig att dessa regler syftar till prestandaförbättring.

jag har några kommentarer om ett par av dessa regler:

• utan något krav(använd i flera kontroller) skapa inte kontext på Komponentkontrollnivå, om det behövs skapa lokala sammanhang, till exempel i vyer

komponentkontrollen är ditt centrala nav för ditt sammanhang. Om du vid något tillfälle har en kontextnod som delas över flera vyer, bör du skapa noden i komponentkontrollen och mappa den till andra vyer.

noder som är specifika för en viss vy kan skapas direkt i vykontexten, men för läsbarhet och uniformitet väljer jag ofta att centralisera alla mina kontextnoder och leveransmetoder i komponentstyrenheten.

• använd singleton-noder om nestings (master detail) är nödvändiga

Singleton-noder är bra för prestanda, eftersom du bara behåller en instans av din nod i minnet, snarare än att ha flera instanser för varje (inaktivt) överordnat objekt. Men du vet bättre vad du gör för om du kommer i en situation där du behöver flera aktiva överordnade element (rad repeater, kapslade tabeller, träd, flervalstabeller…) singleton noden kommer att dumpa din ansökan.

om du inte känner till principen om singleton-noder väl, eller när prestanda inte är ett problem, använd inte singleton-noder.

• använd inte dynamiska attribut (IF_WD_CONTEXT_NODE_INFO – > ADD_ATTRIBUTE)

om du kan använda statiskt definierade kontextattribut använder du statiska attribut. Det kommer dock att finnas situationer där du måste skapa ditt sammanhang dynamiskt. I dessa fall har du inget annat val än att lägga till dynamiska attribut. Jag håller dock med om att du måste undvika dynamisk kontextprogrammering (och dynamisk vyprogrammering) så mycket som möjligt.

• Använd data med kontextstruktur för BIND_TABLE

inte ett hårt krav, internt använder bindningsoperationerna ett drag-motsvarande och behåller originaltabellen i en skuggvariabel. Även om flytten-motsvarande är enligt uppgift dåligt för prestanda. (Jag säger enligt uppgift, för att jag har gjort tester av mig själv och inte kunde hitta någon signifikant skillnad)

• uppdatera sammanhanget endast om data faktiskt måste uppdateras

beror på vad menar du med uppdatering?

• skapa inte långa kontextmappningskedjor.

?

• använd Kontextändringsloggfunktionerna för att upptäcka användarinmatning. Detta har särskilda prestandafördelar medan en användare av programmet ändrar endast en liten mängd data i en vy samtidigt visa en stor mängd blandade data.

Sant. Kontextändringsloggen kan vara mycket kraftfull när den används på ett dynamiskt sätt.

men det är också mycket avancerat. Jag har ett utdrag för att gå igenom alla ändringar i ett sammanhang, tilldela data till lämplig variabel i assistansklassen (fält i struktur eller fält i rad i en intern tabell) och dynamiskt ringa en hanteringsmetod (om en finns). Jag delade detta utdrag med många högkvalificerade Utvecklare. Hittills förstod bara 2 faktiskt vad det gjorde och kunde tillämpa det på sina egna komponenter.

reglerna du nämner är intressanta nog, men som Steve nämnde kanske du vill utarbeta syftet och den underliggande tanken.

skål!