Maris-S

Battery, domāju ka nav labākais veids ceļu līdz lapai norādīt saitē. :) Lietotājam nevajadzētu atšifrēt saiti, lai iegūtu kādu informāciju. Parasti lapas ceļu norāda ar atbilstošu saišu virkni kaut kur virs raksta, nu izkārtojums jau atkarīgs no dizaina, piemēram: Sākums > Ziņas > Jauna PHP versija nu kaut kā tā.

Apskaties PDO.

Nē, nu dažreiz nevaru saprast Jūsu pārlieko kritiku. Kas šajā piedāvājumā ir pārlieku daudz prasīts? Pilnīgi normālas prasības php programmētājam, pie tam oop un mvc iemaņas, pat netiek prasīts zināt profesionālā līmenī, ko mūsdienu programmētājam būtu jāzina. Starp citu līdz kuram laikam ir izsludinātais konkurss?

Ja izdomāsi pielikt jaunus laukus klāt un izmanto InnoDB, tad pievērs uzmanību ka nebūs laba doma ja TEXT, LONGTEXT, BLOB un analogu lauku kopējais daudzums pārsniegs 10 vai 11 (neatceros) koloniņas, sāks izpausties InnoDB ierobežojumi. Par to esmu kādreiz šajā forumā rakstījis, šeit ir diskusija: http://php.lv/f/topic/15912-jusu-domas-par-so-multilanguage-sistemu/page__st__15__p__123713__hl__innodb__fromsearch__1

Papēti iegūto html kodu ko Tu iegūsti pārlūkā. Tev funkcija opendiv($title) vienmēr taisa div elementus ar vienādiem id, gan id="loading", gan id="content", Tu viņus izvadi divas reizes, Tev sanāks divi "loading" un divi "content". Nav saprotams kāpēc Tev vajadzīgs $title, jo viņš funkcijā netiek izmantots. Par jquery nezinu, tas daudz ko atvieglo, bet es personīgi neizmantoju viņu kad vajag sataisīt minimālas javascript lietas. Piemēram, uzskatu ka nav jēgas ielādēt visu jquery, lai vienam divam uz pogas nospiešanas mainītu display.

Pamēģini sataisīt vienalga ko ar radio buttoniem tikai neizmantojot jquery, tā pārliecināsies vai patiešām IE8 kaut ko dara nepareizi.

Nav viegli izdomāt, nezinot kas tieši būs tajā lapā, cik liela informācijas pieprasīšanas/ievadīšanas attiecība. Piemēram sociālajos tīklos diezgan stipri jāpadomā arī par to ka informācija diezgan intensīvi būs ievadīta, ne tikai nolasīta. Domāju pie tāda apmeklējuma būs jādomā pie katra sīkuma, jāskatās, lai iespējami mazāk pārlādētu visu lapu kur to var, jāmēģina dizainu taisīt tā, lai pēc iespējas mazāk baitus pārsūta pa tīklu, nu un protams koda un vaicājumu optimāla veidošana, kā te jau minēja. Pats tik stipri apmeklētos projektos neesmu piedalījies, bet dzirdēts ir gan, cik zinu tur par katru baitu cīnās šādos gadījumos, lai samazinātu noslodzi kur tik var.

Jā, IE savas pozīcijas diezgan ir pazaudējis uz pašreizējo brīdi. Es te nesen sataisīju vieniem lineage spēles lapu, biju domājis ka tur vismaz būs salīdzinoši liels skaits IE apmeklētāju vidū, jo kā nekā tomēr geimeri, tātad riktīgi windowsisti, kam bieži vien open source īpaši neinteresē, bet tomēr IE tikai 4. vietā ar 13.54%.

Gribēju pajautāt vai ir kādi labi SEO analizētāji, es domāju rīki, kas pārbauda mājas lapu cik tā labi ir optimizēta priekš meklētājiem, der arī komerciāla programmatūra. Nu būt viņi ir, to jau tā kā var atrast pa google, bet es domāju vai ir kādi, kas būtu tā kā atzīti par labākajiem izstrādātāju vidū?

Sataisi atsevišķu funkciju, kura izpildīs šīs divas darbības un tad uz onclick izsauc sataisīto funkciju.

Es gan taisītu šādas liets bez jquery, protams ja tā nav vienīgā lieta kur izmanto jquery, tad tomēr var arī viņu izmantot. <form name="form_name" action="" method="post"> <div> <input type="submit" name="button_name" value="Nosūtīt" onclick="javascript: this.disabled = true; setTimeout(function() { document.form_name.button_name.disabled = false; }, 5000); return false;"> </div> </form> Return false šoreiz uzliku, lai nenotiek submits, bet cik skatos Tev to lietu jātaisa izmantojot visu submitu. Tātad doma sekojoša, ja tika submitoti dati, tad uzreiz noklusēti liec pogai disabled un timeouta funkciju, kas ieslēgs atkal viņu. Pirmo reizi kad atver lapu (netika veikts submits), atstāj pogu vienkārši enabled.

Codez, tagad sapratu, sākumā mazliet savādāk to iedomājos. Mixis, kā ta nav jāpārstartē? Vai arī atkal kaut ko nepareizi sapratu? Ir taču tā, ja tulkojumi ir .mo failos, tad palaižot apache tie tiek sakešoti un, ja pēc laika vienkārši tiks izlabots kāds sīkums .po failā, tad nokompilēts uz .mo un tad vienkārši pa virsu pārkopēts iepriekšējam failam, tad tās tulkošanas izmaiņas neparādīsies bez apache pārstartēšanas. Diezgan daudz agrāk pa google šito lietu skatījos un šitās lietas apiešana ir tikai izmantot izlabotos failus ar jauniem nosaukumiem, piemēram pieliekot modificēšanas datumu nosaukuma. Es meklēju iespēju, kā atslēgt kešošanu apache, bet tā arī nesanāca atrast.

Codez, es iespējams kaut ko nepareizi izpratu, bet tā sanāk ka Tavā gadījumā tie .tpl faili satur html kodu? Principā, ja patiešām tā ir, tad uzturēšana šajā ziņā gan nav īsti labākā, nu es domāju kopējās sistēmas uzturēšana vispār, jo sanāk ja skatiem, kas tiek sarakstīts tpl failos, ir jāmaina kaut kas, piemēram tabulas struktūra vai tml., tad sanāk tas ir jālabo katras valods .tpl failā, nav īsti parocīgi, pie kādām 7-8 valodām. Vai es kaut ko līdz galam tai templeitu sistēmā tomēr nepareizi sapratu? Pats personīgi lieku lapas saturu datubāzē (piemēram: object_id, lang, value, kaut kā tā), tas ir ar cms sistēmu ievadāmajiem un aministrējamiem objektiem: rakstiem, ziņām, galerijām un tml., tad tādas mazas lietas kā uzrakstus lietotāja vārdam, parolei, uzrakstus uz pogām un tml. lieku valodu masīvos. Man patīk arī .po faili (sīkāk šeit: http://lv.php.net/manual/en/book.gettext.php), bet te atkal cits trūkums, apache sakešo lokalizācijas failus un kaut ko izmainot ir vai nu jāpārstartē apache, vai arī jāpārsauc lokalizācijas faili, tāpēc šo pieeju pagaidām praksē nekur neesmu pielietojis.

Jau šeit forumā kaut kad rakstīju par šo: http://www.phpletter.com/Demo/Ajax-File--Manager Darbojas kā TinyMce plugins, gan kā atsevišķs failu pārlūks, tikai kārtējo reizi atgādinu ka pirmais kas jāizdara ir jāpārliecinās vai ir ieslēgta autentifikācija un jānomaina noklusētā parole.

Saskāros ar tādu lietu ka jānosaka priekšteci pēc nested set modeļa veidotā datubāzē. Tā kā nācās pie tā mazliet spēcīgāk padomāt, nolēmu risinājumu ierakstīt šeit, ja nu kādam noder. Tātad pēc nested set modeļa pamatdomas datu iegūšanas vaicājums ir aptuveni tāds: select node.*, count(parent.id)-1 as depth from web_sections node, web_sections parent where node.lft between parent.lft and parent.rgt group by node.lft order by node.lft Tā kā tieši parent.id kā koloniņu mēs iegūt nevaram, jo tiek veikta grupēšana un nevar norādīt kuru tieši priekšteču tabulas rindiņu jāskatās, tad ir jātaisa papildus vaicājums: select node.*, count(parent.id) - 1 as depth, (select id from web_sections where lft < node.lft and rgt > node.rgt order by lft desc limit 1) parent_id from web_sections node, web_sections parent where node.lft >= parent.lft and node.rgt <= parent.rgt group by node.id order by node.lft Šajā gadījumā tiek meklēti visi mezgla priekšteči, sakārtoti dilstoši un tātad sanāk tiek izvadīts tieši pēdējais priekštecis visā ceļā. Šādai pieejai vienīgais, kas jāuzlabo ir ātrdarbība. Balstoties uz jau izrunātām lietām, pie diskusijas par valsts noteikšanu pēc ip adreses, izmēģināju izveidot funkciju priekšteča noteikšanai, ātrdarbība uzreiz pieauga, pie tam ļoti jūtami. CREATE DEFINER=`root`@`localhost` FUNCTION `get_parent`(i_lft int, i_rgt int) RETURNS int(11) NO SQL DETERMINISTIC BEGIN RETURN (select id from web_sections where lft < i_lft and rgt > i_rgt order by lft desc limit 1); END Izskatās MySql pie šādiem vaicājumiem bez funkcijas neizsauc atsevišķi katru reizi vaicājumu, bet mēģina kaut kādu joinu veidot, bet nezinu, iespējams arī ir citi iemesli šādai veiktspējas atšķirībai. Būtībā, ja ir nepieciešams priekštecis, tad pareizāk būtu pielikt papildus koloniņu ar priekšteča id un likt jaunus mezglus kopā ar priekšteča id. Noteikt priekštečus ar jau esošiem priekšteču id būs daudz ātrāk. Tātad, ja ir nepieciešams jau esošo tabulu papildināt ar priekšteču id, tad to var izdarīt, izmantojot iepriekš aprakstītos vaicājumus. update web_sections node, ( select node.id, (select id from web_sections where lft < node.lft and rgt > node.rgt order by lft desc limit 1) as parent_id from web_sections node, web_sections parent where node.lft >= parent.lft and node.lft <= parent.rgt group by node.id ) parent set node.parent_id = parent.parent_id where node.id = parent.id Man kolēģis izveidoja vēl vienu priekšteča noteikšanas metodi, tā strādā ātrāk, jo neizmanto papildus vaicājumu, bet gan left join. select N.id, N.lft, N.rgt, IF(ISNULL(P.id), 0, MIN(CONVERT(CONCAT(N.lft - P.lft, '.', P.id * 10 + 1), DECIMAL(16, 8)))) as parent from web_sections N left join web_sections P on ( N.lft > P.lft and N.rgt < P.rgt and N.id <> P.id) group by N.id order by N.lft Šis vaicājums nav pilnīgs, jo rezultātā tiek atgriezts skaitlis, pēc kura var noteikt priekšteča id, šajā gadījumā id ir decimālskaitļa decimālā daļa, kurai jānoņem pēdējās nulles un pēdējais 1. Uz ātro neatradām kā MySql varētu no skaitļa atgriezt tieši decimālo daļu, bet principā to varētu izdarīt konvertējot skaitli uz rakstzīmju virkni un iegūt to no rakstzīmju virknes. Metodes būtība ir tāda, ka tā meklē mazāko starpību no mezgla lft vērtības līdz priekšteča lft vērtībai, mazākā starpība tad norāda uz priekšteci. Vaicājums ir uzbūvēts tā, lai joina rezultātā nebūtu rindiņa, kurai sakrīt mezgla un priekšteča id. Mazāko starpību varētu meklēt arī priekšteču lft un rgt starpībai.

Tā īsti neizpētīju, bet vai pirmajam uzdevumam nebūtu ērtāk Tev papētīt un izmantot MySql trigerus? Tā sākumam sataisīt būs sarežģīti, bet sanāks php kods īsāks un saprotamāks.

Paskaties šo te: http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html domāju ka varēsi pielāgot, ja tas Tev derēs.

Jā, varētu būt ka neoptimizē, vēl variants ka izmantojot apakšvaicājumu viņš veido kaut kādu joinu, kas varbūt palēnina visu, bet iespējams kļūdos. Apvienot abas pieejas arī mēģināju, bet sanāca lēnāk, tādā gadījumā arī jātaisa vai nu apakšselekts vai arī funkcija, tā, lai varētu izmantot limit nevis visam vaicājumam, bet tieši valsts noteikšanai. Man liekās ka tur salīdzinoši maz atliek ierakstu ko pārbaudīt pēc atlasīšanas pēc bitiem, tāpēc arī nekas ātrāks nesanāk.

Sanāca izmēģināt arī ar funkciju. Nu cepuri nost tādai pieejai. Nezinu kāpēc ar apakšvaicājumu nestrādāja kā vajag, bet ar izveidotu funkciju sanāca pat pārspēt bitu (15 bitu) pieeju. Vaicājums izpildījās 0,887 sekundes, ar 15 bitu tabulu izpildījās 1,124 sekundes. Mēģināju līdzīgā veidā pārveidot bitu vaicājumu, ieliekot funkcijā, sanāca lēnāk. Vienīgais veids kā sanāca ar bitiem uzlabot Codez pieejas ātrumu ir taisīt bitu tabulu ar mazāk bitiem. Starp citu, te jāpiezīmē ka uzsākot šo tēmu rakstīju ko vairāk bitu to ātrāk strādās un būs lielāka tabulu, tur es kļūdījos būtībā ir pretēji, ko mazāk bitu to ātrāk strādā un lielākas tabulas. Tātad, lai mazliet apdzītu Codez pieejas izpildes laiku pietika ar 14 bitiem, sataisīju arī 12 bitu tabulu, mēģināju arī 10 bitus, bet tā arī nesataisīju, pārāk ilgi jāgaida. Tālāk informācija par ātrumiem un tabulu izmēriem. 15 biti: laiks - 1,124 sekundes, datu garums - 11868152 indeksa garums - 2041856 14 biti: laiks - 0,729 sekundes, datu garums - 17184196 indeksa garums - 2962432 12 biti: laiks - 0,414 sekundes, datu garums - 50238516 indeksa garums - 8615936 Domāju parastai mājas lapai, kurā ne tik bieži jānosaka valsts pēc ip, mierīgi var izmantot Codez pieeju, strādā ļoti ātri, ja nepieciešams mazliet ātrāk tad jāģenerē bitu tabulas, domāju jāsāk ar 12 bitiem, citādi nav īpaši ātrāk kā Codez pieejai. Nezinu par cik 10 bitu tabula būs ātrāka, man liekās sanāk diezgan maz intervālu, kas nav sadalīti 12 bitiem, tas netika izmēģināts. Protams ja vajadzīga ļoti bieža valstu noteikšana, tad labākais ir Marrtins piedāvātais risinājums, vienīgi php paplašinājuma vietā būtu labāk veidot dll/so MySqlam, lai funkciju varētu izmantot pašā datubāzē, ne tikai php pusē. Man vienīgi tagad radās jautājums. Kāpēc funkcija tik labi uzlaboja apakšvaicājuma pieeju?

Vēl iedomājos par to ka nevajadzētu izmantot sesiju neveiksmīgu loginu skaitīšanai. Piekrītu ka jābloķē nevis ip, bet lietotājs. Ja kāds salīdzinoši gudrāks bots mēģinās piemeklēt paroli, tad sesijas skaitītāju viņš salīdzinoši viegli noņems. Ja bloķēšana tiek veikta lietotājam, tad skaitītāju labāk likt datubāzē.

Codez, ip adrešu tabulu sataisīju no Marrtins saraksta, ko viņš iedeva šeit: http://php.lv/f/topic/12005-kadus-darba-efektivitates-tulus-izmantojat/page__view__findpost__p__96078 . Tabulā mazliet vairāk kā 18000 ieraksti. Par funkciju nezinu, iespējams Tev taisnība par subquery. Pagaidām nemēģināju taisīt funkciju, būs jāpamēģina, to tagad gan nesanāks pārbaudīt, būs pirmdien jāpamēģina.

Jā, to pamanīju, bet pirms tam mēģināju mainīt un izmantot fromaddr sakārtošanai, bet līdz galam nesagaidīju, arī tagad tāds vaicājums izpildās daudz ilgāk, pagaidām nav izpildījies un nezinu kāds būs kopējais laiks. Izskatās ka labāk sakārtot tieši pēc toaddr, protams ja izmanto šo pieeju. select sql_no_cache a.ip, (select `name` from iptocountry where fromaddr <= inet_aton(a.ip) order by fromaddr desc limit 1) from ip_addresses a

Jā, tagad darbojas. Tātad vaicājums ir tāds: select sql_no_cache a.ip, (select `name` from iptocountry where fromaddr <= inet_aton(a.ip) order by toaddr desc limit 1) from ip_addresses a Rezultāti ir pareizi, arī notiek daudz ātrāk nekā ar neoptimizētu vaicājumu, bet tomēr salīdzinot ar bitiem nav ātri. Izpildes laiks 595.995 sekundes.

Codez, indekss ir pielikts. Reku tabulas DDL: CREATE TABLE `iptocountry` ( `fromip` varchar(15) COLLATE utf8_bin NOT NULL, `toip` varchar(15) COLLATE utf8_bin NOT NULL, `fromaddr` int(10) unsigned NOT NULL, `toaddr` int(10) unsigned NOT NULL, `code` varchar(2) COLLATE utf8_bin NOT NULL, `name` varchar(128) COLLATE utf8_bin NOT NULL, KEY `i_fromaddr` (`fromaddr`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin Jā un patiešām ja rakstīt kā Tu minēji ar <= nevis >= tad nostrādā ļoti ātri, ja ir indekss. Vaicājums ir sekojošs: select sql_no_cache a.ip, (select `name` from iptocountry where fromaddr <= inet_aton(a.ip) order by fromaddr limit 1) from ip_addresses a Nostrādā ļoti ātri, bet nepareizi. Visām ip adresēm tiek atgriezta pirmā vērtībā no tabulas iptocoutnry, kas ir ja tabulu sakārto pēc fromaddr. Pēc loģikas tā arī jābūt, ja Tu paņem <=, tad pilnīgi jebkurai ip adresei izpildīsies nosacījums pie paša pirmā ieraksta un, ta kā ir limit 1, neko vairāk arī nemeklēs. Savukārt ja uzliek zīmi pretēji, t.i. >=, pēc loģikas jābūt pareizi, jo sakārtotam sarakstam viņš atradīs tieši pirmo pareizo fromaddr, kas ir lielāks vai arī vienāds ar pirmo intervāla skaitli, bet, to izpildot, praktiskais rezultāts tomēr nav pareizs, nezinu kāpēc, bet izskatās ka patiešām sākumā tiek izpildīts where un tikai pēc tam tiek veikta sakārtošana. Arī viens atsevišķs vaicājums nestrādā pareizi: select `name` from iptocountry where fromaddr >= inet_aton('24.100.14.0') order by fromaddr limit 1 Šis vaicājums izdod Kanādu, kaut gan jābūt ASV. Nomainot zīmi uz <=, tātad: select `name` from iptocountry where fromaddr <= inet_aton('24.100.14.0') order by fromaddr limit 1 tiek atgriezta Asia/Pacific Region, kas ir pirmais rezultāts, ja tabulu iptocountry sakārtot pēc fromaddr, nu šis ir ļoti loģiski, šajā gadījumā to arī tā kā būtu jāatgriež. Protams ja šim vaicājumam pieliek vēl klāt otru nosacījumu, kas pārbauda intervāla lielāko skaitli, tad protams rezultātu rādīs pareizi, neatkarīgi no tā vai ir limit vai nav, sanāk standarta pieeja, bet tas jau ir bez jebkādas optimizācijas un strādā protams ļoti lēni: select sql_no_cache a.ip, (select `name` from iptocountry where inet_aton(a.ip) >= fromaddr and inet_aton(a.ip) <= toaddr order by fromaddr limit 1) from ip_addresses a

Jā un indeksus MySql patiešām var izmantot arī ar < un >