Lynx

Heh :D Es jau jutu, ka kautko esmu palaidis garām, vienmēr mocot js nākas saskarties ar nesaprotamām kļūdām un nezināju kas tās rada un kur meklēt. Mozzila javascript konsole palīdzēja problēmu atrisināt. Es sāku strādāt ar formām, lai nomainot manuāli vērtību, tiktu nomainīta pretējā pusē vērtība un pabīdits slaiders. Viss strādā, bet apreiķini notiek tikai kad tiek nospiests peles taustiņš pēc skaitļa ievadīšanas ar onchange eventu. Man šķita, ka onchange nostrādā tikko kā kautkas izmainās, nevis pēc tam kad nospiež peles taustiņu. Vai kaut ko es jaucu?

Nu jā šo kļūdu izlaboju, bet tāpat tas nemaina rezultātu, neiet. Nekas nenotiek. Meiģināju ielikt funkcijā alert("blabla"); viņa arī netika izsaukta, pieņemu, ka kautkas nav pareizi ar izsaukšanu,

WHERE lauks LIKE "%b%"

Hmm tas nav tas, jo es šādi te katram slaideram piešķiru savu id: <td><div id="slider_'.$i.'" style="left: '.(625+$px_right).'px; top: '.$px_down.'px; position: absolute; width: 5px; height: 22px; background-color: white; border: 1px black outset;" ><div><script>draw(slider_'.$i.', '.$total.', '.$px_down.')</script></td> Visa ideja, es pieļauju ir galīgi garām, kā es meiģinu palaist.

Hmm tomēr nepielāgoju, problēma radās tad kad man bija nepieciešams neierobežots skaits slaideru lapā, attiecīgi tabula kur katram <tr><td></td></tr>vajag pa slaideram. Itkā uzrakstiju funkciju, kurai vajadzētu visus slaiderus kontrolēt, bet nedarbojas. function draw(slider_id, summa, y) { var slider = document.getElementById(slider_id); Drag.init(slider_id, null, 575, 675, y, y); slider.onDrag = function(x, y) { document.getElementById("left_"slider_id).innerHTML = summa*(x-575)/100; document.getElementById("right_"slider_id).innerHTML = summa*(675-x)/100; } } izsaucu ar <script>draw(slider_'.$i.', '.$total.', '.$px_down.')</script>

Liels paldies, pielāgoju savām vajadzībām.

Grafisks attēlojums un ideja ir šāda: Ja mēs velkam slaideru pa kreisi, tad labās puses vērtība samazinās par tik cik palielinās kreisās puses vērtiba. Līdz aizvelkot līdz galam kreisajā pusē vērtība būs 1000 un labajā pusē 0. Pretēji tas pats. 600 | ---------[]--------- | 400 Ir idejas kā ko tādu dabūt gatavu? Piemērus šāda tipa slaideram neatradu un meiģinājumi pārveidot piemērus bija nesekmīgi.

Mans pa lapām dalīšanas skripts, pievieno vēl 2us ifus un dabūsi sev vajadzīgo rezultātu. Vispār ir efektīvāks veids kā šo pašu skriptu uzrakstīt? $offset = !isset($_GET['lpp']) ? 0 : ($_GET['lpp'] - 1) * 40; $cat = mysql_fetch_assoc(mysql_query(SELECT group_count FROM blabla WHERE blabla LIMIT '.$offset.', 40)); $pg_count = ceil($cat['group_count'] / 40); if($pg_count > 1) { echo' <table cellpadding="1" cellspacing="0"> <tr> <td class="pagecount">'.$pg_count.' Lapas</td>'; if($_GET['lpp'] > 3) { echo'<td class="page"><a href="blabla&lpp=1" title="Iet uz pirmo lapaspusi"><b>«</b></a></td>'; } if($_GET['lpp']-1 != 0) { echo '<td class="page"><a href="blabla&lpp='.($_GET['lpp'] -1).'"><b><</b></a></td>'; } for($i = $_GET['lpp']-2; $i <= $_GET['lpp']+2; $i++) { if($i > 0 && $i <= $pg_count) echo '<td class="page"><a href="blabla&lpp='.$i.'">'.($_GET['lpp'] == $i ? '<b>'.$i.'</b>' : $i ).'</a></td>'; } if($_GET['lpp']+1 <= $pg_count) { echo'<td class="page"><a href="blabla&lpp='.($_GET['lpp'] +1).'"><b>></b></a></td>'; } if($_GET['lpp'] <= $pg_count - 3){ echo'<td class="page"><a href="blabla&lpp='.$pg_count.'" title="Iet uz pēdējo lapaspusi"><b>»</b></a></td><td></td>'; } echo' </tr> </table>'; } Rezultāts šāds:

Jā šāds variants darbojas. Tikai locked nāk pirms parastajiem, kautgan viņiem būtu jajaucas. Bet pēc idejas šādi pat ir labāk, vienkārši locked tiks uztaisīts atsevišķs lauks enum('0','1') un tad arii sticky un announcementus varees nolockot. Sākumā bija ideja apvienot zem viena. Paldies.

Forumam ir nepieciešams upgreids un sāku strādāt pie Announcement(1), Sticky(2), Locked(3) un normal(4) sistēmas izveides. Ir enum lauks type kurā mēs tad norādam lauka tipu. Cik saprotu ir 2as iespējas. Mēs ar vienu pieprasījumu izvelkam visus datus, sagrupējam 1 ar 2 kopā un sortojam pēc tipa, lai augša būtu Announcements. Un tad sagrupējam 3 ar 4 un tie vienkārši šķirojas pēc last post date. 2ais būtu taisīt 2us atsevišķus pieprasījumus. vienu priekš 1 un 2 otru priekš 3 un 4, cik papētiju kodu šādi to dara phpbb. Tad jautājums kurš ir labāks 1ais vai otrais variants skatoties no izpildes ātruma un db noslodzes. 2o es uztaisītu bez problēmām, bet kā veikt 1ajā pieminēto grupēšanu nav ne jausmas. Jaņem vērā fakts, ka topiku izvadē vēl tiek taisīts left joins, lai pievienotu info vai šis konkrētais topiks ir izlasīts vai nav.

<PHP if(!isset($_POST['code'])) { echo' <form name="form1" method="post" action="verify.php?id=cb756p2c7e8pxvtrv7cpcxv473pc7x4"> <p>Verification code: <input type="text" name="code"></p> <p><input type="submit" name="Submit" value="Submit"></p> </form> <p>'; } elseif($_POST['code'] == 'CA126') { include('order.php'); } ?>

Selects izrādās viss kārtībā 0.0122s Bet ar insertu gan ir pašvakāk un lēnums ir jūtams: Inserted rows: 2 (Query took 0.3330 sec) Ar svaigu galvu pastudēju šo lietu un pievienojot postiem vel vienu indeksu - posta laiks tas pats inserts tika samazināts uz 0.0011 sec, kas jau ir labs ātrums. Izskatās, ka problēmu esmu atrisinājis. Un, Kavacky, neesmu izlepis :) man vienkārši patīk ieviest sarežģītus labas kvalitātes un funkcionalitātes risinājumus. Pats daudzko iemācos procesā(šoreiz, piemēram, indeksu nozīmīgums) un liels prieks, ka beigās viss strādā tieši kā paredzēts.

Pēc idejas jau tabulas struktūra var būt: id|lietotaja_vestules_id|paarejie dati id lauks buus primary, autoincrement pašai db, bet lietotaja_vestules_id tiks skaitīts + 1 klāt katram lietotājam atsevišķi, kad viņš saņems vai nosūtīs vēstuli un pēc šī paša lietotaja_vestules_id notiks arī visi pieprasījumi lietotāja galā.

Hmm, pieņemu, ka varētu būt pilnīgi nepareizi, jo nav pieredze ar indeksu likšanu un pats neesmu neko mainījis, kā bija, kad tiku pielaists tā arī atstāju: šadi ir postu tabulai PRIMARY PRIMARY id cat_id INDEX cat_id group_id INDEX group_id status INDEX status user_id INDEX user_id neizlasītajiem ir tikai PRIMARY PRIMARY id un grupu tabulai PRIMARY PRIMARY id cat_id INDEX cat_id public INDEX public last_post_date INDEX last_post_date Edit: Pastudēju sīkāk par indeksiem un papildināju neizlasītos postus ar dubultu indeksu(patiešām dara brīnumus un iet vismaz 2reiz ātrāk, ir vēl ieteikumi kā uzlabot?): info INDEX user_id topic_id

Eh, nonācu pie secinājuma, ka pašlaik ir ļopoti slikti :/ Lapas ielādes laiks forumā ir paildzinājies kādas reizes 5as un ir kļuvis ļoti smagi jūtams, praktiski nebaudāms. Pašam nav sanācis neko būtiski uzlabot, tapēc vēlējos te dabūt nedaudz palīdzības, cik saprotu visvairāk ēd paši kveriju, jo pārēja lapā ir tikai nelieli salīdzinājumi, kas nevar daudz resursus aizņemt.

Eh neiet :/ Sākumā nepatika, ka bt_forum_unread tiek izmantots divās vietās un vajadzēja piešķirt citu nosaukumu. Tālāk met paziņojumu: INSERT TABLE 'bt_forum_unread' isn't allowed in FROM table list un tas rodas no ON sintakses. Eh, nav citu ideju, jo ar šitik sarežģitiem joiniem neesmu ņēmies. mysql_query("INSERT INTO bt_forum_unread (user_id, topic_id, time) SELECT '$usr[id]', bt_forum_posts.group_id, NOW() FROM bt_forum_posts LEFT JOIN bt_forum_unread AS tab2 ON tab2.topic_id = bt_forum_posts.id AND bt_forum_posts.publ_date > '$usr[last_login]' WHERE tab2.topic_id IS NULL AND '$usr[last_login]' > NOW() - INTERVAL 1 DAY GROUP BY bt_forum_posts.group_id") or die(mysql_error()); Pārējā forumā visu esmu sataisījis un pēc idejas varētu arī nemaz nelikties ne zinis par dubultiem ierakstiem, vienkārārši uz izvadi arī pievienot GROUP BY, jo tagad, cik tie dubultie ieraksti ir, tik lieki nevajadzīgi topiki tiek izvadīti. Postu apskatē - nekādu problēmu nav.

Tā sāku strādāt pie sistēmas pēc Venom padoma un uz doto brīdi īsti nevaru saprast vienā lietā kā labāk. Savadu iekšā visus datus ar INSERT INTO SELECT un viss strādā. Tagad sanāk, ka katram postam ir viens ieraksts un ieejot tēmā mēs tiem postiem, kas ir šajā tabulā pieliekam neizlasīts zīmi. Skatot tēmas atliek tikai salīdzināt vai kādam no ierakstiem nav tāds pats topic_id un parādam, ka neizlasīts. Ir vēl otrs sarežģītaks(bet vai labāks) variants uztaisīt GROUP BY topic_id tagad sanāk, ka katram topikam ir viens ieraksts un nav liela datubāze jakustina, un visiem postiem, kas ir pēc neizlasīto tabulas tstamp laika likt klāt neizlasīts zīmi. Tikai domāju, vai tas GROUP BY pārāk nepaildzina visu procesu un nenoslogo serveri? Šājā gadījumā nevaru arī izdomāt viltīgo Venom Joinu, lai netiktu pēc jaunu postu pievienošanas pievienots ieraksts ar tādu pašu tēmas ID, ja tāda tēma jau eksistē tabulā.

Par to tīro CSS zināju, bet pilnībā izslēdzu šādu variantu, jo, ja tiek iztīrīts history visas tēmas uzrādīsies kā nelasītas un tas nu nebūs labi. Par hmnc bija tādi pati ideja, tikai problēma tāda, ka vajadzēs tad speciāli atzīmēt izlasītās tēmas pēc pēdējās ielogošanās, lai visas neuzrādītos, kā neizlasītas, kautgan cilvēks ir apskatījis. Un uz logout iztīrīt, bet tākā cilvēki reti izmanto logout iespēju db paliks netīrīta un būs jadomā kautkāds automatizēts skripts, kas tīra vecos ierakstus ārā. Sviesc bee) variantam arī mīnus, jo tikko kā mēs pakustamies visas tēmas tiek pārtaisītas par lasītām, jo pēdējās kustības laiks > tēmas pēdējā posta laiku. Datubāze ar neilzsītajiem postiem, liakam būtu vislabākais variants, bet pēc idejas nepatīk datubāze, jo nezinu kā operatīvi apvienot datus vadot ārā tēmas. Taisīt kādu Joinu? piemēram: SELECT teemas.id, teemas.kategorija, neizlasiitie.1aisneizlasiitaispoists, tas, velkautkastas, FROM teemas JOIN(kādu joinu vajag, lai nebļautu, ka nevar izvadīt no abām tabulām, ja tomēr tas posts ir izlasīts un nav ieraksts pie neizlasiitajiem.) neizlasiitie WHERE teemas.id = neizlasiitie.teema AND neizlasiitie.user_id = blabla Vēl man iešāvās prātā visu šo infu glabāt sessijā, īsti precīzi nezinu, bet laikam ieksh array() jāglabā un pēc tam meklēt iekš array vai tēma izlasīta un tad sanāk: Cilvēks ienāk, viņam tiek izveidots sessijas mainīgais ar visām neizlasītajām tēmām. Pēc tam vienkārši izvadot ārā tēmas salīdzinam ar id vai ir izlasīts vai nav. Un uz katru kustību papildināt šo sesijas mainīgo ar jaunām tēmam, ja tādas ir radušās. Hmm, cik labi tas ir glabāt daudz datus iekš sesijām? Vēlviens jautājums: sanāk ka mums katru reizi ir jamaļ datbuāze, kad cilvēks pakustās, lai noskaidrotu vai nav jauni posti. Bet jaunie posti ir pašās beigās tabulai, ir kautkā iespējams prasīt lai mysql meklē no tabulas beigām un, piemēram, uztaisīt LIMIT 100, lai nebūtu jaskrien katru reizi cauri pašreizējiem 160 000 postiem.

Liels paldies, darbojas ideāli!

Tā featuru ziņā uztaisīju visu ko vēlos un viss arī strādā kā nākas, ja neskaita 2us bugus - katram browserim pa vienam. <script type="text/javascript"> <!-- function codeinsert(tag) { //IE if (document.selection) { if(tag == "URL" || tag == "IMG") { var myValue = "[" + tag + "]http://" + document.selection.createRange().text + "[/" + tag + "]"; } else { var myValue = "[" + tag + "]" + document.selection.createRange().text + "[/" + tag + "]"; } document.post.txt.focus(); sel = document.selection.createRange(); sel.text = myValue; document.post.txt.focus(); var range = document.post.txt.createTextRange(); position = range.text.length; range.collapse(true); range.moveEnd("character", position - tag.length -3); range.moveStart("character", position - tag.length -3); range.select(); } Tā IE daļa visa pozicionēšana darbojas ideāli līdz brīdim, kad tiek nospiests Enter tālāk tiek skaitīta viena zīme pa daudz, kas nojauc visu kursora pozicionēšanu un galīgi nav labi, ja [/sheit] tiek novietots kursors. Ir kautkaads veids kā panākt, ka tie enter tiek ignorēts skaitīšanā? //MOZILLA else if (document.post.txt.selectionStart) { var startPos = document.post.txt.selectionStart; var endPos = document.post.txt.selectionEnd; if(tag == "URL" || tag == "IMG") { var myValue = "[" + tag + "]http://" + document.post.txt.value.substring(startPos,endPos) + "[/" + tag + "]"; } else { var myValue = "[" + tag + "]" + document.post.txt.value.substring(startPos,endPos) + "[/" + tag + "]"; } document.post.txt.value = document.post.txt.value.substring(0, startPos) + myValue + document.post.txt.value.substring(endPos, document.post.txt.value.length); document.post.txt.focus(); loc = startPos + myValue.length - tag.length -3; document.post.txt.setSelectionRange(loc,loc); } else { document.post.txt.value += myValue; document.post.txt.focus(); } } // --> </script> Mozzilai atkal problēma ir tāda, ka pati pirmā zīme iekš <textarea> tiek principiāli ignorēta un rodas dīvaini gļuki. Ja nav nevienas zīmes, tad kursors pēc teksta ievadīšanas tiek novietots beigās, nevis pāris zīmes atpakaļ. Tikko kā ierakstam kautvai atstarpi viss darbojas. Vēlāk kad ieviesu, lai pa vidu tiktu ievadīts iezīmētais teksts, ja nav neviena zīme tad vienkārši tiek insertots vārds "undefined", kā arī ja mēs iezīmējam tekstu un iezīmētajā teksta laukumā ir 1ā zīme viss teksts tiek repleicots ar vārdu "undefined". Citos gadījumos viss strādā perfekti.

Ideāli, paldies! loc = document.post.txt.selectionStart - 4; document.post.txt.setSelectionRange(loc,loc); Eh, nekur nevaru atrast javascript iebūvēto funkciju sarakstu tikai samplus. Tad nebūtu japrasa šeit: kā var noteikt stringa garumu. Tad es kodā automātiksi noteiktu cik garš ir "tag" pieskaitītu klāt 3 jo [/] un nebūtu manuāli nekas jāraksta.

Man ir nepieciešams uztaisīt sistēmu, ka visi jaunie posti forumā tiek parādīti kā neizlasīti un te rodas jautājums, kā to vislabāk(serverim un db pēc iespējas mazāks noslogojums) izveidot? Pēc idejas katram lietotājam varētu glabāt neizlasīto postu id iekš datubāzes, bet ja viņš neielogojas, piemēram, 3 mēnešus tā db tiks īsā laikā izveidota milzīga. + katru reizi kādam pakustoties būs forumā jamaļ tā datubāze - imho sanāk galīgi garām. Vēl bija ideja, kas mazāk noslogotu: noteiktā datubāzes tabulā saglabāt pēdējā apmeklējuma laiku un tad skatīties, ja konkrētā posta laiks ir lielāks par pēdējo apmeklējumu tad uzrādam, ka posts ir neizlasīts. Tikai tagad jautājums kā nodrošināt, ka, ja cilvēks šajā apmeklējumā izlasa šo postu tad tas vairs netiek uzrādīts kā neizlasīts. Ir vēl citas idejas?

Tātad man ir neliels skripts, ceru, ka nav pa lielu, lai te kopētu: function codeinsert(tag) { var myValue = "[" + tag + "][/" + tag + "]"; //IE if (document.selection) { document.post.txt.focus(); sel = document.selection.createRange(); sel.text = myValue; document.post.txt.focus(); } //MOZILLA else if (document.post.txt.selectionStart) { var startPos = document.post.txt.selectionStart; var endPos = document.post.txt.selectionEnd; document.post.txt.value = document.post.txt.value.substring(0, startPos) + myValue + document.post.txt.value.substring(endPos, document.post.txt.value.length); document.post.txt.focus(); document.post.txt.selectionStart = startPos + myValue.length; document.post.txt.selectionEnd = startPos + myValue.length; } else { document.post.txt.value += myValue; document.post.txt.focus(); } } Ideja ir šāda, ka nospiežot uz linku tiek ielikts iekš <textarea> noteikts teksts piemēram [c][/c](C, jo šejienes bbcode izkauj B tagus) kursora atrašanās vietā un pēc ielikšanas kursors novietojas tieši pēc ievietotā teksta. Jautājums, kā uztaisīt, ka kursors tiek pabīdits, piemēram, 4as zīmes atpakaļ, lai būtu tieši pa vidu starp [c] un [/c]?

Eh, par šito lietu pilnīgi biju aizmirsis. Liels paldies, tagad visu dabūju gatavu.

Njaa es atkal pameiģināju tavu variantu un strādā. Bet ar tekstu no datubāzes, kas aizņem aptuveni vairāk par 200 rindām nestrādā. Un sākumā nestrādāja manas muļķības dēļ - pavisam biju aizmirsis pieminēt, ka tabula izskatās šādi: <TABLE cellspacing=10 cellpadding=0 border=0> Veicu izmaiņas koda un patiešām nekādi \n neparādijās iekš tabulas. Bet tikko, kā palaidu caur nl2br rezultātu tā visā tabulā bija <b /r> iekšā un velaizvien repleicotais vārds no preg_replace. $text = preg_replace('@\<TABLE cellspacing=10 cellpadding=0 border=0\>.*</TABLE\>@Umse', 'str_replace("\n","asd","\0")', $teksts); echo nl2br($text); Daļa no rezultāta izskatās šādi: <TABLE cellspacing=10 cellpadding=0 border=0><TR><br /> asd<br /> asd<TD><A href=""><IMG src="" border="0" alt="1"></A></TD><br /> asd<TD>utt Tātad sanāk, ka nostrādā tikai daļēji.