2easy

a kāpēc, izvēloties kādu citu/tālāku filtru, pirmais būtu jāpazaudē? liec adresē arī iepriekšējos filtrus, un nekādus sesijas mainīgos tad nevajadzēs

es izmantoju konstanti piemēram, production versijā ir define('APP_URI', '/'); dev versijā uz localhost, kur ir vairāki projekti define('APP_URI', '/projekta-id/'); + vēl lietoju līdzīgas funkcijas kā marcis

relax edi, have fun

ja vajag tikai "pie lapas ielādes automātiski", tad vnk uzliec tagam atribūtus width vai height (var arī css) tu taču pats vari apskatīties source kaut vai savam postam un paexperimentēt vispār priekš tādām lietām iesaku uzinstalēt Firebug add-on. tad jebkurā sev interesējošā lapā varēsi viegli daudz ko uzzināt par jebkuru elementu (css un dom īpašības), uzklikšķinot tam ar peles labo pogu un izvēloties "Inspect Element" piemēram, tavai bildei šajā forumā html ir <img class="bbc_img resized" height="104" width="712" alt="Posted Image" src="http://bildites.lv/images/eqkca5ctayei35r6p8b.jpg" style="cursor: pointer;" origwidth="1485" origheight="217" shrunk="1" newwidth="712" newheight="104" handled="1"/> kur ar fiksētām dimensijām height="104" width="712" jau pietiek, lai browseris pats "pie lapas ielādes automātiski" resaizotu tavu bildi pēc klikšķa tiek izsaukta foruma funkcija ipb.global.enlargeImage(), kas nomaina dimensijas (iekš css) element.style { cursor:pointer; height:217px; width:1485px; } element.style { cursor:pointer; height:104px; width:712px; } thats it

laikam kārtējais piektklasnieks... un kādi jautājumi panesīsies, kad php sāks kļūt populārs arī bērnudārzā? :D

šāds varētu būt algoritms, kā sadalīt komandas pa laukumiem tā, lai tās neatkārtotos function arrSplitRand($a, $iParts) { // sadala masīva $a elementus $iParts daļās. izdod masīvu ar šo sadalījumu $iCnt = count($a); for ($i = 0; $i < $iCnt; $i++) { $j = array_rand($a); // uz random izvēlas kādu no atlikušajiem masīva elementiem (elementa indeksu) $a2[$i % $iParts][] = $a[$j]; // pievieno izvēlētā elementa vērtību jaunajā masīvā array_splice($a, $j, 1); // izņem šo elementu no masīva, lai tas vairs neatkārtotos } return $a2; } $aField = array('Laukums 1', 'Laukums 2', 'Laukums 3'); $aTeam = array('Komanda 1', 'Komanda 2', 'Komanda 3', 'Komanda 4', 'Komanda 5', 'Komanda 6'); $aTeamParts = arrSplitRand($aTeam, count($aField)); foreach ($aField as $k => $v) echo $v . ': ' . implode(', ', $aTeamParts[$k]) . '<br />'; /* Laukums 1: Komanda 5, Komanda 2 Laukums 2: Komanda 3, Komanda 6 Laukums 3: Komanda 1, Komanda 4 */

pēdiņas jau nav obligāti. ar apostrofiem tač arī viss strādā! varbūt tur tieši bija pateikts, ka var gan tā, gan tā? :D bet varbūt tajā grāmatā bija pārāk zamudrīts piemers, kur reg izteiksmē bija iebāzts kkāds mainīgais tipa "/$variable/" vai "/aaa{$variable}bbb/" un tad tā vērtību var dabūt tikai tad, ja apkārt ir pēdiņas...

konstrukcija doc.$imgSwaps nozīmē, ka objektam doc ir īpašība/property $imgSwaps funkcijā ImageSwap() tas ir nodefinēts 4. rindiņā ;) doc.$imgSwaps = new Array(); tobish, tas ir visparastākais masīvs! :)) ko vienkāršāk būtu pierakstīt doc.$imgSwaps = []; hmm, vispār jau funkcijas būtība ir funkcijas nosaukumā ;) bet konkrēti šai funkcijai padod bildes id un jauno src, un tā to nomainīs. savādi, ka tā neņem vērā pirmos 2 argumentus, tāpēc to izsauc šādi: SwapImage(0, 0, "bilde-1-id", "bilde-1-src", "bilde-2-id", "bilde-2-src", ...); (šo netestēju, tikai kodu izlasīju) pasaulē ir sarakstīts ļoti daudz koda ar n-tajiem workaroundiem priekš visādiem spec gadījumiem, un tevis iepostētais koda gabals tam ir piemērs, taču to mierīgi varētu aizvietot ar vienu rindiņu document.getElementById("bildes-id").src = "jaunais-src";

nju es, piemēram, aplikācijas init daļā izpildu define('IP', $_SERVER['REMOTE_ADDR']); un pēc tam lietoju konstanti IP visur kur vien vajag ip. man vimaz tā ir vienkāršāk un ātrāk. par tādu HTTP_CLIENT_IP vispār pirmā dzirdēšana! ;) uzgūglēju vienīgi to, ka tas ir extra headeris, ko dažreiz pievieno proxy. mb tas arī var noderēt. un tādā gadījumā īsto ip varētu iegūt ar echo isset($_SERVER['HTTP_CLIENT_IP']) ? $_SERVER['HTTP_CLIENT_IP'] : $_SERVER['REMOTE_ADDR']; bet es uz to bez īpašas vajadzības neiespringtu un paliktu pie vnk $_SERVER['REMOTE_ADDR']

pareizi, pareizi, waplet ^^ lasi domas :D

pēdējos 3 ciparus varētu "aizstāvēt" šādi $a = array('84.237.205.8', '84.237.205.88', '84.237.205.888'); foreach ($a as $v) echo substr($v, 0, -3) . '***' . '<br />'; /* 84.237.20*** 84.237.205*** 84.237.205.*** */ bet tā kā ip adreses pēdējā daļā var būt 1..3 cipari, tad pareizi būtu aizstāt visu daļu, nevis kkādu fiksētu ciparu skaitu $a = array('84.237.205.8', '84.237.205.88', '84.237.205.888'); foreach ($a as $v) { $aIp = explode('.', $v); $aIp[3] = '***'; echo implode('.', $aIp) . '<br />'; } /* 84.237.205.*** 84.237.205.*** 84.237.205.*** */

viss ir pareizi. utf8 kodējumā lv burti ar garum/mīkstinājum zīmēm aizņem 2 baitus (daaaaaaaaaa :D), bet ar $str[$x] no stringa var paņemt tikai 1 baitu. tāpēc lai to burtu varētu normāli attēlot, vajag pielikt klāt arī otru baitu... $str = "AĀBCČDEĒ"; $x=1; echo $str[$x] . $str[$x + 1];

viss ģeniālais ir vienkāršs ;)

hmm, tā kā validētiem/nevalidētiem lietotājiem ir (un arī turpmāk būs) vieni un tie paši lauki, tad tos droši var likt vienā tabulā, un filtrēt pēc bit tipa Valid lauka ar 0/1. no otras puses nevalidētos varētu nolikt atsevišķi, lai pie liela skaita nevalidēto lietotāju, netiktu pārāk tālu aizdzīts un mākslīgi uzpūsts AUTO_INCREMENT id (ja tam vispār ir kkāda nozīme). otrs piemērs, kad viena veida datus sadala pa vairākām tabulām ir arhivētie dati. tas gan vairāk attiecas uz precēm vai dokumentiem, ne lietotājiem. lai nu kā, es noteikti netaisītu otru tabulu tikai tāpēc, lai kkur SELECTam atvieglotu WHERE daļu :D arī vnk UPDATE ar SET Valid = 1 (drīzāk tas varētu būt tinyint tipa Status lauks, kas vēlāk var noderēt vēl kkam, un kur 0 ir tikai sākuma stāvoklis, tipa nevalidēts) man liekas daudz ērtāks risinājums nekā jau pievienota ieraksta kopēšana uz citu tabulu un dzēšana no iepriekšējās +1 vienai tabulai ;)

;) nju galvenais jau, ka viss strādā tā, kā vajag! vnk man no lietu loģikas likās, ka tā kā funkcija mysql_real_escape_string() ir domāta, lai sagatavotu vērtības priekš db query, tad to labāk izpildīt vēlāk varētu būt situācija, ka validācija neatļauj: \ lietotājs ievada: as"df tava validācija teiks: nava labi! jo echo mysql_real_escape_string('as"df'); // as\"df tobish var gadīties, ka kādā brīdī tev nāktos mazliet "pārkodēt" kādu savu ieradumu :D

hehe piekrītu 100%. ne jau visi atšķir terminus "funkcionālā programmēšana" un "procedurālā programmēšana". tik viegli kļūdīties, kad ir funkcijas, tad jau "funkcionālā" :D:D:D

try this '/^[a-z0-9._-]+$/i' starp citu mysql_real_escape_string() parasti pielieto tikai pašās beigās, kad izpilda db query. tobish pēc datu validācijas vai vēl kādas datu apstrādes

tas ir gaumes jautājums. jo īpaši ja tu viens pats taisi projektu un pats menedžē visu kodu. galvenais, savu kodu organizēt tā, lai pašam būtu ērti strādāt. ir viena kategorija cilvēku, kas beztolkā izmanto oop tikai tāpēc, ka tā ir krutāk, piemēram, taisa objektu ar statiskām metodēm, kur mierīgi var izmantot parastas funkcijas. vnk ja kādam patīk rakstīt par 30% vairāk, lai panāktu to pašu rezultātu, tad lai tā dara. protams, ir atsevišķi gadījumi, kur patiešām var izmantot manuprāt vienīgo oop fīču: mantošanu (inheritance), bet kodējot webu kkas tāds reti kad ir vajadzīgs. anyway to pašu efektu var panākt arī savādāk otra oop fīča datu abstrakcija (data abstraction/encapsulation) ir tīri koda menedžments, par ko jau es pieminēju sākumā, un var noderēt, kad projektu taisa komanda (5/10/50/... cilvēki). iespējams, tieši tāpēc oop koncepciju sākot no 60. gadiem sāka ieviest programmēšanas valodās, lai ar pašas programmēšanas valodas līdzekļiem/ierobežojumiem disciplinētu programmētājus, un tādā veidā samazinātu kļūdu varbūtību (un noturētu produkta kvalitāti) pildot lielus valdības un korporāciju pasūtījumus, kad pie projekta strādā simti un tūkstoši programmētāju. manuprāt izmantot oop vienkāršai weblapai ir pilnīgs overkills pēdējā oop fīča polimorfisms (polymorphism) vispār vairāk attiecas uz tādām valodām kā c/c++ (strongly typed language), jo php mainīgajam jau tāpat var būt dažādi datu tipi. līdz ar to šī oop fīča jau ir iebūvēta pašā valodā (patiesībā tā pat nav oop fīča bet programmēšanas valodas fīča attiecībā uz datu tipiem, lai gan to bieži piedēvē oop) karo4e oop ir ideāls priekš tiem, kam patīk objekti, interfeisi, un visādi abstrakcijas līmeņi. vienvārdsakot, lai sarežģītu vienkāršas lietas :D es patiešām respektēju oop, taču lietotu to tikai tajos gadījumos, kad tas man dotu reālus ieguvumus :)) ja tava prakse un veselais saprāts saka, ka procedurālā programmēšana tavā gadījumā ir izdevīgāka, tad tā arī dari ;) kiss (keep it small and simple)

^^

haha tomēr nevajadzēs pašam taisīt sortēšanu. php tiešām par visu ir padomāts :P array_multisort() ftw $a[] = array('a' => 'AAA1', 'b' => 'BBB1', 'c' => 2); $a[] = array('a' => 'AAA2', 'b' => 'BBB2', 'c' => 3); $a[] = array('a' => 'AAA3', 'b' => 'BBB3', 'c' => 1); for ($i = 0; $i < count($a); $i++) $aSort[] = $a[$i]['c']; array_multisort($aSort, SORT_ASC, $a); echo '<textarea rows="25" cols="80">'; print_r($a); echo '</textarea>'; /* Array ( [0] => Array ( [a] => AAA3 [b] => BBB3 [c] => 1 ) [1] => Array ( [a] => AAA1 [b] => BBB1 [c] => 2 ) [2] => Array ( [a] => AAA2 [b] => BBB2 [c] => 3 ) ) */ c'mon tauta lasām taču manuāli!!!

lai kko tādu varētu izdarīt ar sort() funkciju, laikam nāktos mainīt php source un pēc tam to pārkompilēt. vienkāršāk būtu, ja tu uztaisītu savu sortēšanas funkciju speciāli šim gadījumam (array salīdzināšana pēc konkrēta key), izmantojot kādu no tiem sortēšanas algoritmiem, kurus esi mācījies skolā/augstskolā. starp citu vai tu gadījumā necenties uztaisīt pats savu db ar šiem arrayiem? :D

dažas pašreizējās adreses: 1) blenubode.lv/?sec=163 // Kontakti 2) blenubode.lv/cat_view.php?cat=103 // Puzles 3) blenubode.lv/pro_view.php?cat=103&pro=507 // Puzles > Puzle "Lācis" 4) blenubode.lv/cat_view.php?cat=109 // Spēles 5) blenubode.lv/pro_list.php?cat=109&scat=101 // Spēles > Prāta spēles 6) blenubode.lv/pro_view.php?cat=109&scat=101&pro=991 // Spēles > Prāta spēles > Spēle "Taurenis" ja mod_rewrite izmanto priekš seo (googles), tad 1) blenubode.lv/kontakti 2) blenubode.lv/katalogs/puzles/103 3) blenubode.lv/prece/puzles/puzle-lacis/507 4) blenubode.lv/katalogs/speles/109 5) blenubode.lv/katalogs/speles/prata-speles/101 6) blenubode.lv/prece/speles/prata-speles/spele-taurenis/991 ja mod_rewrite izmanto, lai adrese būtu "smukāka", tad 1) blenubode.lv/kontakti 2) blenubode.lv/puzles 3) blenubode.lv/puzles/puzle-lacis 4) blenubode.lv/speles 5) blenubode.lv/speles/prata-speles 6) blenubode.lv/speles/prata-speles/spele-taurenis kad adresē norāda ciparisko id, tad parasti pietiek ar vienu/gala id, jo pēc preces id var noteikt, kurā kategorijā/apakškategorijā/apakšapakš...kategorijā tā atrodas, un to pareizi parādīt user interfeisā (menu,breadcrumbs,...). tā pat arī pēc apakškategorijas id var noteikt visas augstākās kategorijas, jo tabulās visi šie dati ir (normāli ir jābūt). līdz ar to adresē tehniski ir iespējams atstāt minimālu info pirms vispār sākt lietot mod_rewrite, iesaku attiecīgajās tabulās blakus cipariskajam id ieviest lauku arī dabiskajam id (pēc analoģijas ar ciparisko id to laikam varētu saukt arī par "burtisko" id :D:D:D). dažos gadījumos pat pietiek tikai ar dabisko id. parastajām lapām (kontakti, par mums, ...) sākotnējās/ārējās adreses /kontakti /par-mums iekšēji tiek padotas uz /?n=kontakti /?n=par-mums. šīs vērtības tad arī pārbauda parasto lapu tabulā, un parāda attiecīgās lapas saturu. starp citu parametrs n ir nice saīsinājums (nice uri - "smukā" adrese) ;) "mod_rewrite for seo" variantā attiecībā uz NE parastajām lapām (kategorijas,preces,...) ir ieviesti speciālie vārdi "katalogs", "prece", lai uzreiz varētu atpazīt, kas tas ir par saturu. piemēram, no parametra /?n=katalogs/puzles/103 pirmās daļas "katalogs" ir skaidrs, ka tālāk seko kategorija(s) un uzreiz var izmantot pēdējo daļu 103 ar tehnisko/ciparisko id, lai ar to savāktu un parādītu vajadzīgos datus. līdzīgi arī no /?n=prece/puzles/puzle-lacis/507 pēc "prece" ir skaidrs, ka ir jārāda prece ar id 507. lai arī kategoriju un preču nosaukumi šeit vēl netiek izmantoti kategorijas/preces identificēšanai, taču formējot adresi tiem anyway ir jābūt (iegūst vai nu automātiski uzģenerējot no nosaukuma/virsraksta, aizvācot garum/mīkstinājum zīmes un aizvietojot atstarpes ar "-", vai nu pats, pievienojot kategoriju/preci, ieraksta arī dabisko id) "mod_rewrite for beauty" variantā, kad adresē vairs nav nekāda lieka/tehniska info, ir jāveic papildus pārbaudes, lai noskaidrotu, uz ko vispār attiecas adresē redzamās vērtības. piemēram, saņemot /?n=speles/prata-speles/spele-taurenis, vispirms pārbauda vai "speles" ir parasto lapu tabulā, pēc tam kategoriju tabulā (tikai starp pirmā līmeņa kategorijām), un ja nav arī tur, tad tikai parāda paziņojumu, ka pieprasītā lapa nav atrodama. šajā gadījumā gan noskaidrotos, ka "speles" tomēr ir un ir kategorija, kas nozīmē, ka tagad var pārbaudīt pēdējo daļu "spele-taurenis", lai noskaidrotu vai tā ir apakškategorija vai prece, un beigās parādīt attiecīgo (preces) saturu. ok, šīs papildus pārbaudes, protams, ir arī papildus slodze serverim un arī programmētājam to uzkodēt un pēc tam uzturēt (lai gan neliekas pārāk sarežģīti), toties adrese ir "smukāka" :)) kuru no "mod_rewrite for ..." variantiem izmantot, tas ir atkarīgs no paša un no klienta vēlmēm... ;) good luck, have fun

papildināt masīvu var arī vienkāršāk ;) $masivs[] = $a1; $masivs[] = $a2; ... $masivs[] = $aN; lasīt manuāli mūsdienās laikam vairs neskaitās stilīgi... :P http://www.php.net/manual/en/language.types.array.php

$masivs = array($a1, $a2, $a3);

par to, kā uztaisīt tās "vienkāršā pieraksta" adreses, dokumentācija ir te: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html vari arī uzreiz pamēģināt savā web rootā izveidot .htaccess failu RewriteEngine on RewriteBase / RewriteCond %{REQUEST_FILENAME} -d [OR] RewriteCond %{REQUEST_FILENAME} -f RewriteRule .* - [L] RewriteCond %{QUERY_STRING} ^$ RewriteRule (.+)/$ $1 [R,L] RewriteCond %{QUERY_STRING} .+ RewriteRule (.*[^/])$ $1/ [R,NE,L] RewriteRule ^([a-z0-9-/]+?)/?$ ?n=$1 [QSA] tad virtuālās adreses http://domain/bla-bla1/bla-bla2 tiks padotas uz http://domain/index.php parametru n=bla-bla1/bla-bla2, kur gan tālāk tev pašam tās vajadzēs apstrādāt $a = explode('/', $_GET['n']); ... ja web aplikācija neatrodas web rootā, bet kkur dziļāk, piemēram, http://domain/app/, tad attiecīgi nomaini RewriteBase /app/