ivka

Skaidrs, paldies par info, būs varbūt jāpamēģina. Tomēr lieta sensitīva - ieteiksi klientam un izrādīsies kaut kāds trash - te var ne tikai reputāciju sabojāt :( Ar FirstDatu un bankām jau līdz šim šādas problēmas nebija - jo nebija īpaši arī izvēles iespēju LV.

Cik es saprotu nauda pēc darījuma ir Paysera kontā, kuru pārdevējs var pārskaitīt uz savu kontu. Atšķirībā no piem. Paypal bonuss ir tāds, ka piemēram uz LV Swed tas notiek bez komisijas. Ja tas sistemātiski notiek bez ķeršanās un stresu uzdzenošām "pieturēšanām", tad jau labi :). Otra lieta - piemēram ja izmanto viņu banklinkus - maksājuma uzdevumā kā saņēmējs ir redzams kas - Paysera? Pircējiem tas nav drusku mulsinoši? Ja banklinkus taisa pa taisno ar bankām, tad jau kā saņēmēju redz tirgotāju. LV "lētās" kartes (piem. Maestro, ar kuru ārzemju e-veikalos principā neko nevar nopirkt) viņi arī normāli procesē?

Vai ir kādam reāla pieredze ar Paysera (aka mokejimai.lt)? "Uz papīra" piedāvājums ir visnotaļ sakarīgs, bet interesē pilnā bilde - uzticamība, stabilitāte, zemūdens akmeņi, "small print" utt.

Tik traki gan nav. Pirmkārt - ja notiek darbs, tad ir arī ieņēmumi (protams jo vairāk/labāki/kvalitatīvāki risinājumi, jo ieņēmumu vairāk) Otrkārt - sākotnējā lietu apgūšanas etapā nav problēmu maksāt arī par jēdzīgi pavadīto laiku, nevis par pārdoto darbu, galvenais lai ilgtermiņā ir kustība uz sevis atpelnīšanu, kā jau tas normāli ir pieņemts jebkurā konsultāciju/IT uzņēmumā, kur ieņēmumi rodas no paveiktā+pārdotā, nevis atrauti no realitātes caur investoru injekcijām vai sponsorēti no blakus biznesiem vai tml. Tāpat arī pašreiz galīgi neizskatās, ka pārskatāmā nākotnē varētu iestāties "nav ko darīt" situācija, jo darbu kaudze ir iekrājusies pamatīga, tik nav kas izdara. Ja patiešām viss tiks izdarīts un iestāsies "nav ko darīt", tad tas būs great success, arī finansiāli :)

Par uzņēmumu sevi vēl nesaukšu, bet pēdējo gadu laikā ir izveidojusies saimniecība no 5+ klientiem ar kopā 7+ web lapām, kuras visas ir vidējas sarežģītības e-komercijas aplikācijas - pārsvarā B2C/B2B internet veikali ar web back-end vai integrēti ar ERP sistēmām. Šīs saimniecības uzturēšanai un paplašināšanai nepieciešams jauns komandas biedrs ar vismaz: * vidējām-labām iemaņām Linux, MySQL vai PostgreSQL, PHP5, HTML, CSS, JavaScript * izpratni par MVC (vēlams kāda no populārākajiem PHP framework formā) * spējām kaut ko šad un tad (reti) uzzīmēt Photoshopā * bez uzkrītošiem komunikācijas trūkumiem * nobriedušu un atbildīgu personību Darba apjoms līdz pilnai slodzei pēc vienošanās (iespējams pietiekami brīvs darba grafiks). Jūsu atalgojums tieši saistīts ar ieņēmumiem projektos (pilnīgi iespējams arī krietni labāks nekā "konkurētspējīgs"). Iespējams kā darba līgums, tā arī citi sadarbības modeļi. Pieejamas klusas un mājīgas biroja telpas, ideāla vieta brain-consuming darbam, kā arī tehniskais nodrošinājums. Interesentus lūdzu rakstīt uz [email protected], īsumā norādot iepriekšējo pieredzi.

Par šīm lietām ir vērts sākt domāt tikai tad, ja projektā atbildība ir dalīta un projekts ir liels. Savādāk nevienam tas nav vajadzīgs. Pat ieviešot biznesa vadības sistēmas shēmas tiek zīmētas tā ļoti nosacīti un parasti aprobežojas ar use-case diagrammām. Normāli programmeris pats visu izdomā un uztaisa. Piesaistot relatīvi nelieliem projektiem kaut kādus sistēmanalītiķus un shēmu zīmētājus - izlietoto resursu overheads diemžēl ir stipri par lielu - viens otru nesaprot, dalās domas par metodēm un 80% laika aiziet diskusijās par virtuālo optimumu, kā rezultātā pat ja šis optimums tiek sasniegts, rezultāts ir ~10% labāks par to, kas būtu radies, ja koderis būtu strādājis viens. Par cik tehnisko dokumentāciju tāpat neviens neraksta, tad drūmā realitāte ir tāda, ka ja koderis aiziet no darba, uzņēmums zaudē klientus. Un tiešais cēlonis tam ir tas, ka vienmēr visiem visu vajag jau vakar, un mūsu nabadzīgajā valstī proj.vad. pats sevi ir gatavs apsolīt klientam verdzībā, lai tik dabūtu kārtējo pasūtījumu. Kamēr no katra kodera ir atkarīgi tikai daži klienti tikmēr OK - neviens īpaši nepārdzīvo - suņi rej, karavāna anyway kustās - tāda dzīve. Bet ja tiek veidots softs, kuru plānots pārdot 100+ kopijās, tad jau varbūt arī kāds sāk aizdomāties - "a kas būs ja notiks šitā..." un pievērst uzmanību sīkumiem, t.sk. dokumentācijām, testēšanai, performancei un tml. A par cik web projekta vai weblapas izstrāde (šis tomēr ir php forums) ir katram klientam ar kaut ko unikāls pasākums, kur budžets tipiski ir zem 1000 Ls, tad nafig palielināt izstrādei nepieciešamo resursu vairākas reizes??? Galvenais lai viss ir strādājošs un ātri gatavs. Beta-notestēs pats klients :) Pēdējo gadu laikā esmu pastrādājis kādos programmēšanas 4 uzņēmumos (visi diezgan labi pazīstami LV, viens no viņiem UK), no kuriem divos taisīju web-based projektus, otros divos kodēju risinājumus vienai grāmatvedības/ERP sistēmai - diemžēl klašu diagrammas un tml. plānošanas esmu redzējis tikai tik pat daudz cik jūs visi - respektīvi - aiz neko darīt pats mēģinājis zīmēt. Varbūt nav noveicies vienkārši... :( No softa pasūtītāja parasti par daudz prasīts ir jau tas, ka šis skaidri spēj nodefinēt savas prasības. Un no proj.vad/konsultanta/analītiķa (nu whatever - kurš uzklausa klientu) ir par daudz prasīts lai viņš kaut ko adekvāti saprastu. Un šajā atklāsmes stadijā sāk likties, ka ne waterfalls, nedz arī rapid metodoloģijas te neiet cauri - softu jāsāk rakstīt no user manuāļa :) Bet tipiski ir tā, ka klients grib kaut ko vienu, koderis uztaisa kā viņš to lietu redz, un klients, kad viņam pārgājis pirmais šoks no ieraudzītā, piekrīt uz kompromisu - t.i. - uzlabot to kas ir uztaisīts lai varētu darīt lietas kā viņš ir iedomājies, savādāk viņš pārtērēs savu budžetu reizes 3 :) Protams no tā var izvairīties, ilgstoši kopā ar klientu analizējot viņa problēmas, bet tad patiešām pati kodēšana sastāda max. 30% no visa darba, un tam šeit neviens nav gatavs morāli.

Te jau par ko bazars.. Ja nelieto begin commit, tad uz selektu rezultātiem fig var paļauties, jo cits useris pa vidam var visu nodzēst vai izUPDATēt, bet ja lieto, tad par to nav jāuztraucas.

Labi. Laikam pats visu sapratu - biju noputrojies ar persistentajām konekcijām un principā uztraukumam nav pamata. Varbūt kādam noderēs mazliet teorijas.. Katrs apache childs vienlaicīgi servē vienu rekvestu. Tas gan nenozīmē, ka vienam userim taisot vairākus rekvestus viņš visu laiku strādās ar vienu un to pašu childu!!! Citiem vārdiem - mans.php fails no sākuma līdz beigām, ieskaitot visas includes utt. atrodas viena apaches childa ietvaros un citi useri pa to laiku pie šī childa resursiem (piemēram db konekcijām) netiek. Tas, savukārt, nozīmē, ka jebkādas transakcijas, kas sāktas konkrētā skriptā, ir ekskluzīvi pieejamas šim skriptam. Ja nelieto persistentās konekcijas, tad konekcija ar datubāzi tiek aizvērta skriptam izbeidzoties. Neesmu 100% pārliecināts, bet šķiet, ka ja netaisa COMMIT, tad viņš automātiski nenotiek. Fckn slikti vārdu sakot - db konekcijas dzīvo tikai skripta izpildes laiku un ne vairāk. Persistentās nepalīdz. Nošauties... Labi ka neprogrammēju PHP ikdienā...

Par to jau jautājums :-) Ja zinātu ka var droši pages sākumā izpildīt BEGIN un beigās COMMIT, būtu baigi labi.. Bet kaut kā nav pārliecības.

Piebilde. Ja runa ietu par db tabulām ar 1000 ierakstiem un websaitu ar 10 hitiem minūtē, tad es te par to nevārītos....

Atkal jau lietus līst un atkal kaut kas manuāļos nav līdz galam uzrakstīts... Tātad - vai kādam ir sanācis ņemties ar PostgreSQL un transakcijām, izmantojot PHP par frontendu? Problemātika sekojoša: 1) PHP patīk rejūzot jau esošas atvērtas konekcijas ar datubāzi. Respektīvi, ja man viens apache childs apstrādā 7 klientus, tad visticamāk ka šamiem visiem tiks izmantota viena un tā pati konekcija ar datubāzi. 2) Transakcijas, kā zināms, darbojas pa visu db konekciju, respektīvi - ja viens useris izpilda BEGIN, tad otrs, kurš pa to laiku izpilda kaut ko citu, visticamāk trāpa iekšā iesāktajā transacijas blokā, un ja pirmajam pēkšņi notiek ROLLBACK, tad otrajam arī nekas nesanāk, jo šie sanāk ka ir lietojuši vienu transackciju. Tas viss principā ir nepieciešams, jo ir vēlme izmantot kursorus (DECLARE my CURSOR FOR SELECT.......) un sekojoši ar FETCH bīdīties pa recordiem pēc vajadzības. Gribas, lai skripta sākumā notiktos BEGIN, bet beigās COMMIT vai kaut kur pa vidu ROLLBACK. Visideālāk, protams, būtu, ja db konekciju varētu piesiet pie usera sesijas un managēt šīs konekcijas, tad varētu reāli sabūstot performanci ar šitām lietām, jo pie katra page refresha taisīt 20 selektus nav ne vēlmes ne arī principiālas nepieciešamības. Komentāri? Zinu ka pg_connect() var izsaukt ar PGSQL_CONNECT_FORCE_NEW :-) Vairāk interesē principiālā pieeja - vai kāds kaut ko tādu ir darījis un cik liels čakars bija? Vai arī vispār es te murgoju un nekad nevar sanākt tā ka viens useris trāpa otra iesāktajā transakcijā....

Nu reku tālu nemaz nebija jāmeklē: http://www.xisc.com/ No pirmā acu uzmetiena liekas tīri ok. Jāizpēta uz ko šis spējīgs ;)

Zināmā mērā ir, bet universāla pieeja request/response modelim tāpat nava. Lai gan sen nav pa tīklu bradāts - jāpameklē moš kāda pērle atrodas.

Hmm.. negribi minēt kādu piemēru, kuri ir šie "veiksmīgie projekti" šīs diskusijas (drīz jau par manu monologu taps :unsure: ) kontekstā? Kā es to redzu - populārie un veiksmīgie ir monolīti kluči aļa šī foruma software - mēģināsi iebāzt savās includēs vai integrēt savā saitā - galus atstiepsi :) Iekopēt un darbināt nav māksla, savu headeri vai CSSu uzlikt arī, bet pamēģini teiksim kaut vai no phpBB uztaisīt Delfu komentārus (kas būtībā ir tas pats) - possible? Lai gan var jau būt, ka es par maz esmu redzējis.

Tipa kāpēc es te raudu - tāpēc ka nupat ir kādu pusgadu sanācis attālināties no webu pasaules un pakodēt iekš MS Business Solutions Navision - vot tā bļin ir sistēma - protams kā jau 4GL viņai ir n-tie ierobežojumi, bet ja tu vari (ņemsim analogu no php pasaules) diskusiju forumu uzkodēt vienā stundā no nulles, tad arī klients labprāt piecietīs to, ka "kaut ko šī sistēma tomēr nesuportē". Par to viņš pretī saņems risinājumu 50x ātrāk (nepārspīlējot!) un efektīvāk gatavu nekā ja būtu iekš Visual Basic jākodē. IMHO tīra analoģija ar frameworkiem - jā, tu esi ierobežots, bet tu nebūvē velosipēdu katru reizi (jo izgudrots viņš tā kā tā jau ir sen), bet domā par to, uz kurieni tu ar viņu brauksi.

Mkeey.. Izlasīju abstractu iekš http://www.spinellis.gr/codereading/ - doma protams ir lieliska - būtu tikai laiks ar to visu nodarboties. Bet problēma (tā par kuru es te izsakos) ir citur - man it kā pat vienalga vai kaut kur kāda cita rakstīta koda iekšpusē ir budzis vai nav - problēma ir tajā, ka mēs (PHP tauta) nehavojam industry-standard veidu, kā tikt galā ar HTTP protokola piedāvāto request/response modeli un katrs to daram savādāk, kā rezultātā fundamentāli mainās veids, kā lietas tiek implementētas. Varianti ir daudz un dažādi - katrs no viņiem ar n-tajiem apakšvariantiem un visi viņi savstarpēji kombinējami. 1) Ņemam gatavas HTML lapas un tajās vietās kuras vajag dinamiskas, sabāžam PHP kodu, kurš to izdara 1a) tajās vietās includējam includes 2) Tajās pašās HTML lapās pirms jebkura outputa izdaram visu mainīgo apstrādi un iegūstam rezultātus, jo mēs jau tāpat zinam, kas šajā lapā jārāda. 3) Būvējam lapas no includēm - header, left panel, main panel, footer etc.. Katrs bloks (include) apstrādā uz viņu attiecošos GET/POST parametrus.. Bet figņa ta ir tāda, ka gan requests, gan response ir viens vesels un ja katrs views tiek sadalīts n-tajās includēs, tad rodas problēmas ar linku veidošanu, bloku savstarpējām interakcijām utt. Ātri uzrakstīt 4-soļu formu wizardu vispār nav jebkuram pa spēkam - just think about it. Tāpēc ir nepieciešams kaut kāds frameworks, kas šīs lietas darītu puslīdz automātiski vai vismaz asistētu to veikšanā, savādāk tak var nošauties, līdzko kaut kas lielāks jāuzraksta. A figņa tāda, ka šāds vispārpieņemts frameworks php pasaulē... does not exist, tāpēc katram viņš ir savs (reāls, iedomāts.. vai arī koderis vienkārši par šīm problēmām neaizdomājas). Sekojoši arī kaut kādas gatavas klases var uzrakstīt tikai tādā gadījumā, ja viņām nav jāimplementē vairāki ekrāni un viņu savstarpējā interakcija. OK, pēdējā teikumā mazliet iefantazēju par skaisto nākotni, bet ceru ka sapratāt.

Kaukas nav labi ar to linku - neveras :(

Offt: uz sevi tēmē? :D :P Bet taisnība tev ira 100%.

Jap. Un stipti vieglāk un lētāk ir atrast HTMLizētāju ar minimālām PHP iemaņām nekā purnu, kurš kaut reizi būtu dzirdējis par Smarty, Velocity un tml. brīnumiem. Bet ne par to šis bazars... Attiecībā uz klasēm - nu PAVISAM sliktu piemēru uzrakstīji :D ar domu - ļoti precīzu - ja kāds raksta šādi, tad viņam nav visi mājās vai arī krāns par īsu :unsure: Vispār jau ieraugot echo() vai <html> klases iekšpusē jāsāk domāt par sliktu stilu. Doma tāda, ka ar klasēm var panākt (ja māk) ļoti smuku un rejūzojamu kodu, kuru atkārtot daudzos projektos - tipa shopping carti, galerijas, forumi un viss pārējais kas nāk prātā. BET - kā jau Kaklz izteicās - ilgos gados neesam vienojušies par metodiku (atšķirībā teiksim no JSPistiem, kas visi kā viens lieto MVC/Struts) - tāpēc viens kaut ko uzrakstīs, otram no tā nebūs nekādas jēgas. Gribētu mazliet paturpināt tēmu - negribās lai par PHP, kurš savā piektajā versijā izārda JSP mazos gabaliņos (tūlīt man uzbruks... :ph34r: ) domā kā par bērnu valodu un par Javu/JSP kā par Olimpa virsotni, kurā banku mājas lapas un internetbankas jāraksta. Un tas notiek faktiski tikai dēļ šī viena iemesla - nespēja veidot sakarīgus koda gabalus, no kuriem būtu jēga arī kādam citam. Rezultātā - nekāda codebase neeksistē (tiešām neesmu dziļi pētījis tos Pear un PECL vai kā viņus tur, bet šķiet ka viņi bērnu autiņos) un PHP spēks ir vienāds ar spēcīgākā kodera spēku vai drīzāk izturību. Java uzvārījās ar savu strikto OOP manuprāt, kamēr PHP izauga no templašu valodas. Ja tu raksti OOP, tad tev gribot negribot jāaizdomājas par pieejas un jēgas jautājumiem, jo savādāk defaultā tiek sabraukts auzās. IMHO protams. Ak jā - un par nedēļā uztaisāmām lapām protams ka nerunājam.

Neskaldu matus - piedāvāju pieeju :-) Kā arī MVC neslavēju - ja slavētu, tad pats lietotu, bet nelietoju odnako - skat. topiku par MVC. Par automātiskajiem/manuālajiem SQLiem gan nepiekritīšu. Kaut vai aiz tā aspekta, ka neesmu redzējis nevienu serveri, kurš nebūtu PentiumMMX un mirtu nost dēļ DB pārslodzēm. Ā nē, tomēr vienu esmu redzējis (šito) B) . Bet nu ideja skaidra - nav labu vai sliktu SQL statementu (ja runājam par strādājošiem) - ir ātri un lēni :P. Ja ātrums nav problēma (un >90% gadījumos nav), tad dodu priekšrodu metodēm, kas ļauj ātrāk un efektīvāk (nevis skaistāk un pareizāk) kodēt. Tieši te jau tas KISS arī darbojas: try { $a = new Article($_GET['id']); $a->set_field_value('comment_count', $x); $a->update(); } catch(Exception $e) { header('Location: /error.php?ec='.$e->getMessage()); die; } nevis $id = abs(intval($_GET['id'])); $q = "UPDATE articles SET comment_count='.$x.' WHERE id=".$id; $result = db_exec($q); if(hvz_affected_rows($result)==0) { header('Location: /error.php?ec=154'); die; } Un defaultajā gadījumā rindiņas no otrā koda ir jāraksta cauru dienu bez apstājas ilgu mēnešu garumā :( Pie kam ar objektiem, kas reprezentē ierakstus ir daudz ērtāk darboties nekā ar kaudzi mainīgo, kas atbilst konkrētiem laukiem.. aļa list($id, $author, $title, $lead, $body, $comment_count) = hvz_getrow($result);

Nav jau runa par to, ka tagad rakstīsim visu paternos. Protams ka mazām lietiņām to tanku suportēt nav jēgas - pilnīgi saprotu to hello world piemēru un tml. Kāpēc interesējos.. pirms pāris gadiem uzcepu sistēmu - online shoppings, resursu managēšana, nedaudz loģistikas problēmrisināšanas, rēķinu izdrukas, veicamo darbu ģenerācijas un tā. No tehniskās puses paskatoties - 33 tabulas datubāzē un hvz cik rindiņas koda - bail skaitīt. Bet kas sāka iebesīt - rakstot šādas lietas 90% laika paiet sacerot SQL selektus, kas būtībā ir vienveidīgi un tipizēti, kā arī ņemoties ar GET/POST mainīgo apstrādi, rutinētu operāciju kodēšanu (insert,edit,delete visa veida ierakstiem) - un tas būtiskākais kas šādai sistēmai ira - t.i. - biznesa loģika, tiek izsvaidīta pa 150 includeem, kas ne tikai ir suxaini no atrašanas/labošanas viedokļa, bet arī daudz vienkāršāk kļūdas salaist, kaut ko aizmirst un tā... MVC kā risinājums - nezinu, tāpēc jautāju - kāds vispār ar kaut ko tādu nodarbojas? Lielākā daļa man zināmo php koderu baidās no OOP kā tāda, kur nu vēl būtu gatavi studēt šitās lietas.. Bet tad kad es vairāk to projektu nesuportēšu, tad ļoti negribās lai viņš tiktu izsviests miskastē un pārrakstīts no nulles - kā tas notiek ar visiem webiem, kad nomainās programmeris/firma. It kā jau nav mana darīšana, bet anyway - šādā situācijā kaut vai ieraksts portfolio arī pazūd.

Apskatot topika sākumā uzstādīto problēmu... Redzu ka topiks vecs, bet varbūt kādam noderēs :-) Klase Posts - ja mēs domājam objektos - kādu objektu weblapā šī klase reprezentē? Manā skatījumā - nekādu. Ja nu vienīgi kaut kādu abstraktu funkciju kopu, kas māk no DB izselektēt un atgriezt piecus rakstus (jau formatētus). Krietni loģiskāk būtu definēt klasi Post, kura reprezentētu vienu rakstu kā tādu (tam atbilstu viens ieraksts datubāzes tabulā). Klase Post varētu sevī ietvert definīcijas (aprakstus) gan attiecībā uz datubāzes tabulas laukiem, gan saturēt kā mainīgos visu lauku vērtības, kad klase Post tiek reāli izveidota par KONKRĒTU objektu - KONKRĒTU rakstu. Tāpat arī klase Post varētu implementēt rakstam specifiskas funkcijas - piemēram - pievienot komentāru, pievienot bilžu galeriju, nomainīt autoru vai whatever. Ja tas tiek organizēts šādi, tad līdz automātiskai SQL ģenerācijai ir viens solis - jāuzraksta klase piemēram DBRecord un mūsu apskatāmā klase Post ir jāatvasina no šīs klases. Klasei DBRecord būs pieejama visa informācija par Post laukiem, kā arī klasei Post būs pieejamas klases DBRecord funkcijas. Un šajā modelī (hipotētiski), lai izselektētu kaut kādu rakstu: $a = new Post(); $a->db_get_by_primarykey($vajadziigais_raksts); Un nekādu SQL murgu. db_get_by_primarykey() ir klases DBRecord funkcija, kas SQLu ģenerē automātiski, izejot no klasē Post definētajiem mainīgajiem, izpilda šo SQLu un klases Post mainīgajos ieraksta izselektētās vērtības. Tālāk jau operējam vienkārši: $a->set_field_value('comment_count', $comment_count); $a->db_update(); Arī db_update() ir klases DBRecord funkcija, kas māk izveidot un izpildīt UPDATE vaicājumu. Pagaidām šis modelis neapskata vairāku ierakstu izselektēšanu vienā rāvienā - priekš tam būtu jāraksta jauna klase, piemēram DBRecordSet, kurai padodot objekta tipu un vairājuma parametrus, varētu saņemt pretī masīvu no objektiem, kurā katrs elements reprezentē konkrētu objektu. Vienkāršākais piemērs (izselektēt visus rakstus): $rs = new DBRecordSet(new Post()); $results = $rs->db_select(); include('templates/show_posts.inc'); Nu un show_posts.inc ir pieejams $results mainīgais (masīvs no Post objektiem), ar kuru tad var arī operēt (piem izdrukāt katra raksta komentāru skaitu): foreach($results as $article) { echo '<div class="post">'.$article->get_field_value('comment_count').'</div>'; } Lūk arī maģiskais presentation layeris, kuram neparko citu nav jāsatraucas, kā tikai izvadīt to kas jāizvada. Un iet ieskrieties visi Smarty un citi brīnumi, kas paredzēti tikai lai apgrūtinātu cilvēkiem dzīvi. Nu ja. Karoch tas viss ir reāli iespējams (arī ar PHP4, tiesa gan ar PHP5 glaunāk) - es pats šādi jau labu laiku kodēju un nezinu bēdu :-)

Ehm... Klases jau nebūvē pēc tā, kur viņas pielieto. Lasīju pavirši, bet salikās, ka klase Posts ir izveidota tikai tāpēc, ka kaut kur projectā ir vieta, kur jādrukā komentārus. Klases būvē atbilstoši zobratiņiem, kas to visu pasākumu kustina. Skat kā - saliec 100 zobratiņus pareizi vienu ar otru kopā - vot tev i ātrumkārba!! (jauna klase). Saliec pareizi kopā ātrumkārbu ar motoru, stūri, riteņiem etc... vot tev i mašīna (atkal jauna klase). Baigi interesanti pie tam ir tas, ka es te lasu šito forumu (šodien tikai iesāku) un nespēju nobrīnīties - lielākā daļa tautas raksta no sērijas: class Posts { function print_posts() { return '<pilns ar HTMLu>'; } } kāda reāli no tā jēga??? tas ir tipa tas pats, kas rakstīt bez klasēm, tikai kodu mākslīgi sabāzt klasēs, jo tāpat jau pēc tam notiek parsings pa visu PHP dokumentu, kurš ir mikslis no HTML (vai includēm) un PHP gabaliem un atšķirībā no include(something) tu lieto echo $posts->print_posts(); Tad jau labāk: $p = new Posts(); $p->get_posts($_GET['article_id']); include('templates/post_showing_template.inc'); Web projectiem tas pasākums vēl ir salīdzinoši triviāls - vienīgās lietas, ko reāli gribās ir: 1) object persistance (1:1 klašu mapošana pret SQL tabulām); 2) lai nav pašam SQLi visu laiku jākomponē. Pārējam salīdzinoši po, izmantot klases vai nē. No klasēm ieguvums ir tikai tīrāks kods (kuru grūtāk lasīt vidusmēra cilvēkam).

Interesē pieredze - ir/nav, sanāk/nesanāk, ērti/neērti, rules/sucks un cita veida pārdomas. Runa ir par Phrame un PHP.MVC. Kādu laiciņu provēju ar šiem kaut ko darīt bet beigās nosliecos ņe to gluži savu frameworku uzrakstīt, bet vismaz savu metodoloģiju ieviest, kas pa lielai daļai nodrošina visu MVC burvību. Tagad sirdsapziņa neliek mieru - moška nevajadzēja?

Tipa tā - nesapratu precīzi ko domāji, bet doma tāda, ka jā, patiešām ar apostrofiem un pēdiņām iekš PHP ir liela ķēpa. Iesaku iekš php.ini uzstādīt magic_quotes_gpc=off un tālāk rīkoties sekojoši: 1) pirms kādu stringu liekam iekšā SQL statementā, izpildam uz viņa addslashes() 2) pirms kādu stringu (kas ir izselektēts no SQL) izvadīt HTMLā, izpildam uz viņa htmlspecialchars(). Un nebūs problēmu, ja vien neaizmirsīsi šīs 2 funkcijas pareizajās vietās lietot.