john.brown

Nu bet elementāri ;) Tu papriekš izdrukā formu, un tikai pēc tam ģenerē to random skaitli. Loģiski, viņš formā vienmēr ir no iepriekšējās sessijas... Liec to random ģenerāciju failā ar formu, un pēc tam pie bildes ģenerēšanas, ņem šamo no sessijas - un viss būs pareizi...

imagecopyresized() vietā lieto imagecopyresampled() - kvalitāte būs labāka, slodze serverim lielāka, ātrdarbība - lēnāka ;)

Ja neskaita Server Side Include - to varētu uzskatīt par "līdzīgu" tehnoloģiju :) Ar zināmām atrunām... Pure HTML tas, protams, nav ;)

Es saprotu, ka var uzrakstīt :) Tik man nez kāpēc liekas, ka dotajā gadījumā tas nav īsti lietderīgi. Ko mēs iegūstam? Sarežģītāku un mazāk saprotamu kodu, palielinātu noslodzi db, nespēju lietotājam pateikt, cik ierakstu atrasts... Ar plus zīmi nekas prātā nenāk... Tomēr jau uzrakstīju ar rezultātu glabāšanu sessijā - strādā jauki.

Hemorojs ir sekojoš: Ir modulis A un modulis B. Uz lapas liekam 20 ierakstus. Modulī A mēs atrodam 5. Modulī B ir, teiksim, 30 atbilastoši ieraksti. Ok, taisot selectu pirmajai lapai viss ir forši - dabonam ar LIMIT 0,$pagelimit+1 piecus ierakstus. Taisam selectu modulī B. Nu jau šitādu - LIMIT 0, $pagelimit-$res_founded+1. Un tālāk sākas hemorojs - taisot selectu priekš next page, man jāatcerās, kādā modulī man beidzās iepriekšējais selects, ar kādu ofsetu viņš beidzās... Ja ejam katru reizi cauri visam, skaitot ierakstus, tad, teiksim, modulī A pa to laiku ir parādījušies jauni ieraksti, tātad, priekš moduļa B būs k. kādi jauni ofseti, kuru rezultātā k. kādi ieraksti rādīsies vairākās lapās, vai taisni otrādi - vispār kaut kur pazudīs... To biš, kaut kādi viltīgi aprēķini ar šaubīgu rezultātu. Par jauniem ierakstiem, kas parādās pa to laiku, kamēr staigā pa atrasto rezultātu lapām. Nu lai tak. Mēs jau rādam resultātu uz meklēšanas brīdi. Tev tak google ar neapdeito dinamiski ierakstu skaitu, pārejot uz nākamo rezultātu lapu ;) P.S. bez tam, ir tak jauki, ja vari userim pateikt "Uz jūsu pieprasījumu atrasti x ieraksti" :)

Nu, tas atkal ir viena selecta risinājums... Vai jāuzskaita procesā, cik jau ir rezultāti atrasti, un izejot no tā dinamiski jāmaina LMIT parametri nākamajam. Un atkal ejot pa fwd-> jātaisa viltīgs algoritms, lai sāktu no vietas, kur iepriekšējā lapa beidzās. Hemorojs... Patiesībā jau nolēmu sessijā glabāt. Datu apjoms orientējoši nesanāk pārāk liels... Tak turpinājumā vēl jautājums. Vai var dabūt no db ārā "sakritību skaitu"? Tipa selects ar WHERE field LIKE '%bla%' - cik reižu katrā ierakstā tas bla ir atrasts. Jeb to var tikai ar kādu substr_count() dabūtajam textam izdarīt?

Laikam gan nesanāks apvienot. Moduļi visi ir praktiski neatkarīgi, katram ir k. kādi savi meklēšanas ruļļi. Apvienošana/procedūras radīs imho lieku savstarpējo atkarību visai tai lietai, un pats process bik hemorojiska būs. Vot meklēšanas rezultāti visiem moduļiem ir pilnīgi vienā formātā, un tos mierīgi varētu likt kādā temp tabulā. Un no turienes jau taisīt to limit. Jautājums, kā efektīvi šamo tīrīt... Vai sessijā likt. Tad vispār tīrīšanas jautājums atkrīt...

Parastam selectam ar limitu nav ne vainas, ja tas būtu viens selekts. Tak tas rezult�“jošais masīvs ir vairāku selectu rezultāts. To biš, mekl�“šanai katrā modulī ir savs selekts, jo katram modulim ir savas k. kādas tabulas, ar saviem laukiem, kuros meklet... Nesanāk nekādi parasts ar limitu :) Jeb tu no kurienes domāji to "katru reizi"? ---------------------- Uz lietu neattiecas, tak pēc Quick Edit forumā garais e paliek par jautājumzīmi ar pēdiņu. IMHO, kaut kur jānomaina str_replace() uz mb_ereg_replace()... vismaz man iekš RTE kādreiz līdzēja.

Tātad, tiek veikta mekl�“sana dažādu moduļu tabulās. Rezultāti pagaidām likti iekš masīva, tipa $finder = new SearchFinder(); // inicializ�“jam mekl�“tāja objektu $finder->setSearchString($_GET['search']); while($modules) { // ejam cauri visiem moduļiem $mod = array_shift($modules); $cfgfile = $mod[0].'config/searchrules.php'; if(!is_file($cfgfile)) continue; include($cfgfile); // dabonam kādās tabulās, p�“c kādiem laukiem meklet $finder->setSearchRules($rules); // $rules - masīvs nodefin�“ts ieks $cfgfile $results = $finder->doSearch(); // pievienojam svaigi atrastos ierakstus iepriekš atrastajiem $this->viewArgs['results'] = array_merge($this->viewArgs['results'],$results); } Tāds variants, saprotams rada probl�“mas ar dalīšanu lapās, ja ierakstu daudz. Domas, kā atrisināt ir sekojošas. Veidot tabulu search_results, kurā likt iekša rezultātus, tad no tās taisīt selectu ar limit, p�“c kam dz�“st visu mekl�“šanas rezultātu. Nepatīk, ka katru reizi, pieprasot nākamo lapu, pa jaunu jāmekl�“ cauri visām tabulām. Vai arī likt iekšā kādu timestamp, un katru reizi dz�“st ierakstus, kas vecāki par kādu laiku... V�“l ir doma, izmantot heap tabulu... Ar vien vārd sakot, kādas var�“tu būt idejas efektīvam risinājumam? P.S. vēl ienāca prātā, varbūt tos rezulttus vispār nelikt iekš db, bet ielikt kā masīvu iekš sessijas? Un tad taisīt slici no šamiem... Tas atbrīvotu no nepieciešamības tīrīt vairs nevajadzīgos...

Nu, par to foreach visai strīdīgi... Imho, foreach jāizmanto ar associatīvajiem massīviem konstrukcijā tipa : foreach($array as $key => $value) {} Visos citos gadījumos būtu pareizāk izmantot for(), jo šamais ar visu count() ir ātrāks :) Pats gan slinkuma , gan īsāka pieraksta dēļ, šo jauko domu ne vienmēr ievēroju... ;)

Nu bet jāatšķir tak piešķiršana no salīdzināšanas ;) if ($_COOKIE["dream_lang"] == ru)...

Labi, nebij man šodien slinkums, un ir labdarības uzplūdi :) Neierobežota dziļuma meņucis, ar text faila datubāzi.... datu fails menu.txt: #path|name|url news|News|news.php news/intro|Intro|news.php?id=intro portfolio|Portfolio|portfolio.php portfolio/photo|Photo|portfolio.php?id=photo portfolio/video|Video|portfolio.php?id=video fails menu.php <?php $menufile = 'menu.txt'; $menuitems = get_items_from_file($menufile); print_menu($menuitems); function get_items_from_file($file) { $lines = file($file); $items = array('sublevels' => array()); foreach($lines as $line) { if($line[0] == '#') continue; $line = trim($line); list($path,$name,$url) = explode('|',$line); $path_parts = explode('/',$path); $curr_node = & $items['sublevels']; while($path_parts) { $part = array_shift($path_parts); if(!isset($curr_node[$part])) { $curr_node[$part] = array('name' => '','url' => '','sublevels' => array()); } if(count($path_parts) == 0) { $curr_node[$part]['name'] = $name; $curr_node[$part]['url'] = $url; } $curr_node = & $curr_node[$part]['sublevels']; } } return $items['sublevels']; } function print_menu($items) { echo '<ul>'; foreach($items as $key => $values) { echo '<li><a href="'.$values['url'].'">'.$values['name']."</a></li>\n"; if(count($values['sublevels']) > 0) { print_menu($values['sublevels']); } } echo '</ul>'; } ?> Labumi, ko iegūsti pie šāda risinājuma: 1) neierobežots submeņucu dziļums 2) arī pēc 10 gadiem, atvēris datu failu, tu sapratīsi, ko tu tur esi sarakstījis. Tavā variantā arī pēc pusgada tas būs varoņdarba cienīgs uzdevums ;) Bet vispār, kā krievi saka "скромнее надо быть", savā mājas lapā esi sev baigos skillus sarakstījis, un šitādas muļķības dod ārā... Un nevienu galvā neņem... P.S. nekādus komentārus nerakstīju speciāli. Gribēsi ko modificēt, nāksies kārtīgi kodā iebraukt ;)

Es jau tev teicu, ka tevis "sniegtā ideja" ir metama miskastē. Atvaino par tiešumu :) Ja sagribēsi trešo līmeni pievienot? Ko, vēl kādu dīvainu atdalītāj simbolu meklēsi, un visu kodu pārrakstīsi? Un kad beigsies dīvainie simboli? Nevajag izgudrot velosipēdu, piedevām, sliktu...

Klau, tev jau vairāk kā lapa ir ieteikumu "kā attīstīt šo kodu", tak tu neko galvā neņem, tik cep vienu pēc otra vienādus postus. Kā tu domā, ar tādu piegājienu kādam ir interese tev ko ieteikt?

Nē, nekas netiek mainīts $newsList = new model_NewsList(); while($news = $newsList->get()) { include(TPL_PATH.'/newstpl.php'); } Tas jau ar ir dīvaini. Principā jau problēmu apgāju - uzrakstīju savu each() analogu, tak tīri teorētiski... Vispār jau php4 priekš oop ir sucks :( P.S. uz php5 viss tas pats iet kā pa sviestu :)

Ir man divas klasītes class model_NewsList { var $db = NULL; var $news = NULL; function model_NewsList() { $dbfile = NEWS_PATH.'/data.dat'; $this->db = & MICROdb::instance(); if(!is_file($dbfile)) { $this->db->createTable($dbfile,array('title','body','time')); } else $this->db->connectDB($dbfile,2); $this->news = $this->db->selectWhere('*'); } function get() { if(list($id,$vals) = each($this->news)) { // šeit ir problēma $news = new model_News($this); // ja nepadod $this tad viss iet $news->fill($vals); return $news; } return false; } .... } class model_News { var $id = NULL; var $title = NULL; var $body = NULL; var $time = NULL; var $list = NULL; function model_News(&$list) { $this->list = $list; } function fill($data) { foreach($data as $key => $value) { $this->$key = $value; } } function save() { $this->list->save($this); } function del() { $this->list->del($this); } function setId($id) { $this->id = $id; } } Joki tādi, ka each() vienmēr atgriež tik pirmo masīva elementu. Ja nepadod referenci uz NewsList, viss notiek pareizi. Nekādi nesaprotu, kas par fišku - it kā tak tā reference nekur neiesaistās pie masīva apiešanas...

Dīvaini, man IE7 visu nosūta, un, godīgi, ne reizi ar tādu brīnumu sakāries neesmu 8) ------------- Ah, bļin FF tas bij! Sorry, Jā, ie nesūta :( Atvainojos par dezu...

Izmanto kostanti __FILE__ iekš inkludojamā faila. Konstante __FILE__ satur pilnu ceļu uz failu, kurā ir pieminēta. Kā no pilna ceļa dabūt tev vajadzīgo, ceru, pats izdomāsi. P.S. nav prātīgi taisīt failbrouseri, kas bāzējas uz to, ka katrā folderī jāliek kāds izpildāmais fails. Ko, katru reizi taisot jaunu folderi, kopesi tur php failu? Liec vienu php failu root katalogā, un izmanto k.kādu variabli, tipa $base_dir, kurā tev ir ceļš uz pašlaik lasāmo folderi.

Lietojot mvc paternu un php5 par labu un ērtu esmu atradis šitādu template engine: http://www.avtox.ru/templus/ Tur gan doķi švaki, un krieviski, tak lietošana bezgala primitīva, bet iespējas diezgan plašas...

Tu domā direktoriju, kur izpildāmais fails atrodas? dirname($_SERVER['PHP_SELF'])

Bet tev jau tur nekādas otras bildes nav :D Kas tur var "pārlekt"?

Atkārtošu vēlreiz - pati ideja glabāt tādā izskatā to meņuci ir bezcerīga. Katram meņuca itemam ir jābūt savā rindā, ar norādi, kur konkrēti tas items iet. Vēl, kā ideju varu piesviest: glabā katram itemam "ceļu uz vietu". Tipa tā: lauki: path | name | url failā rindiņas: news|News|news.php news/intro|Intro|news.php?id=intro portfolio|Portfolio|portfolio.php portfolio/photo|Photo|portfolio.php?id=photo portfolio/video|Video|portfolio.php?id=video Kā no tiem ceļiem uztaisīt smuku masīvu, kuru tālāk kā meņuci izvadīt, vari šeit paskatīties: http://php.lv/f/index.php?showtopic=5818 Tur, protams, tik ideja ir - kā pielāgot tavai konkrētajai vajadzībai nāksies tomēr padomāt. Tā varēsi taisīt meņucus ar neierobežotu dziļumu :) P.S. un esi tomer tik mīļš, un iemācies kodu lasāmi noformēt.

Jā, pasteidzos priecāties :( Šitāds querijs pareizi aizgāja man uz lokālās mašīnas (Mysql 5) : SELECT DISTINCT f.fid, f.path FROM folders AS f LEFT JOIN user_folder AS uf USING ( fid ) LEFT JOIN folders_ugroups AS fu USING ( fid ) WHERE ( f.fid = uf.fid AND uf.user_id =1 AND uf.can_read = '1' ) OR ( f.fid = fu.fid AND fu.gid IN ( 1, 2 ) AND fu.can_read = '1' ) ORDER BY f.path Dimžēl, uz production mašīnas (Mysql 4.1.21) šamais neiet. Tā pati vaina - ja tukša user_folder, neatgriež neko, tak ja user_folder ir k.kas, tad atgriež tik to ierakstu no folders, kuram ir atbilstošs ieraksts iekš user_folder. T.b. noteikums priekš atbilstības ar folders_ugroups tiek ignorēts :( Neesmu specīgs iekš sql, varetu to dabūt ar diviem pieprasījumiem, tak ļoti negribas... Help...! #------------------- Sucks! Uz Mysql 4.1 iet šitāds, par kuru Mysql 5 lamājas: SELECT DISTINCT f.fid, f.path FROM folders AS f LEFT JOIN user_folder AS uf, folders_ugroups AS fu USING ( fid ) WHERE ( f.fid = uf.fid AND uf.user_id =1 AND uf.can_read = '1' ) OR ( f.fid = fu.fid AND fu.gid IN ( 1, 2 ) AND fu.can_read = '1' ) ORDER BY f.path Vot p*&$%#@c! :(

Loģisks risinājums ir prātā :) Atteikties no tās dīvainās faila struktūras, kura gaisu jauc. Un : 1) turēt prastu php failiņu ar struktūru, tipa, kā Delfins uzrakstīja 2) izmantot mysql ar tabulu, tipa: item_id | name | parent_id. Un no tās taisīt struktūru, kā Delfins uzrakstija 3) taisīt augstāk minēto tabulu teksta failiņā, un rakstīt iekš php handleri, kas no tā failiņa taisīs struktūru, kā Delfins uzrakstīja :)

Nu, jā, paldies. LEFT JOIN palīdzēja :)