[MUZIKO Ludanta] 

ROB Bowden: Hi. Mi Rob, kaj mi esperas ke vi pretas meti stoko en ĉi solvo. Unue, ni rigardu registro. Do memoru, ke ĉi tie ni estas kontrolanta por vidi, ĉu formo estis afiŝis al tiu paĝo. 

Do unue ni iras fari estas iri al la alia. Kaj ni tuj redonu registrito formo. Do la registro formo tuj sendi al register.PHP. Kaj kio ĝi tuj sendas? Ĝi tuj sendos salutnomo kiun la uzanto tuj plenigi, pasvorto, kaj konfirmon - la pasvorto tajpita denove. 

Do nun kiam tiu formo estas sendita al register.PHP ni devos ekzekuti tiu se. Rigardante ĉi se ni estas unue tuj validigi la enigo. Ni volas certigi ke la uzantnomon kaj pasvorto ne estis malplena, kaj tiu la konfirmo reale matches la pasvorton. Iam ni kontrolis ke ni povas reale registras la uzanto. 

Kion tio signifas? Nu, ni volas enmeti la uzanton en nia datumbazo. Kaj ĉi tiu estas kiel ni faros tion. Do ni tuj enigi en la uzantoj tablo la kampoj uzulonomon, Baldaux, kaj mono. 

La defaŭlta valoro de mono tuj estos 10.000. Kaj ni tuj pasas kiel uzantnomo, username, tra la POST super tutmonda tio estas donita de la formularo. Kaj ni tuj ĉifri la pasvorton. 

Do se tiu okazis, tiam rezultas Estos ne-malvera. Se ĝi fiaskis, tiam ni volas pardonpeti. Io misokazis. Kaj kion povus esti irinta erara? 

Nu, ne bezonas esti unika uzantnomon. Kaj tial la demando povus esti maltrafinta se la uzantonomo jam ekzistis en la tabelo. Do alprenanta ĝi estis sola salutnomon, tiam ni tuj demandi ekpreni la ID de tiu uzanto. Memoru ke la ID estas auto-pliigante. 

Kaj do se tio okazas al malsukcesi pro iuj Tial, ĉar ni volas pardonpeti ke ni ne povis kapti la identigilo. Sed supozante, ke ĝi ne maltrafis, tiam Ni havigu la ID de kio la informpeto revenis, stoki, ke en nia kunsido - do ni volas saluti ĉi uzanto tra stoki la ID en la kunsido super tutmonda, kaj fine redirekti al nia katalogo. Kaj tio estas por registro. 

Nun ni tuj pluiri al citaĵo. Do citaĵo tuj havos vere simila aro supren. Oni vidas ĉi tie ke tiu estas la kodo kiun ni tuj faros kiam formo estas afiŝis al tiu paĝo. Sed unue ni efektive havas por repagi, ke formo. Do prenante rigardu citaĵo formon, kio kampoj estas tie? 

Ni vidas ke ĉiuj citaĵo tio estas ununura tekstujon kun la nomo simbolo. Kaj do kiam citaĵo formo afiŝis al quote.PHP ni nun tuj ekzekuti tiu kodo. Kaj la sola variablo en nia POST super tutmonda tuj estos simbolo. 

Ni validigi ke por certigi ke ili efektive eldonis la simbolo. Kaj se ili ne faris tion, ni diras al vi devas havigi simbolo. Supozante ke ili faris ofertas simbolo, ni rigardas supren, ke simbolo. 

Nun memoru ke rigardon supren havu malsukcesis pro tio, nu, eble tio ne estis valida simbolo por komenci. Do, se tio aspektas supren reveno falsa, ni volas pardonpeti ke la simbolo ne estas trovita. Iam ni trovis la simbolon, nun ni povas repagi la quote.PHP ŝablono. 

Kion tio aspektas? Tio simple intencas presi tiun parton sendistinge karceron nomo estis valoras nenial la stoko prezo estas. Nun kial oni uzas ĉi htmlspecialchars funkcias? Tio estas ĉar la stoko nomo kaj simbolo povus reale enhavi specialajn karaktrojn kiuj ne devus esti interpretita kiel HTML. 

Enorde, do tio estas por citaĵo. Nun ni volas rigardi index.php kaj biletujon. Sed unue ni reale bezonas konstrui la tekon tablo. Jen kiel ni tuj faros. 

Do ni rigardu la strukturo. Kaj ni vidas, ke la tekon tablo tuj havi ID. Do tiu tuj estos la uzanto ID tio estas la enmeto de la agoj. Ni havas simbolon, kiu tuj estos la simbolo de la kompanio kiun ni estas enmeto de la agoj por. Kaj tiam la agoj estas la nombro de agoj kiuj estas enmetitaj. 

Do memoru, ke po la pset spec, ni specifi ke IRU kaj simbolo - Ni kontrolu indeksoj, ID kaj simbolo estas la primara ŝlosilo. Do oni uzantidentigilon kaj simbolo parado devus nur aperas sola tempo en tiu tabelo. Nun ni rigardu la kodon. 

Do nun index.php tuj kapti tutan de nia biletujo informojn kaj montri ĝin al la uzanto. Do unue, ni tuj havigu la kontanta mono ke la uzanto aktuale havas de la kontanta tablo. Memoru, ke informpeto ĉiam tuj reveni tabelo de arrays. Do eĉ se ni nur selektitaj kontanta el unusola vico, ni ankoraŭ bezonas grab ke mono per indeksante en la nula indekso de vicoj kaj ekkaptis la kontanta indekso. 

Do nun ni volas elekti ĉiujn informoj el la tekon tablo tio estas grava por la aktuale ensalutinta uzanto. Ni kompreneble necesas validigi ke ke efektive okazis, kio ni devus ĉiam faras kiam ajn ni demandi. Iam ni devas ĉiuj de tiu informo, la pset spec informas nin, ke ni devus fari ĉi celo nicely stoki ĉiuj de la informo en tiu pozicioj tabelo. 

Do ni looping super ĉiuj el la biletujo informoj, suprenrigardante la stock asociita kun ĉiu vico en la biletujo informon, kaj poste stokante en la pozicio vestu la nomo, prezo, agoj kaj simbolo ĉiuj asociitaj kun tiu stoko. Kaj fine, ni tuj redonu portfolio.PHP, pasante en la kvanto kontanta mono ni havas nuntempe, la pozicioj tabelo, ke ni simple konstruita, kaj la titolo de ĉi tiu paĝon, kiu estos biletujo. 

Ni rigardu portfolio.PHP. Kaj ni vidas, ke la granda interesa parto estas tiu buklo. Do ni looping super la pozicioj tabelo, kreante tablo, kie tiu tablo - ni popoli ĉiu vico kun la informo, ke ni metu ene de la pozicioj tabelo. 

Denove, ni bezonas uzi htmlspecialchars en la okazo ĉi simbolo aŭ la nomo enhavas HTML signojn. Kaj ĉi tie ni estas multiplikante la prezo kaj la la kvanto de agoj kiujn ni havas la celo akiri kiom tio aktuale valoras por la uzanto. Kaj tio estas por biletujo. 

Nun ni rigardu vendi. Do sell tuj reiri al la formato kiun ni havis en register.PHP. Ni vidas, ke tiu formo estas iri esti sendita al cxi tiu pagxo. Sed unue, kiam ni ŝarĝas la paĝon, ni tuj faros. 

Do kio estas cxi tiu faris? Nu, ni povus simple havi la sell paĝo havi solan tekston skatolo, ke la uzanto eniras ĉi simbolo kiu ni volas vendi. Sed ni tuj esti iom pli ruza kaj ni tuj havos guto malsupren kiu permesas al la uzanto elekti reala simboloj kiujn ili jam posedas. 

Do ni ricevas la uzanto biletujo. Ni tuj elektu el tekon ĉiuj el la simboloj kiujn la uzanto aktuale havas, la nune ensalutinta uzanto. Certiĝu ke tio sukcesis. Kaj nun ni iras al buklo super la Revenis informojn, simple grabbing ĉiu simbolo, kaj stokante ĝin en ĉi simboloj tabelo. 

Kaj nun ni iras al redonu la sell formo. Do la sell formo tuj ĝuste esti falmenuo, unuaranga. Kaj ĉiun opcion en la sell formo estas tuj ĝuste presi la simbolo ke ni kaptis el la tekon tablo. 

Do la sell formo tuj submit reen al sell.PHP. Rigardante sell.PHP, ĉi tiu estas la kodo ke tuj ekzekuti kiam ni submit al tiu ĉi paĝo. Ni deziras validigi ke la uzanto efektive eniris simbolo. 

Nun supozante, ke ili faris - do nun ni volas determini kiom da dividu la uzanto estas efektive vendas kaj kiom da mono la uzanto devus akiri por vendi, ke multaj agoj. Do ni havigu la nombro de agoj kiuj La uzanto havas por tiu simbolo. Ni rigardis supren en teko por la donita de uzanto kaj la donita simbolo. 

Nun certiĝi ke tiu fakte Revenis vico. Ĉar se ne, la uzanto ne efektive havas tiun simbolon por vendi. Supozante ke ili ja havas tiun simbolon, Ni deziras kapti la nombro de agoj kiujn ili havas. Kaj nun ni volas rigardi supren kiom multe ĉiun parton valoras. 

Do ni uzis la rigardi supren funkcio. Ni rigardis supren la valoro de la simbolo. Supozante ke la rigardon supren sukcesis, nun ni iras al reale ĝisdatigi ĉiujn la informo. Do ni volas forigi el tekon la agoj kiujn ni vendas. Ni volas aktualigi la uzanto kvanto da mono. 

Kaj ni ĝisdatigi ĝin per agoj tempoj la stoko prezo - tiel ke estas kiom da mono la uzanto ĵus faris. Kaj nun ni volas aktualigi nian historion. Do ni ne prenis rigardo ĉe la historio tabelo ankoraŭ. Do ni revenu al tio. 

Nun fine ni tuj ridirektanta Reen al la biletujo. Nun ni rigardu buy. Do, aĉeti devus esti bela simila por vendi. 

Ni vidas, ke ni denove irante kontroli por vidi, ĉu ni estas Sendante al tiu paĝo. Supozante, ke ni ne, ke ni estas tuj ŝarĝi la aĉeto formo. Do kion signifas la aĉeto formo aspektas kiel? 

Oni vidas ĉi tie estas nur kutima formi ke tuj submit reen al buy.PHP. Kaj ĝi tuj devos simbolon kiu la uzanto estas enirinte, la nombro de agoj, ke la uzanto volas aĉeti de tiu simbolo, kaj tio estas ĝi. Do kiam ni submit reen al buy.PHP, ni estas nun tuj ekzekuti tiu kodo. 

Ni denove deziras validigi ke la uzanto eniris io validas. Do jen ni cerciorándose ili efektive eniris simbolo. Ĉi tie ni certigante ke ili efektive eniris agoj. Kaj ĉi tie ni estas certigi, ke ili eniris entjero por agoj, tiel ili ne provas aĉeti ABC agoj. 

Nun ni volas serĉi la prezo de la simbolo tiom ni scias kiom da mono ni devus subtrahi de la uzanto. Nun ni devos elekti kiom da mono la uzanto vere havas kaj certigi ke kiuj sukcesis. Ĉi tie ni kaptante la kontanta. Kaj nun jen, ni estas certigi ke la uzanto havas sufiĉan monon. 

Do, se la nombro de agoj de la uzanto volas aĉeti fojoj la prezo de ĉiu de tiuj agoj estas pli granda ol la kvanto da mono kiun ni havas, tiam la uzanto ne povas pagi tio. Supozante ke la uzanto havas sufiĉan monon, Nun ni volas enmeti en la uzanto biletujo. Nu, ni devos enmeti al la uzanto biletujo se ĉi tio okazas al esti la unuafoje la uzanto estas aĉetanta ke aparta simbolo. 

Sed kion se ili jam okazi havi iom da Apple stoko? Nu, nun ni estas farante uzon de la sur duobligi klavo ĝisdatigo komunikaĵo. Do tiu estas kial antaŭaj ni specifis ke ID kaj simbolo devas esti komuna primara tonalo, tiel ke se ni klopodos enmetas ID kaj simbolo kiu estas jam ekzistas, ni ĵus ĝisdatigis la agoj al inkluzivi la novaj agoj kiujn la uzanto estas aĉeti. 

Nun ni volas aktualigi la kvanto de kontanta mono, ke la uzanto havas, ĉar ili nur elspezis iom da mono en tiuj agoj. Kaj fine, ni devos ĝisdatigi la historio tablo denove. Kiu, denove, ni rigardu ĉe en sekundo. Kaj fine ni ridirektanta Reen al portfolio.PHP. 

Do ni rigardu la historio tablo. Nun memoru, ke la historio tablo estas supozis konservi spuron de ĉiu aĉeto kaj Vendas ke ĉiuj uzantoj fari, ne nur la aktuala nombro de agoj, ke la uzantoj havas, kiu estas kio biletujo estas por. Do ni konservanta trako de la uzanto, kiu Estas aĉeti aŭ vendi, ĉu tiun apartan transakcion estis buy aux vendi, la simbolo kiu estas estante aĉetis aŭ venditaj, la nombro de agoj ke ni aĉeti aŭ vendi, la prezo de unu sola porcion tio estas estante aĉetis aŭ venditaj, kaj fine, la tempon ke ĉi aĉetado aŭ vendado estas okazanta. 

Kaj tio estas ĉiuj la historio informoj kiujn ni bezonas spuri. Do kiam ni rigardis vendi, ni vidis, ke ni estis la enmeto en la historio sell, kiel ĉu ni aĉeti aŭ vendi, la nuna tempo sigelilo, kaj la aktuala uzulo, la simbolo kiu estas estante venditaj, la nombro de agoj kiuj estas esti venditaj, kaj la prezo de la trunko ĉe ĉi tiu tempo. Simile, en aĉeto, ĝi malebligos aspektas preskaŭ la samaj. La sola diferenco estas anstataŭ de vendado, ni aĉetas. 

Do en vendi kaj aĉeti, ni enmeto en la historioj tablo ĉiuj aĉetas kaj vendas kiuj okazas. Do ĉiuj history.PHP bezonas fari estas grab la informo de la historio tablo, certigu ke ĝi okazis, kaj redonu tiun informon. Do rigardante la history.PHP ŝablono, la interesaj informoj estas korekta ĉi tie. 

Ni looping super ĉiuj el la transakcioj, printado, ĉu tiu Estis acxeti aux vendi, formatting dato tempon ke ni faris ĉi transakcio. Memori ni bezonas uzi htmlspecialchars sur la simbolo, ĉiaokaze. Kaj fine, formatting la nombro de agojn, kiuj aĉetis kaj la prezo de sola parton en tiu tempo. 

Kaj tio montras ĉiujn el la historio informo kiun ni bezonas. Kaj tio estas por ĉi pset. Mia nomo estas Rob, kaj ĉi Estis CS50 Financoj.