Dos and Don’ts: Webdynpro Context.

wydaje mi się, że te zasady mają na celu poprawę wydajności.

mam kilka uwag na temat kilku tych zasad:

• bez żadnych wymagań (użyj w wielu kontrolerach) nie twórz kontekstu na poziomie kontrolera komponentów, jeśli jest to wymagane twórz konteksty lokalne, na przykład w widokach

kontroler komponentów jest centralnym hubem dla kontekstu. Jeśli w dowolnym momencie masz węzeł kontekstowy, który jest współdzielony przez wiele widoków, powinieneś utworzyć węzeł w kontrolerze komponentu i zmapować go do innych widoków.

węzły specyficzne dla określonego widoku mogą być tworzone bezpośrednio w kontekście widoku, ale dla czytelności i jednolitości często decyduję się na scentralizowanie wszystkich moich węzłów kontekstowych i metod dostarczania w kontrolerze komponentu.

• używaj węzłów singleton, jeśli nestingi (szczegóły główne) są konieczne

węzły Singleton są dobre dla wydajności, ponieważ przechowujesz tylko jedną instancję węzła w pamięci, zamiast mieć wiele instancji dla każdego (nieaktywnego) obiektu nadrzędnego. Jednak lepiej wiesz, co robisz, ponieważ jeśli znajdziesz się w sytuacji, w której potrzebujesz wielu aktywnych elementów nadrzędnych (repeater wierszy, zagnieżdżone tabele, drzewa, tabele wielu wyborów…) węzeł singleton zrzuci Twoją aplikację.

jeśli nie znasz dobrze Zasady singleton nodes lub gdy wydajność nie jest problemem, nie używaj singleton nodes.

• nie używaj atrybutów dynamicznych (IF_WD_CONTEXT_NODE_INFO – >ADD_ATTRIBUTE)

jeśli możesz użyć statycznie zdefiniowanych atrybutów kontekstowych, użyj atrybutów statycznych. Będą jednak sytuacje, w których będziesz musiał dynamicznie kreować swój kontekst. W takich przypadkach nie ma innego wyboru niż dodanie dynamicznych atrybutów. Zgadzam się jednak, że należy unikać dynamicznego programowania kontekstowego (i dynamicznego programowania widoków) w jak największym stopniu.

• Użyj danych ze strukturą kontekstową dla BIND_TABLE

nie jest to trudne Wymaganie, wewnętrznie operacje wiązania używają odpowiadających ruchom i utrzymują oryginalną tabelę w zmiennej cienia. Chociaż ruch odpowiadający jest podobno zły dla wydajności. (Mówię podobno, bo sam zrobiłem testy i nie mogłem znaleźć żadnej znaczącej różnicy)

• zaktualizuj kontekst tylko wtedy, gdy dane faktycznie muszą zostać zaktualizowane

zależy, co masz na myśli z aktualizacją?

• nie tworzy długich łańcuchów mapowania kontekstowego.

?

• Użyj funkcji dziennika zmian kontekstu, aby wykryć dane wejściowe użytkownika. Ma to szczególne zalety wydajności, podczas gdy użytkownik aplikacji modyfikuje tylko niewielką ilość danych w widoku, wyświetlając dużą ilość mieszanych danych.

True. Dziennik zmian kontekstu może być bardzo potężny, gdy jest używany w sposób dynamiczny.

ale jest też bardzo zaawansowany. Mam fragment, aby przejść przez wszystkie zmiany w kontekście, przypisać dane do odpowiedniej zmiennej w klasie assistance (pole w strukturze lub pole w wierszu w wewnętrznej tabeli) i dynamicznie wywołać metodę obsługi (jeśli taka istnieje). Udostępniłem ten fragment wielu wysoko wykwalifikowanym programistom. Do tej pory tylko 2 rzeczywiście rozumiał, co robi i były w stanie zastosować go na własnych komponentach.

Zasady, o których wspomniałeś, są wystarczająco interesujące, ale jak wspomniał Steve, możesz chcieć rozwinąć cel i podstawową ideę.

zdrówko!