Dos și Interdicții: contextul Webdynpro.

mi se pare că aceste reguli vizează îmbunătățirea performanței.

am câteva observații cu privire la câteva dintre aceste reguli:

• fără nicio cerință (utilizare în controler multiplu) nu creați Context în nivelul controlerului de componente, dacă este necesar creați contexte locale, de exemplu, în vizualizări

controlerul de componente este hub-ul dvs. central pentru contextul dvs. Dacă în orice moment, aveți un nod de context care este partajat pe mai multe vizualizări, ar trebui să creați nodul în controlerul de componente și să îl mapați la alte vizualizări.

nodurile specifice unei anumite vizualizări pot fi create direct în contextul vizualizării, dar pentru lizibilitate și uniformitate, aleg adesea să centralizez toate nodurile mele de context și metodele de furnizare din controlerul componentelor.

• utilizați noduri singleton dacă sunt necesare cuibări(detaliu principal)

nodurile Singleton sunt bune pentru performanță, deoarece păstrați o singură instanță a nodului dvs. în memorie, mai degrabă decât să aveți mai multe instanțe pentru fiecare obiect părinte (inactiv). Cu toate acestea, ar fi bine să știți ce faceți, deoarece dacă veniți în situația în care aveți nevoie de mai multe elemente părinte active (repetor de rânduri, tabele imbricate, copaci, tabele multiselecție…) nodul singleton va arunca cererea dumneavoastră.

dacă nu cunoașteți bine principiul nodurilor singleton sau când performanța nu este o problemă, nu utilizați noduri singleton.

• nu utilizați atribute dinamice (IF_WD_CONTEXT_NODE_INFO – > ADD_ATTRIBUTE)

dacă puteți utiliza atribute de context definite static, atunci utilizați atribute statice. Cu toate acestea, vor exista situații în care trebuie să vă creați dinamic contextul. În aceste cazuri, nu aveți altă opțiune decât adăugarea de atribute dinamice. Cu toate acestea, sunt de acord că trebuie să evitați programarea dinamică a contextului (și programarea dinamică a vizualizării) cât mai mult posibil.

• Utilizați date cu structura context pentru BIND_TABLE

nu este o cerință greu, pe plan intern, operațiunile bind utiliza o mișcare corespunzătoare și să păstreze tabelul original într-o variabilă umbră. Deși se pare că mișcarea corespunzătoare este proastă pentru performanță. (Spun relatărilor, pentru că am făcut teste de mine și nu a putut găsi nici o diferență semnificativă)

• actualizați contextul numai dacă datele trebuie să fie actualizate

depinde de ce vrei să spui cu actualizarea?

• nu creați lanțuri lungi de cartografiere a contextului.

?

• utilizați funcțiile de jurnal de schimbare a contextului pentru a detecta intrarea utilizatorului. Acest lucru are beneficii speciale de performanță în timp ce un utilizator al aplicației modifică doar o cantitate mică de date într-o vizualizare în timp ce afișează o cantitate mare de date mixte.

adevărat. Changelog context poate fi foarte puternic atunci când este utilizat într-un mod dinamic.

dar este, de asemenea, foarte avansat. Am un fragment pentru a parcurge toate modificările dintr-un context, pentru a atribui datele variabilei corespunzătoare din clasa de asistență (câmp în structură sau câmp într-un rând într-un tabel intern) și pentru a apela dinamic o metodă handler (dacă există). Am împărtășit acest fragment cu o mulțime de dezvoltatori cu înaltă calificare. Până în prezent, doar 2 au înțeles de fapt ce a făcut și au fost capabili să o aplice pe propriile componente.

Regulile pe care le menționați sunt destul de interesante, dar, așa cum a menționat Steve, poate doriți să elaborați scopul și ideea de bază.

noroc!