2easy

sākumā iemāci mums nolasīt domas :D

aha, vislielākās briesmas slēpjas visnekaitīgākajās bildītēs: sākot no smieklīgas/atmaskojošas info līdz pat vairs ne tik smieklīgiem exploitiem :D:D:D omg, paga paga paga!!! tu gribi teikt, ka pieglabāt oriģinālo/uploadoto bildi uz servera ir extremely dangerous??? pheew, oi nē, viss kārtībā. kr4 viss būs droši, kamēr file extension būs "jpg" un php parseris tam neķersies klāt :D

vajag uztaisīt tā, lai javascript tikai nomaina html. tad viss arī iekļausies tajā pašā 0.1 sec kr4 vairāk vajag izdarīt uz servera un tur nokešot, tā lai visur visu pēc iespējas padod gatavu

ofc, its a must!!! savādāk jau visu laiku tikai nopietni kodējot/runājot, jumts aizbrauktu... (un mēs būtu kabrioleti) :D:D:D

lol, chiizij, tas ka nodzēs vizuālo daļu, jau nu galīgi ir par maz! un pati pārbaude nav jānodzēš? :D tb rindiņas 28..30 arī ir jānodzēš ;) un briedim cepums (klāt pie aliņa :D:D:D)

un kur tad palika visi lielie oop "kingi", ka nenāk aizstāvēt savu oop??? kkāds 2easy klaji apdirš oop, un neviens oop fans (izņemot codez) pat neiepīkstas? :D:D:D nee nju labi, viens no maniem aprēķiniem, mēģinot piešķilt diskusijai fleimu, bija dabūt kkādu feedback, uzzināt kko jaunu, kādu krutu oop pielietojumu, ar ko es varētu kko izdarīt ātrāk/labāk nekā procedurāli. es patiešām joprojām ceru, ka kkad atklāšu tās oop pērles, ar ko tas kkādos aspektos varētu būt pārāks par parastām funkcijām. es domāju kkādu reālu pievienoto vērtību to get the job done faster/easier. bet līdz šim vnk kkā tā ir sanācis, ka procedurālā programmēšana liek iekšā oop vienos vārtos :P vai varbūt vnk neviens neuzskata par vajadzību mēģināt iet kko pierādīt kkādam 2easy? ;) ehh, laikam nobody cares... :D

labāk taisi vien pati savu thumbnail (exif thumbnailam var nebūt vajadzīgās dimensijas), ja vien nav baigi speciāli vajadzīga tāda exif apstrāde ^^

stilīgi (to saku par ajax) ;) good job!

yep, tā protams ir laba lieta ;) varēji jau pie reizes ielikt arī linku, lai visi zin (kas vēl nezin) http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js starp citu, kad jūs inklūdojat jquery no googles, google zinās jūsu lapas apmeklētāju ip un lapu, ko tie apmeklē. līdz ar to šis ir kārtējais veids, kā google var ievākt statistiku par apmeklētājiem :D:D:D

uzrakstīt savu browseru neatkarīgu httpGet() ir ~10x īsas rindiņas (salīdzinot ar jquery bibliotēku, kura sver desmitiem kilobaitu). un pēc tam to izsaukt arī ir tikai 1x rindiņa ;)

lol, tur kur esi tagad tu, es biju pirms gadiem 5 :D:D:D taču es nemēģināju pārvarēt ieradumus. es dabiski jutu, ka kkas ir jāmaina, ka kkas nav tā kā vajag. es runāju par oop. es patiešām mēģināju atrast tam pielietojumu, bet katru reizi sanāca, ka procedurāli ir ātrāk un vnkāršāk. n-tās reizes esmu filozofējis un mēģinājis skatīties uz lietām pēc būtības, kas ir kas. kas ir izdevīgi un kas nav. ko vajag darīt un ko nē. galu galā par oop man salikās šāds priekšstats: tas ir bērnu trīsritenītis (atšķirībā no divriteņa tam ir extra ritenītis drošībai, lai nevar apgāzties, taču šī fīča nāk klāt uz ātruma rēķina...) tb oop ir domāts muļķu drošai programmēšanai. pirmos gadus, kamēr programmētāji vēl mācās kodēt, labāk tiem uzlikt visādus ierobežojumus jau pašā programmēšanas valodā, lai iemācītu disciplīnu un samazinātu muļķīgu kļūdu iespējamību. tāpēc pašā programmēšanas valodā ir salikti visādi ierobežojumi, tipa private/protected etc. viss ir baigi explicitly un baigi kārtīgi. protams, normāli/sakarīgi organizēt savu kodu var jebkurā valodā, taču oop to vnk naturāli brutāli uzspiež! taču tādiem totalitāriem piegājieniem ir vairāki drawbacki. neskaitot to, ka kodējot oop neizbēgami ir jāraksta kods, kas nerada nekādu pievienoto vērtību, bet ir tīri paša koda menedžējošais kods, ir vēl citas problēmas: ierobežojumi. tb citas klases funkciju šajā klasē var izsaukt tikai tad, ja šī klase ir mantota (extend). inheritance tiek pasniegta kā sazin kkāda tur baigā oop fīča, bet patiesībā tas ir oop design flaw. un lai tiktu vaļā no ierobežojumiem, tomēr nākas meklēt veidu, kā to atļaut, un tad arī ir inheritance ftw. taču no mārketinga viedokļa oop problēmas tiek pasniegtas tieši otrādi: ka aizliegšana ir baigā fīča :P kr4 man oop sintakse jau pašos pamatos liekas wrong priekš profesionālas programmēšanas. mācoties vispār kodēt, oop vēl ir ok, bet jo ātrāk tam tiek pāri, jo labāk :)) oop filozofija man gan patīk, jo es arī uz daudz ko (bet ne uz visu) skatos kā uz objektiem, taču vairs nekodēju oop sintaksē dēļ pārāk lielā liekā koda overhead un nevajadzīgiem (priekš manis) ierobežojumiem. bet nju tas ir tikai mans humble opinion par oop ;) ymmv

+1 +1 tikai tad, ja tam ir pietiekami liela pievienotā vērtība ;)

es jau uzrakstīju, kā man patīk kodēt :)) vēlreiz to pašu netaisos paskaidrot... ja vajadzētu kko optimizēt dēļ performances, tad es arī konkrētajā situācijā izdomātu, ko darīt. zinu, ka uz mana pc db konekcijas izveidšana paņem nepilnas 2 milisekundes, kas ir relatīvi ļoti daudz, salīdzinot ar citām "sīkām" darbībām. lai arī man interesē koda optimizēšana un es mēru performanci - kaut vai nupat pavisam svaigs piemērs http://php.lv/f/topic/16057-str-replace-un-rand-savienosana-tada-ka-cikla/page__view__findpost__p__125165 taču man nav pieredzes tādu patiešām lielu un noslogotu projektu izstrādē. anyway, es pielāgotos on demand... bet savādāk kodētu tā, kā man ir ērti ;) un tas arī ir message, ko gribēju pateikt es šeit vnk reklamēju to, ka vajag domāt arī pašiem un kritiski novērtēt dažādas web izstrādes tendences (sry ja aizvainoju kādu vai kāda ieradumus). tb ideja ir neskriet līdzi visam un visiem pēc kārtas. dažas zivis peld pret straumi un pareizi dara :D:D:D

saskaiti baitus (un laiku), cik daudz ir jāraksta tavs kods, un cik mans :D:D:D aa un par performanci u r right! :)) tavs kods izpildās vidēji par kādiem 20% ātrāk ;) $gnTm = 0; function tmu() {list($nSecU, $iSec) = explode(' ', microtime()); return $iSec + $nSecU;} // micro time - izdod pašreizējo unix laiku: sekundes + mikrosekundes (aiz "komata") function tmrSet() {global $gnTm; $gnTm = tmu();} // set timer function tmrGet() {global $gnTm; return tmu() - $gnTm;} // get timer function tmrEcho($sInfo = '') {printf('%s%.4f<br />', $sInfo, tmrGet());} // echo timer - parāda laiku ar precizitāti līdz 100 mikrosekundēm (ilgākām darbībām). lielākas precizitātes mērījumiem desmitos mikrosekunžu (vai vēl mazāk) ir jāņem vērā arī pašas funkcijas izsaukuma laiks (tb tad būtu jāizmēra function call overhead) $text = str_repeat('bla bla bla bla bla bla bla bla bla bla', 100); // 1000x bla tmrSet(); $s = preg_replace_callback('/\x20+/', create_function('', 'return rand(1000, 9999);'), $text); tmrEcho('preg_replace_callback(): '); tmrSet(); $arr = explode(' ',$text); $newtext = current($arr); while(next($arr)!==false) { $newtext .= rand(1000,9999) . current($arr); } $s2 = $newtext; tmrEcho('indoom kods: '); /* aptuvens vidējais rezultāts uz mana pc: preg_replace_callback(): 0.0053 indoom kods: 0.0042 */

tur katrā else if ir sava pārbaude... tad switch neder

un kas notiek, ja nodzēš $ no tās rules? RewriteRule ^([^/]*)/([^/]*)/([^/]*)$ /index.php?page=$1〈=$2&t=$3 [L]

looool, un problēmai vsp nav nekāda sakara ar ajax!!! :D:D:D ie browseriem select taga options nevar nomainīt ar innerHTML. ir jāmaina pats select tags. tb to <select> ieliec iekš <div id="tavs-dropdown-wrapperis"><select>...</select></div> un maini document.getElementById("tavs-dropdown-wrapperis").innerHTML = "<select>...</select>";

vajag likt tikai to kodu kas attiecas uz problēmu, nevis sazin kkādas tur riepas. ja uz ie nevar uztaisīt ajax requestu, tad uztaisi vienu mazu button vai link, kas taisa ajax request un tad ieposto šeit to kodu kas nestrādā. bet tu iekopē 90% koda, kas vsp neattiecas uz tavu problēmu!!!

njaa codez, oop ir lipīga slimība, bet arī to var izslimot :D 1) attiecībā uz pirmo daļu par mysql http://php.lv/f/topic/15781-mysql-vaicajums/page__view__findpost__p__122190 ja jau web applikācija vsp izmanto db, tad db konekciju vajadzēs izveidot anyway. tāpēc iekš init() arī izsaucu dbconn() (init() ir funkcija, kurā veicu dažādas applikācijas startup darbības). agrāk gan darīju apmēram kā Tu, ka db konekciju veidoju tikai pirmajā pieprasījumā, bet vēlāk to vairs neuzskatīju par tik labu praksi un novienkāršoju algoritmu :)) un katru reizi, kad vajag izpildīt db kveriju, vnkārša go() vietā rakstīt ~4x garāku LDb::i()->query() tur jau pat zirgam būtu jāsmejās :D:D:D:D:D nju kā tā var sarežģīt vnk funkcijas izsaukumu!!! tiešām nebiju no Tevis to gaidījis... 2) par inklūdošanu. es priekš sevis ieviesu tādu jēdzienu kā komponents, kā gan loģiski, gan fiziski iedalīt web applikācijas kodu, un inklūdoju tikai tos failus, kas tobrīd ir aktuāli/nepieciešami. ir standarta inklūds, kas notiek vienmēr pašā sākumā un inklūdo konfigu un dažādas standarta/lib funkcijas, bet custom komponentu inklūds notiek vēlāk kontrolierī: applikācijas main() funkcijā. lapas adresē jau ir skaidri pateikts, kāds saturs ir jārāda, līdz ar to tiek inklūdots viss nepieciešamais, lai to parādītu... vnk nāk smiekli par to, ka kāds izmanto oop tikai tāpēc, ka php tam ir piekabinājis kkādu autoload, kas pats par sevi nav nekāda oop fīča, bet php fīča :D:D:D anyway ja Tu rakstītu procedurāli, Tev nebūtu tik ļoti uzpūsts/bloated kods un Tev nevajadzētu katru sīkumu likt savā klasē un katru klasi savā failā. Tu varētu vnk inklūdot vajadzīgo komponentu atkarībā no konteksta un tur būtu visas darbam nepieciešamās funkcijas. bet Tu jau pats izvēlējies rakstīt sarežģītāk un tagad arī cīnies ar šo sarežģītību ar tās līdzekļiem. hahaha :P kr4 autoload vsp nav nekāda fīča! tas tika ieviests, lai palīdzētu developeriem cīnīties ar vienu no oop blakusefektiem: daudzām klasēm daudzos failos. tas toč nav nekas tāds, ar ko varētu lepoties

bildei norādi absolūto uri (sāc ar /)

kad kāds tā pasaka, es taisni nezinu, kā uz to reaģēt: 50% ka novērtē, 50% ka nes cauri :D:D:D

kad kodē ar galvu, tad ir viegli uzturēt gan procedurālu, gan objektorientētu kodu (un tas ir just a matter of coding style). bet ja nedomā, tad problēmas būs pa ļubomu :D:D:D

4. ohhh :D:D:D pareizi! mājiens ar mietu ir vislabākais :P

waplet, Tu esi sācis pārāk gudri runāt :)) un tāda vienkāršā tauta, mani ieskaitot, tevi vnk nesaprot... :D:D:D

jau atkal izklausās pēc spama, bet šie visi lielā mērā tiešām ir gaumes jautājumi... lai kā arī organizētu kodu un lai kā arī to pēc tam nosauktu (mvc vai watever kā), galvenais ir būtība, kāpēc tas tiek darīts: lai atvieglotu/paātrinātu izstrādi/uzturēšanu. vai ne? tātad kādam tā likās ērti. vēl kādam arī. vēl 10 miljoniem citu developeru arī. un viņi taisa augšā web applikācijas ar savu mvc. bet citi 10 miljoni developeru taisa kkā savādāk, kā nu kuram ir ērtāk galvenās lietas, kas tiek nodalītas atsevišķi, ir datu pieprasījumi/query (ko mvc sauc par model) un ui attēlošana/echo (ko mvc sauc par view) un tad vēl ir kods, kas apstrādā requestu (ko mvc sauc par controller) un veic gan datu pieprasījumus, gan arī pēc tam tos attēlo, izmantojot iepriekš nodefinētās funkcijas. šo ideju var norealizēt līdz dažādām pedantiskuma pakāpēm: gan iekšēji baigi strikti nodalīt funkcijas un visus datus vairākkārtīgi padot no vienas funkcijas argumentiem tālāk citai funkcijai (tipa spēlēt volejbolu, piespēlējot/mētājot datus no vienas funkcijas tālāk nākamajai), gan arī visu sadalīt daudzum daudzos failiņos pa atsevišķiem folderīšiem. bet var pieiet arī elastīgāk un mixēt un pat apvienot līdzīgu funkcionalitāti. vot šī mvc implementācija ir tas, ko es saucu par gaumes jautājumu. savukārt, kad es teicu ka "MVC toč ir priekš noobiem", es domāju, ka noobiska ir tieši ļoti cītīga pieturēšanās pie kkādiem priekšrakstiem, ko cilvēks pats līdz galam nesaprot, un kas atbilstošajā situācijā var pat nebūt pareizākā un lietderīgākā ok, lai nebūtu tikai kritizēšana (un lai Jūs varētu pakritizēt arī mani :D:D:D), mans piegājiens ir apmēram šāds: web applikāciju dalu komponentos (komponents var apvienot vairākus līdzīgus objektus): 1) statiskais kontents (par mums, kontakti, bla bla bla) 2) produkti, kategorijas 3) grozs, pasūtījumi katram komponentam ir 1) datu modulis ar db pieprasījumiem/kverijiem: gan triviāliem select,insert,update,delete, gan advancētākas darbības, kad vienā funkcijā ir vairāki db kveriji 2) ui modulis (priekš site un cms katram savs), kurš turklāt dalās divās loģiskās daļās: a) ui darbību izpilde (formu apstrāde) b) ui attēlošana (saformē html un echo) ui modulis manā izpildījumā izsauc datu moduļa funkcijas: tās, kuras ir nepieciešamas, lai attēlotu konkrēto komponentu/objektu konkrētajā kontekstā kontrole aizņem vismazāk koda: vnk jāizpilda attiecīgā ui darbība un/vai jāparāda attiecīgais kontents thats it! so simple ;) lai arī lietoju vārdu "objekts", taču es tikai domāju objektos. funkciju nosaukumus arī rakstu objektorientētā stilā, piemēram: datu pieprasījumu funkcijas: productSelectItem(), productSelectList(), productInsert() ui darbību funkcijas: productInsertOp(), productUpdateOp() // op - ui operation (op galā pielieku tāpēc, lai funkcijas nosaukums atšķirtos no līdzīgām zemāka līmeņa datu pieprasījuma funkcijām. kr4 lai nebūtu naming kolīzijas) ui attēlošanas funkcijas: productItemEcho(), productListEcho() man tā vnk ir ērtāk organizēt kodu, kad domāju objektorientēti, taču viss kods anyway ir procedurāli, jo kodēt web applikācijas burtiskā oop sintaksē ir smags overkills, jo oop ir jāraksta kkur vismaz par 20% vairāk koda, lai dabūtu to pašu funkcionalitāti, ko rakstot procedurāli. visu kodu, kas veido web applikācijas funkcionalitāti, var ļoti labi sadalīt pa moduļiem procedurāli (modulis - fails ar līdzīgām funkcijām, pie kam failā var būt vairāki moduļi. tādā gadījumā tos saucu par loģiskiem moduļiem) mācoties taisīt web applikācijas var iekrist dažādās galējības: daļa programmētāju (pārsvarā iesācēji) pieiet pārāk vienkārši un raksta kkādu makaronu kodu, kur viss ir kopā, bet citi, kas jau ir mazliet gudrāki, bieži krīt otrā galējībā un visu nenormāli cenšās abstrahēt caur entajiem abstrakciju līmeņiem, interfeisiem un objektu objektiem, etc. protams, viņi ir krutāki par pirmajiem, jo pirmie vnk nemāk to oop un līdz ar to arī nemāk tik sarežģīti uztaisīt, taču savā "krutumā" tie otrie nepamana, ka ir noobi no viena cita aspekta - tādā ziņā, ka netēmā sarežģī vienkāršas lietas. vajag atcerēties vienu vienkāršu patiesību: web lapa nav nekas vairāk kā vnk strings no <html> līdz </html> (ar DOCTYPE sākumā + vēl ārējie resursi css,js,images,...) un izstrādātāja galvenais uzdevums ir tik vien kā saformēt šo stringu un echo. lai izdarītu tādu pēc būtības vienkāršu lietu, tiešām nevajag pārcensties ar sarežģīšanu... kr4 zelta vidusceļš ftw nju tie bija my 2 cents about mvc and stuff ;)