ezis Posted November 30, 2011 Report Share Posted November 30, 2011 (edited) Aiz gara laika strādāju pie Template klases (iesācēja līmenis, tāpēc STFU!). Būtu labi, ja iekš php templates varetu ielādēt kontrolierus (jā, paštaisīta +/- MVC sistēma, turas kopā uz puņķiem, bet taisu savu, jo mācos), tāpēc domāju par funkciju iekš šīs klases, lai viņus varētu izsaukt! Tad tā php template varētu izskatīties šādi: <?php $this->css(); ?> <table> <tr> <td> <?php $this->panel('members/stats'); ?> </td> </tr> <tr> <td> <?php $this->panel('applikacija/iespeja/arguments/arguments'); ?> </td> </tr> </table> Kontrolieri iekš tempaltes tiek izsaukti ar URI līdzīgu stringu, laikam tā to nosaukt. Tik tālu viss ok. Bet, ja iekš katra kontroliera ir funkcija, kas pievieno piemēram css, tad tas $this->css() nevarētu uzģenerēt css includes, jo paneļi tiek izsaukti pēc $this->css()! Tad tālāk rīkojos tā, ka tā panel funkcija nevis atgriež kontroliera saturu, bet atstāj aiz sevis "pirkstu nospiedumu!" Tā vietā tiks ielikts kontroliera saturs! Arī funkcija css() aiz sevis atstās pirkstu nospiedumu, kur tad vajadzētu saģenerēt tās css inkludes. Izskatās aptuveni šādi: function panel($name) { $this->panels[] = $name; echo '\'.$panel_'.$name.'.\''; } echo '\'.$panel_'.$name.'.\''; tiek izmantots tāpēc, ka tālāk ar eval palīdzību tiks palaists tempalte saturs! Piemēram: function tpl() { ob_start(); include 'tpl.php'; $tpl = ob_get_clean(); foreach($this->panels as $p) { ${'panel_'.$p} = $p(); } eval('echo \''.$tpl.'\';'); } Viss strādā, tiek atstāti pirkstu nospiedumi, piereģistrēti css faili un viss salitks pa vietām izmantojot šādu tpl struktūru. Bet es nezinu cik tas viss ir efektīvi un droši. Izmantot str_replace un piemēram {SIDE_PANEL} nevēlos kaut kā, jo tas str_replace darboajs abos virzienos un viņš var pārdefinēt kko vēlreiz, piemēram, ja jau iepriekš aizstātā {SIDE_PANEL} ir piemēram saturs, kurā ir arī šāda paša tipa apzīmējums {...} Tad sanāk, ka Tur ir lieki str_replace. Man arī patīk labāk iekš tempalte izmantot piemēram <?php $this->panel('members/stats'); ?> nevis {SIDE_PANEL} un tad iekš kāda kontroliera definēt, kas tad būs tas sānu panelis. Šādi viss notiek +/- pa "tiešo"! Rīkojos šādi, jo tā liekas viss ērtāk. Nezinu cik resursietilpīgi un atjautīgi tas ir. Varbūt ir kāds labāks piemērs, ka šādā manierē to var paveikt? Strādājošs piemērs: template.zip Edited November 30, 2011 by ezis Quote Link to comment Share on other sites More sharing options...
ezis Posted December 1, 2011 Author Report Share Posted December 1, 2011 (edited) Ideja tomēr nedaudz aplama. Problēmas sākas, ka parādās pēdiņas template, tāpēc šur tur izmaiņas: function panel($name) { $this->panels[] = $name; echo '<?php echo $'.$name.'; ?>'; } function tpl() { ob_start(); include 'tpl.php'; $tpl = ob_get_clean(); foreach($this->panels as $p) { $$p = $this->get_panel_data($p); } $css=$this->getCSS(); # tiekam valja no liekiem speishiem //$tpl = preg_replace('/>\s+</','><',$tpl); eval(' ?>'.$tpl); } Tagad eval izpilda šādu no tempaltem un vieview saņemto saturu: <html><head><?php echo $css; ?></head><body><table><tr><td><?php echo $test_panel; ?></td></tr><tr><td><?php echo $test_panel2; ?></td></tr></table></body></html> un problēmas it kā nekur nav.. (: Edited December 1, 2011 by ezis Quote Link to comment Share on other sites More sharing options...
briedis Posted December 1, 2011 Report Share Posted December 1, 2011 (edited) Reāli, ko tu te muhļī? :) Šādas perversijas nav vajadzīgas: echo '<?php echo $'.$name.'; ?>'; Nekādi templeiti arī nav vajadzīgi. Pietiek ar parastu .php failu, kas satur HTML un tīri izvada citus datus html struktūras veidā. users.php skats, ko iekļaujam vajadzīgajās vietās <div> <? forach($users as $user): ?> <p> Lietotājs: <?=$user->username;?> </p> <? endforeach; ?> </div> Tad ir galvenais skats, piemēram, index.php : <html> <head></head> <body> <p>Blablalbla</p> <? include "/views/users.php"; ?> </body> </html> Kontrolieris paņem no DB lietotāju sarakstu, padod to skatam, un padod skatu attēlošanai. Kontorlieris izskatītos šādi: function index(){ $view = new View("/views/index.php"); $view->users = Model_Users::getUserList(); $view->render(); //Tiek parādīts skats } Bet principā tas, ko tu tur gribi panāk ar MVC nav tik ērti panākams, tur jau būtu jāizmanto HMVC. Edited December 1, 2011 by briedis Quote Link to comment Share on other sites More sharing options...
codez Posted December 1, 2011 Report Share Posted December 1, 2011 (edited) iesaku ieviest tādu lietu kā parent kontroleris, kurš tiek automātiski izssaukts un tam pa vidu tiek iesprausts child kontrolieris. Tas būtu aptuveni: // \controllers\mainpage.php class MainPage extends Controller{ } // \templates\mainpage.php <html> <head></head> <body> <div id="header"></div> <div id="wrapper"> <?php echo $childcontent; ?> </div> <div id="footer"></div> </body> </html> // \controllers\somepage.php class SomePage extends Controller{ public $parent='MainPage'; } // \templates\somepage.php Hello, I am somepage and will be wrapped into mainpage. Edited December 1, 2011 by codez Quote Link to comment Share on other sites More sharing options...
ezis Posted December 1, 2011 Author Report Share Posted December 1, 2011 (edited) Tagad man ir aptuveni tā kā codez piemēra, bet es vēlos ko savādāku. Ērtāk taču ir visu ko vajag salikt "templeitā"!? Piemēram, paneļus, menu utt.. Tie visi ir atsevišķi kontrolieri. Katrs kontrolieris pievieno savu css failu template masīvam, un tad iekš tempalte ir tas $this->css(); Bet kā gan masīvs var saņemt css, ja piemēram ir secība: $this->css(); $this->panel('some/panel'); ? Tāpēc arī rīkojos tā. Joprojām nešķiet muhļīšana, bet gan pamatots iemesls.. :? un man tas šķiet diezgan ērts, bez dullām HMVC, kur ir tūkstošiem rindu, lai tik izvadītu parastu lapu! o0 Ceru, ka sapratāt! Edited December 1, 2011 by ezis Quote Link to comment Share on other sites More sharing options...
Toms Posted December 1, 2011 Report Share Posted December 1, 2011 Vienīgais labums no šādas divriteņa izgudrošanas ir - kaut ko iemācīsies. Un kad būsi iemācījies pietiekoši daudz, tad sapratīsi, ka labs HMVC nav nemaz tik daudz rindiņas un tomēr izpildās ātrāk un ir ar mazāk kļūdām un vairāk fīčām nekā paša meistarotais. Varbūt liksies interesanti un noderīgi: http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/ http://techportal.ibuildings.com/2010/11/16/optimising-hmvc-web-applications-for-performance/ P.S. HMVC nav neērts un dulls ar tūkstoš rindām priekš prastas lapas. Prastai lapai vispār HMVC nav vajadzīgs, jo nav kur to pielietot. Quote Link to comment Share on other sites More sharing options...
ezis Posted December 1, 2011 Author Report Share Posted December 1, 2011 njam, Paldies Toms! Esmu jau kkur šos rakstus redzējis! Mans Divritenis tomēr darbojas nedaudz savādākā manierē, līdz ar to piegājiens un veids kā to realizē ir savādāks. Vienu lietu var realizēt dažādo veidos. Mācība ir un paliek mācība. (: K, nedaudz paburšos cauri. Neesmu daudz pētījis gatavus variantus. Cenšos izaicināt sevi, tāpēc daru pats. :P Quote Link to comment Share on other sites More sharing options...
codez Posted December 1, 2011 Report Share Posted December 1, 2011 (edited) Vienīgais labums no šādas divriteņa izgudrošanas ir - kaut ko iemācīsies. Un kad būsi iemācījies pietiekoši daudz, tad sapratīsi, ka labs HMVC nav nemaz tik daudz rindiņas un tomēr izpildās ātrāk un ir ar mazāk kļūdām un vairāk fīčām nekā paša meistarotais. Ne vienmēr šis ir patiesība. Es MVC kodolu pielāgoju katram projektam atsevišķi un pēc vajadzībām, jo tieši tā - HMVC nav tik daudz rindiņu. Un manējais - taisot benčmarku, ir daudz ātrāk, kā visi OSS pieejamie. Tā, ka ja nodrabojies ar riteņbraukšanu profesionāli, bieži atmaksājas pielāgot savu riteni vajadzīgajam uzdevumam, nevis izvēlēties no plaukta gatavu. Edited December 1, 2011 by codez Quote Link to comment Share on other sites More sharing options...
Toms Posted December 1, 2011 Report Share Posted December 1, 2011 (edited) Profesionāls riteņbraucējs kvalitatīvu riteni pielāgo kad nepieciešams, nevis izgudro no nulles. Jo izgudrot no nulles - tas ir laiks un darbs, ko profesionālis ne vienmēr var atļauties tērēt. Ja tev jau ir savs divritenis, kas pierādījis sevi neskaitāmās sacensībās, tad viss kārtībā. Bet savu frameworku ir arī jāattīsta, kas atkal prasa laiku.. Es neieteiktu taisīt savu frameworku kā tikai mācību nolūkos vai tajos retajos (nevis biežajos) gadījumos, kad tiešām vajag custom risinājumu. Interesanta lasāmviela par tēmu :) Edited December 1, 2011 by Toms Quote Link to comment Share on other sites More sharing options...
ezis Posted December 1, 2011 Author Report Share Posted December 1, 2011 Interesanta lasāmviela gluži nē, bet gōgle saites noteikti.. . No tām "Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels" es domāju, ka vairāk attiecas uz mani. Es neveidoju komerciālus web risinājumus klientiem. Es neesmu PHP etc. programmētājs. Es mēģinu saviem spēkiem iemācīties kā konkrētu problēmu atrisināt ar savu piegājienu! Tikpat labi, kāpēc lai es šobrīd izmantotu CI vai ko citu? Kāpēc gan, lai es mēģinātu pielāgot kaut ko gatavu sev, ja es neesmu riteņbraucējs, bet varbūt "wannabe" inženieris? Tas tik tā, starp citu runājot, jo tad kāpēc nav viens universāls ietvars, ko izmanto visi, bet gan pietiekoši daudz pielāgoti? Nemaz negribu sagaidīt atbildes uz šo jautājumu, jo varu tās iedomāties :D Bet tas par to riteni un cik daudz un dažādas konfigurācijas, manuprāt nav tik svarīgi, jo par katru gadījumu var diskutēt daudz un dikti. Mans gadījums ir par to, ka es mācos nevis iepazīt jau esošos, bet veidot savu un tad salīdzināt, kur esmu nošāvis greizi, pat ja esmu! Jo kā jau teicu, vienu un to pašu lietu, bieži vien, var panāk dažādos ceļos. Tur kur viens saskata advantages tur cits disadvantages! Tāpēc domāju, ka tālāk par to diskutēt nebūtu vērts. Labāk parunāt par to vai konkrētie piemēri atrisina konkrēto problēmu! :P Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted December 3, 2011 Report Share Posted December 3, 2011 (edited) Profesionāls riteņbraucējs kvalitatīvu riteni pielāgo kad nepieciešams, nevis izgudro no nulles. Jo izgudrot no nulles - tas ir laiks un darbs, ko profesionālis ne vienmēr var atļauties tērēt. Ja tev jau ir savs divritenis, kas pierādījis sevi neskaitāmās sacensībās, tad viss kārtībā. Bet savu frameworku ir arī jāattīsta, kas atkal prasa laiku.. Es neieteiktu taisīt savu frameworku kā tikai mācību nolūkos vai tajos retajos (nevis biežajos) gadījumos, kad tiešām vajag custom risinājumu. Interesanta lasāmviela par tēmu :) Tu arī programmē un brauc ar riteni? Pozitīvi! Kā redzams, tas iztīra galvu no murgainām idejām, kas rodas "aiz gara laika". Priekš codez: Ja runājam par riteni, sacensību braucēji neko nepielāgo ritenim. Viņiem riteni iedod komandas mehāniķi, bet komandas mehāniķiem - sponsori. Savukārt sponsoriem - lielie ražotāji. Pats braucējs varbūt pielāgo riteņa ģeometriju, bet ne jau ķēdes vietā ieliek kardānu vai saliek nestandarta izmēra riteņus. Visa riteņa attīstība ir viens liels process, kur viss notiek organiski, gadu no gada tendences mainās, un tām seko līdzi visi. Protams, katrai disciplīnai ir savs ritenis, bet tā, ka kāds tur baigi pielāgotu - tā nenotiek. Nozare ir noslīpēta līdz pēdējai skrūvītei, pašdarbībai nav vietas. Tavā gadījumā runa ir par tavu no caurulēm sametināto frīkbaiku vs. vadošo ražotāju top klases modeļiem. Tu vienkārši nespēj uztaisīt ražotni ar krāsnīm, testēšanas mašīnu 24h laikā kas simulē gadiem ilgu rāmja nodilumu u.c. lietas. Bet dzīvē arī frīkbaikiem ir sava vieta, un gadās, ka klients par riteņa cenu nopērk arī maximas brīnumu. Ja tāds ir jūsu bizness un jūs ar to lepojaties, okay, tā ir jūsu izvēle... Edited December 3, 2011 by Mr.Key Quote Link to comment Share on other sites More sharing options...
codez Posted December 3, 2011 Report Share Posted December 3, 2011 Mjā, esam iegājuši riteņubraukšanas tēmā un ar to mēģinām izdomāt, kā lābāk programmēt. Bet vienu varu teikt, esmu mēģinājis daudzus populārākos frameworkus un viņiem visiem ir ducis ar lietām, kuras es nosauktu par debīlām, sākot jau ar to, ka visos ir pamatīgas problēmas ar principa "Do not repeat yourself" neievērošanu un "Loose coupling" neivērošanu. Un tāpēc esmu nonācis pie secinājuma, ka vislabāko freimworku var dabūt, zinot savas vajadzības, būvējot to priekš tām un ņemot tikai labās lietas no daudzajiem OSS freimworkiem. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted December 3, 2011 Report Share Posted December 3, 2011 Ļoti interesē, kā, piemēram, "Do not repeat yourself" un "Loose coupling" netiek ievērots Zend Frameworkā. Quote Link to comment Share on other sites More sharing options...
briedis Posted December 3, 2011 Report Share Posted December 3, 2011 (edited) Kāda starpība, ja pats ietvars strikti ievēro DRY un Loose coupling'u, bet pats programmētājs raksta sūdīgu kodu? Manuprāt nav nozīmes ietvaram, galvenais, lai pašam ērti strādāt. Tas, cik kvalitatīvs kods beigās būs, ir taču atkarīgs no paša programmētāja. Tikko sāku jaunu projektu iekš Kohanas :p Edited December 3, 2011 by briedis Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted December 3, 2011 Report Share Posted December 3, 2011 Bieži vien sūdīgs kods un sliktas domas par FW rodas elementāra slinkuma (nevēlēšanās pilnībā izprast FW darbību). Kaut vai tāda elementāra lieta, kā kodēšanas standarts. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.