Viks Posted February 22, 2011 Report Share Posted February 22, 2011 Daudzus gadus iepriekš uzgāju PhpWcms. Vācu puiši to stutē. Quote Link to comment Share on other sites More sharing options...
foxsk8 Posted February 22, 2011 Report Share Posted February 22, 2011 Daudzus gadus iepriekš uzgāju PhpWcms. Vācu puiši to stutē. Bet vai tas ir labākais? :) Par tādu pirmo reizi dzirdu. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted February 23, 2011 Report Share Posted February 23, 2011 Starp citu,WordPress 3.1 ir gatavs! Quote Link to comment Share on other sites More sharing options...
Toms Posted February 24, 2011 Report Share Posted February 24, 2011 Starp citu, Kohana 3.1 ir gatavs! Quote Link to comment Share on other sites More sharing options...
daGrevis Posted February 24, 2011 Report Share Posted February 24, 2011 Kohana 3.1 jau sen ir gatava... =P WordPress 3.1 tikai kopš 22/02. =) Quote Link to comment Share on other sites More sharing options...
martinsdudeks Posted April 12, 2011 Report Share Posted April 12, 2011 php comasy :) bet nenoliegsu kad wordpress ir labakais,neatkartosu visus ieprieks minetos piemerus kadel ! Quote Link to comment Share on other sites More sharing options...
anonīms Posted April 12, 2011 Report Share Posted April 12, 2011 Ja agrāk es te nerakstītu vispār, jo CMS nepatika, tad tagad, kad nekas cits neatliek, tad noteikti drupal. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted April 12, 2011 Report Share Posted April 12, 2011 Ja būtu izvēle... sagaidītu mažorversiju "Fuel'am" un lai uz tā pamata top kas burvīgs! Quote Link to comment Share on other sites More sharing options...
wintermute Posted April 13, 2011 Report Share Posted April 13, 2011 daGrevis, a tu novelc RC versiju un sourci paskaties. Tur takš' ir pinlīgs vājprāts, kas sarakstīts. Ja godīgi - es no tā FW turētos pa gabalu. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted April 13, 2011 Report Share Posted April 13, 2011 Vājprāts? Kur Tu to redzi? Quote Link to comment Share on other sites More sharing options...
daGrevis Posted April 14, 2011 Report Share Posted April 14, 2011 Wintermute, Es patiešām gribētu redzēt kur Tu redzi to "vājprātu"? Cik pats redzu (un dzirdu) - Fuel's ir patiešām labi izveidots - ņemot vērā to, ka tas ir tikai RC1 stadijā. Vai varbūt Tev ir iebildumi kā tādi pret MVC arhitektūru (HMVC?) vai objektu-orientēto programmēšanu, PHP kā tādu?? Quote Link to comment Share on other sites More sharing options...
Kverkagambo Posted April 14, 2011 Report Share Posted April 14, 2011 Ko domājat par Bertu? Es nesen par tādu uzzināju, pabrīnījos par tādu. Quote Link to comment Share on other sites More sharing options...
wintermute Posted April 15, 2011 Report Share Posted April 15, 2011 Wintermute, Es patiešām gribētu redzēt kur Tu redzi to "vājprātu"? Cik pats redzu (un dzirdu) - Fuel's ir patiešām labi izveidots - ņemot vērā to, ka tas ir tikai RC1 stadijā. Vai varbūt Tev ir iebildumi kā tādi pret MVC arhitektūru (HMVC?) vai objektu-orientēto programmēšanu, PHP kā tādu?? Man nav iebildumu ne pret OOP, ne pret (H)MVC , ne arī pret PHP. Bet man ir iebildumi pret sliktu OOP, parodijām par MVC (bet tas attiecas uz gandīz visiem php framework'iem .. neskaitās) un bardaku PHP kodā. Es tikai nezinu no kura gala, lai te ķerās klāt .. referātu negribas rakstīt. Ok , tā .. slikts OOP. ------------------------------------------- Viena no vispārzināmām OOP praksēm ir šāda: katra metode 'zin' tikai par tiem objektiem, kuri šai metodei ir tikuši padoti vai jau pieder metodi saturošajam objektam( wiki links ). Piemērs kas ir pretrunā ar šo praksi: $foo = new Bar(); $x = new Thing(); echo $foo->get_n(); // izvada 1 echo $foo->get_n(); // izvada 1 $x->do_something(); echo $foo->get_n(); // izvada 9 Šinī gadījumā , metodes do_something() izpildīšana objektā $x izraisīja izmaiņas objektā $foo, lai gan tie nav nekādā redzamā veidā saistīti. Šādu uzveidību parasti rada globali mainīgie, vai cita veida globals stāvoklis ( singletoni , reģistri un citas struktūras kas izmanto statiskus mainīgos/funkcijas ). Un diemzēl Fuel prakstiski visas Core klases satur vienīgi statiskas metodes un mainīgos. Ja tu raksti klasi , kurā ir tikai statiskas metodes , tad tas nav OOP, bet gan procedurāls kods, kas 'ietīts' iekš namespace'ā. P.S. lielākajā daļā "tīro" OOP valodu ( Scala, Smalltalk, etc. ) nemaz nav tāda keyword'a static. ------------------------------------------- Nākamā problēma : cieša koda sasaistīšana. Viena no labākajām OOP fīčām ir polimorfisms ( polymorphism ), kurš protams Fuel frameworkā netiek izmantots. Rezultātā neeksistē veids kā realizēt veikt atkarību iekļaušanu ( Dependency Injection ), un tā vietā izstrādātāji oficiāli iesaka "vienkārši nosauc klasi tāpat kā mēs to saucam un ielādē no citas lokācijas". Un tad vēl protams ir ORM. Kas ticis veidots pēc ActiveRecord pattern'a. Triks ar šo patternu ir tāds, ka Domeina Modelis tiek neatraujami sasaistīts ar datubāzes struktūru un veic "maģiskas" darbības. Rezultātā, ja tiek, piemēram, mainīts nosaukums kolonai tabulā, tad ir jāmaina arī Modelis un visas klases, kas ar to saistītas. Lielākā aplikācija rodas tāds kā lavīnas effekts. ------------------------------------------- Ehh .. apnika. Nedaudz par MVC. ( ) Tātad, ko dara katra komponente: Model - domeina modelis. Atbild par aplikācijas biznesa loģiku. Modelis nav ORM un (ideālā gadījumā) pat nezin, ka tā ir datubāze no kuras nāk dati, un kurā tie tiek saglabāti; View - skats. Atbild par lapas attēlošanas loģiku, templeitu renderēšanu un pieprasa informāciju no modeļiem (skats nemaina modeļu stāvokli, informācija parvietojas tikai vienā virzienā - no modeļa ); Controller - kontrolieris. Piesaista izvēlētos modeļus skatam un veic izmaiņas modeļu un skata stavoklī.(informācija pārvietojas tikai vienā virzienā - no kontroliera uz skatu un modeļiem ) Protams ka Fuel tā nav. View ir pliks templeits, Controlieris satur presentācijas loģiku un Modelis ir burtiski saaudzēts ar datubāzi. Un tad vēl ir tā dīvainā situācija, kad Request klase kontrolē Controller instance .. ok , tas ir vienkārsi dīvaini. ------------------------------------------- Un kas attiecas uz bardaku , tad neizplūdīšu sīkumos. Metodei ir jāpilda viena un tikai viena funkcija. Ja metodei viens no parametriem ir boolean, tad tur drošvien bija jābūt divām metodēm nevis vienai. Ja metodes parametros ir divi boolean'i, tad programētājs no rīta nav savus 'vitamīnus' iedzēris. Ja metodes nosaukums sākas ar "is_", tad tā atgriež boolean'u , nevis dažreiz atgriež booleanu un dažreiz atgriež objektu. Ja metodes nosaukums sākas ar "set_", tad tā neko neatgriež. Utt., utjp.. Ja tu lieto frameworka core klasēs @ priekš kļūdu apspiežanas , tad tev vajag pa kaklu. Apnika. Drukas kļūdas nelabošu. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted April 15, 2011 Report Share Posted April 15, 2011 Nu jā, taisnība jau ir. Bet vai tad tas nav ne tikai ar Fuel'u, bet arī ar citiem tamlīdzīgiem "framework'iem"? CodeIgniter, Kohana, CakePHP... pat Zend?! Ir. Varbūt Viņi neseko striktam MVC arhitektūras piemēram... bet "kamoon", tas ir PHP, nevis kaut kāds C++ vai Java. Rezultāts ir apmierinošs. Jebkurā gadījumā... ko tu iesaki? Rakstīt visu no nulles? Nē? Lūdzu priekšlikumus ideālam "framework'am". P.S. Necenšos Tevi apstrīdēt (redzami esi gudrāks par Mani)... vienkārši, pats gribu zināt. Quote Link to comment Share on other sites More sharing options...
codez Posted April 15, 2011 Report Share Posted April 15, 2011 Sarakstīt jau nu daudz trololo, bet nu labi, pakomentēšu... Viena no vispārzināmām OOP praksēm ir šāda: katra metode 'zin' tikai par tiem objektiem, kuri šai metodei ir tikuši padoti vai jau pieder metodi saturošajam objektam( wiki links ). Protams, ja tu nodarbojies ar dzenbudismu un tiecies uz kaut kādu iedomātu pilnību, tad jā. Praksē, tu obketiem nepadosi norādes uz tādiem objektiem, kā db objekts, kešošanas objekts, utt. Savādāk tev liela koda daļa pārvērtīsies par objektu inicializāciju ar kaudzi objektu padošanu. Praksē tomēr tiks izmantots kāda globāla saikne uz Factory, Singletona paterniem un pietam kopā ar autoload funkcionalitāti. Piemērs kas ir pretrunā ar šo praksi: $foo = new Bar(); $x = new Thing(); echo $foo->get_n(); // izvada 1 echo $foo->get_n(); // izvada 1 $x->do_something(); echo $foo->get_n(); // izvada 9 Šinī gadījumā , metodes do_something() izpildīšana objektā $x izraisīja izmaiņas objektā $foo, lai gan tie nav nekādā redzamā veidā saistīti. Piemērs, kur tu šo praksi nevari apiet. Datubāze. Tev ir divi objekti, kuri darbojas ar db. Nu netaisīsi tu katram savu konekciju tā viena iemesla dēļ, ka tad tu nevarēsi nodrošināt transakcijas. Un tad vēl protams ir ORM. Kas ticis veidots pēc ActiveRecord pattern'a. Triks ar šo patternu ir tāds, ka Domeina Modelis tiek neatraujami sasaistīts ar datubāzes struktūru un veic "maģiskas" darbības. Rezultātā, ja tiek, piemēram, mainīts nosaukums kolonai tabulā, tad ir jāmaina arī Modelis un visas klases, kas ar to saistītas. Lielākā aplikācija rodas tāds kā lavīnas effekts. Ja tiek mainīt nosaukums kolonai, tad arī aplikācijā ar plikiem SQL, tev būs jāmaina visi SQL, kur izmanto šo kollonu. Tāda ir dzīve. Bez tam izmantojot ORM, kuros kollonas definē modeļa definīcijā, db tabulas pa tiešu vispār neaiztiek, tā vietā to dara tūļi, kuri modeļa definīciju pārnes uz db. Nedaudz par MVC. ( ) Tātad, ko dara katra komponente: Model - domeina modelis. Atbild par aplikācijas biznesa loģiku. Modelis nav ORM un (ideālā gadījumā) pat nezin, ka tā ir datubāze no kuras nāk dati, un kurā tie tiek saglabāti; View - skats. Atbild par lapas attēlošanas loģiku, templeitu renderēšanu un pieprasa informāciju no modeļiem (skats nemaina modeļu stāvokli, informācija parvietojas tikai vienā virzienā - no modeļa ); Controller - kontrolieris. Piesaista izvēlētos modeļus skatam un veic izmaiņas modeļu un skata stavoklī.(informācija pārvietojas tikai vienā virzienā - no kontroliera uz skatu un modeļiem ) Par vienvirziena datu plūsmu, no modeļa, tikai uz view-u un no kontrolera tikai uz modeli. Praksē tas nav iespējams, jo kontrolerim gandrīz vienmēr būs nepieciešami dati no modeļa, lai veiktu tālākās darbības. Piemēram, tu nospied pogu pirkt. Kontrolerim ir jāpārbauda vai lietotājam pietiek nauda (no user modeļa), jāpārbauda vai noliktavā ir prece (no storage modeļa), utt. un tikai tad, kad ir saņemti dati no vairākiem mopdeļiem, kontroleris var tālāk izlemt kādas darbības un izmaiņas veikt citos kontroleros un kādu view izsaukt. Man praksē ir pierādījies, ka vispraktiskākais datu plūsmas veids ir, no kotroler uz modeli, no modeļa uz kontroleri un no kontrolera uz view-u. [*]Metodei ir jāpilda viena un tikai viena funkcija. Kas tas par murgu? Jebkuru darbu var sadalīt smalkāk - jebkuru funkcionalitāti var sadalīt smalkāk. Tāpēc tāds jēdziens kā viena funkcija ir absurds. Metodei jāpilda tāda funkcionalitēte, kuru loģiskā veidā var atdalīt no pārējā un katrs gadījums ir individuāls. Pietam, viena metode var saturēt algoritmu, kurš izmanto vairākas citas metodes - bez tā nav iespējams iztikt. Pēc tavas šīs filozofijas, nav nemaz iespējams būvēt normālus aplikācijas abstrakcijas slāņus. [*]Ja metodei viens no parametriem ir boolean, tad tur drošvien bija jābūt divām metodēm nevis vienai. Un ko darīsi, ja būs int parametrs ar iespējamām 5 vērtībām? Taisīsi 5 funkcijas. Pietiek murgot. Sāc domāt. 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.