[jnt]

Tervist!

Selline küsimus, et tahaks väga lugeda kuskilt sellise teema kohta, et kuidas peaks olema üks tõsiselt suuremahuline admin paneel teostatud. Praktikas läheb ehitamiseks PHP/MySQL peal, kuid antud teemal keelel väga vahet pole ja kui koodi tsiteeritakse, siis pole vahet, olgu või pseudokood. Oluline on just design pattern ja kuidas mis toimib.

Ideeks on see, et mul on tagataustal baas, mul on juba olemas sellisted asjad nagu resultset'id ja dataobjectid (activerecord), model/factory patternid jne. Nüüd oleks vaja sinna peale ehitada korralik admin paneel. Idee oleks, et kasvõi see, et selle asemel, et mul näiteks mingite klientide listi jaoks oleks oma template, oleks mul hoopis nt Gui_List_Generator, mis kasutab mitte Client model-objekte vaid nt GUI_Client objekte, mis omavad definitsiooni kasvõi selle kohta, milliseid field'e ekraanil näidata või mitte ja kuidas. Ja muidugi koos sellega tekib "consistency", kuna kõiki liste genereeritakse ühtmoodi, kõiki forme ühtmoodi jne. Point oleks teada saada kellegi targa inimese nägemus, kuidas peaks kõhu all asi toimima, et ma lõpuks kontrolleris ütlen ainult, et tee vot sellise list'i klientidest mulle list-tabel ekraanile, või et mul on see objekt ja ma tahan nüüd edit-form'i sellest. Ka võiks asi asi kindlasti sisaldada seda, kuidas ka implementeerida seda, et lõpuks ma ei kirjuta enam nt html'i, et siin on nüüd input field, vaid et ma ütlen, et "siin" on field ja see on hetkel edit mode'is. Vastavalt datasource'ile omakorda on see kas input field, drop-down selectbox või lausa hunnik checkbox'e. Ja selle kõige kõhualune on see, millest lugeda tahaks.

Just sellist veidi teoreetilisemat materjali oleks vaja, et enne hurraaga alustamist tahaks veel üht-teist tarka läbi lugeda.

Ehk on keegi (no kindlasti on) kokku puutunud samasuguse asjaga?

[YberCyrus]

Pole küll päris see vastus mida sa otsid aga kui ma midagi sellist ehitama peaks siis ma ehitaks Javas järgmiste frameworkide peale Spring+Hibernate+ZK ja Tomcati app serveri peale jooksma. Kui väga modulaarsust vaja siis ehitaks OSGi arhitektuuri peale ja käiku läheks veel Spring DynamicModules/Gemini Blueprint ja app serveriks EclipseRT Virgo. Eriti rõhutan siinjuures ZK (http://www.zkoss.org/) frameworki mis sulle eriliselt hästi sobiks. Tegu on fat client (99% AJAX) frameworkiga kus frontend HTML/JS/AJAX/CSS genereeritakse sulle ära ja sina pead backendis component oriented stiilis koodi kirjutama või kasutama nende skriptimiskeelt. Sarnaneb väga Swingi progremisele (kui tead mis see on), igal komponendil on oma event listenerid ja sa ei pea muretsema kuidas event detection töötab vaid tegutsema siis kui miskit vajutati.

[neros]

Ma ei soovitaks isegi vaenlasele sellist süsteemi käsitsi ehitama hakata. Nende jaoks on olemas juba paras ports frameworke millel on support ja community taga. Siiski, kui soovid ise midagi valmis nikerdada, oleks samuti mõttekam raamistikke kasutada. Näiteks Zend kuna tal peaks olema ka juba AR tugi olemas.

Ise ma võtaks pigem ette ASP.NET MVC kas versioon 3 või siis 4+SPA. Entity Frameworki peal on võimalik suurem osa asju ära scaffoldida ja isegi view'd on väga lihtsasti esitatavad puhta backend koodi kujul: @Html.DisplayFor(model => model.FieldHere) ning ka @Html.DisplayForModel() (on ka EditorFor) mis suudab automaatselt tuvastada kuidas asjad töötavad, attribuutidega saab lisaks paika panna scaffoldattribuudi või muud asjad, mis siis kas vajadusel peita või kuvada saab. Lisaks on paar AOP (Aspect Oriented Programming) frameworki, nagu PostSharp, Aspect# ja ka Javalastele tuntum Swingi sugulane Swing.NET, põhimõtte on samuti eventlisteneride tegemine ning isegi method injection kui on tarvis näiteks logida midagi. A la, viskad kõikidesse meetoditesse kus on logimist tarvis lihtsalt LogAttribute'i. Dünaamilisi komponente saab isegi väga madalal tasemel kirjutada. Lisaks on NuGeti kaudu võimalik saada absoluutselt igat masti tööriistu jms mis võtavad terve hunniku koodikirjutamist välja.

Kahjuks pole muidugi väga palju dünaamilisi supermooduleid kirjutanud, ja need mida olen, on valdav enamus õhukesed kliendid (RIA) olnud.

Aga kui mingeid konkreetsemaid küsimusi on, siis tasub neid postitada. Kindlasti oskab keegi, kui mitte YberCyrus või mina, kuidagi abiks olla.

[serk]

Ma küsin pigem nii, et kellele on soft suunatud? Proff või tavakasutaja? Totaalselt teine lähenemine. Profitarkvara loomiseks pead väga hästi tundma DBAde ja sys adminnide igapäeva tööd, raamatust seda ei loe. Profi ja tavakasutaja vajadused ja lähenemisviisid on erinevad. Tehnoloogiliselt pole oluline mis keeles ehitada.

Ja mida kuradit te seda hibernatei poputate? Õudus kuubis.

[YberCyrus]

[jnt]

serk, tegemist oleks ühe konkreetse asutuse sisese kliendihaldusinfosüsteemiga. Hetkel jookseb kõik PHP peal ja kood on väga vana, mida hallata enam ei suuda. Enne, kui hakkame uut koodi kirjutama, teeks veidi research'i ja sellest ka see teema siin.

Nö koodi klientuuriks on meie oma töötajad ja ei pea mõtlema selle peale, et iga suvaline mats asjast aru saaks.

[serk]

[neros]

Mappingud on selle jaoks tarvilikud, et framework oskaks seoseid koostada tabelite vahel ning kui programm tahab küsida Customer->Orders siis saaks framework aru, et "ahhaa, küsiti Customeri ID'd 420 ning sealt omakorda Ordereid vaatame mis childrenid tal on... oo, CustomerId on foreign key, järelikult paneme hakkama where CustomerId = 420

[jnt]

PHP's on meil kirjutatud mudelitele oma skript, mis käib andmebaasi information_schema db mööda ringi ja kirjutab mudelite definitsioonid maha. (field'id, foreign key'd jne) Käivitada vaja iga kord, kui mingi uus mudelobjekt teha või olemasolevat muuta. Et milleks peaks seda käsitsi kirjutama?

Küll aga, homme hakkan vaatama mis siin antud framework'ide nimede taga reaalselt peitub. Esialgu oleks meeldiv veel PHP peale jääda, kuid eks ole näha. Eks Zend framework'il on ka mingid form'id ja form_element'id jmt kraam olemas, kuid pole jõudnud veel uurida, mis need on ja kuidas käituvad. Ehk saab hoopis midagi nende peale ehitada. Siis on kõige low-level kraamil olemas ka laialdaselt kasutav kommuun ja support.

[kullar]

Yii framework on väga asjalik ja päris paljude extensionitega.

[napoleon]

[jnt]

Hetkel uurin ja puurin Yii, Zend ja Code Ignitor raamistikke. On teil ka ehk nendega kogemusi olnud, veel enam, ehk mitmega neist? Oleks hea kuulda nende kohta mingeid võrdluseid. Netis juba mitu-mitu artiklit leitud, mis vaja läbi lugeda ja oma mõttemaailm kujundada nende põhjal.

[kullar]

Endal olemas kogemus Yii ja CodeIgniteriga ja iga kell eelistan Yii'd just rohkemate võimaluste poolest ja koodi pool on palju soliidsem ja ei pea nii palju koodi kirjutama. CodeIgniter ja Yii on sarnase loogikaga(MVC). Kõikidel core funktsioonilel on olemas beforeFuncName ja afterFuncName. Ehk funktsioon, mis kutsutakse ennem ja pärast funktsiooni välja.

* ORM, Active Record, ActiveForm
* Võimalus automaatselt genereerida terve register(andmebaasi tabeli nimekiri/vorm/view)
* Sisseehittaud Jquery ja jQuery ui.
* CRUD
* Palju erinevaid extensione
* Gettext moodul tõlgete jaoks
* Mugav moodulite haldus

[phpzone]

kas need ajad juba möödas ei ole, kus CRM tuli käsitsi kirjutada. Enamus crm süsteeme on suhteliselt avatud ja suhteliselt lihtsasti kohandatavad ükskõik millise ettevõtte vajadusega. Saab oma mooduleid juurde kirjutada ja saab ka täiesti enda lahenduse tekitada, ilma et nö. "mootorit" peaks leiutama. andmete import/export käib APIdega ja saab suht lihtsalt siduda erinevate infosüsteemidega. See ei ole lahmimiseks mõeldud, lihtsalt tasub kaaluda sellist varianti ka, tuleb odavam ja lõpptulemus parem. nullist kirjutatud uus lahendus on ajast ja arust juba paari aasta pärast.

[jnt]

phpzone, aga muidugi. Ega polegi välistanud seda, et tuleb mingi teine framework meie asjale lihtsalt alla. Kuid sellegi poolest sooviks asjast ka veidi teooriat lugeda. Mitte võib-olla et isegi ise kirjutamise pärast, kuivõrd just, et oskaks teada, mida hinnata ja mille järgi framework'i valida. Hetkel tundub, et teaks nagu küll, mida vaja, kuna tehtud ju oma activerecord model-factory patternis, millel on featuure, mida teistes framework'ides näinudki pole. Kuid tegelikult see ju ei tähenda, et kohe kõike nüüd tean.

Hetkel uurin veidi täpsemalt seda Yii framework'i. Vaikselt on tunne, et pigem võtaks framework'idest õppust, kui et hakkaks kohe kasutama. Kui oma framework piisavalt lähedale jõuab ette võetud framework'ile, siis võib teha ka switch'i, mis oleks sel hetkel juba väga lihtne.

[neros]

Sa tahad enda frameworki saada lähedale mõnele laialtkasutatavale raamistikule? Good luck with that, neisse on läinud aastepikkune arendustöö.

Sul on hetkel kaks kõige mõistlikumat valikut:

1) Kirjutad ise kogu kupatuse algusest, korralikult, OOP'd ja muid toredaid patterneid/paradigmasid kasutades väga spetsiifilise suunitlusega...
2) Kasutad frameworki.

Frameworkidest on nii palju mõtet õppust võtta, et ära hakka ratast leiutama.

[lehm2]

[jnt]

lehm2, mustritega olen suures osas juba üsna tuttav. Pigem otsin teooriat, kuidas kõige efektiivsemalt üht või teist asja teha. Näiteks väga lihtsa näitena, et activerecord (ja üleüldse kõik, mis laadimisega tegelevad) peaksid kasutama lazy loadingut, et miks peaks ja kuidas on kasulik tekitada universaalsed beforeSave() ja afterSave() meetodid (justnimelt miks), kuidas peaks objekte hoidma cache'is ja kuidas cache'i mõistlikult piirata, kuidas teha efektiivsuse mõttes preload'e ja batchload'e activerecord'itele jne jne. Selline kõige-kõige low-level kraam.

Üks nüanss, mida ma pole kuskil kohanud, aga mis andis meil väga suure performace boosti, oli "objectList". Asi nimelt on objekt, mis käitub nagu array, enda sees hoiab objekti klassi nime ja id'sid. Tal on private muutuja batch_size, milleks on näiteks 20. Nüüd kui factoryst küsin välja list'i, mis sisaldab 200 activerecord objekti, siis tegelikult tagastatakse mulle see objectList. (activeRecord objekte pole veel olemas) Kui ma loop'iga hakkan objectList'i läbi käima, teeb objectList esimese objekti accessiga kohe 20 activeRecord objekti, batchLoadib nad juba eelnevalt ära ja paneb cache'i. (objectPool) Kui loop jõuab 21 objektini, luuakse ja laetakse järgmised 20 objekti ning pannakse cache'i. Kokkuvõttes loopi sees pole miskit aru saada, et algul objekte olemaski polnud või et pärast toimusid batchLoad'id, kuid performance on tunduvalt suurem, kui võrrelda iga objekti oma laadimist eraldi vs 20 objekti laadimist. (1 vs 20 query't stiilis "SELECT * FROM table WHERE id = X" 20 korda või "WHERE id IN(x, y, z)" 1 kord)

Eelnimetatud optimeeritud viisi objektide listi läbi käia ei ole ma netis kusagil kohanud. Kui kuskil räägitaks sellistest asjadest, siis kujutan ette, et sellises artiklis oleks veel palju palju muudki huvitavat, mida kõrvataha panna.

Vaatan ka, mis see raamat endast kujutab. Ehk ongi midagi, mis tasuks tööle ära tellida.

madedog, low-level framework (activeRecord, factory pattern) on meil olemas ja väga hea. Meil on oma eraldi factory (sisaldab nö preFilled filtreid, et ei peaks pidevalt uuesti filtrit kirjutama), activeRecord'id (viewObject/saveObject, vastavalt kas taga on tabel või view), filtri objekt, mis võimaldab põhimõtteliselt sql'i kirjutada autohintinguga ja optimeeritult, core'i asjadest objectPool, objectList jmt. See on meil olemas. Samas oleks huvitav lugeda, kuidas tasuks selliseid low-level asju kellegi teise arvates teha.

Teisest otsast tahaks lugeda just, kuidas tuleks ehitada suure süsteemi controller ja view osa. Milline üles-ehitus peaks olema, kui kaugele mingi asjaga tasub minna standardiseerituses (nt kui tahan objectList'ist html tabelit, kui automaatne see peaks olema ja kui palju peaks see "html generaator" oskama ja millal tasub mul hakata käsistsi html'i kirjutama) jne jne.

[YberCyrus]

See mida sa rääkisid objektide fetchimise kohta tundub by default Javas Hibernatega kaasa olevat ja tõenäoliselt ka .NETis NHibernatel (pole seda ise näppinud). Lazy loading on by default alates Hibernate 3st sisse lülitatud. Cache külge pookimine on vajaliku cache provideri otsimine ja 2 rida confi lisamine. Ise olen kasutanud Ehcachet. Väga võimekas cache provider on, saab igasugu asju confida nagu entity sized (memory ja disk), eviction policyd ja skaleerub ka hästi juhuks kui sul ühest serverist ei peaks piisama. Lubab ka rohkem advanced cachimist nagu query cache. Ise küll batch fetch sizet pole eraldi confinud aga confi tasandil on täiesti olemas atribuut (hibernate.default_batch_fetch_size). Ja mis Hibernate puhul veel suur pluss on see, et kuna arendaja ei pea querisid ise kirjutama siis andmebaasi vahetus on teoorias 1 rida confi kus tuleb öelda millise SQL dialektiga tegu on (praktikas vb natuke rohkem, näiteks MySQLil on auto_increment aga Postgrel on selle jaoks sequencid ja sel puhul tuleb ka mapping failis vastavad muudatused sisse viia, aga see on suht minimaalne copy paste).

Olen ka omast kogemusest ise implementeerinud mingisugust algelist chachet mis töötas koos Spring ORMiga (pidi ise querisid kirjutama). Ütleme, niiet kui switchisin Hibernate peale koos Ehcachega säästsin kokkuvõttes rõvedalt aega ja koodi mis kulus ORMi peale. Ühesõnaga jalgratast pole mõtet leiutada, peaaegu alati on olemas tööriist mida sa otsid. Kui PHPst sarnast asja ei leia siis tea, et Javas/.NETis on olemas.

[jnt]

YberCyrus, tore tore, et selliseid asju tehtud on, kuid kas nüüd lugeda teooriat ka nende kohta kuskilt saaks?

Väga palju pole muidu aega olnud uurida, kuid näiteks Yii framework'is ei tundunud sellist asja olevat, nagu meil objectList on. Neil oli küll List objekt, kuid kõik objektid jmt eksisteeris ikkagi kohe alguses, mitte laadimsie ajal ja batch load'e jmt seal by default ka polnud. (of course alati saab ise juurde kribada miskit taolist, kuid see selleks...)

[Fukiku]

Kui nii suur huvi on süviti minna, siis on ilmselt üks paremaid võimalusi enda harimiseks see, kui vastavasisuliste projektide lähtekoodi uurida ja miks mitte ka ise projektis osalema hakata. Võibolla ka näiteks projektide dev meililistide arhiivid näiteks?

Ei ole küll hästi struktureeritud teadmus, kuid ilmselt open-source projektide puhul parim, mida võtta.

Teine alternatiiv on hakata teaduspublikatsioonides sobrama, sest ilmselt enamiku lahendusi on keegi kunagi teoreetiku künka otsast ka artikliks kirjutanud.

[jnt]

Fukiku, hetkel uuringi Yii framework'i koodi selle pilguga, et mis ja kuidas seal tehtud on. Kas kunagi see aluseks võtta, selle otsustamine jääb tulevikku. Kindlasti kavas peale Yii'd veel mõni teinegi fw üle vaadata.

Teaduspublikatsioonid ongi ehk see õige keyword, mida ma tegelt otsin. On keegi millegi hea peale sattunud? Googeldada oskan ise ka, kuid ehk teab keegi midagi konkreetset?

[andresv]

kui otsid publikatsioone, siis võibolla leiad siit midagi: http://research.google.com/pubs/papers.html
aga pole kindel, kas seal frameworkidest ka juttu on.

[phpzone]

Ma ei mõelnud valmis PHP framework kasutamis vaid valmis CRM süsteemi kasutamist. Tänapäeva CRM süsteeme saab kohandada pea ükskõik millise ettevõtte vajadustel ja kasutata nagu framework'e. Esmapilgul tundub kallis, kuid kui kui nullist ise arendada, siis aastate pikkune arendus on lihtsalt piduriks ettevõtte igapäeva töös ja kokkuvõttes kulukam. 1-2 aastaga võib põlve otsas arendus uuesti ajast ja arust olla. vaata nt Microsoft Dynamics CRM, kui MS ei meeldi siis nt. sugar crm võimalusi. variantide nimekiri on tegelikult väga pikk

[tonis]

Mulle tundub, et eesmärk on liiga keeruline. St. asja saaks lihtsamalt tehtud ja kiiremini, kui ei vaevaks end mingite imelike küsimustega ega mõtleks kuidas ise mingit frameworki ehitada vms.

Nähtud küll neid kes arvavad et probleemi lahendamiseks on vaja ehitada mingi keeruline hästi üldine asi mille kood ja ülesehitus on ideaalsed - tulemuseks on jõle keeruline asjandus millest keegi aru ei saa ega kasutada ei oska.

Võta mõni olemasolev asi ja proovi seda kasutada.. muidugi uut ehitada oleks lihtsam kui hakata mõne olemasolevat rakendust vana baasi peale vägistama, siis läheb keeruliseks.