bubu

Kā arī friendly urļi, kurus rewraito uz tavu urli: domains.lv/home/pirmaa

Kāpēc gan lai elementiem nebūtu id, bet būtu name (tajā tavā situācijā)? It īpaši <a> elementiem? Es vēl saprastu, ja runa būtu par formas <input> elementiem, kuriem bez name neērti iztikt... Pie tam, HTML standartā (sadaļa 12.2.1) teikts, ka ančora vārdiem ir jābūt unikāliem. Tad kāpēc gan izmantot name, kurš var būt ne-unikāls, ja, lietojot id, tādu kļūdu nevar pieļaut! Ančors pēc būtības ir unikāla lieta - tas nevar atrasties divās vietās. Jo tas unikāli definē vienu konkrētu pozīciju dokumentā. Pie tam XHTML standartā (sadaļa 4.10) ir teikts, ka name atribūts ir deprecated un "will be removed in a subsequent version of XHTML".

Nevajag jaukt valodu (Ruby) ar freimworku (Ruby on Rails). Jo freimworku (Ruby on Rails) salīdzināt ar valodu (php) nav nekādas jēgas. Tikpat labi var salīdzināt arī ar Python, kuram arī ir kaudze freimworku - TurboGears, Django, utt

Kā nevar? Nū, ja tu nezini - tad jā, tad tu nevari zināt. Bet visiem citiem tas ir fakts, ka Latvijā nic.lv ir vienīgais oficiālais domēnu dalītājs. Visi pārējie ir tikai starpnieki.

Tad kad tev ir visas tās zināšanas, tad galvenais paliek ātri un efektīvi izveidot gatavu produktu, nevis katru reizi katram projektam izgudrot divriteni (vienu un to pašu).

Ja jau nesanāk, tad viņš nav labs programmētājs un ir jāpamācās programmēt pirms ķerties pie kautkādu editoru integrēšanas.

Nu ne jau web dizaina kursā māca to qbasic. Gan jau kautkāda Programmēšana vai tml līdzīga nosaukuma kursā to māca. Un kāpēc gan ne? Tas tikai attīstīs loģisko domāšanu. Lai gan varētu pastrīdēties par to, vai tieši qbasic būtu jāmāca, nevis, piemēram Pascal :) Datorzinātņu bakalauros (LU) māca diferenciālvienādojumus risināt (vesels kurss). Vai tas programmētājam vajadzīgs? (retorisks jautājums :)

Vai tik auto_increment nav līki uzrakstīts: "auto_incremen"

Un vai tas kāds konkrēti ir kļūdas paziņojums ir valsts noslēpums?

Jā, visu var uztaisīt lai rāda.

Easy: position: fixed; Tik palasies par IE workaroundiem.

Sintaktiska kļūda 18 rindiņā (vai 17-tajā).

xPtv45z: arī tavs kverijs negarantēs, ka katra no tām union daļām atgriezīs ierakstus sakārotus pēc id augošā/dilstošā secībā.

Kāpēc tu neapskati linku postā #2? Tur viss ir parādīts. Varu apmēram to pašu atkārot te: css: @media print { #elemA { display: none; } } @media screen { #elemB { display: none; } } html: <p id="elemA"> Šis nebūs redzams uz PRINTERA. </p> <p id="elemB"> Šis nebūs redzams uz EKRĀNA. </p> <p> Uzmini nu uz kā būs redzms šis? </p>

A pamēģināt pašam nav ātrāk nekā forumā prasīt? Nekādas papildus pogas nav jānorāda. Ieliec atšķirīgo stilu printerim tajā printera css'ā un viss notiksies.

ah, nu labi jau labi. pēdiņās vēl to id vajag ielikt :) Protams, ka normāli tā nedara. Par tiem čarsetiem - ja tev ir strings ar sekojošiem simboliem "abc", tad UTF-16BE čarsetā pa batiem tas izskatīsies kā a \0 b \0 c \0 (tb a = "a\0", utt). Un normālais escape tos 0-baitus eskeipos, kas nav pareizi. Jo serveris saņemts sekojošus baitus: a \ \0 b \ \0 c \ \0, kurus interpretējot UTF-16BE čarsetā iegūs pavisam citu stringu (pa čariem = a\, \0b, \\0, c\ un invalīds viens baits \0). real_escape turpretī saprastu, ka tās nulles nevajag eskeipot - tās pieder pie konkrēta čara. Turpretī UTF-8 formātā \0 baits ir iespējams tikai un vienīgi, kur ir \0 čars. tātad tas tiks eskeipots pareizi. Tieši tāpat, piemēram, ar " pēdiņu. UTF-16 čarsetā divi baiti "" ir kautkāds unikodes čars. Un ja to eskeipo uz \"\", tad te jau sanāk pavisam invalīdi divi čari (viena vietā) ar vērtību \" (pa baitiem, ne čariem). UTF-8 turpretī garantē, ka baitu vērtības, no kurām sastāv multi-byte čarakteri vienmēr pieņem vērtības > 128. Tātad parastie ascii čarakteri (32-127) tajos nav.

Man nekad nav bijusi problēma ar nereālo mysql_escape_string funkciju. Imho tas ir tikai svarīgi, ja tev konekcijas charsets ir tāds, kurā baits ar vērtību \0 vai ' vai " var būt sastāvdaļā no multi-byte charactera (utf-16, utf-32). Parastā ascii vai arī utf-8 tas nekad nenotiek. Par kādiem warningiem ir runa?

sql injekcija nebūs iespējama, ja lietos mysql_escape_string. Tad var arī bez visādiem is_numericiem mierīgi iztikt.

+0123.45e6 ir ļoti normāls skaitlis (lai gan ne integer tipa, tiesa). Pārvērsts uz integer tas būs 123450000. Tā ka ja to lietosi atlasē pēc kautkāda ID lauka, tad jau viss būs kārtībā. Ja tiešām gribās atļaut tikai integer tipa skaitļus, tad var lietot vienkāršu regexpu - [1-9][0-9]* Es vienmēr biju lietojis http://php.net/intval Tiesa, tas arī atļaus iepriekšējo skaitli, bet to gan pārvērtīs par 123. Toties outputā tā piespiedu kārtā skaitli pārvērš par integer tipa. Tāpat tā is_numeric funkcija atļaujs ieejā skaitļus hex pierakstā - is_numeric("0xDEADBEEF") == true.

Javaskriptam ir unescape. Gan jau AS arī tāds pats ir.

Joprojām nesaprotu, ko tu gribi ar to masīvu darīt? Izvadīt to ir/nav numeric tikai tad, ja pirmā vērtība ir masīvā? if (in_array($pirmaa_veertiiba, $PAGES) && is_numeric($otraa_vert)) { // ... }

if ($pirmaa_veertiiba == "video" && is_numeric($otraa_veertiiba)) { echo "ir numeraals"; }

Iekš php strings ir masīvs, taču masīvs (array()) nav masīvs - tā ir heštabula.

Tā nav nekāda problēma. Tā ir relāciju datu bāžu specifika - tās nu nekādīgi negarantē atgriezto ierakstu kārtību rezultāta datasetā. Vai nu uzdod pats kārtību ar ORDER BY pēc kautkā (kaut vai RAND funkcijas rezultātu), vai arī paļaujies uz kautkādu-sazinkādu kārtību. Visdrīzāk vien tev jādara kā andrisp saka. Tik par ātrdarbību gan tad būs jāpiedomā.. vai mysql tur joprojām izmantos indeksu?

Kurā gan gadījumā var izpildīties šī if daļa: elseif (!$parole) ? Un tur kautkā jocīgi - cipars 1 ir "aizmirsts", bet kopējais simbolu skaits ir 34, taču tiek izvēlēti tikai 33 simboli... Iesaku izmantot ASCII tabulas specifiku - burti no a līdz z un cipari no 0 līdz 9 iet pēc kārtas.