Pradinis
Pagalba
Užsisakyk!
- Reklamą
- Hostingą
- El. pašto dėžutę
Užsisakyk!
Įrankiai
Pasidalink
- Visos temos
Forumas | PHP-Fusion, WordPress, Shopify, PHP ir MySQL (PROGRAMAVIMAS) | Bendri PHP-F klausimai |
Autorius: mirkus | Peržiūrų: 13217 |
mirkus Narys Patrankų mėsa Pranešimai: 5 Įstojęs: 2017 Spa. 21 00:10:34 | |
Parašiau chat'e tokią žinutėlę, bet atrodo, jog simbolių limitas užsimetė. Sakyčiau, čia yra bug'as šitame saite. Jeigu limituojate žinutės ilgį, turėtų būti aiškiai tas nurodyta. Tą galima padaryti metant error'ą arba tiesiog nukerpant tekstą, t.y. neleidžiant daugiau rašyti. Kaip patogiau, bet iš UI/UX pusės tai gaunasi visiškas fail'as šioje vietoje. O šiaip man įdomu, kaip PHP-Fusion gali turėti kažkokią ateitį apskritai. Ar yra vizija kažkokia? Jeigu taip, tai kokia? Kiek suprantu, dabar fusion'as skirtas paprastiems user'iams, kurie nenori vargti kurdamiesi saitą. Tai tas neblogai yra visai. Susimeti failus į servą, paleidi 'install.php' (anksčiau, kiek pamenu, buvo 'setup.php', bet principas tai tas pats) ir viskas įsirašo. Bet va yra toks dalykas - jeigu user'is yra visiškai neišmanantis, kaip naudotis hostingo teikiamais privalumais, jis iki susimetimo step'o net neprieis. Bet jis nori turėti saitą. Ir samdys kažką, kas jam įmes tą saitą ir suinstalins. Tai va šioje vietoje galima eiti toliau. Sakykime, sukurti kokį nors apps'ą (kad ir ant Qt parašytą, jog būtų cross-platform), kuris automatiškai prisijungia prie user'io nurodyto FTP servo, sumeta fusion'ą ir jį įrašo. Tai yra, user'is labiau nori viską pasidaryti vienu click'u be ėjimo per krūvą step'o. O po to jau turėti saitą ir jį pasikonfiginti per adminkę be jokių error'ų. Tačiau situacija apie PHPF dabar. Deja deja, bet jį developina visiški lameriai arba žmonės, kurie šiaip mėgsta užsiimti opensourceingu, bet nėra tikrieji pro developeriai. Tikėtina, pastarieji turbūt ir palaiko šitą TVS. Tada kyla kitas klausimas. O kas lems, jog, augant user'io, norinčio saito, verslui, jis ir toliau liks su fusionu? Kodėl jam nebus geriau investuoti pinigus į kitą sistemą, kuri būtų patikimesnė? Va čia PHP-Fusion ir fail'ina, nes visiškai ignoruoja verslo logiką, scale'inimąsi. Tada apibendrinant viską. Fusion'as, atrodo sugeba atsitiktinai eiti gera linkme. Bet reikėtų daugiau aiškumo, tikslingumo ir konkretumo. Jeigu tas būtų, tai tada fusion'as turbūt ir nemirs. Kitaip sakant, trūksta šių dalykų dabar fusion'e: 1. Abstraktaus duomenų bazės sluoksnio. Net ir dabar PHP-Fusion sugeba palaikyti tik MySQL. Tai yra riba, kurią reikėtų apeiti. Rimtas CMS'as turi sugebėti palaikyti bent kelias labiausiai naudojamas šiuo metu duomenų bazes. 2. Resursų kūrimo ir nuskaitymo variklis. Dabar atrodo, kad vienintelis išorinis resursas fusion'e - paveiksliukai. Bet realiasi tai gali būti bet kas, tad nereikėtų apsiriboti vien tik image'ais. 3. Migracijos variklis. O čia rimtai svarbu. Sakykime, naudoju Wordpress ir svarstau pereiti prie fusion'o. Ką man daryti, kad visus duomenis iš wordpress'o permesčiau į fusion'ą? Na rankutėmis viską perkelti turbūt... O kodėl to neina automatizuoti? Taip kad fusion'as turi kur tobulėti, ir kryptys tobulėjimui aiškios. Jeigu tos kryptis bus įgyvendintos, fusion'as ateitį turės. Kitu atveju bus mirtis. |
|
ewl VIP narys Pulkininkas Pranešimai: 419 Įstojęs: 2008 Rugp. 22 10:08:27 | |
mirkus parašė: Net ir dabar PHP-Fusion sugeba palaikyti tik MySQL. Nuo v9 palaiko PDO ir MySQLi. |
|
mirkus Narys Patrankų mėsa Pranešimai: 5 Įstojęs: 2017 Spa. 21 00:10:34 | |
ewl parašė: <...> Nuo v9 palaiko PDO ir MySQLi. Tas vis tiek nekeičia situacijos. PDO yra tik PHP lib'as kaip abstrakcija naudoti duomenų bazę. Kaip tai buvo "mysql_* and friends", taip vietoje to atsirado aukštesnio lygio abstrakcija. Ir gerai, kad PHP-Fusion tą ėmė naudoti. O va MySQLi support'as nėra kažkas wow, nes tai yra tas pats MySQL veikiantis kaip extension'as, skirtas quer'inti... MySQL'ą... Kita vertus, žiūrint iš kodo, tai chebra ten tiesiog sumetė tą abstrakciją, bet paliko tas pačias užklausas nepasirūpinę, jog atsirastų kažkoks tai interfeisas ORM'ui, kas jau įgalintų bent jau pradėti rašyti ORM'o implementacijos engine'us ir plėsti PHP-Fusion galimybes palaikyti ne tik MySQL, bet ir ką nors daugiau. Va tarkim būtų pasikeitimas, jeigu PHP-Fusion turėtų tokį core'ą, jog būtų įmanoma parašyti driver'į, pavyzdžiui, kokiam Raven DB. Tiesiog tai yra NoSQL'inė DB, kuri yra greita ir paprastam saitui nėra problemos to naudoti. Bet Raven DB turi kitų privalumų, susijusių su tam tikrų užduočių vykdymu. O dar geriau būtų, jeigu apskritai būtų įmanoma vienu metu naudoti kelias duomenų bazes. Sakykime, man niekas nedraudžia pakurti MySQL, Raven DB ir dar kokį Postgre SQL ant to paties servo. Ir gal aš matau prasmę visas šis DB naudoti skirtingoms užduotims atlikti? Ir va norėčiau, jog man užtektų PHP-Fusion utilizuoti visam tam funkcionalumui. Tad iš esmės kryptis fusion'ui, kurią matau, tai jam reikėtų tapti framework'u, kuris dalinai implementina ką reikia, jog būtų galima pasileisti saitą. Va, licencija padori yra, trūksta tik turbūt vizijos jiems iš šito reikalo išspausti totalų maksimumą. |
|
avice Narys Terminatorius Pranešimai: 1441 Įstojęs: 2010 Bir. 25 20:06:33 | |
Per gyliai mastai. |
|
RIOMAS51 Narys Patrankų mėsa Pranešimai: 4 Įstojęs: 2014 Sau. 15 19:01:25 | |
Labas vakaras aišku mirkus gera kritikuoti kitus, php-fusion sistema yra tai kas nestovi vietoje ir kiek vienas gali dirbti juk tai atviro kodo kūrinys. O tobulumui ribų nėra... tikiu, kad ką čia aprašei yra šios sistemos ateitis. Pagarbiai: riomas senas nikas riomas |
|
ozzWANTED Administratorius Legenda Pranešimai: 8478 Įstojęs: 2006 Gru. 29 14:12:31 | |
MySQL'as yra puiki duomenų bazė su savo MariaDB alternatyva. WordPress'as labai puikiai argumentavo, kodėl visokie heavy-weight ORM'ai iš esmės neturi prasmės, o dar ir nesaugūs yra: https://codex.wordpress.org/Usin..._Databases Tas pats ir Fusion'ui galioja. Į šį tinklapį aš žiūriu pirmiausia kaip į programuotojų ir dizainerių bendruomenę. Ir viskas galiausiai susiveda į finansus, t.y. norėjimą investuoti bent jau 20,000 EUR į tai, kuo tiki. Aš tikiu šiuo portalu. Kaip tikiu, kad ir Fusion'as su tinkamomis investicijomis turi parako ir potencialo. Ir aš tikrai turiu planų investuoti į tai. Aš netikiu Facebook'u (kuris dabar jau net Food Ordering'o servisą pristatė), netikiu ir Google'u. Ir manau yra labai daug žmonių pasaulyje, kurie nori tam priešintis. Tad tikrai yra perspektyvų. O kalbant apie Licenziją, kaip ir minėjau, Php-Fusion licencija yra kur kas geresnė ir tinkamesnė komercijai, nei kokio WordPress'o. Ir WordPress'as savo GPLv2 tikrai nekeis, nes licencija, iš esmės yra visko pamatas, pradmuo. BR#1, Most Wanted |
|
Žmogus Narys Viršesnis už Dievą Pranešimai: 5621 Įstojęs: 2006 Gru. 8 17:12:08 | |
ozzWANTED parašė: MySQL'as yra puiki duomenų bazė su savo MariaDB alternatyva. WordPress'as labai puikiai argumentavo, kodėl visokie heavy-weight ORM'ai iš esmės neturi prasmės, o dar ir nesaugūs yra: https://codex.wordpress.org/Usin..._Databases Tas pats ir Fusion'ui galioja. Į šį tinklapį aš žiūriu pirmiausia kaip į programuotojų ir dizainerių bendruomenę. Ir viskas galiausiai susiveda į finansus, t.y. norėjimą investuoti bent jau 20,000 EUR į tai, kuo tiki. Aš tikiu šiuo portalu. Kaip tikiu, kad ir Fusion'as su tinkamomis investicijomis turi parako ir potencialo. Ir aš tikrai turiu planų investuoti į tai. Aš netikiu Facebook'u (kuris dabar jau net Food Ordering'o servisą pristatė), netikiu ir Google'u. Ir manau yra labai daug žmonių pasaulyje, kurie nori tam priešintis. Tad tikrai yra perspektyvų. O kalbant apie Licenziją, kaip ir minėjau, Php-Fusion licencija yra kur kas geresnė ir tinkamesnė komercijai, nei kokio WordPress'o. Ir WordPress'as savo GPLv2 tikrai nekeis, nes licencija, iš esmės yra visko pamatas, pradmuo. Gal galima plačiau dėl tos licenzijos? Koki jinai čia vaidmenį atlieka? Kas dėl ateities. Tai tiesiog pavėlavo smarkiai su ta nauja versija. Kaip konkurentai jau pralenkė, net pats WP pristatė visiškai naują platformą: https://developer.wordpress.com/... o ką fusionas per ta laiką padarė? iš MySQL* perėjo į PDO? Pasižiūrai į https://github.com/php-fusion/PH...incore.php arba https://github.com/php-fusion/PH.../print.php tai net šiurpas nukrečia, dabar dauguma nauji CMS, sukasi ant frameworkų, kas yra visiškai suprantama. Kodas tvarkigas, daug lengviau maintaininti ir pnš. O čia gauni spagheti code. Ir poto stumia, kad PHP prasta programavimo kalba, nes visur aplinkui visokie bad practises. Smagu, kad ji dar maintainina (PHP-Fusion), bet manau reiktu jau jį apleisti po mažu arba daryti kažką visiškai naujo, bet čia daug darbo ir neverta gaišti laiko tam, vis tiek kažko naujo ir revoliucingo nepasiūlys.. Kas dėl portalo tai biški gaila, kad apmirė, nes čia tikrai nebloga būtų programuotojų ir dizainerių bendruomenė, bet reiktu keistis iš esmės, perdaryti į forumą. Redagavo Žmogus 2017 Spa. 31 21:10:24 |
|
ozzWANTED Administratorius Legenda Pranešimai: 8478 Įstojęs: 2006 Gru. 29 14:12:31 | |
Dėl licenzijos. Esmė ta, kad WP yra išleistas ant GPL. O GPL sako, kad taip, tu gali sukurti kitam asmeniui komercinį produktą / tinklapį, ir neprivalai dalintis su visais tuo (EXCEPT if you are going to distribute it). Vat būtent ta EXCEPT yra ir yra didžiausia bėda. Jeigu nori savo sukurtą produktą ar whatever platinti (ne parduoti vienam klientui) už pinigus pvz. 1000-ančiui, tu to daryti pagal GPL negali, t.y. privalai į WordPress.org įkelti pvz. tą savo THEME. Kai tuo tarpu Php-Fusion'as V9 net ir pats "Native" turi mokamus pluginus / themes savo tinklapyje, papildomai prie nemokamų. Ir tai galbūt dabar nėra tokia didelė bėda, kol į šitą faktą yra žiūrimą pro pirštus, bet apie tai yra kalbama, ir licenzijos bėdos, kaip žinia ištinka kai tampi labai populiarus, top-selling, tada kažkas gali pradėti rašyti straipsnius, ir pradėti daryti spaudimą, tada kokia ES agentūra imtųsi didelio tyrimo ir t.t., ir gali paliepti open-sourcint'i. Kaip va neseniai JAV teisėja liepė vienai IT įmonei, kuri daro DNR tyrimus. Tiesa, ten dėl pačio DNR algoritmo tikrumo, bet precedentas yra. Todėl tu gerai pagalvoti turi apie savo verslo modelį prieš priimant sprendimus. Ar 'problemos' atveju ruošiesi PATS parašyti naują CMS'ą ar Framework'ą (t.y. 'Version without WordPress' ir spręsti visokius autentifikacijos, o svarbiausiai rinkos patikimumo klausimus), ar pasiimsi kokį CMS'ą su tinkama licencija, kuris maitaininamas, žinomas jau 15 metų, turėjęs šlovingų dienų praeityje, ir savo paskirtimi iš esmės panašus (WP+bbPress+BuddyPress = Php-Fusion). Fusion'o, nežinau, neigiamas ar teigiamas dalykas yra tai, kad forumas ir user-messaging nėra kaip pluginai. Jeigu būtų, tai galbūt blogai tuo, kad visad turėtum tikrinti ar tokia funkcija įjungta, būtų sudėtinga kitką kabinti ir t.t. Bet, kaip ir minėjau, šitas Forumas dar 2007 metais išėjo už Php-Fusion'o, ir net už programavo ribų, ir apima visą e-commerce stack'ą - programavimą, interneto verslus, web-dizainą, reklamą. Akcentas programavimas be abejonės, jaunųjų programuotojų mokymas. Ir pats portalas savo realizacija (naujienos, straipsniai, forumas, chat'as) ir visa kita yra tikrai geri sprendimai ir jie puikiai tinka ir šiomis dienomis, tik jie parašyti 10-11 metų senumo technologijomis, o user-interaction šiuo metu kiek inovatyvesnis. StackOverflow'as labai gerai daugelį klausimų išsprendė, ypač su Ajax'u. O ir dalykai skiriasi - pabandyt įtakoti WordPress raidą vienas žmogus nelabai jau gali, tai kaip korporacija kokia, tik kad opensource. O štai Php-Fusion'ą gali net ir labai smarkiai. Tik turi žinoti ko jis siekia. BR#1, Most Wanted |
|
equals Narys Kapitonas Pranešimai: 751 Įstojęs: 2009 Lie. 31 00:07:41 | |
Sutinku ,kad si bendruomene buvo pradejusi plestis uz php-fusion ribu, kas man labai patiko. Tai koks dabar planas laukia sio projekto? Noreciau kazkaip prisidet prie atgaivinimo |
|
ozzWANTED Administratorius Legenda Pranešimai: 8478 Įstojęs: 2006 Gru. 29 14:12:31 | |
Tie laikai, kai investuotojai dalina pinigus praėjo. Jeigu jie išvis kada buvo, nors gal ir buvo kurį laiką, kokiam Silicon Valley. O visur kitur tai ką gali gauti lengviau tai banko paskolą verslui, kurią reikės grąžinti. Tai tikrai nėra gera idėja, tai ne lizingas automobilio ar ofiso patalpų pirkimas. Tad vienintelis logiškas sprendimas yra dėti savo lėšas, nepaisant to ar programuosi kažką ar neprogramuosi. Be 20,000 EUR'ų šiais laikais nieko nepadarysi. Tad tuos pinigus reikės įdėti bet kuriuo atveju. Jeigu esi sukaupęs santaupų, tiki šiuo projektu, gali padaryti savo bent 5,000 EUR įmoką, kaip savo dalį, tada parašyk į gamespot TŠK ltu GMAIL'ą. Jeigu nori programuoti metus - irgi gali parašyti, bet turi suprasti, kad bet kuriuo atveju vis vien kažkas turės įnešti pinigus - kitu atveju tai tik vaikų fantazijos. Dar kitas dalykas, prisidėdamas prie komandos turi atsisakyti per didelių ambicijų, ir nerealių vizijų. Aš, Creatium, ar kuris kitas co-founderis visad išklausys į protingas mintis ar pasiūlymus, bet turi suvokti, kad toks projektas pirmiausia yra filantropija, kurio esminė nauda yra politika, reputacija, pažinčių tinklas, o ne finansinė grąža. Kitiems metams turime įvairių idėjų. Bet jokių pažadų čia nedalinsiu. Beje, investavimas liečia visus be išimties. Vadinasi savo laiku ir man savo lėšas taip pat reikės įdėti. Dėl to, kad aš tikiu šiuo projektu, ir jo vizija. Ir kiekvieną dieną matydamas pyktį kylantį žmonių prieš Facebook, prieš Microsoft'ą, kuris dabar dar ir Linked'ą su Outlook'u apjungė, tikrai žmonės vis labiau pradeda rūpintis savo gyvenimo kokybe ir gerbti privatumą. Žmonės nebenori, kad korporacijos joms diegtų į galvas, už ką balsuoti, su kuo susiconnectinti, kas geras o kas blogas. Stackoverflow'as irgi nudegė. Užvakar buvo straipsnis TC'e, kad jie 20% layoffiną darbuotojų, iš esmės visus 3rd party hiringo servisus, nes vos nepaklydo, kas jie yra - ar dev community, ar hiring'o platform'a pilna reklamos, tad jie grįžta prie savo ištakų. Ir man labai nepatinka tas žodis 'gaivinimas'. Gaivina tuos kurie negali egzistuoti be pinigų, užsidaro ir pan. Su bendruomenėmis, yra kiek kitaip - tai iš esmės labiau žengimas su tų dienų technologijomis, inovacijomis ir poreikiais. Ir kai kalbu ten apie 20,000 EUR'ų, tai kalbu apie mažiausiai, kad apskritai kažkas pasikeistų. Tikrai galima ir 100,000 EURų sudėti be jokių didesnių problemų. Tad visad reikia suvokti savo ambicijų dydį, kas realu, o kas ne. Mačiau ne vieną projektą, kur ir 30 milijonų ES lėšų sudegino pilotiniams projektams. O čia veikianti, egzistuojanti ir žinoma bendruomenė su daugiau nei 10 metų istorija. Tad žengti žingsnį ten, kur 10 metų kapitalas yra, yra daug lengviau nei pakeisti pasaulį su pilotu. BR#1, Most Wanted |
|
mirkus Narys Patrankų mėsa Pranešimai: 5 Įstojęs: 2017 Spa. 21 00:10:34 | |
Tokiam CMS'ui kaip fusion'as geriausia licencija būtų "The Unlicense ". |
|
Žmogus Narys Viršesnis už Dievą Pranešimai: 5621 Įstojęs: 2006 Gru. 8 17:12:08 | |
Tai kas pasikeitė per 2 metus php-fusion pasaulyje? |
|
mynootropics Narys Patrankų mėsa Pranešimai: 2 Įstojęs: 2016 Rugs. 9 17:09:00 | |
Seni geri php-f laikai) |
|
XruN Narys Terminatorius Pranešimai: 1215 Įstojęs: 2008 Spa. 12 19:10:31 | |
Tikriausiai niekas sena gera tvs bet d4ja 6iomis dienomis jau pasenusi ir nepasi8lo to ko reikia 6iomis dienomis Uždarbis internete: https://uzdarbisinternete.lt |
|
Narys Patrankų mėsa Pranešimai: 3 Įstojęs: 2021 Vas. 2 13:02:54 | |
Gal ir pavėluotai, bet pastebėjimai ir dabar aktualūs. Dėl ORM argumentai, sakyčiau, silpnoki. Jeigu netinka esami abstrakciniai layeriai, tą galima pasirašyti ir patiems (WP, kiek suprantu, kažkokį layer'į ir naudoja, tik kur kas paprastesnį, kas nebūtinai yra blogai). Jeigu pasiūlys kažką light-weight, paprastesnio, bet saugaus ir veikiančio, tai tą daug kas ir naudos. Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas. ORM layerio paskirtis yra tiesiog užsitikrinti pakankamą abstrakcijos layer'į, kuriame būtų galima kurti entities klases su tipizuotais laukais, taip pat pateikti savo custom filtrus, pritaikytus būtent dalykinei sričiai. Iš jų po to gauname entities klases, repozitorijas, dar controllerius. Patiems visa tai apsirašyti užtruktų nemažai laiko, todėl tas mums padeda sutaupyti laiko. Jeigu layeris failina paprastuose dalykuose, tai čia yra ne idėjos problema, o tiesiog "poor implementation details". Pavyzdžiui, Doctrine tikrai galėtų suimplementinti protingesnį insert'ą SQL'ui su didesniu kiekiu duomenų apart šaudyti po vieną insert'ą, dėl ko skundžiasi beveik visi per stackoverflow, kas su tuo susidūrė. Gal su ORM problema, kurią galima būtų pastebėti, yra tai, kad jie bando sukurti abstrakciją tiek užklausoms, tiek migracijoms, t.y. bando būti šveicarišku peiliu. Bet čia jau problema kaip ir visur. "Kas tinka viskam, tas netinka niekam". Galbūt protingiau būtų atskirti visus ORM'us į tris dalis - duomenų logikos sukūrimas, duomenų logikos naudojimas ir duomenų logikos migracija. Bet klausimas, ar tai patiks programuotojams. Pats PHP eina labai geru keliu išties. Turi Composer, patys 3rd party libai daugumoje yra labai "lousely coupled", gal net labiau nei kokiame C#. Ir tas yra puiku, nes tai rodo, kad didelę dalį problemų galima išspręsti rašant geresnius libus. Man su PHP kas patinka, tai kad užtenka susikurti Composer projektą ir jau gali susibuildinti norimą frameworką vien iš libų. Retai kur tokį dalyką pamatysi - ten iškart turi pasiimi "core boilerplate" kodą ir ant jo mėginti kažką lipdyti. Galutinis klausimas. Pamenu, šis puslapis turėjo krūvas lankytojų kažkada. Ir nemaža dalis jų buvo norintys prisidėti prie bendruomenės plėtros savo lygyje. Kur jie visi dingo dabar? |
|
Žmogus Narys Viršesnis už Dievą Pranešimai: 5621 Įstojęs: 2006 Gru. 8 17:12:08 | |
programuotuvas parašė: Gal ir pavėluotai, bet pastebėjimai ir dabar aktualūs. Dėl ORM argumentai, sakyčiau, silpnoki. Jeigu netinka esami abstrakciniai layeriai, tą galima pasirašyti ir patiems (WP, kiek suprantu, kažkokį layer'į ir naudoja, tik kur kas paprastesnį, kas nebūtinai yra blogai). Jeigu pasiūlys kažką light-weight, paprastesnio, bet saugaus ir veikiančio, tai tą daug kas ir naudos. Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas. ORM layerio paskirtis yra tiesiog užsitikrinti pakankamą abstrakcijos layer'į, kuriame būtų galima kurti entities klases su tipizuotais laukais, taip pat pateikti savo custom filtrus, pritaikytus būtent dalykinei sričiai. Iš jų po to gauname entities klases, repozitorijas, dar controllerius. Patiems visa tai apsirašyti užtruktų nemažai laiko, todėl tas mums padeda sutaupyti laiko. Jeigu layeris failina paprastuose dalykuose, tai čia yra ne idėjos problema, o tiesiog "poor implementation details". Pavyzdžiui, Doctrine tikrai galėtų suimplementinti protingesnį insert'ą SQL'ui su didesniu kiekiu duomenų apart šaudyti po vieną insert'ą, dėl ko skundžiasi beveik visi per stackoverflow, kas su tuo susidūrė. Gal su ORM problema, kurią galima būtų pastebėti, yra tai, kad jie bando sukurti abstrakciją tiek užklausoms, tiek migracijoms, t.y. bando būti šveicarišku peiliu. Bet čia jau problema kaip ir visur. "Kas tinka viskam, tas netinka niekam". Galbūt protingiau būtų atskirti visus ORM'us į tris dalis - duomenų logikos sukūrimas, duomenų logikos naudojimas ir duomenų logikos migracija. Bet klausimas, ar tai patiks programuotojams. Pats PHP eina labai geru keliu išties. Turi Composer, patys 3rd party libai daugumoje yra labai "lousely coupled", gal net labiau nei kokiame C#. Ir tas yra puiku, nes tai rodo, kad didelę dalį problemų galima išspręsti rašant geresnius libus. Man su PHP kas patinka, tai kad užtenka susikurti Composer projektą ir jau gali susibuildinti norimą frameworką vien iš libų. Retai kur tokį dalyką pamatysi - ten iškart turi pasiimi "core boilerplate" kodą ir ant jo mėginti kažką lipdyti. Galutinis klausimas. Pamenu, šis puslapis turėjo krūvas lankytojų kažkada. Ir nemaža dalis jų buvo norintys prisidėti prie bendruomenės plėtros savo lygyje. Kur jie visi dingo dabar? Kažką, kolega, maišot su ORM ir dideliai insertais, ORM ne tam skirtas |
|
Narys Patrankų mėsa Pranešimai: 3 Įstojęs: 2021 Vas. 2 13:02:54 | |
Žmogus parašė: <...> Kažką, kolega, maišot su ORM ir dideliai insertais, ORM ne tam skirtas Siūlau dar kartą paskaityti. Kažko apie ORM ir didelius insertus aš nieko kaip ir neakcentavau konkrečiai. |
|
Žmogus Narys Viršesnis už Dievą Pranešimai: 5621 Įstojęs: 2006 Gru. 8 17:12:08 | |
Tai kas gero nutiko su php-fusion per tiek laiko? Matau, kad githube yra branch "Andromeda", galvojau, kad bus kažkas įdomaus. Bet still spagheti code... https://github.com/PHPFusion/PHP.../print.php P.S. kas čia? Konkurentai šito portalo? http://www.phpfusion.lt/news.php programuotuvas parašė: <...> Siūlau dar kartą paskaityti. Kažko apie ORM ir didelius insertus aš nieko kaip ir neakcentavau konkrečiai. Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas. Norėčiau šaltinio apie ORM ir mass insert |
|
Narys Patrankų mėsa Pranešimai: 3 Įstojęs: 2021 Vas. 2 13:02:54 | |
Žmogus parašė:Tai kas gero nutiko su php-fusion per tiek laiko? Matau, kad githube yra branch "Andromeda", galvojau, kad bus kažkas įdomaus. Bet still spagheti code... https://github.com/PHPFusion/PHP... Jie net branch'ams pavadinimus teikia kažkokius keistokus, o ne pagal nusistovėjusius standartus. Tad ar galima tikėtis normalaus kodo ten? Visgi čia tik vienas failas, ar ne? Gal jie kitur ten šaudo nerealius refactoring commit'us? Nelabai: https://github.com/PHPFusion/PHP...6329b7ee27 . Tiesiog jie išsitraukia kažkokius singleton'us, po to juos naudoja, kad parašytų utility funkcijas, kurias patys po to naudoja. Ir taip lipto antipattern'us ant antipattern'ų. Visgi gal tik čia taip negražiai? Na ne, panašu, tai yra tendencinga. Pvz čia maišomi concern'ai: https://github.com/PHPFusion/PHP...91ff06b194 . Ne paprasčiau būtų tiesiog naudoti kokį views'ą, kuris neturėtų jokių sąlygų, o po to jau logikoje atfiltruoti duomenis, kuriems tas views'as būtų pritaikytas (t.y. MVC, MVP, MVVM pattern'ai). programuotuvas parašė: <...> Siūlau dar kartą paskaityti. Kažko apie ORM ir didelius insertus aš nieko kaip ir neakcentavau konkrečiai. Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas. Norėčiau šaltinio apie ORM ir mass insert Na ten nieko ypatingo nerašiau, tiesiog manau, kad Doctrine kūrėjai labiau galėjo pasistengti su transakcijų optimizacija. Nes ką reiškia transakcija? Iš esmės išeina, kad tu pirma suformuoji užklausų paketą, o po to jį commit'ini, t.y. nurodai vykdyti. Tai Doctrine bent tuo metu, kai teko juo naudotis (tas buvo kažkur prieš 6mėn, nes mano stack'as kiek kitoks yra, tad galiu ir klysti), tai multiple insert'us tiesiog šaudo po vieną, o ne sudeda, pavyzdžiui, optimizuojant pagal duomenų bazės tipą. Pvz MySQL galima taip daryti: INSERT A1 INSERT A2 arba, jeigu A1 ir A2 toje pat lentelėje randasi ir naudojami stulpeliai sutampa: INSERT A1, A2. Aišku, galima stumti ant to fusion'o, kiek tik norime, galima tam ir galo nematyti, bet siūlyčiau pastebėti kelis dalykus. Ir jie labai paprasti: 1. PHP-Fusion pirmą versiją parašė žmogus, kuris pasivadino Nick Jones, Digitanium jo slapyvardis buvo. Tuo metu tai buvo tikrai fenomenalus programuotojas, iš kurio ir pats daug išmokau. Deja, jis mirė. Tad neliko pagrindinio šios idėjos kūrėjo dar tuomet, kai jis nebuvo perdavęs šios idėjos kažkam kitam. O ir fenomenalumas yra labai reliatyvus dalykas. Dabar tai vadiname spaghetti code, tada tai buvo superinis kodas, nes kiti rašė dar tragiškiau. Tas žmogus sugebėjo vos per kelias dienas perrašyti bug'ovą messages.php faile esantį kodą, kai pamatė, kad yra beviltiška ten lopyti visas spragas. Ir ne tik perrašė, bet ir išreleas'ino. Tai, mano manymu, yra neblogo developer'io bruožas. Kitas ten burtų apie mėnesio projektus, darytų krūvas meeting'ų, o tas tiesiog padarė darbą ir ramu buvo. 2. PHP-Fusion atsirado dar 2003 metais, jeigu ne dar anksčiau, nes aš pamenu, kad 2004 metais tai jau buvo kokia 5 ar 6 versija. Ir kiek matau github'e, yra kodo dar dabar iš 2003 metų. O to kodo ir tada buvo tūkstančiai eilučių. Nejau realu tikėtis, kad tokį kodą, kuriam beveik 20 metų, įmanoma vien open source iniciatyva išrefactor'inti? Aš tai abejočiau tuo, nes refactor'inimas yra juodas darbas, neretai ir ten, kur mokami pinigai, renkamasi geriau viską rašyti nuo nulio negu taisyti kodą, kuris jau kaip giltinė reikalauja grąžinti visas gyvenimo skolas. 3. https://github.com/PHPFusion/PHP...ntributors - kiek žmonių PHP-Fusion develop'ina. 38. Tai nėra daug, bet ir nemažai. Ar jie kažką tarpusavy derinasi, turi kassavaitinius meeting'us? Na ne. Ir kas tie žmonės? Kiek matau, tai nėra high level developer'iai. Didžioji dalis net nepraeitų atrankos ten, kur pats dabar dirbu, jeigu ne visi iš jų. Tad, kaip ir minėjau, galima stumti kiek nori, bet PHP-Fusion tiesiog dabar neturi jokių sąlygų būti išgelbėtas. Norint išgelbėti tokį framework'ą reikėtų monstriškų pastangų. O visi rimti developer'iai šiandien, deja, to laiko turi labai mažai. Kaip ir aš pvz. Kada čia galiu prisijungti? Vos kartą per pusmetį ar rečiau netgi. ir taip yra, nes darbų belekiek. Atrodo, renkiesi tuos darbus, esi išrankus, bet vis tiek jie tave vejasi ir tik retkarčiais atsiranda daugiau laisvumo. |
|
ozzWANTED Administratorius Legenda Pranešimai: 8478 Įstojęs: 2006 Gru. 29 14:12:31 | |
Susitvarkytum kapitalą asmeninį, pasyvias investicijas, tai ir to laiko atsirastų. Jeigu neatsiranda, vadinasi yra viduje problemų tavo gyvenime (nesakau, kad man geriau). Bet jeigu gyvenime esi patyręs, laisvo laiko tikrai turėtum. BR#1, Most Wanted |
Peršokti į forumą: |