[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.

[jnt]

tonis, optimeeritus core'is on vajalik, kuna meil on kohutavalt palju kliente 24/7 online. Praegune core sisaldab peamiselt factory-pattern'is activeRecord'it ja on ses suhtes ehk valmis, et kõik toimib kiiresti, konkreetselt, efektiivselt ja võimekalt.

Küll aga ei ole meil hetkel pea-aegu, et isegi mitte mõistlikku controlleri ülesehitust. See teema siin ongi kõige rohkem siiski selle suunaga tehtud, et kuidas ehitada admin paneeli ja seda hästi.

Me ei saagi endale lubada kehvemat kood, kui ideaalset. Vastasel juhul kukub asi kokku.

[Fukiku]

Kas tänapäeval ei ole üldiselt arvutusvõimsuse juurde ostmine ja ülalpidamine odavam, kui nanosekundite optimeerimiseks inimtundide kulutamine?

[jnt]

Fukiku, on on, kuid kui sa kulutad päeva millegi optimeerimisele, mis annab iga kliendi puhul natuke aega juurde, siis rääkides suurtest kogustest klientidest, see väike aeg on summana väga suur.

[Fukiku]

Sa ju ei räägi optimeerimisest - sa räägid oma raamistiku tegemisest praktiliselt. Tulemuseks on tavaliselt see, et sul on raamistik, mille kogu know-how terves maailmas on sinu kontoris, halval juhul koguni ainult ühe inimese peas. Sul ei ole elu sees võimalik turult kogemustega arendajaid sinna leida ja sul ei ole võimalik probleemide korral suurelt community'lt nõu küsida, sest seda lihtsalt ei eksisteeri. Minu arvates on need üsnagi suured miinused, mis varem või hiljem lähevad kalliks maksma (arhitekt jääb auto alla - what do?). Ei tahaks uskuda, et olemasolevad raamistikud on nii ulmeaaeglased, et neid ei saaks kasutada suurte süsteemide jooksutamiseks eriti, kui nad toetavad klasterdamist.

Sa räägid igatahes sellist juttu, nagu teil oleks tohutu koormus koguaeg taga - mina lahendaks selle mure igatahes pigem võimsama(te) serveri(tega) ja populaarse raamistikuga, kui nanosekundite tagaajamisega in-house frameworki džunglis mässates ja säästurauda kasutades. See tuleb igal juhul odavam - sa ei pea kulutama kõigepealt mitut inimkuud (või aastat) raamistiku arendamiseks, vaid saad hakata kohe oma äriloogikat realiseerima - kulub vähem raha, jõuad varem turule, kiisud oksendavad vikerkaari su toote peale.

Oleks nagu ka meelde jäänud, et ikkagi sellel kümnendil väärtustatakse ka arvamusliidrite poolt arendamise lihtsust, kiirust ja programmeerija närvikava stabiilsust rohkem, kui nanosekundeid, sest arvutusvõimsus on odav, inimene aga mitte.

[tonis]

Tegelikult saaksid sa siit asjalikumaid vastuseid kui küsimus oleks mingi konkreetse asja kohta. Praegune küsimus on väga ebamäärane, midagi nagu "kuidas teha head CRMi?".
Sellele saab ka väga hägusaid vastuseid. Kui on konkreetne lahendamist vajav probleem siis saad ka paremaid vastuseid.

Fukiku argumendid on väga head. Kui ma oleks selle asutuse juht või omanik ja saaks teada et keegi leiutab mingit oma frameworki.. siis ma saaks veidi kurjaks sest selle normaalselt tööle saamine võtab aega, kulub palju raha ja mõne aasta pärast ei oska mitte keegi sellega midagi peale hakata kuna kõik teadmised on paari inimese peas.

Mitmed aastad tööd programmeerijana (mitte, et mingi vana kala vms) on õpetanud, et parem on teha asi veidi lihtsa ja lollina, vähemalt on hiljem koodist võimalik aru saada.. mitte teha mingit keerulist optimeerimist või imelisi kõiki keele/frameworki peidetud featuure kasutavaid elegantseid lahendusi. Muidu seda asjandust hiljem nii kolleegid kui sa ise ka.
Sinu jutu järgi vähemalt tundub, et tahad midagi eriti keerulist teha... mingid patternid jne, factoryd, ei tea mis imeasjad.

Tundub, et pigem on sul vaja teada kuidas on mõistlik rakendust üles ehitada, sest 'admin paneel' ei ole iseenesest mingi väga eriline rakenduse liik.
Vaata näiteks Ruby on Railsi rakenduste struktuuri. On modelid, viewd ja controllerid. urlidest leitakse controller ja action route-de järgi ja kõik on REST. REST struktuuri peale surumine on Railsi puhul üks paremaid asju.. sest siis ei saa keegi ise midagi liiga imelikku tegema hakata. Enamus uuemaid veebiframeworke on mingil viisil maha viksitud Railsi pealt naguinii, mõni päris kehvasti.

[jnt]

Fukiku, tonis, muidugi on mõistlik üks hetk võtta 3rd party framework kasutusse, kuid praegu on küsimus tegelikult olnud teooreetilise materjali kohta. Siin jutt läks muidugi asja enda ehitamise peale, kuid algusest peale on mu peamine soov olnud lugeda, kuidas peaks kapotialune töötama või millised erinevad patternid ja algoritmid on olemas ning kus mida kasutada.

[kullar]

Peale tonise postitutse lugemist tuli kohe meelde selline framework nagu symfony, kus esimeses versioonis oli kõik loogiline, kuid kui välja tuli versioon 2, siis see oli juba liiga keeruline ja ei näinud mõtet sinna süveneda.

[serk]

Sa väga tugevalt keskendud hetkel tehnilisele lahendusele, aga oled sa ka mingisugust analüüsi teinud, et mis asi ikkagi pudelikaelaks jääb? Kas andmebaas? Rak. Server? Või midagi muud? Mina ei tea andmebaasi suurust ja andmemudelit, aga sõnad hibernate ja activerecord 99% juhtudel tähendavad mitte just parimaid andmebaasi praktikaid ja seda, et äriloogika koondub veebiossa, mis lisab oluliselt koormust rak. serverile. Ja ära sa loodagi, et vähegi suuremate andmemahtude puhul päringud kiirelt ja efektiivselt käivad. Loomulikult on erandeid, aga seal on ka aastate pikkused arendused taga. Okey, osad inimesed mingipärast tahavad sellist patternit kasutada, fine, aga topi siis lihtsalt rak. serverid clustrisse ja thats it. Kasutusse mõni ennast tõestanud PHP või Java framework ja anna tuld.

Kui sul ei ole seljataga just suur ja väga kogenud arendajate team, siis sa ei suuda eales ise midagi paremat üllitada kui ennast juba aastaid tõestanud frameworkid. Ning ma võin mürki võtta, et kokkuvõttes uue frameworki arenduskulud tulevad oluliselt suuremad kui kasutada ennast tõestand lahendusi ja lihtsalt lükata servereid clustrisse.
Ning nagu eelnevate kaasvõitlejate poolt mainitud, sa pead ikka kõva müügimees olema, et müüa maha idee kirjutada oma raamistik. Kujutad sa ikka reaalselt ette mida see tähendab? Arendus, testimine, dokumentatsioon, koolitused, bugide batchimine - see on hea mitme aasta töö.

[jnt]

serk, kui rääkida müügitööst, siis praegu on vaja pigem pingutust, et mõni fw maha müüa.

Aga point pole üldse olnud selles siin teemas. Mida ma otsin ja tegelikult küsin, on ikkagi in-depth kirjandus patternide, loogikate jmt kohta.

Andmebaasi kohta võin öelda, et hetkel on suurus 40GB kanti ja see suureneb eksponentsiaalselt.

[Fukiku]

Sa räägid kohati iseendale vastu - ühest küljest üritad rõhuda, et sind huvitab ainult teoreetiline teadmine .. aga samas kaldud kohe jälle oma projekti tehnilistesse detailidesse ning esined arvamusega, et sa suudaksid kodukootud lahendusega paremini kui sissetöötatud ja üldtunnustatud lahendusega. Samuti su viimase postituse väide, et on vaja pingutada, et sulle raamistikku maha müüa, et sa seda kasutama hakkaks. Siit jääb kangesti mulje, et sa ikkagi kujutad endale ette, et sa loed mingit teooriat natuke ja siis lased puusalt täpsemini, kui teised mehed optilise sihikuga pärast aastatepikkust treeningut.

See ikkagi taandub kõik ju rahale - kas sa oled pannud kõrvuti rahanumbrid, mis kulub sul oma raamistiku ja rakenduse ehitamisele vs rakenduse ehitamine olemasoleva hästi toetatud raamistiku baasil? On sul selline raha? Ja kas sa oled valmis kõigi nende riskide jaoks, mida siin eelpool on välja toodud?

Mis puutub teoreetilisse käsitlusse - kas sa oled minu soovitatud kahe allika poole vaadanud? Raamistike lähtekood/developer meililistid ja teaduspublikatsioonid (kui sul on mõne ülikooli kaudu äkki võimalik neile ligi pääseda, siis Web of Knowledge peaks näiteks olema mingi koht, kust alustada otsingutega).

[jnt]

Fukiku, huvitabki teoreetiline teadmine. Ma olen alati siin rääkinud, et ei välista mõne fw kasutamist ja võib-olla ongi mõne fw peale üleminek. Kuid praegune esimene step on mul on teada saada täpsemalt, kuidas kõike teha. Selle järgi vaatan ka fw sortsu, kuna ma ei hakka valima fw'd mingite video tutorialide järgi. Praegust projekti olen kasutanud näitena, kui täpsemalt mu postid uuesti läbi loed.

Ärge hakake mulle sõnu suhu panema vaid lugege ka, mida räägin. Tahan teoreetilist materjali ja kui rääkida konkreetsest projektist siis see, kas sinna tuleb mõnid 3rd-party fw või mitte, on lahtine ja üldse teine teema.

Saage aru, ma ei hakka praegu midagi ehitama, ma tahan vaid infot, kuidas ehitada.

[Fukiku]

Selge, siis ma olen öelnud kõik, mis ma oskan öelda antud teema kohta.

Huvipärast proovisin ise - MVC web framework otsingu peale tuli Web of Knowledge kaudu 62 publikatsiooni, millest ehk õnnestuks mõni tera välja sõeluda .. ja siis loota, et ka täistekstile ligipääsu saab.

[serk]

Sry, viimane postitus non topic teemal, aga loodan, et sa ei pahanda

Läbi on käinud vestlus teemal java või php - üldiselt kui on tõsiselt suur infosüsteem, siis tasuks siiski mõelda java peale.
Enterprise tasemel lahendus omab kolme kihti - andmebaas, middle tier(no ei tule eesti keelne mõiste meelde) ja frontend. Middle tier'it PHPs ei tee, kui siis ainult mingi käsitsi nikerdatud värk. PHP kood üldjuhul on mingisugune mega monstrum makaron.

Siit tuleneb ka küsimus, et mis kihti planeerid sa panna äriloogika? Kirjutades PHPs on sul sisuliselt kaks võimalust: frontendi või andmebaasi. Kuna tihedalt on läbikäinud activerecord, siis oletan, et enamus loogikast topid frontendi. 40+ ja expo. kasvav DB saab sul väga kiiresti probleemiks, ehk patterni otsimisel pead kindlasti skoopi lisama ka andmebaasi. Mulle on samuti natuke see teema segane. Sa oled väga detailides, sa oleks juba nagu ära otsustanud sisuliselt tehnilise lahenduse - activerecord ja hibernate. Ehk sisuliselt oled sa juba ära piiranud oma valikud. Või kui need tehnoloogiad pole "must be used", siis mina alustaks kõrgemalt, võtaks näiteks EA ja hakkaks joonistama, alustades andmemudelist ja lõpetades UI ja andmete liikumise skeemidega. Selle pealt juba saab rohkem infot planeerimiseks ja soovitamiseks.

Amazonis on ka väga palju selle teemalisi raamatuid, osta sealt mõned.

Rohkem ei postita non topic teemasi , sry

[jnt]

serk, ei, ei pahanda.

Praegu on olemas activerecord cache'ide ja värkidega ja controlleris käib suhtlus factory'te ja activerecord objektidega. Factory'd on staatilised klassid, kus sees on põhimõtteliselt hunnik staatilisi funktsioone, mis annavad ühe või mitu activerecord objekti. Factory'd on põhimõtteliselt nagu prefilled filtrid objektide otsimiseks. Äriloogika funktsionaalsus istub iga konkreetse activerecord objekti sees. (nt "Client extends ActiveRecord" ja loogika on Client klassis) Äriloogika niiöelda käivitamine on kontrolleri teha. View osa on hetkel vaid smarty template'i osa, kuid kohati tekib tunne, et võiks vaja minna mingitsugust view-controller'it ka.

Et selline on hetkel ülesehitus. Ideeliselt ei ole sel häda midagi, kuid praegune admin paneel, mis kaugemas tulevikus tuleks normaalseks saada, on suurel määral väga vana kood, kus siiani tehakse nii mõneski kohas otse päringuid andmebaasi jne. (admin paneel kui selline koosneb hetkel siis kontrolleritest ja template'idest.)

Aga see on see, kuidas asi praegu on. Tuleviku suhtes pole veel ühtegi vaia maha löödud.

Amazon'ist juba otsin ja siin mainitud raamat ka üle vaadatud ja arvatavasti tellitakse üht-teist nüüd varsti ära.