wintermute

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.

Varbūt pienācis laiks atmest alert() un sākt izmantot console.log() kā lielam puikam ?

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.

Izmantojot SUBSTRING() metodi. Darbojas visās populārajās SQL datubāzēs.

Tātad šitas ir viens no "kā es varu novilkt ss.lv php failu ?" jautājumiem. Heh.

un ko tiešit tu nevari uztaisīt ?

Rādi kodu, vai arī ej uz http://sirups.kasjauns.lv/lv/forum.html

Ja serveris ir tavs : salabo php.ini failu. Ja nav - tad pašā skripta sākumā ieliec: ini_set('display_errors', 1 ); error_reporting( E_ALL | E_STRICT );

http://tinyurl.com/3clszb5

http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html

Šajā foruma par to nevar būt drošs ..

Ak jel. Kāds sakars programām ar to vau tu izmant KDE vai Gnome ? Lai palaistu KDeveloper tev nevajag darbināt KDE ! Besides: gan Zend Studio, gan Aptana Studio, gan Komodo Edit, gan Netbeans ir pieejami uz visām OS. Un kas ir ar šito epidēmiju ar dažādām Ubuntu modifikācijām ?! Gribi ātru OS - iemācies uzinstalēt normālu distributīvu.

nu lieto kādu citu: http://uk.php.net/ http://fi.php.net/ http://ee.php.net/

mirstigais, beidz lieto @ kā rīku kļūdu slēpšanai. Tā metode padara kodu lēnāku un apgrūtina debuging'u.

Papildinājums yeahz domām: http://wordpress.site5.net/rockwell/doc/

Tu labāk apskaties iekš phpinfo() vai tev ir GD extension's ielādēts.

Ieleic pašā lapas sākumā šito: ini_set('display_errors', 1 ); error_reporting( E_ALL ); Un parādi mums, kādas kļūdas tu redzi.

Eh ... tak tu āksts esi. Ko tad tu biji gaidījis ? http://lmgtfy.com/?q=%22www.lapa.lv%22+-site%3Alapa.lv+-LTD+%20site%3A.lv

Drošvien kaut kas apmēram šitāds: RewriteRule ^/forums(.*)? /e107_plugins/forum/forum.php?param=$1 RewriteRule ^/services(*.)? /page?15&param=$1 Vai kaut kā līdzīgi... slinkums testēt. RTFM : http://httpd.apache.org/docs/current/mod/mod_rewrite.html WTF ?

Vispār jau drošvien biji domājis: $path = dirname(__FILE__); $root = $_SERVER['DOCUMENT_ROOT']; $external_path = str_replace( $root , '' , $path ); define("FPATH", $external_path); Vai kaut ko tādā stilā. Un protams ir jau arī vēl <base>. Bet tie visi ir bugfix'i priekš līka risinājuma, kurš uztaisīts problēma, kuru kāds nebija spējīg pareizi nodefinēt. Pointless...

Tatad tu citiem stāsti stulbības, tāpēc ka tev pašam rokas līkas ? Interesanta pieeja.

deGrevis, nav tur nekāda css faila tai plugina instalācijā. Šams iekopēja kodu, ko tu tik pat labi vari dabūt arī http://www.sterling-adventures.co.uk/blog/2009/01/01/comments-with-avatars/ Autor, vai tev tiešām neienāca prātā, ka, kad tu labo CSS gļuku, PHP kods ir bezjēdzīgs !? Tā vietā tev vajadzēja ietot linku uz dzīvu lapu ( kur visi var pabakstīt css un html ), vai vismaz iemest css un html saturu kaut kur internetā un pievienot bildi ar "kas nav pareizi". Ehh ..

Nu ko tu tur dirs tagad !? Ar ko vairāki proekti uz viena domeina atšķiras no tiem pašiem vairākiem projektiem uz localhost ? Vai varbūt uz lokālā webservera tu neesi spējīgs vhost sakonfigurēt ?

Absolūts ceļš ir tas kurš šākas vai nu ar "/" vai ar "http(s):". Ja tu bildēm, css'am un scriptiem uzliec linkus kas sākas ar "/" , tad mainot hostu problēmas nekādas nebūs.

A davai ka iemacies css/html pamatus, ko ? http://htmldog.com/guides/ Jo tev pat neienak prātā , ka uz tavu jautājumu "KUR", neredzot kodu nevar atbildēt ..