Tehtävät ja kiellot: Webdynpro Context.

näyttää siltä, että näillä säännöillä pyritään suorituskyvyn parantamiseen.

minulla on muutamia huomioita parista näistä säännöistä:

• ilman mitään vaatimusta(käyttö useassa ohjaimessa) älä luo Kontekstia Komponenttiohjaimen tasolla, tarvittaessa luo paikallisia Konteksteja, esimerkiksi näkymissä

komponenttiohjain on keskeinen solmukohta kontekstiasi varten. Jos sinulla on milloin tahansa kontekstisolmu, joka jaetaan useiden näkymien kesken, sinun pitäisi luoda solmu komponenttiohjaimeen ja kartoittaa se muihin näkymiin.

tietylle näkymälle ominaiset solmut voidaan luoda suoraan näkymäkontekstiin, mutta luettavuuden ja yhdenmukaisuuden vuoksi päätän usein keskittää kaikki kontekstisolmut ja Toimitustavat komponenttiohjaimeen.

• käytä singleton-solmuja, jos ne ovat tarpeen

Singleton-solmut ovat hyviä suorituskyvyn kannalta, koska säilytät vain yhden ilmentymän solmustasi muistissa sen sijaan, että sinulla olisi useita esiintymiä jokaista (toimimatonta) pääkohdetta varten. Kuitenkin, sinun on parempi tietää, mitä olet tekemässä, koska jos tulet tilanteeseen, jossa tarvitset useita aktiivisia vanhemman elementtejä (rivi toistin, sisäkkäisiä taulukoita, puita, monivalintataulukoita… singleton node hylkää hakemuksesi.

jos et tunne singleton-solmujen periaatetta hyvin, tai kun suorituskyky ei ole ongelma, älä käytä singleton-solmuja.

• älä käytä dynaamisia määritteitä (IF_WD_CONTEXT_NODE_INFO – >ADD_ATTRIBUTE)

jos voit käyttää staattisesti määriteltyjä kontekstiominaisuuksia, käytä staattisia attribuutteja. Tulee kuitenkin tilanteita, joissa sinun täytyy dynaamisesti luoda oman kontekstin. Näissä tapauksissa sinulla ei ole muuta vaihtoehtoa kuin dynaamisten attribuuttien lisääminen. Olen kuitenkin samaa mieltä siitä, että sinun on vältettävä dynaamista kontekstiohjelmointia (ja dynaamista näkymäohjelmointia) mahdollisimman paljon.

• Bind_table

ei ole kova vaatimus, sisäisesti sidontaoperaatioissa käytetään move-vastaavaa ja pidetään alkuperäinen taulukko varjomuuttujana. Tosin move-vastaava on tiettävästi huono suoritus. (Sanon tiettävästi, koska olen tehnyt testejä itsestäni ja löytänyt mitään merkittävää eroa)

• Päivitä asiayhteys vain, jos tiedot todella on päivitettävä

riippuu siitä, mitä tarkoitat päivityksellä?

• Älä luo pitkiä kontekstikartoitusketjuja.

?

• käytä Kontekstimuutoksen lokitoimintoja tunnistaaksesi käyttäjän syöte. Tällä on erityisiä suorituskykyhyötyjä, kun sovelluksen käyttäjä muokkaa vain pientä määrää dataa näkymässä näyttäen samalla suuren määrän sekalaista dataa.

totta. Context changelog voi olla erittäin voimakas, kun sitä käytetään dynaamisesti.

, mutta se on myös hyvin kehittynyt. Minulla on katkelma käydä läpi kaikki muutokset kontekstissa, määrittää tiedot sopiva muuttuja avustusluokassa (kenttä rakenne, tai kenttä rivi sisäisessä taulukossa) ja dynaamisesti kutsua käsittelijä menetelmä (jos sellainen on olemassa). Jasin tämän pätkän kanssa paljon korkeasti koulutettuja kehittäjiä. Tähän mennessä vain 2 todella ymmärsi, mitä se teki, ja pystyivät soveltamaan sitä omiin komponentteihinsa.

mainitsemasi säännöt ovat tarpeeksi mielenkiintoisia, mutta kuten Steve mainitsi, saatat haluta tarkentaa tarkoitusta ja taustalla olevaa ajatusta.

Kippis!