Aleksejs Posted July 13, 2009 Report Share Posted July 13, 2009 16 PHP Frameworks To Consider For Your Next Project Pirmās rindkopas tulkojums: Kādēļ tērēt vērtīgo laiku, kodējot visu no nulles? Freimworka izmantošana ir lielisks veids, kā ietaupīt laiku un pūles jūsu nākamajā projektā - jums būs stingrs pamats uz kā sākt būvēt, būs iepriekšizveidoti moduļi, lai veiktu nogurdinošos kodēšanas uzdevumus, un ja patīk mācīties, šis ir lielisks veids kā apgūt kodēšanas labo praksi. PHP milzīgā popularitāte nozīmē, ka izstrādātājiem ir plašs freimworku klāsts no kā izvēlēties. Mēs esam pārliecināti, ka varat atrast starp šiem 16 tādu, kas apmierina jūsu vajadzības. Ir ļoti īsi apskatīti: Agavi Akelos CakePHP CodeIgniter eZ Components Fuse Horde Kohana PHP on Trax PHPOpenBiz Qcubed Seagull Symphpony WACT Zend ZooP Quote Link to comment Share on other sites More sharing options...
endrju Posted July 13, 2009 Report Share Posted July 13, 2009 Varbūt padalies arī pats ar savu pieredzi, ja esi kādu no tiem lietojis vai turpini lietot. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted July 14, 2009 Author Report Share Posted July 14, 2009 Manā pieredzē pagaidām nav bijusi nepieciešamība lietot kādu frameworku, jo viss ko esmu taisījis ir ļoti vienkāršs pēc savas būtības, kam īsti neatmaksājas izmantot frameworku. Taču interese par šo lietu ir un ik pa brīdim pasekoju līdzi to attīstībai. Quote Link to comment Share on other sites More sharing options...
Web Developer Posted July 14, 2009 Report Share Posted July 14, 2009 Tas nav nekāds "apskats", tā ir "link-liste". Es biju informēts par lielāko daļu no šiem freimvorkiem, diemžēl, nav objektīvas analīzes daudzos apskatos, tai skaitā "performance" salīdzinājums, "security" testi utt. Vienkārši, vajag analīzi, nevis saišu katalogu. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted July 14, 2009 Author Report Share Posted July 14, 2009 Tev ir visas iespējas uzrakstīt šādu analīzi - feci quod potui faciant meliora potentes ;) Šo tēmu uzsāku ar domu, ka šeit varētu mest iekšā norādes tieši uz šādām atrastajām/izveidotajām analītiskajām publikācijām. Quote Link to comment Share on other sites More sharing options...
tas_pats Posted July 14, 2009 Report Share Posted July 14, 2009 (edited) Jau kādu laiku lietoju CodeIgniter, ātri apgūstams un neuzspiež striktus nosacījums. Nezinu kā ir patreiz (kā pārējie ietvari attīstījušies), bet kādreiz tas arī skaitījās ātrākais. Edited July 14, 2009 by tas_pats Quote Link to comment Share on other sites More sharing options...
Web Developer Posted July 14, 2009 Report Share Posted July 14, 2009 Jau kādu laiku lietoju CodeIgniter, ātri apgūstams un neuzspiež striktus nosacījums. Nezinu kā ir patreiz (kā pārējie ietvari attīstījušies), bet kādreiz tas arī skaitījās ātrākais. Ļoti slikti, ka neuzspiež striktus nosacījumus. Vismaz kodēšanā, pierakstā, stilā, arhitektūrā tādiem ir jābūt! Zini kā var būt strikti nosacījumi, bet elastīga programma? Quote Link to comment Share on other sites More sharing options...
tas_pats Posted July 14, 2009 Report Share Posted July 14, 2009 Nepiekrītu.. Viens no ietvaru galvenajiem mērķiem ir paātrināt programmatūras izstrādes procesu. Jo vairāk ierobežojumi, kam jāpiemērojas, jo vairāk tie samazinās izstrādes procesa ātrumu un vietām tie arī ierobežo aplikācijas elastību. Tāpēc, manuprāt, daudz labāk ir definēt vadlīnijas, kuras ieviešot un pie kurām pieturoties tu saproti to jēgu un jūti to devumu. Teiksim, pašos pirmsākumos, kad līdz ar šī ietvara apguvi, mēģināju apgūt arī MVC modeli. No sākuma neizpratu Modeļu (models) jēgu un būtību, tāpēc rakstīju (un CodeIgniter nespieda mani to darīt) visus vaicājumus kontroleros, nevis modeļos, līdz sapratu cik pārskatāmāku un lasāmāku kodu to izmantojot var iegūt. P.S. protams viss atkarīgs no tā ko katrs no mums saprot ar terminu "strikti ierobežojumi" Quote Link to comment Share on other sites More sharing options...
v3rb0 Posted July 14, 2009 Report Share Posted July 14, 2009 MVC kontekstā, modeļi nav tikai tāpēc, lai būtu atsevišķš fails kurā rakstīt kveriju palagus. Domā par modeļiem kā blokiem (ne vizuāliem) kurus līmē kopā kontrolerī, lai galā sanāktu vajadzīgā biznesa loģika. Quote Link to comment Share on other sites More sharing options...
foxsk8 Posted July 14, 2009 Report Share Posted July 14, 2009 (edited) Ir sanācis padarboties ar Symphpony, totāls murgs. vai nu arī man nebija vajadzīgā saprašana. Bija viens projekts, mini firmas webs, paskatījos kā galvenais veidojis uz Symphpony bāzes, lol 3K lieku failu parastam firmas webam. :D Ir reizes, kad lietot ir ok, ir reizes, kad to darīt nav jēgas. Jāskatās kam un kur. Edited July 14, 2009 by foxsk8 Quote Link to comment Share on other sites More sharing options...
Web Developer Posted July 14, 2009 Report Share Posted July 14, 2009 Nepiekrītu.. Viens no ietvaru galvenajiem mērķiem ir paātrināt programmatūras izstrādes procesu. Jo vairāk ierobežojumi, kam jāpiemērojas, jo vairāk tie samazinās izstrādes procesa ātrumu un vietām tie arī ierobežo aplikācijas elastību. Tāpēc, manuprāt, daudz labāk ir definēt vadlīnijas, kuras ieviešot un pie kurām pieturoties tu saproti to jēgu un jūti to devumu. Teiksim, pašos pirmsākumos, kad līdz ar šī ietvara apguvi, mēģināju apgūt arī MVC modeli. No sākuma neizpratu Modeļu (models) jēgu un būtību, tāpēc rakstīju (un CodeIgniter nespieda mani to darīt) visus vaicājumus kontroleros, nevis modeļos, līdz sapratu cik pārskatāmāku un lasāmāku kodu to izmantojot var iegūt. P.S. protams viss atkarīgs no tā ko katrs no mums saprot ar terminu "strikti ierobežojumi" Tik vienkārši tas viss nav. Tas MVC ir izdomāts lai atvieglotu projekta uzturēšanu un attīstību, nevis tieši sākotnējo izstrādi pirmajam rezultātam. Strikti ierobežojumi ir vajadzīgi, lai kods būtu pārskatāmāks, loģiskāks, vienveidīgāks un veidots pēc paraugiem, noteikumiem. Neviens freimvorks parasti tik ļoti "nespiež" darīt tā un tā, bet vēlams jau no sākuma iemācīties darīt tā kā ir pareizāk darīt. Modeli uztver kā datu modeli - tas ir objekts, kur glabājas tavi dati. Kā tu viņu uzpildi un sapildi, tas ir biznesa loģikas jautājums, tu to vari darīt "data supplier" klasē, kas var būt kā kontrollera sastāvdaļa, pēc tam tu šo modeli izmanto savā view, lai vienkārši attēlotu datus. Šitās lietas vienmēr ir vērts labi pārdomāt un pārskatīt, jo pēcāk tas tev ievērojami atvieglos darbu - tu zināsi - ā, šiten jāizdara tas un tas, tad man jāaiztiek tikai attiecīgais view un viss... Šeit vajag uzprogrammēt jaunus nosacījumus datu apstrādē ar jau esošiem esošie datiem - ok, pamainam kontroleri un viss aiziet, šeit mums vajag pievienot jaunu lauku datubāzē, ko pēc tam izmantot kodā - ok, uztaisam datubāzē un modelī šo jauno lauku, pēc tam bez problēmām izmantojam jebkur. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted November 20, 2009 Author Report Share Posted November 20, 2009 Šodien vēl klejojot plašajās Interneta ārēs ieraudzīju šādu: http://www.silverstripe.org/sapphire/ Quote Link to comment Share on other sites More sharing options...
Java Posted November 24, 2009 Report Share Posted November 24, 2009 Runājot par frameworkiem tieši uz php, ir pamēģināts, piemēram, ZendFramework. Pateikšu godīgi - tas izskatījās nevis pēc mēģinājuma atvieglot darbu un uzlabot tā kvalitāti, bet gan pēc mēģinājuma to sarežģīt un pārtaisīt pašu php tam neatbilstošā līmenī - kaut ko uz stingra OOP pusi kā Java, C# utml. Protams, tas ir SVIESTS! Php ir vienkārša skriptu valoda personīgajām mājaslapiņām, tāpēc nedomāju, ka tur vispār nepieciešams bāzt virsū kaut kādus mistiskus "frameworkus" jo php ir "frameworks" pats par sevi - ierobežotu iespēju valoda ar iebūvētām funkcijām un bibliotēkām. Var vienkārši ieviest vienotus MVC arhitekturālus patternus, bet nafig sarežģīt interpretējamu skriptu valodu, mēģinot uzlēkt augstāk par tās iespējām! Pirmkārt, php nemaz nav īsts tīrs OOP un nevar būt, tāpēc to ir absurdi izmantot kā tīru OOP valodu. Quote Link to comment Share on other sites More sharing options...
rATRIJS Posted November 24, 2009 Report Share Posted November 24, 2009 (edited) Nu jau, nu jau - ne jau ar php veido tikai "mazas personīgās mājaslapiņas". (nez kādēļ to vienmēr saka JAVA programmētāji) Freimworks paātrina izstrādes gaitu, konkrēti nosaka kur, kam ir jābūt, atvieglo programmētāju no daudz, viendabīgā, koda rakstīšanas. Par katra konkrētā freimwork'a izmantojamību jau ir cits stāsts. Domāju, ka daudzi freimwork'i ir iespaidojušies no citu valodu analogiem (Django, Rails) un mēģina attēlot to darbību. Ne vienmēr tas ir viegli izdarāms, vai vispār iespējams, bet kādēļ necensties. Edited November 24, 2009 by rATRIJS Quote Link to comment Share on other sites More sharing options...
Java Posted November 24, 2009 Report Share Posted November 24, 2009 Freimworks paātrina izstrādes gaitu, konkrēti nosaka kur, kam ir jābūt, atvieglo programmētāju no daudz, viendabīgā, koda rakstīšanas. Par katra konkrētā freimwork'a izmantojamību jau ir cits stāsts. Nē, "framework" nozīmē "ietvars". Reāli tas neatbild par izstrādes ātrumu vai gaitu. Tas neatbild arī par koda rakstības stilu, tas ir atkarīgs individuāli no programmētāja, tas var dot tikai ieteikumus. Koda rakstības stils paliek "valodas līmenī" un programmētāja paša "rakstības stila" līmenī, bet "freimvorks" par to tev neatbildēs. Jā, tas, ka frameworks var uzspiezt savu arhitektūru, tā ir patiesība un tas daļēji varētu būt arī freimvorka mērķis - pieprasīt, lai programmētājs veido programmu vēlamajā arhitektūrā, bet galvenokārt - tas piedāvā bibliotēkas, lai atvieglotu darbu pie vairāku veidu aplikāciju veidošanas - lai nav šīs lietas jātaisa pašam. Bet ir tāda veca patiesība - "kas der visam, neder nekam". Katrai valodai un frameworkam ir savs uzdevums. Bet ir vēl viena svarīga patiesība - universālai lietai jābūt vai nu perfektai vai tuvu perfektai. Un nevar censties uztaisīt "pilnīgāku, universālāku, advancētāku" (sauciet kā gribat) uz bāzes, kas nav tik "pilnīga, stabila, universāla, perfekta". Īsāk sakot, tas nozīmē, ka nav jēgas taisīt frameworkus, kas mēģina pildīt uzdevumus, kas sniedzas pāri php iespēju robežām, ja par "iespēju robežām" uzskatām "stabilas, viendabīgas un veiktspējīgas darbības kopu". Cerams, domu sapratāt. Domāju, ka daudzi freimwork'i ir iespaidojušies no citu valodu analogiem (Django, Rails) un mēģina attēlot to darbību. Ne vienmēr tas ir viegli izdarāms, vai vispār iespējams, bet kādēļ necensties. Kad cenšās, var arī pārcensties un beigās sanākt "bugi" un nopietnas nepilnības, kas liek rakstīt tā saucamos "hakus"! Vienam projektam šīs problēmas vēl var menedžēt, apkalpot un novērst, bet diezvai tūkstošu projektu bāzei, ja nevēlas vērā ņemamas "papildus izmaksas" gan laikā, gan naudā, gan nervos. 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.