jb4

Mēs esam sarakstījuši funkciju bibliotēkas. Bibliotēkās ir funkcijas, kurām padod atsevišķus gaidītus parametrus un tad viņas apstrādā tos parametrus un izdara gaidītās lietas. Viss ir jauki, bet vienu dienu mēs gribam, lai šī funkcija ņem vērā tūkstoš citu lietu, kuras līdz šim neesam padevuši kā parametrus. Rakstīt jaunu funkcijas versiju, kur paredzēt jaunos parametrus? Tas, ka var iekļaut f-jā neparedzētu parametru apstrādi, nav gluds risinājums. Un tā katru dienu jaunu funkciju? Šīs problēmas risināšanai pēdējā laikā izmantoju šādu metodi: uzrakstu jaunu f-jas versiju ar diviem parametriem - $input un $handler, kur $input ir viss tradicionālais ievads un $handler ir nosaukums f-jai, kura interpretēs $input ņemot vērā visu iespējamo nevis tikai tos dažus parametrus, kurus padevām vecajai f-jas versijai. Tālāk piemērs kodā f-jai, kas no asociatīva masīva, kas veidots formā [value]=>label uzģenerē HTML formā noderīgu <option> elementu sarakstu: <?php // Tipiskas f-jas function optionsList($options,$value) { foreach ( $options as $optValue=>$optLabel ) { ?> <option value="<?=$optValue?>"<?=($optValue==$value)?' selected="selected"':''?>><?=$optLabel?></option> <?php } } // F-jas, kādas iesaku rakstīt function optionsList2($options,$value,$optionsHandler=null) { if ( is_null($optionsHandler) ) { foreach ( $options as $optValue=>$optLabel ) { ?> <option value="<?=$optValue?>"<?=($optValue==$value)?' selected="selected"':''?>><?=$optLabel?></option> <?php } } else { foreach ( $options as $option ) { list($optValue,$optLabel) = call_user_func($optionsHandler,$options); ?> <option value="<?=$optValue?>"<?=($optValue==$value)?' selected="selected"':''?>><?=$optLabel?></option> <?php } } } ?> Apdarinātāji (handlers) ir foršā padarīšana. Tā man izdodas saglabāt loģikas nodalījumu no vizualizēšanas. Lai kāds būtu izvads, šādām funkcijām padodu jēlus, neapstrādātus datus, jo tur, no kurienes, es viņas izsaucu, man nav laika speciāli taisīt tieši konkrētai vietai noformētus datus. Ja kādai vietai vajag speciāli noformētus datus, tad tos noformēsim caur apdarinātāju. Cerams, ka noder arī jums.

izlabots.

<select name="valsts"> <?php $valsts = 'est'; $masivs = array('lat'=>'Latvija','est'=>'Igaunija','lit'=>'Lietuva'); foreach ( $masivs as $optValue=>$optLabel ) { ?> <option value="<?=$optValue?>"<?=($valsts==$optValue)?' selected="selected"':''?>><?=$optLabel?></option> <?php } ?> </select>

Vecozēn, ja mans ūdens tev nav noderīgs, nedomā, ka tas citiem arī uzreiz nav noderīgs. forums - tas nav vienai dienai. Ja tu man tagad saki, ka tu ar iframe nodrošini pastāvīgi sakaru starp klientu un serveri, tad ej tu ar savām zināšanām bekot vai zini. slēp savus iframe un tik dragā. augstie kalni gaida, kad tu viņus gāzīsi. peace on earth vai kā tur tagad mēdz teikt.

Izklausās vilinoši, bet es neesmu gatavs nodot savu telefona numuru katram, kas tā pateiktu. Kādu uzņēmumu jūs pārstāvat vai, ja darbojaties individuāli, kā jūs sauc un kāda ir jūsu hostēšanas pieredze. Mana e-pasta adrese ir jaba [iekš] inbox [punkts] lv.

Ar latviešu valodas zināšanām var braukt tikai uz Zilupes teātra dienām. Ja grib programmēt, tad jāmācās angļu valoda. Te tāda pamācība, kas izpušķota ar daudzām ilustrācijām. Varbūt sapratīsiet: http://www.tanguay.at/installPhp5.php5?step=1

Tāda sīkdatne būs spēkā tikai līdz pārlūkprogrammas aizvēršanai. Aizveram pārlūkprogrammu, ejam atkal iekšā un še tev - balsojam vēlreiz.

Tu vēljoprojām neesi sapratis, kas ir PHP. PHP ir programmēšanas vide uz servera. Javascript - programmēšanas vide lietotāja pārlūkprogramma. Starp šīm divām vidēm pa vidu ir saziņas protokols (saziņas noteikumu kaudze), ko sauc par HTTP (hypertext transfer protocol). Šis te protokols paredz ļoti stingras klienta-servera attiecības. Klients ir tas, kas var tikai dabūt un var pieprasīt. Serveris ir tas, kas var uztvert pieprasīto, nosūtīt atbildi. Abi nav vienādās lomās! Ievēro. Serveris nevar no zila gaisa pieslēgties pie kaut kāda klienta un teikt viņam: vecīt, aizmirsti šito sīkdatni (cookie), atver te mums logu un apēd šito kūciņu. Tā tas nenotiek. Serveris klientam, rupji runājot, var nosūtīt tikai HTML kodu (es teicu - rupji runājot, tāpēc nepiekasieties). Tas HTML kods var saturēt Javascript, kurš, ja lietotājs ļaus, izpildīsies klientā, tas ir, lietotāja pārlūkprogrammā. Tava vienīgā iespēja kaut ko darīt uz lietotāja datora ir rakstīt Javascript. Tavu problēmu iespējams risināt, uzrakstot Javascriptā sīkdatņu izdzēsēju, ko iedarbina pie tā unonload notikuma. Pameklē tīmeklī Javascript (googlē rakstī kaut kādu "delete cookie javascript"), kas to dara - pats no galvas nezinu. Ne par tavu tēmu, bet lai tu zinātu: klients var pieslēgties serverim! Klients var nosūtīt kaut kādu pieprasījumu, bet tā ir servera darīšana, kā viņš to uztvers. Tāds čats HTTP protokolā reāli nav nemaz čats. Nav tā, ka tava pārlūkprogramma klausās, ko saka serveris un tad visus jaunos čata tekstus iedrukā tavā logā (runa nav par IRC, par IRC es nekā nezinu). Ir tā, ka tava pārlūkprogramma katru mīļu brīdi prasa serverim, vai ir kas jauns. Vai ir kas jauns? Vai ir kas jauns? Un tā visu laiku. Ja ir kas jauns, tad kaut kādā Javascript vai citā pārlūkprogrammas programmēšanas vidē tiek nodrošināts, ka tev tas parādās lapā ar rokām nemaz nespiežot nekādus refresh. Pameklē internetā Javascript+HTTPRequest (tieši vienā vārdā HTTPRequest) un tur izlēks labas lietas droši vien. Var rakstīt Javascript, kas pieslēdzas serverim un nolasa atbildes, bet lietotājs pa to laiku lapā nav spiedis nekādas podziņas!! Serveris, var noskaidrot, vai lietotājs ir atslēdzies, spriežot tā - ahā - lietotājs nav man neko prasījis jau veselu mūžību, tātad viņš ir miris, tātad viņa sesija ir dzēšama - tas ir tad, ja sesijas tiek glabātas kaut kur uz servera, piemēram, MySQL datubāzē. Šitais ir ļoti nesakārtoti uzrakstīts, bet doma bija lāpīt kaut kādus tavu zināšanu caurumus, ceru, ka uz dažiem trāpīju.

orion, nemāci citiem muļķības. viņš tev prasīja par cookies, tad atbildi par cookies. ja tev dzied par cookies erroru, tas nozīmē, ka tu esi nosūtījis lietotājam html kodu pirms šīm darbībām ar cookies. Sīkdatnes (cookies) ir jānosūta lietotājam pirms jebkāda html koda ģenerēšanas, jo sīkdatnes tiek ievietotas tam HTML kodam priekšā un pārlūkprogramma jaunās sīkdatņu vērtības meklē tikai HTML koda priekšā. Ja tu sūti kaut kur HTML koda vidū, pārlūkprogramma tās vairs nemeklē. Tāpēc PHP tev saka priekšā, ka nav vērts sūtīt, jo pārlūkprogramma to nesapratīs. Lai nosūtītu sīkdatnes pirms jebkāda HTML koda sūtīšanas, iespējami divi varianti: ideālais variants: vispirms veicam visas operācijas, kas nav saistītas ar HTML koda ģenerēšanu, tai skaitā, nosūtām sīkdatnes; pēc tam sākam ģenerēt HTML kodu. iesācēju variants: rakstām kā gribam, tikai koda sākumā ievietojam rindiņu ob_start(); šī rindiņa pasaka PHP, ka izdrukātais HTML kods nav uzreiz jāsūta pārlūkprogrammai, bet gan tikai tad, kad tu to norādīsi. Ja tu to speciāli nenorādīsi (skaties http://php.lv/ob_start), tad tas notiks PHP koda izpildes beigās. Līdz ar to, ja tu HTML koda ģenerēšanas vidū uztaisīsi setcookie(...), tad kļūdas nebūs, jo PHP varēs noformēt sīkdatni pirms HTML koda! Kad uzstādi sīkdatni, tad jālieto sekojošs pieraksts: setcookie('nosaukums','vērtība','laiks, cikos kļūt nederīgam','taciņa, kur tas ir spēkā'); Ja man vajadzētu glabāt cookie uz 1 minūti, es rakstītu: setcookie('kukijs','vērtība',time()+60,'/'); Saproti, no kurienes tas +60? Tas ir pašreizējam laikam pieskaitītas desmit sekundes. Jāzina viena lieta: kad kukijus glabā ar setcookie, tad $_COOKIE masīvā tos nemaz nevar uzreiz nolasīt! Tos var nolasīt tikai pēc vienas lapas pārlādes, jo tāds ir sīkdatņu princips - vispirms tās tiek uzstādītas uz lietotāja lapas un tikai tad, ja lietotājs nākamreiz pieprasot lapu, tās nosūtīs tev, tad tu iegūsi $_COOKIE masīvā attiecīgo vērtību. Piemēram, ja lietotājam nebūs atļauta sīkdatņu uzstādīšana, tad arī nākamreiz tu neko tai $_COOKIE masīvā nedabūsi. Es parasti pēc setcookie() vai nu ielieku attiecīgu vērtību ar rokām $_COOKIE masīvā vai arī (daudz labāks veids) veicu redirektu (tā, ka lietotājs vēlreiz pieprasa manu lapu un līdz ar to nosūta sīkdatnes man) ar šo rindiņu: header('Location: skripts.php'); Šo funkciju arī nevar izsaukt, ja esi jau nosūtījis pārlūkprogrammai HTML kodu. Tāpēc lieto ob_start() visu kodu sākumā.

Man liekas, ka tu citiem palīdzi, izmantojot zināšanas, ko iegūsti šajā forumā. Nu tas skrīnšots ir diezgan daiļrunīgs. Vai tev maksā par to atbildi?

Nav normālu līdzekļu, ar kuru palīdzību uz servera uzzināt brīdi, kad lietotājs aizver pārlūkprogrammu. HTTP protokols ir vienkāršs - lapa tiek pieprasīta, saņemta un savienojums izbeidzas. Lietotājs var tavā lapā sēdēt, neko neklikšķināt un brīnīties piecus gadus. Piecu gadu laikā tava lapa jau sen ir izdzēst un atslēga - nolauzta, bet lietotājs nezina! Jo pēc lapas ielādes nav sakaru starp tevi un viņu. Kad uzstāda sīkdatnes un nenorāda to darbības laiku, tad tām vajadzētu izdzēsties pēc pārlūkprogrammas aizvēršanas. Ja tev vajag izdzēst sesiju uzreiz pēc lapas ielādes, tad tev, acīmredzot, sesiju nevajag vispār vai arī tu nesaproti to būtību. Sesija ir līdzeklis pašreizējā stāvokļa uzglabāšanai vairāku lapu garumā. Ja tā ir tā lapa, kur lietotājs beidz darbu tavā sistēmā, tad tev kādā PHP skriptā jāievieto rindiņa session_destroy(). Un nevis HTML daļā, bet vēl pirms HTML ģenerēšanas. Ieliec visu savu skriptu sākumā rindiņu ob_start() un tad tu varēsi laikam session_destroy() izsaukt arī skripta beigās. Tikai neliec to nekādā onload notikumā iekš Javascript. onload notikumā var rakstīt tikai Javascript, bet tu ko ierakstīji?

Ja runa ir par MySQL tabulas lauciņa īpašību auto_increment, tad šī īpašība ir domāta, lai norādītu, ka lauciņā pie INSERT jāģenerē unikāls ID, kas ir automātiski par vienu lielāks nekā iepriekšējam šajā tabulā ievietotajam ierakstam. Ja iepriekš neviens ieraksts nav bijis, tad pēc noklusējuma tiek ievietota vērtība 1. Piemēram, rakstot INSERT pieprasījumu var rakstīt: INSERT INTO tabulasNosaukums (id,vards,uzvards) VALUES ('','Vārds','Uzvārds'); Kā redzams priekš 'id' lauciņa vērtība nav norādīta - tā tiek iegūta automātiski ar auto_increment. Ja man nebūtu auto_increment uzstādījums šim 'id' lauciņam, tad tur atkarībā no pieļaujamā datu tipa tiktu ievietota 0 vai tukšums.

Meklēju PHP5 hostingu Latvijā pie cilvēka, kas zina, ko dara hostinga lietās. Prasības: vieta 100 līdz 150MB, MySQL 4.1, PHP5.0.2->, PHP5 jābūt iekompilētiem vismaz sekojošiem extensions: iconv, tidy, mbstring, xsl, gd2, mysqli, pdf, zip, xmlreader, xmlwriter (no Pecl pakotnes). Jābūt iespējai kaut ko ielikt crontabā. Var nebūt SSH, SFTP gan varētu (bet pārdzīvošu, ja tikai FTP), jābūt ātram un stabilam pieslēgumam. Nekāda masu lapa nav paredzēta, pornogrāfijas nebūs. Maksāt varētu līdz 10Ls mēnesī. Tas būtu personīgi man.

!?! Tas tak nav specpasūtījums, bet gatavs produkts, kuru pērk simtiem cilvēku visā pasaulē. Uztaisīt Lāses piena pakas iepakojumu arī nevar par Ls0.45. Ja kas.

Eu, pacani. Ja vajag servakam OSi, es varu dabūt nullifie Windows 2004 Advanced Server versiju. Karoče zvaniet, sarunāsim. Komjunitī vārdā man nav žēl. p.s. te mums ir tie cilvēki, kurus sauc par latviešiem praktiskajiem.