bubu

Droši vien. Pasaki kur ir problēma (ar kādu JS debugeri).

Nesapratu, kur tur jāspiež. Man tur viss refrešojas. Bet bez refreša datus var ielādē lapā ar AJAX metodi (ar Javascript palīdzību). Uzsērčo kautvai tepat forumā ar XMLHttpRequest keywordu. Reku kautkāds vecs piemērs: http://php.lv/f/index.php?s=&showtopic...ost&p=20172

Pamēģini to pašu ar iconv fju, nevis mb_convert_encoding.

Eu, WebStandart, tev nav apnicis katrā otrajā tēmā braukt offtopikā? Gribi runāt par krīzi - taisi jaunu topiku un žēlojies. Autors savā oriģinālajā topikā nebija ne vārda par krīzi teicis.

Nolaidās arī tīģerēns tikpat zemu: http://php.lv/f/index.php?s=&showtopic...ost&p=79761

Kādos citos laukos? Tur tak tikai viens teksta lauks ir. Par kādiem laukiem tu tur runā? Nebrauc offtopikā. Runa nav par nekādiem MVC vai citiem patterniem softa uzbūvē, un tavu izpratni par tiem. Jautājums bija par to, kāpēc tu uzskati, ka šeit AJAX ir lietots nevietā, un, citējot tevi, ajax "nevis darbu atvieglo, bet pat padara to neērtu. Kāpēc nav pogu?". Domā uzlietot <input type="button" onlick=".." .../> vairs AJAX nevarēs pielietot.

Kādu citu iemeslu dēļ gan tu gribētu nospiest enter? Un tu neatbildēji jautajumu - kāds UI ir sakars ar AJAX "izmantošanu nevietā"?

Man gan liekas ļoti ērti - uzklikšini un viss notiek. Līdzīgi kā GMailā - uzklikšķini un viss notiek. Nevis kautkādas pogas jauns/labot jāspaida. Liekas darbības. Bet tiešām - kāds gan UI ir sakars ar AJAX?

Kas tas ir par tādu sertifikātu ar licenci, kuru var sajaukt? Un kā tas ir - garmtech.lv nav sertifikāt? Ir gan, tik tas piesaistīts kautkādiem subdomēniem, tāpēc nevajag pa tiešo vērt vaļā rootu caur https protokolu. Viņiem izdevējs vismaz nav viņi paši, bet gan "Equifax Secure Global eBusiness CA-1". Un šis izdevējs by default ir browseru sertifikatu sarakstos (FF3 un IE7 vismaz). Tā ka domā, ko runā Rihij. Vai tu maz pats apjēdz, kam domāti SSL sertifikāti un kā tie darbojas? (hints: tie nav domāti tikai atslēgas ikoniņas parādīšanai browserī)

Šausmīgs teksts. Tev skolā komatus nemāca likt? Tas defaultais_id to arī nozīmē, ko prasi. T.i. ko rādīt, ja nav GET parametrā tas id ielikts.

Padod vajadzīgo id GET parametrā (tieši tā kā es kodā uzrakstīju). Tik protams to ID velc ārā no DB, nevis statiski kodā ieraksti. Un tad, kad vajadzīgs izselektēt konkrētās valsts ierakstus, tad izmanto šo GET parametra vērtību savā SQL kverijā: $id = isset($_GET["id"]) ? intval($_GET["id"]) : $defaultais_id; SELECT ... FROM ... WHERE id = $id

Nesapratu ko tu gribi panākt. Šito? <a href="?id_race=1">Australia</a>

Es tev pilnīgi piekrītu. Man arī grūti atrast pat pašam savas rakstītas lietas te, jo pat pēc korektiem keywordiem, kurus atceros no postā rakstītā, milzums nederīgu postu/topiku atrodas. Ok, ja saņemšu piekrišanu šādu lietu izdzēšanai arī no citiem foruma dalībniekiem, tad šāda veida topiki/posti turpmāk tiks dzēsti uz neatgriešanos.

SELECT SUBSTRING(lauks, 0, 50) FROM tabule

Muah, un es domāju, ka runa ir par kautkādiem dinamiskajiem vairāklīmeņu meņučiem ar javaskriptu :) Sasa - tak jaunai lapai ielādējoties tā vienmēr ir nopoziocionēta sākumā. Tā ir vienmēr un visos laikos tas bijis. Ja nu vienīgi tu pats ar JS nepārpozicionēsi to, vai arī URLī būs kāds anchor's uz kuru jāaizlec.

Jā, tas tā var būt.

Jā, tev taisnība.

$_POST masīvs satur datus pēc submita. Ja jūzeris submito atkal, tad dati veidojas no jauna. "Vecajam" $_POST masīvam ar to nav nekāda skara. To, ko tu vari darīt: 1) pēc submita redirektēt uz citu lapu (adresi), nevis izvadīt informāciju ārā. Tad refrešosies tā cita lapa, nevis POST pieprasījums 2) pēc submita ar JS diseiblot formas submitu (formas onsubmit eventā return false). Šis gan ir drīzāk ir pret lietotājiem, kas bezjēgā spaida submit pogu, nevis nākamās lapas refrešu. 3) php pusē salīdzināt nosūtītos datus ar ievietotajiem DB, ja ir identiski, tad nerakstīt neko tur. 3. punkts ir vienīgais, kas tev 100% garantēs aizsardzību pret dublikātiem. 1. punkts var gadīties, ka dažās situācijās nepalīdzēs.

Nu ini faila formāts jau nav tik ļoti sarežģīts, lai neuzrakstītu pats vienkāršu parseri - lasi failu pa rindām, ja rinda sākas ar [ un beidzas ar ], tad tā ir jauna kategorija. Visas pārējās rindas, ja tās nav tukšas un nesākas ar ; vai # (komentāri), taisi explode uz 2 vērtībām pēc =, un to visu liec asociatīvā masīvā.

Varbūt stulbs jautājums - bet vai tu esi drošs, ka lauka "lauks" vecā vērtība atšķirās no jaunās vērtības? Moš vislaik tu centies vienu un to pašu rakstīt pāri tādai pašai vertībai. Kā ar UPDATE uz to pašu WHERE nosacījumu, bet tik cita lauka vērtības mainīšanai? Tas strādā?

Tev tur jātaisa pieprasījums uz adresi? To nav prātīgāk darīt ar curl'veidīgu funkciju, nevis kautkādas formas postēšanu simulēt. Un arī - kāpēc tev ir <form> iekš cita <form>? Imho tas ir dikti nepareizi.

Nelieto kautkādus dīvainus mysql wraperus? Moš tev tur kautkāda transakcija ir ieslēgta, kas nav nokomitota (vai nu kā savādāk tas tur mysql'ā saucās)

Ja tas ir lokālajā tīklā, tad SQLite var turēt uz šāres un visiem piekļūt caur to. Ar vairākiem lietotājiem SQLite ar nav problēmas - tā korekti apstrādā tranzakcijas.

Imho vienas no vieglāk pārnesamajām datubāzēm ir tādas, kur visa DB ir embeddota - piemēram, SQLite, HSQLDB un tamlīdzīgas.

indoom: es jau iepriekš viņam teicu - ja vajag tekošā ieslektētā select'a optionu, tad jā, nevajag optioniem id, vajag selectedIndex izmantot. Bet kā tu zini, ko viņam vajag... Varbūt vajag atsevišķam optionam tikt klāt un dabūt to title. Tad likt to id atsevišķiem optioniem nav ne vainas. Ej un sazini, ko viņam vajag... kristāla bumba ir jāiegādājas.