NePo
Kovas 31, 2008

Kuriam savo TVS

Norėčiau pakviesti visus diskusijai apie tai, kas yra gera turinio valdymo sistema. Ne, teiginiai jog, “PHPnuke rulz” arba “Joomla zux” ne argumentas. Mes esame programuotojai, todėl pamėginkime išnarplioti… išardyti gerą turinio valdymo sistemą po kaulelį ir po to vėl surinkti.

Esu matęs ne vieną turinio valdymo sistemą ir mane labiausiai trikdydavo tai, kad kiekvienam moduliui būdavo mažiausiai po kelis vienodus failus. Įsivaizduokite, kad turime naujienų modulį tuomet mes greičiausiai turėsime news.php ir news.class.php, manote jog tai viskas? Klystate, tokius failus turėsime kliento ir administratoriaus dalyje, nesuprantu, kam reikalingas tų failų, tų pačių funkcijų dubliavimas.
Kitas man nesuprantamas dalykas, tai kodėl norėdamas parašyti naują straipsnį turiu jungtis prie administravimo? Kodėl negalėtų būti tiesiog meniu punktas “rašyti” vartotojo dalyje? Ar tikrai reikia atskirti vartotojo ir administratoriaus dalis?
Taigi, kuriam savo . Nuo ko turėtume pradėti? Gal nuo failų struktūros. Šia tema Pixel.lt buvo vienas straipsnis, tačiau labai sukritikuotas. Todėl, matyt, reikėtų pradėti nuo pradžių.
Greičiausiai CSS failus saugosime direktorijoje css, js - scripts, paveikslėlius - images, vartotojo įkeliamus failus - files. Gerai?
O puslapio dizaino paveikslėlius kur saugoti css/images ar tiesiog images?
Ar reikalinga galimybė lengvai pasikeisti puslapio dizainą? Jeigu taip, tai galbūt reiktų dizainus saugoti direktorijoje themes/dizaino_pavadinimas? Atitinkamai persikels ir css bei dizaino paveikslėlių failai į themes/dizaino_pavadinimas/css bei themes/dizaino_pavadinimas/images. Kita vertus, kaip dažnai jūs keičiate savo puslapio dizainą?
Aš esu didelis Smarty šalininkas, tačiau ar tikrai verta naudoti šablonų variklį? Jeigu taip, tai gal yra kas nors geriau už Smarty?
Pakalbėkime apie varikliuką. Jeigu kalbėsim sąžiningai, tai funkcinis kodas veikia greičiau, tačiau ar 0.001 sekundė mums svarbi? Jeigu rašome objektiškai tai greičiausiai klases saugosim direktorijoje classes, o modulius - modules. Gerai?
Duomenų bazė. Naudosime Mysql? O gal geriau susikurti failinę struktūrą ir viską saugoti xml, csv, ar kitokio tipo failuose?
Dar vienas dalykas - kalbos, ar reikia daryti daugiakalbę sistemą ar užteks vienkalbės? Jeigu darome daugiakalbę, kaip tuomet daryti su vertimais? Talpinti duomenų bazėje? O gal geriau failuose? Kaip lengviausiai ir geriausiai padaryti vertimus, kad nereiktų vėliau dėl to gaišti daug laiko?
Moduliai. Kokių modulių jums reikia? Man asmeniškai užtenka naujienų su komentavimo galimybe ir RSS, o jums?
Niekada nesupratau, kam reikalingi tokie moduliai, kaip sistemos statistika arba naujienų prenumerata. Jeigu norite statistikos įsidedate Google Analytics, jis tikrai nėra vienintelis šioje srityje, tiesiog geriausiai žinomas. Jeigu norite naujienų prenumeratos, tai tuomet savo RSS paleidžiate per FeedBurner ir valio. O gal vis dėl to yra priežastys, kurti tokius modulius?
Atrodo būsiu praleidęs vieną labai svarbią dalį: visą kodą rašyti savo ar galbūt naudotis kokiomis kodo bibliotekomis? Zend Framework, prototype.js, jquerry, žinote dar kokią nors gerą?
Ar projektui reiktų naudoti MVC, o gal yra kokia nors geresnė alternatyva?
Tikiuosi išsamios diskusijos, pasiūlymų, idėjų, klausimų. Rėžkit viską nuo liežuvio galo, negailėkit klaviatūrų. Jeigu diskusija pavyks, pabandysiu parašyti dar vieną apibendrinantį straipsnį. O dabar laukiu jūsų komentarų.

Panašūs straipsniai


“Kuriam savo TVS” komentarų: 15

  1. vildoc

    PHPnuke rulz, o jei rimtai aš jos iki šiol nesuprantu.
    Į bylų struktūra tai menkai kreipiu dėmesį svarbu, kad nesimaišytu tas kas nereikia.
    Smarty patinka, juk tvs šerdis kuriama ne vienam projektui, todėl toks sprendimas geras.
    Būtinai daugiakalbė, geriausias sprendimas būtų Gettext bylos drupal pavyzdys, nes visokie csv, xml ar php negėris kai atsinaujina sistema, nebent naudotis CMSms pavyzdžiu. Beja daugiakalbiškumas turėtų būt ne tik admin pusės bet ir turinio.
    Modulių kuo daugiau tu geriau, bet juk nevisi turi būt pagrindiniam leidime. Nes toks modulis kaip: google analytics integravimas, beprasmis dalykas.
    Svarbus dalykas “priekinis” administravimas, kai firmos sekretorė matytu ką daro, o ne lystu į “galinį “administravimą kur reikia sukurti bylą, po to straipsnį, po to nuorodą navigacijoje, priskirti kokį šabloną naudoti, ir … (na gal persūdžiau, bet būna tokių)
    Nepamirštam seo.
    daugiau nesugalvoju.. darbo pabaiga..

  2. Rimantas

    Na va, puiki iliustracija, kodėl naujos TVS rašomos ir rašomos, o gerų vis nėra ir nėra.
    Iš viso to, kas čia prašyta gal tik „vartotojo ir administravimo dalies atskyrimas“ turi kažką bendrą su vartotoju. Visą kita – technologija, kurios vartotojas nemato, nežino ir jo tam nereikia.
    Žmogui rašančiam į savo naują blogą visai neįdomu, kokiose direktorijose sereryje guli failai, ar šablonus varto smarty ar phemplate, yra ten mvc, ar nėra, mysql ten ar postgre, prototype ten siuntinėja ajax užklausas ar jquery. Jam net neįdomu, kas tas ajax.
    Kokias problemas su šiuo TVS spręs programuotojas jau matyti. Dabar klausimas, kokias vartotojo problemas šitas TVS padės spręsti ir kaip…

  3. neworld

    Ar šiuo metu Google Analytics gerai veikia kai įdedi naujus tinklapius, nes kai pridėjau dar vieną tinklapį tai tik fiksuoja puslapius kurie aprašyti goal, be ne visus, tuo tarpu tinklapį kurį seniai esu įkėlęs, fiksuoja viską.

  4. Blogorama #380 : nežinau.lt

    […] Pirkėjų norai ir būsto kainos. • Į mokyklą Japonijoje norite? • Policijos paslaugumas. • TVS nuo nulio. • Lašiša su […]

  5. Povilas

    Already ahead of you: http://diferior.com ( arba http://diferior.lt ) ;)


  6. Idealiu dalikų nėra o taisyklės nuolat laužomos.

    Dėl statistikos sutinku, nebent kurti pradėsitė TVS, kuri prisitaiko pagal vartotojo elgseną.

    Na, naujienų prenumerata - gan geras modulis. Kaip rodo statistika, žmonės noriai patis registruojasi naujienoms, ypač jai jiems tai aktualu.

    Jei TVS skirta mažam tinklapiui (sakisim iki 20 puslapių) ir jokių įpatumu, tai xml ar panaši technologija į mano SDF puikiai atsiperka, ypač XML dabar, kai turime SimpleXML įjungtą pagal nutylejimą.

    Jei TVS dydesniam tinklapiui, tai aišku kad duomenų bazė. Apseitu ir su MySQL, bet jai turėsi koki Framework - turėsi ir kitu bazių palaikymą.

    Nepamirškite apie SEO, tai ne tik madinga, tai butina betkuriam verslo tinklapiui (turinčiam daugiau nei 10 puslapių). Iš asm. patirties: kai paskutini kartą sukuriau super-seo pritaikyta TVS, užsiknisau su modulių rašimų - jie neįlenda į remus.

    Sunkiausia bus sugalvoti modulių palaikimą ir visems suprantama API, kad ne tik pats galėtum kurti modulius.

    Asmeniškai aš bandyčiau kurti su ZF. Rašyti visk nuo nulio užtruks žymiai daugiau, nei panaudoti paruoštus svetimus sprendimus.

    Nepamirškite apie kodo dokumentaciją, vartotojo instrukcija.

    Bet man pabodo tu TVS kurymas. Įgriso ši tema. Nekenčių TVS. Kuriau teksinių failų pagrindu (txt, xml, sdf), kuriau duomenų bazių pagrindų, nagrinėjau temas apie “prie vartotojo elgesio prisitaikančių” TVS kurimą, klausiau/skaičiau mintis apie visiškai automatizuotas TVS (kur vos ne turini pačios sugeneruoja ar taiso). Pabosta, įpač kai viskas yra grinai “ant entuziazmo” ir dar turi donau uždirbti o turima tuo metu patirtis tokiems iššukiams netinka ir jos įgyti nera kur.

  7. Apie TVS || Re: Kuriam savo TVS @ pixel.lt | Arūnas Liuiza

    […] vėl pasiilgo peštynių. Tik šį kartą diskusiją šaukia ne savo asmeniniame bloge, o pixel.lt erdvėje. Kadangi apie TVS žinau ne tik iš nuogirdų, pabandysiu pridėti savo tris […]

  8. Martin

    iš kūrėjo pusės žiūrint, manau, patogesnio modelio nei MVC nėra. šitai atsako į daugelį problemų - t.y. iš esmės nėra skirtumo, kokia fizinė failų struktūra, bet be normalaus OOP neapsieiti, todėl PHP5 derinys su MySQL savo darbą atliktų neblogai.

    VISI KITI klausimai nėra svarbūs (bent jau tikrai ne _sugalvojimo_ stadijoje). t.y., aišku, galite mąstyti, ar norit turėti jQuery ar prototype’ą, bet pradėti visvien reikės nuo paties sistemos branduolio - todėl gal kol kas ties juo ir susikoncentruokite.

    PS pataisykite straipsnyje jquerry > jquery

  9. Giedrius

    tipiškas phpnuke ar kitų “tvs” šablonas..limonas parametrų bei failų ir t.t.

  10. insane

    Kolegos
    Jus man dabar pasakykit kaip sprendziat tokia problema, kai susiduriama su pacio turinio isdeliojimu public saite?
    Aisku galima tiesiog templeituose nurodyti kas kur gules ir viskas. Bet daznai buna kad kur nors prireikia kokio blokelio ir tingisi po templeitus kuistis)
    Kitas variantas - apsirasineti struktura kokiais nors n-maciais masyvais ir po to dinamiskai generuot tam tikru bloku pozicijas
    Man bent jau noretusi viska daryt maximum universaliai, kad veliau nereiktu kist nagu prie kodo - uztektu tik su pele maigyt, bet velgi pasitaikius kokiam nors nestandartiniam dizainui tas universalumas gali sugriut, ko nors nenumacius; gaunasi kaip uzburtas ratas)
    O gal vistik nusispjaut i viska ir daryt elementariai: left side, right side, middle ir tai turbut tenkintu 90% poreikiu]


  11. 1 - Visose sistemose yra BETA versija, kuri yra nepriklausoma nuo to ka mato per public, ir kai administratorius mano kad BETA versija tinkma, jis ja perkelia i PUBLIC versija
    2 - Visas blokeliu valdymas yra administratoriaus rankose. Jis mato puslapio “atvaizda” ir reikiama turinio zona pertempia reikiama bloka. Taip, zonu kiekis yra ribotas, o jai reikia kazko nestandartinio reikia jau moketi ir CSS. Nors, TVS kurtas vidiniams tikslams.
    3 - Taip tai sukele problemu

  12. sirex

    Per savo PHP programuotojo karjerą, esu bandęs rašyti savo TVS nuo nulio, gal kokius 4 kartus. Tiesa, pastaruoju metu taip pat šiek tiek tobulinu, tikriausiai jau paskutinį nusistovėjusį TVS variantą, kuris gal greičiau primena Frameworką su TVS elementais :)

    Įgavęs TVS kūrimo patirties galiu pasakyti, jei jūsų kompanijos pagrindinė veikla nėra susijusi su TVS kūrimu, tai nekurkite patys TVS, tai labai ilgas ir sudėtingas darbas (žinoma priklauso nuo to, ką norite pasiekti). Jei bandote kurti savo TVS, savo malonumui, taip pat nekurkite, geriau nagrinėkite jau parašytas TVS, bus daug daugiau naudos.

    Žinau, kad geriau nekurti savo TVS, tačiau pats, tobulybės beieškodamas vis tik kuriu savo TVS :) Todėl pasidalinsiu mintimis apie tai, kokia turėtu būti tobula TVS.

    Pirmas ir ko gero svarbiausias elementas – adresas. Viskas prasideda nuo adreso. Manau nėra nieko paprasčiau už šį adresavimo būdą: “parametras/parametras/parametras”. Visam tam reikėtu sukurti varikliuką, kuris pasiima adresą ir padaro su juo tai ką reikia.

    Kitas dalykas – vidinė sistemos duomenų cirkuliacija ir pasiskirstymas pareigomis, kas už ką atsakingas. Šioje vietoje nėra lygių MVC modeliui, kuris atsirado jau labai senai ir yra paprasčiausiai primityviai tobulas. Taigi naudojame Model View Controller modelį.

    Kad jau paminėjau Model, tai visiškai nesvarbu, kur bus saugomi duomenys, failuose, MySQL, PQSQL ar dar kokioje kitoje duombazėje, už visą tai turėtu būti atsakingas duomenų bazės objektas, su kuriuo vieninteliu ir bendrausite. Šiuo metu populiariausi yra ADOdb ir PEAR::DB, tačiau nei vienas, nei kitas man nepatinka, todėl siūlau pasirašyti savo, kaip aš tai esu padaręs :) Duomenų valdymas yra labai svarbus elementas, todėl neapsiribokime vien tik duomenų bazės abstrakcija, siūlau naudotis DRY (Don’t Repeat Yourself) principu, tai reiškia, kad reikia sukurti priemones, kurios naudojantis detaliai aprašytais modelio duomenimis galėtu sugeneruoti trūkstamas duomenų bazės lenteles, sukurti toms lentelėms įvedimo formas, atvaizduoti sąrašus ir t.t. ir t.t. Tokiu atveju, turėsim jau beveik padarytą administravimo dalį, todėl daugiau laiko galėsime skirti naudotojo daliai, kas manau yra svarbiausia.

    View, šablonai. Hėi, ar žinojote, kad PHP pati savaime yra šablonų sistema, tai reiškia, kad PHP kodas yra rašomas HTML kodo viduje, lygiai taip pat, kaip tai daroma ir su šablonais. Tai kam gi išradinėti dviratį ir su PHP rašyti šablonų variklį? Gaunasi sviestas sviestuotas? Todėl asmeniškai aš pasisakau tik už PHP based šablonų variklį.

    Esminė dalis – Controller, tai turėtu būti ta vieta, kur vyksta pagrindinis veiksmas. Šią vietą reikėtu riboti, kaip įmanoma mažiau. Žinoma tai yra labai sudėtingas klausimas, tačiau aš pats naudoju vieną primityvią BaseController klasę, kurios pagalba kuriam kiti įvairiausių paskirčių kontroleriai. Svarbu prisiminti, kad norint suprogramuoti kažką labai didelį ir sudėtingą, OOP yra tiesiog būtinas, todėl kontroleriai tiesiog būtinai turėtu būti aprašomi klasių pavidalu, kuriuos vėliau nesunkiai bus galima panaudoti bet kurioje kitoje vietoje (reusable code).

    Daugiakalbiškumas, tai tiesiog būtinas elementas! Visas *nix pasaulis ir dar daugiau naudoja GETTEX, naudokime ir mes. Žinoma modelių ir duomenų bazės dalyje turėtu būti numatytos priemonės ir duomenų lokalizavimui, todėl visu tuo turėtu rūpintis duomenų bazės abstrakcijos dalis ir modelių struktūra.

    Na ir žinoma JavaScript ir visokie AJAX, tam naudoju ir kitiem rekomenduoju JQuery. Daugiau šioje vietoje komentarų neturiu.

    Nuo šios vietos, praktiškai esminė dalis baigta, neskaitant galybės visokių smulkmenų :) Tačiau teoriškai nuo šios vietos prasideda kūrybinis sistemos vystymo procesas. Šioje vietoje reikėtu giliai pažvelgti į TVS paskirtį ir išskirti esmines dalis, kurias toliau pakomentuosiu detaliau.

    Turinys, manau tai kiekvienam akivaizdu, blogo įrašas, naujienos įrašas, paveiksliukas, dokumentas, ir t.t. ir t.t. visa tai yra svetainės turinys, todėl visam tam turėtu būti naudojamas vieningas API.

    Kad turinį būtų galima kur nors atvaizduoti, reikalingai pagrindiniai, paveldimi puslapio šablonai.

    Kad į tuos šablonus būtų galima ką nors patalpinti, būtina svetainės blokų sistema, kurie svetainę daro dinamišką ir kintančią.

    Ir štai paskutinis, bet ko gero svarbiausias dalykas – dokumentacija! Kokia nauda iš krūvos kodo, jei net pats to kodo autorius, po kurio laiko neturi žalio supratimo kaip viskas veikia. Todėl kiekviena funkcija turi būti gerai dokumentuota, jei funkcija neverta dokumentavimo, tai gal jos iš vis nereikia? Tai gi funkcionalumo dokumentavimas yra tiesiog būtinas.

    Na štai ir išsipasakojau :)

  13. mindė

    insane: pilnai užtenka vienmačio masyvo/listo/mysql_lentelės - juk HTML’e viską dėstai paeiliui, reikia pažaisti su CSS’u, ir gausi gana lengvą universlaus templeito redagavimą..

  14. powah

    sirex: aš mąstau turbūt identiškai kaip ir tu :-) Tik gal nepritariu minčiai, kad neapsimoka kurti savo TVS :-) Turėti protingai padarytą branduoliuką programuotojams yra tikrai naudinga. Na, ir tarkim, gavus kažkokį specifinį programavimo atžvilgiu projektą, nereikia laužyti galvos “kaip čia dabar nuhackinus tą opensource TVS’ą, kad jis darytų būtent tai, ko tas pyyyp užsakovas nori??!”.
    Dabar asmeniškai aš audžiu mintį kurti TVS Zend Framework’o pagrindu (ankstesnis bandymas buvo su CodeIgniter, tačiau ankstesnis TVS buvo iš esmės “neteisingai” suplanuotas, tad bandysim “pagimdyti” kažką naujo, labiau “reusable”, panaudojant man šiuo metu labiausiai perspektyviu atrodančio karkaso).

  15. Sharkman

    Turiu tokį pastebėjimą jog kolkas unikaliausia TVS yra PHP-Fusion. Kodėl? Ji nėra sudėtingo ir sunkaus valdymo, apie ją nusimanyti nėra ką tik reikia pažinoti kodus, jai pagalbos puslapių yra gan daug kur sulaukia pagalbos visi, dizainą susikurti yra tikrai labai paprasta nes jo sudėtis tokia kokią gali perprasti bent kas. Vienintelis jos trūkumas yra toks jog su saugumu kūrėjai nepadirbėjo labai daug todėl vartotojai renkasi kitas saugesniais TVS tokias kaip Joomla(mambo) kurios tikrai yra neblogos tik jų valdymas sunkokas. :)

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.