Maris-S
-
Posts
634 -
Joined
-
Last visited
Everything posted by Maris-S
-
Iespējams ka der kādi no ERM, CRM. Bet visumā izskatās ka Tev vajag kaut ko līdzīgu Microsoft Project, ja web bāzētu, tad varētu apskatīties šeit: http://www.cyberciti.biz/tips/open-source-project-management-software.html, pats neesmu pētījis tos produktus. Var meklēt arī bezmaksas Microsoft Project alternatīvas, ja nevajag web bāzēto, uz ātro atradu OpenProj
-
Nesen bija aizsākta viena tēma par meklēšanas optimizāciju. http://php.lv/f/topi...__fromsearch__1 Tur ieteicu http://sphinxsearch.com, bet kā jau tur pieminēju pats neesmu viņu pētījis un nezinu vai viņš var realizēt tādus uzdevumus un vai strādā ar datubāzēm, iespējams ir vērts papētīt. Varbūt tās tēmas autors Rpr jau būs paguvis izpētīt? Visumā, domāju ja meklēšanu veidot tikai ar datubāzes līdzekļiem, izmantojot like, tad šāda pieeja būtu pārāk noslogojoša serverim. Piemēram, ja kādu teikumu no 10 vārdiem sadalīt pa tiem pašiem 10 vārdiem un salikt vienā vaicājumā ar and vai or, izmantojot like, tad strādās pārāk lēni. Indeksi nestrādās ja % būs atslēgvārda sākumā. Tāpēc būtu vērts arī papētīt full text search, kā jau Spainis ieteica.
-
Teorētiski jā, būs jākopē. Vienīgais kas nāk prātā ir sataisīt virtuālo disku caur FTP, ja nemaldos programmiņu sauca FTPDrive.
-
Man Tavējais pirmais screenshots izskatās dīvains. Vai patiešām viņš Tev rādās kad ieraksti localhost? Cik redzu tur ir aizmālēta mājas lapas adrese, nezinu kāda tieši, jo nevar redzēt, bet viennozīmīgi sākās ar www un beigās ir lv, nedomāju ka localhostam tādu uzrādītu. Tev nav kādi redirecti salikti skriptos vai kas tam līdzīgs?
-
Tu pa tiešo kodē uz production servera, bez rezerves kopijas pie sevis?
-
Parasti jau jātaisa pēc klienta definētām prasībām, tātad ja viņam tā vajag, tad būs vien jātaisa.
-
Nu nezinu, vai ir vērts meklēt kaut ko citu, tik elementāras lietas dēļ? Arī ja mājas lapas tiek taisītas uz pasūtījumu, atteikties no projekta tikai tāpēc ka slinkums sataisīt IE6 normālu hover efektu būtu ļoti muļķīgi. Domāju es iztērētu daudz mazāk laika taisot hover, nekā skaidrojot darba devējam kāpēc viņu nevajag taisīt.
-
Nu jā, piekrītu daGrevis, īsti nevar saprast, ko mēģini panākt, bet paskaties tādu kodu, iespējams ideja noderēs. CSS, javascriptu un pārējās lietas pielabo atbilstoši savējam kodam. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Add field</title> <style type="text/css"> .form_container { width: 300px; position: relative; } .form_container .field { width: 240px; display: block; } .form_container .button { width: 50px; position: absolute; right: 0px; bottom: 0px; } </style> <script type="text/javascript"> function getElement(id) { if (document.getElementById) { return document.getElementById(id); } else if (document.all) { return document.all[id]; } else if (document.layers) { return document.layers[id]; } } function cancelEvents(e) { if (!e) e = window.event; e.cancelBubble = true; if (e.stopPropagation) e.stopPropagation(); } function clone(e) { var newElement = document.form_name.elements[0].cloneNode(true); newElement.value = ""; getElement('form_container').appendChild(newElement); cancelEvents(e); } </script> </head> <body> <form id="form_id" name="form_name" action="" method="post"> <div id="form_container" class="form_container"> <input type="text" name="insert[]" class="field"> <input type="button" value="Add" class="button" onclick = "javascript: clone(event);"> </div> </form> </body> </html>
-
Mad182, vecos pārlūkus var ignorēt, bet līdz noteiktam līmenim. Bieži vien darba devējam būs vienalga kādus pārlūkus mēs programmētāji uzskatām par vajadzīgiem atbalstīt un ko dara google. Tad labāk atbilstošajās vietās salikt <a></a>, lai varētu izmantot css, nevis javascriptu.
-
Tā īsti laikam nesapratu ko tieši Tu vēlies panākt, jo nezinu ne kas notiek tanī ilglaicīgajā skriptā, ne arī no kurienes viņš tiek palaists, bet ja tur ir kāds liels cikls, kurš teorētiski katrā solī varētu atgriezt procentus, tad iespējams vari mēģināt izvadīt to rezultātu arī cikla izpildes laikā, izmantojot Output Control Functions. Bet kā jau teicu, neesmu pat pārliecināts ka tā sanāks vispār sataisīt un arī jāskatās vai skripta izpildāmais uzdevums vispār ļaus vismaz mēģināt izmantot tādu pieeju.
-
Es gribu paskālu! :) Bet interesanti. Vienīgi tagad laikam tas ir tikai chromem sataisīts un nav ieslēgts noklusēti. Interesanti, vai citi pārlūki to pašu sataisīs arī?
-
Nu es domāju ka ļoti labi saprati ka tieši funkcionalitātes paplašināšanu un pilnīgi jauna objekta uzrakstīšanu es arī domāju. :) Diskusija ir vienmēr laba liet. Man vēl viens jautājums radās. Kā Tu parasti viņus dabū uz singleton stilu? Piemēram, ja ne Tevis veidotā klase nav singleton stilā sarakstīta, Tu viņu pielabo, vai pārtaisi extendojot? Te man nu gan liekās ka dažreiz daudz vieglāk ir inicializēt to mainīgo atsevišķi, ja viņu bieži neizmanto, tikai vajadzīgajās vietās, piemēram pdf ģenerēšanas klase, ja viņu izmanto 2 vai 3 vietās pa visu lietojumu, vai nebūs vienkāršāk viņu vienkārši inicializēt?
-
Problēma ir tāda ka es runāju par to, vai ir vajadzīgs pārrakstīt veselu klasi, kāda jau ir, bet Tu runā par to kāds Tev ir ietvars. :) Pirmām kārtām, jā, exceptions pārtrauks skripta izpildi, tāpēc ar exception handleri būtu jātaisa tādas izvirtības kā redirektēšana uz kļūdu paziņojumu lapām utt., tieši tāpēc arī neslinkoju pierakstīt lieku rindiņu un izmantoju try - catch, ne tikai logu rakstīšanai, bet vispār, jo man exceptions izmantošana šķiet diezgan ērta. Ja to Tavējo koda gabalu: function getItems(){ if ($uid=Auth::id()){ echo DB::q('SELECT * FROM users_items WHERE uid=%s',$uid)->getRows('json'); } } pliku iemest failā un viņu izsauktu viņš vienkārši nestrādātu, jo vajadzīgs ietvars, kas ļaus visu inicializēt. Tad jautājums ir, kādi iemesli ir līdzīgas ietvara un inicializācijas pieejas realizēšanai priekš šāda koda: try { if ($user->is_logged_in()) echo(json_encode($user->get_items())); } catch (Exception $e) { $log->write("Couldn't get user date.", $e); } ? Ietvara sistēma tā pat varētu inicaializēt gan user, gan db mainīgo, bet, jā, ja neizmantotu singleton patternu, mainīgie būs jāinicializē vienmēr un ja lietotājs nebūs ielogojies, db mainīgais būs inicializēts vienalga, bet tas jau ir pavisam cits stāsts. Tas piemērs ar try - catch ko es iepriekš parādīju pavisam nav domāts kā ietvara vai kādas incializācijas paraugs, tas ir vienkāršs piemērs datubāzu kļūdu logošanai ārpus klases. Pēc kādas pieejas tur tiek inicalizēti dažādi objekti šajā gadījumā ir pilnīgi vienalga. Priekš kam rādot vienkāršu try - catch piemēru man būtu vēl jāstāsta kā izveidot ietvaru? Tur to sākumu ar include un mainīgo inicializēšanu vispār varētu mest ārā un piemēra būtība saglabāsies, vienkārši izkopēju ar sākuma rindiņām. Vajag singleton patternu, lūdzu atbilstoši taisam ietvaru ar singleton patternu, kur problēma? Es ļoti labi zinu kas ir singleton patterns un kā viņš strādā, arī saprotu kas un kā Tev inicializējās, vismaz virspusēji, bet kā jau teicu es nerunāju par ietvara sistēmas veidošanu, bet gan par to, ka gan logošana, gan citas, tieši nesaistītas, ar db lietas, ir iespējams izveidot arī ārpus db klases, kā arī par to ka singletton patterns ir iespējams arī ar PDO klasi, to nepārrakstot. Tādā veidā gan paša klasēm, gan PDO klasei tiek atstātas tieši darbības ar datubāzi, nevis logeri, datu struktūru atšifrētāji un līdzīgas lietas. To es jau teicu no paša sākuma. Par to kādu pieeju izmantot un ko tieši likt klasē jau ir jāizvēlas katram personīgi. Tātad vēlreiz, visi mani piemēri ko es iepriekš esmu iedevis un apskatījis neapraksta nekādu kopēju ietvaru vai sistēmu, bet būtībā ir komentārs un atbilde uz šo: Īsumā bez piemēriem atbildes būtu: Singleton patternu var ziveidot bez lielas custom klases veidošanas, bet izveidojot tikai tieši to ko vajag singleton patternam. Automātisko parametru eskeipošana man nemaz tā īsti nepatīk, kā jau minēju, zūd kontrole pār eskeipošanu. Dažādas funkcijas, kas nav tieši saistītas ar datubāzes lietām es tomēr labāk apstrādātu atbilstošās klasēs. Lūk tādi būtu īsumā apsvērumi kāpēc es nepārveidoju jau esošu db klasi. Īsi un konkrēti šoreiz laikam būs daudz labāk, jo parādot piemērus sākās domāšana kā viņus izmantot sazin kādās sistēmās par kurām nemaz neiet runa un par kurām es pat neaizdomājos rakstot jebkuru no piemēriem.
-
Tieši tādām lietām arī ir domātas funkcijas un metodes, lai izsauktu atkārtojamu kodu vairākas reizes to nepārrakstot, citādi jēga no funkcijām nebūtu. Kādā veidā tad sarakstīt logos dažādas neatkarīgas lietas, kas ir ārpus klases funkcionalitātes? Arī programmētājs, kas pirmo reizi skatīsies uz Tavu kodu sapratīs kas notiek un nevajadzēs pētīt visas klases pēc kārtas, lai saprastu kas un kur tajās izpildās automātiski. Manā skatījumā laba koda lasāmība nav īsāks vai garāks kods, bet informatīvāks kods, nu un protams viegli uztverams. Ja nu patiešām nepatīk pie katra exceptiona, kas tiek izmests, rakstīt $log->write(), tad tik pat labi var uzrakstīt exeption handleri, kas to darīs automātiski. Jebkurā gadījumā logošana lietojumā vajadzīga arī ārpus klasēm un būs jāizmanto klase, kas to dara ārpusē, ne tikai konkrētos objektos. Rakstīt savu db klasi un atteikties no PDO tikai tāpēc, lai tajā būtu iekļauta logošana, ko var veikt ārpusē, neredzu jēgu. Nē, es domāju tieši šo: DB::q('SELECT * FROM users_items WHERE uid=%s',$uid) Ko es biju aizstājis ar: $user->get_items() ko protams var aizstāt ar klase::metode pieeju, ja vajag un ja nepatīk inicializēt mainīgos. Bet varbūt es pārāk stipri aizraujos ar objektiem un dažas ar lietotāju saistītas darbības jāiznes ārpus lietotāja klases. :) Nu nav tā, pirmkārt jau tās 3 rindiņas neizdara tik daudz cik manējās 12. Tev būtu vēl jāiekļauj, vismaz, __autoload() un datubāzes savienojuma parametri, inicializācijai kaut kur jānotiek, lai kā viņa sataisīta. Kā jau teicu, ja slinkums lieku reizi pierakstīt $log->write(), tad to pašu var izdarīt exception handlerī un reāli no 12 rindiņām paliek: if ($user->is_logged_in()) echo(json_encode($user->get_items())); Kāpēc to jādara 50 reizes? Ja tiek izmantots PDO neviens jau neliedz inicializāciju veikt savā stilā to vienu reizi, lai arī kur viņa atrastos. Inicializācijai jābūt vienalga, kaut vai __autoload, db savienojuma parametri utt. Es arī nekur neteicu ka singleton nav vispār jāizmanto. Kā jau pats saki priekš kam rakstīt lieku kodu? Ja vajag singleton patterna pieeju kopā ar PDO, tad priekš kam ir jāpārraksta vesela php klase? Tā pat varētu realizēt tikai tieši singleton patterna daļu. class singletonDB extends PDO { .... .... .... } Es jau nekur nesaku ka to visu nav jāzimanto, es tikai saku priekš kam pārrakstīt db klasi, ja tāda jau ir? Protams Tavā gadījumā daudz svādāk, jo datubāzes klasē Tu izveido arī citas papildus darbības, ne tikai logošanu. Tomēr man izskatījās ka tēmas autors jautā pēc kaut kā daudz vienkāršāka, nekā sarežģītas klases, kas ir veidota balstoties uz vesela ietvara struktūru. Kāpēc lai viņam neieteikt papētīt ko ļauj jau esošās php lietas izdarīt? Jā un arī mysqli ļauj veidot prepared statements, var apskatīties mysqli_prepare.
-
Nē, katrā kontrolierī nav vajadzības rakstīt logošanas funkciju, tā ir globāla klase, tā pat kā db. Kontrolierī jāizsauc logošanas metode, kur to vajag. To pašu echo arī jāizsauc ne vienu vien reizi, bet nekas, kods nepaliek nelasāms no tā. Nesapratu tikai kāpēc jāraksta lietotāju datu iegūšanai kodā atsevišķa funkcija un vēl ar vaicājumu, bet nu tas tā, iespējams kā piemēru domāji. Piemērs logošanai. require('lib/global.php'); $db = new db($connect_options); $user = new user($db); $log = new $log('log/a_user.log'); try { if ($user->is_logged_in()) echo(json_encode($user->get_items())); else $log->write("User items requested while not logged in."); } catch (Exception $e) { $log->write("Couldn't get user date.", $e); } Tā kā tiek izmantoti exceptions, logā ierakstīsies visa informācija, neatkarīgi no tā vai exceptions tika izmests user vai db klasē. Kā redzams logošainai nekāds kods netiek pārrakstīts no jauna, logošana tiek veikta manuāli un tieši kur to vajag, gan kļūdu paziņojumiem, gan jebkādiem citiem informatīviem paziņojumiem. Nekas un nekur netiek atkārtots. Koda saīsināšana vienā rindiņā nepadara to lasāmu un pārskatāmu, tieši otrādi, lasāmība samazinās. Ja nepatīk mainīgo inicializēšana, tad to pašu ko pierakstīju var saīsināt līdz class::method stilam, tikai īpašu jēgu tam neredzu. Tokena piesaiste Tev tā saprotu arī notiek automātiski visur kur vajag un kur nevajag. Te atkal ar automatizāciju Tu panāc to, ko apraksti ka negribi darīt, t.i. izpildīt lieku kodu. Tātad, ja Tokens nav nepieciešams viņš vienalga būs. Bet nu katram programmētājam ir savs pieejas stils, tā ke šeit nav tāda pieņēmuma kā pareizi vai nepareizi, kā kurš pieradis tā arī kodēs, ja protams nekodē komandā, tur nāktos vienoties par kādu konkrētu stilu. Vienīgi, Tavā pieejā, es nesaprotu, kā tiek realizēta logošana. Tev ir sataisīta logošanas klase, ko db klase manto, vai vienkārši db klasē ir logošanas funkcijas sataisītas? Kā, piemēram, Tu veidotu klases, kurām vajadzētu izmantot gan db klasi, gan kurās būtu iespējamas ne ar vaicājumiem saistītas kļūdas, kuras arī būtu jālogo? Kā arī vēl nesapratu, kur un kā tiek norādīti db savienošanās parametri? Sanāk db klasē tos izsauc no globālās konfigurācijas mainīgiem, vai glabājas pa tiešo klasē?
-
Nu apsvērumi ir tādi ka neredzu tam jēgu, vismaz salīdzinoši vienkāršām mājas lapām. Kā jau teicu, iepriekš es taisīju savas db klases uz php, bet viņas man īpaši neko vairāk nedarīja par to, ko dara PDO objekts. Es nekad netaisīju, tādu lietu, kā masīva automātiska atpazīšana, atkodēšana, lai automātiski saģenerētos in() parametrs MySql vaicājumā, vai līdzīgas lietas. Es uzskatu ka db klasei vajag nodarboties ar datubāzes un vaicājumu lietām, nevis datu struktūru atšifrēšanu vai līdzīgām lietām. Pārlieka universālu lietu taisīšana ar php noved pie veiktspējas zuduma. Jā, es esmu taisījis tādas lietas kā metodes, kas masīvus izmanto kā parametrus, piemēram, kas ievieto vai labo kādu ierakstu kā parametrus norādot tabulas nosaukumu, masīvu ar koloniņām=>datiem un where nosacījumu, bet tā jau ir pavisam cita metode, kas paredzēta tieši tādai datu apstrādei un, kas izmanto vienu no query metodēm. Vaicājumu logošana jau būtībā ir salīdzinoši atsevišķs gadījums, to patiešām ir jātaisa ar atsevišķu klasi, ja to vajag. Ar ko tiks realizēts savienojums un manipulācijas ar datubāzi, tā jau ir izstrādātāja izvēle, šeit nekādi tas neatšķiras vai apakšā izmanto mysql, mysqli vai PDO, jo jebkurā gadījumā logošana būs vien jāraksta pašam. Kļūdu logošana ir pavisam cits. Tās es gan netaisītu datubāzes klasēs automātiski. Agrāk taisīju, bet pēc tam es atteicos no šīs domas. Visu kļūdu logošanu taisu ar atsevišķu, tieši tam paredzētu php klasi. Iemesls ir vienkāršs, nav jēgas taisīt logošanu vairākās vietās atsevišķi, ja to var sataisīt vienā vietā. Vieglāk to parādīt uz piemēra. Jāņem vērā ka izmantoju exceptions. Piemēram, man ir db klase, vai paša rakstīta, vai PDO nav būtiski. Tad vēl man ir lietotāja klase user, kas izmanto šo db klasi, lai lietotāju informāciju iegūtu vai ievietotu datubāzē. Tātad, pieņemsim ka man ir automātiska kļūdu logošanās db klasē un lietotāju klasē, tad pseidokods varētu būt apmēram tāds. DB: make query; if error { log_error; throw exception; } else return result; User: try { db->query("select..."); //Pārbaudam lietotāju, izpildot vaicājumu. if logged_in return true; else return false; } catch return false; //Nav jālogo, jo tas izdarīts db klasē, bet vienmēr to jāpatur prātā. } Pašā kodā: if user->loged_in public part; else show "you are not logged in" message; //Nekas nav jālogo, jo tas tiek izdarīts automātiski klasēs. Šeit ir stipri vienkāršots piemērs. Reālajā situācijā lietotāja klasē varētu būt sarežģītākas metodes, piemēram lietotāja ievietošana, kura kā parametru saņem masīvu ar ievadāmā lietotāja datiem. Šajā gadījumā ir jēga logos ierakstīt ne tikai db kļūdas, bet, piemēram, ir jāpārbauda un jāieraksta kļūda, ja masīva vietā tika padots pavisam kaut kas cits, teiksim cipars vai string, tātad jāveic ievaddatu pārbaude. Šajā gadījumā jau rodas nepieciešamība domāt kādas lietas jālogo un kādas lietas jau ir ierakstītas logos ar citām klasēm, ko izmanto user klase. Protams tam visam izsekot līdzi ir salīdzinoši vienkārši, bet izmēģinot citu pieeju nonācu pie secinājuma ka lietas paliek vienkāršākas, vismaz man, ja klasēs pie visām pārbaudēm un kļūdām nevis logo visu pēc kārtas un domā, kas ir jau logos ierakstīts un kas nav, bet tā vietā izmet exceptionu. Šajā gadījumā logošana vienmēr notiek pašā augstākajā līmenī, kam tiek izmantota log klase, saglabājot visus datus par exceptionu. Tātad iepriekšējais piemērs: DB: make query; if error { throw exception; //šeit nav nepieciešams rakstīt logu, jo tas tiks izdarīts pārtverot exceptionu. } else return result; User: check_input_data; if wrong_input_data throw exception("wrong input data."); check_login_with_query; //Nevajaga izmest atsevišķi exception ja query nenostrādā, jo tas tiks izdarīts db klasē, to arī ir jāpatur prātā. if login_correct return true; else return false; //Te varētu arī izmest exception ar atbilstošu paziņojumu un atbilstošu kodu, kogu parasti glabāju kā klases konstanti. Pašā kodā: try { if (user->check_login($login, $password)) redirect to public part; else show "wrong login" message. catch (Exception $e) { $log->write("Login check error.", $e); show "page is not working temporary" message. } Vai arī, ja tika izmests exception pie nepareiza lietotāja vārda vai paroles. try { user->check_login($login, $password); redirect to public part; catch (Exception $e) { $log->write("Login check error.", $e); if ($e->getCode == user::E_CODE_WRONG_LOGIN) show "wrong login" message. else show "page is not working temporary" message. } Jā, koda ir vairāk ārpus klasēm, jo noteikti jāizmanto try - catch, bet toties klases paliek tīras, kas dara tikai savu darbu un neko lieku. Šeit protams zināma līdzība ar logošanu katrā klasē ir, jo arī jāpatur prātā, ka db klasē jau tiks izmests exceptions un tāpēc nav jādomā par vaicājuma pareizību user klasē un nav jāizmet tieši vaicājuma exeptions. Kaut arī ja izmestu nekas nenotiktu, koda izpilde apstātos pie pirmā izmestā exceptiona, tātad nav iespēja ka logā atkārtoti ierakstīsies divas reizes viens un tas pats, pat ja, tā teikt kļūdaini, tiktu izmesti vairāk exceptioni nekā vajag, logs paliek tīrs. Būtībā šāda pieeja nesamazina koda daudzumu kopēji, arī ir jāseko līdzi tam kādā klasē kādi exceptions jau tika izmesti, bet lielākā priekšrocība ir tajā, ka saglabājās klašu loģika, katra klase dara to, kam viņa ir paredzēta. Tas ir, datubāzes klase darbojas tikai ar datubāzi un vaicājumiem, viņa nav logošanas klase, viņa nav dažādu datustruktūru atšifrētājs, viņa saņem datus vaicājumiem un izpilda vaicājumus, ja kaut kas nesanāk ziņo par radušos kļūdu, izmentot exceptionu, lietotāja klase nodarbojas ar lietotāja datiem, saņem lietotāja datus, pārbauda tos un apstrādā lietotāja datus datubāzē, izmantojot db klasi, padodot datus vajadzīgā formā, vai paziņo par kļudu, izmetot exceptionu. Vai to exceptionu ir jāielogo vai jāizvada kļūdu paziņojums jādomā ārpus klases, ja izmanto MVC, to visloģiskāk darīt kontrolierī, kas arī tieši paredzēts visas loģikas apvienošanai. Tādu pieeju būtībā ir jāizmēģina, kā jau teicu, izmēģināju, man iepatikās, jo iepriekš veidojot tādas lielas klases kas dara visu, nu ne visu, bet daudz ko, īsti nesanāca tikt skaidrībā un nonākt pie pareizā secinājuma ko tieši un kur likt logos, tieši ar logiem darbojoties es nonācu līdz exceptionu izmantošanai. Ar tiem ir daudz vienkāršāk, nevajag domāt kur ko izmest, vienkārši, ir kļūda izmet exceptionu un tad pašā kodā to apstrādā, pārtver ar try - catch neatkarīgi no tā cik dziļi tas tika izmests. Tad, ar vienkāršu log metodes izaukšanu, var ierakstīt visu informāciju par exceptionu, ieskaitot stackTrace, tādā veidā pa soļiem redzot kas tika izpildīts kodā, kādos failos un kādās rindiņās kas tika izasukts un līdz ar to precīzi nonākt līdz kļudai. Kļūdu logošanai izmantoju globālu klasi, kas veic ne tikai exception kļūdu logošanu, tā var logot gan dažādas kļūdas, jebkādas, gan pilnīgi jebkuru citu informāciju ko ir jāielogo. Tieši pašus prepared statements es pats arī neizmantoju, tas redzams metodē get_tree, ko iepriekš rādīju. Te mums domas ir vienādas, uz doto brīdi viņiem ir pārāk daudz trūkumu, pie sarežģītu vaicājumu veidošanas. Kā jau teicu PDO izmantoju tāpēc, ka tas ļauj man neveidot savu klasi, jo manējā db klase darītu ne vairāk kā to dara PDO, pat mazāk. Automātiskās eskeipošanas man patiešām nav, kaut kad agrāk arī domāju par šādām lietām, bet rezultātā nonācu līdz secinājumam ka īpaši tas daudz neko nedod, tikai sarežģī db klasi un vēl nedod Tev kontroli pār eskipošanu, kad to nevajag, uz sitien ne visai labs piemērs, bet kaut vai NULL, ko nevajag eskeipot. Protams to visu var realizēt ar dažādiem nosacījumiem, vai taisot atsevišķu metodi, kas neveic eskeipošanu utt., vai vajag, tas ir pavisam cits jautājums. Te jau mazliet netēma aizgāja, bet visumā būtu interesanti dzirdēt citu domas ko liek vai neliek php veidotajās klasēs, tā teikt pieredzes apmaiņai un laikam jau labāk atsevišķā tēmā.
-
PDO::quote. Kā jau teicu, PDO iespējams izmantot pierastā veidā, izmantojot rakstzīmju virkņu apvienošanu. Uz ātro: function get_tree($language) { $language = $this->db->quote($language); $stm = $this->db->query(" SELECT node.*, names.name, names.url_name FROM $this->tree_table as node left join $this->names_table as names on names.tree_id = node.id and names.language_code = $language order by names.name "); return $stm->fetchAll(PDO::FETCH_ASSOC); } Tā ir objekta metode, atbilstoši kodā: try { $tree_items = $tree->get_tree('lv'); } catch (Exception $e) { echo($e->getMessage()); exit; } Protams tas ir vienkāršots piemērs, reāli tur ir mazliet savādāks vaicājums, rekursija utt.
-
Codez, pat ja Tu nosauc to par "vaicājumu ģeneratoru", tad lietas būtību tas nemaina. Tēmas autors grib izveidot sistēmu, kas vaicājumā padod eskeipotus parametrus. Tieši to arī prepared statement ļauj izdarīt. Tas, kā to realizē PDO un cik soļus viņš apakšā sataisa, neko nemaina, jo visumā izpildīsies vaicājums ar jau apstrādātiem parametriem. PDO patiešām nebūs ātrāks par mysqli, es arī nesalīdzināju to ar mysqli, es salīdzināju PDO tieši ar paša rakstītu php klasi, kam apakšā ir eskaipošana, sprintf, rezultātu masīvu veidošana utt. Protams optimāli un ar prātu sarakstītas klases veiktspēja var būt pat izcila. Es nezinu kāda jēga izmantot PDO prepared statements, jo es tos neizmantoju, ieteicu tēmas autoram tos apskatīties, jo viņš grib izveidot to, ko prepared statement ļauj izdarīt, par to vai ierobežojumi ir būtiski, tēmas autoram būs jālemj pašam. Noteikti Tev radīsies jautājums kāpēc es tad vispār izmantoju PDO. To es daru, jo man viņa pilnīgi pietiek, lai aizvietotu visas tās lietas, ko agrāk, izmantojot mysql_query, es realizēju ar sevis rakstīto klasi, piemēram: $db->query() $db->query_assoc() $db->query_row() $db->query_value() $db->quote() $db->begin_tranaction() $db->commit_transation() $db->rollback_transaction() tas tā, biežāk izmantojamās, klasei vēl nāca klāt exceptions izmantošana, kas PDO arī ir. Tātad man vienkārši nav jāveido sava php klase. Zinu ka daudzi iesaka veidot savas klases jebkurā gadījumā, jo tas ļautu vieglāk migrēt uz citām datubāzēm, piemēram, MySql->Postgre, nu nezinu, iespējams tas patiešām ir labi izmantot šādu pieeju, bet praksē vēl ne reizi neesmu ar to sastapies, tā ka nevaru spriest par šo lietu no praktiskā viedokļa puses. Piemērā ko Tu iedevi nemaz nevajag izmantot ciklu, lai iegūtu rezultātu masīvu, ja izmanto PDOStatement->fetchAll, nezinu, ko Tu uzskati par nelasāmu tādā kodā, iespējams, tas ka tur ir vairāk rindiņu, ieskaitot bindParam, bet kā jau esmu teicis līdz šim citās tēmās, es neuzskatu ka papildus rindiņa, protams vajadzīga rindiņa, kodu sarežģī un padara to nelasāmu, dažreiz pat otrādāk, daudzu darbību salikšana vienā rindiņā ar dažādiem ķeburiem un saīsinājumiem, kodu padara vēl sarežģītāku.
-
Codez, prepared statements ir tieši tas ko šīs tēmas autors meklē un mēģina uztaisīt. Jā, PDO ir ierobežojumi, piemēram, Tavs pieminētais in(), tikai tas nekādi nav iemesls, lai atteiktos no PDO un būvētu savas klases. PDO būs viennozīmīgi ātrāks par savu klasi. Izņēmuma gadījumos, ko nevar izveidot ar prepared statement, var izmantot klasisko php pieeju, izmantojot rakstzīmju virkņu apvienošanu, ko PDO pieļauj, protams tad ir jādomā par to, kā masīvs tiks sadalīts un datu drošību.
-
Paskaties PDO un prepared statements.
-
Ne gluži, tas strādās jebkuram līmeņu skaitam. Šajā gadījumā viņš katrai sadaļai izvadīs tiešo apakšsadaļu skaitu, vienalga kādā dziļumā atrastos sadaļai, kurai tiek meklēts apakšsadaļu skaits. Vienīgi uzsvars ir uz "tiešo apakšsadaļu", tālāk uzskatāms piemērs, iekavās skaits. datortehnika (3) cpu (null) ram (null) hdd (null) optika (2) fotoaparāti (3) Nikon (null) Canon (null) Sony (null) objektīvi (null) programmatūra (3) os (null) office (null) security (2) antivirus (null) firewalls(null) Ja vajag visa apakškoka elementu skaitu iegūt, tad jāmeklē rekursīvi, vai jāsaglabā skaits pievienojot, dzēšot, labojot (pārvietojot) sadaļas. Apakškoka elementu skaitu domāju šādi. datortehnika (3) cpu (null) ram (null) hdd (null) optika (5) fotoaparāti (3) Nikon (null) Canon (null) Sony (null) objektīvi (null) programmatūra (5) os (null) office (null) security (2) antivirus (null) firewalls(null)
-
Cik sapratu Tu gribi katrai sadaļai dabūt tiešo apakšsadaļu skaitu, tādā gadījumā vari to izdarīt arī ar sql. SELECT node.*, (select count(id) from sections where parent_id = node.id limit 1) child_count FROM sections as node
-
Tā tīri ienāca prātā pārbaudīt kā strādās rakstzīmju virkne, ja tās elementus paņem kā no masīva. Man izskatās ka ar utf-8 simboliem nepareizi strādā. Vai kaut ko darīju nepareizi? $str = "Ābols"; echo($str[0]);
-
Es jautājumu izlasīju. Es saprotu ka izvadot mainīgo, tā vērtība ir tāda kāda tam piešķirta. Bet tas ko es ieteicu ir izvadīt visu vaicājumu, nevis tikai skaitli un izvadīto vaicājumu pārbaudīt jebkurā MySql klientā, kas parādīs visas kļūdas, ja tādas būs. Vari pārbaudīt kļūdu arī no php, kodā ko Tu iedevi tas netiek darīts. Tavā gadījumā labāk pārbaudīt visu kopējo vaicājumu. Codez, domāju ar tipiem diez vai šoreiz ir kļūda, jo MySql var apstrādāt veselo skaitļu koloniņas, skaitli ieliekot apostrofos, vismaz select vaicājumos, piemēram: select * from sections where id = '8' un arī tēmas autors teica ka ieliekot skaitli bez mainīgā manuāli viss strādā.