Dos a nedělat: Webdynpro kontext.

zdá se mi, že tato pravidla jsou zaměřena na zlepšení výkonu.

mám několik poznámek k několika těmto pravidlům:

• bez jakéhokoliv požadavku(Použití ve více řadičích) nevytvářejte kontext na úrovni řadičů komponent, v případě potřeby vytvářejte lokální kontexty, například v pohledech

řadič komponent je vaším centrálním rozbočovačem pro váš kontext. Pokud máte kdykoli kontextový uzel, který je sdílen ve více pohledech, měli byste uzel vytvořit v řadiči komponent a mapovat jej do jiných pohledů.

uzly specifické pro určitý pohled mohou být vytvořeny přímo v kontextu zobrazení, ale pro čitelnost a uniformitu se často rozhoduji centralizovat všechny své kontextové uzly a metody napájení v řadiči komponent.

• použijte singletonové uzly, pokud jsou nutná hnízda (hlavní detail)

Singletonové uzly jsou dobré pro výkon, protože v paměti uchováváte pouze jednu instanci uzlu, spíše než mít více instancí pro každý (neaktivní) nadřazený objekt. Nicméně, raději vědět, co děláte, protože pokud se dostanete do situace, kdy budete potřebovat více aktivních nadřazených prvků (řádek opakovač, vnořené tabulky, stromy, multiselection tabulky…) uzel singleton vypíše vaši aplikaci.

pokud neznáte princip singletonových uzlů dobře, nebo pokud výkon není problém, nepoužívejte singletonové uzly.

• nepoužívejte dynamické atributy (IF_WD_CONTEXT_NODE_INFO – >ADD_ATTRIBUTE)

pokud můžete použít staticky definované atributy kontextu, použijte statické atributy. Budou však situace, kdy budete muset dynamicky vytvářet svůj kontext. V těchto případech nemáte jinou možnost než přidat dynamické atributy. Souhlasím však s tím, že se musíte co nejvíce vyhnout dynamickému kontextovému programování (a dynamickému programování).

• použití dat s kontextovou strukturou pro BIND_TABLE

není náročný požadavek, interně operace bind používají odpovídající přesun a ponechávají původní tabulku ve stínové proměnné. I když tah-odpovídající je údajně špatný pro výkon. (Říkám údajně, protože jsem provedl testy sebe sama a nemohl jsem najít žádný významný rozdíl)

• Aktualizujte kontext pouze v případě, že data musí být skutečně aktualizována

závisí na tom, co máte na mysli s aktualizací?

• nevytvářejte dlouhé řetězce mapování kontextu.

?

• k detekci vstupu uživatele použijte funkce protokolu změn kontextu. To má zvláštní výhody výkonu, zatímco uživatel aplikace upravuje pouze malé množství dat v zobrazení při zobrazování velkého množství smíšených dat.

pravda. Kontextový seznam změn může být velmi silný, pokud je používán dynamickým způsobem.

ale je to také velmi pokročilé. Mám úryvek projít všechny změny v kontextu, přiřadit data k příslušné proměnné ve třídě asistence (pole ve struktuře, nebo pole v řádku v interní tabulce) a dynamicky volat metodu handler (pokud existuje). Sdílel jsem tento úryvek se spoustou vysoce kvalifikovaných vývojářů. Až do dnešního dne pouze 2 skutečně pochopili, co to udělalo, a byli schopni je aplikovat na své vlastní komponenty.

pravidla, která zmiňujete, jsou dost zajímavá, ale stejně jako Steve zmínil, možná budete chtít rozvést účel a základní myšlenku.

na zdraví!