Kako postići modularan i robusan PHP framework

[bozoou]

Pozdrav,

naum je sljedeći…
napraviti PHP framework koji je modularan na sljedeći način:

• svatko tko dodaje komponentu u sustav, može nasljediti sve od komponenti iz svoje iznad hijerarhije, ali ne može na nikakav način utjecati na file-ove te komponente iz hijerarhije iznad.

Drugim riječima:

• ako bi se pojavila komponenta u sustavu koja bi imala namjeru da našteti sustavu, smjela bi moći naštetiti samo komponentama koje su u hijerarhiji ispod nje, ali ne i onima iznad.

Znači framework je zamišljen tako da može lako ukapčati treće strane, te da onaj tko uključuje druge u sustav ne mora brinuti što će taj “pokvariti”. Jer taj smije moći pokvariti samo svoju komponentu i one koje će on uključiti ispod sebe.

Da pojasnim i što bi bila komponenta u gornjem kontekstu.
Komponenta bi tu bila ono što često zovemo kontrolerom. No struktura nekog frameworka je uglavnom podjeljena na kontrolere i metode koje pripadaju svakom tom kontroleru.

Npr. imamo kontroler Home i metode tipa: index, edit, delete, gdje url-ovi onda izgledaju:
Home/index , Home/edit, Home/delete.

Sada zamislimo da svaki kontroler unutar sebe može imati novi kontroler…i tako hijerarhijski u dubinu koliko god. Znači konačni url prema nekom kontroleru bi mogao izgledati:

Servis/AmazonTool/Users/Manage

No to nije samo link prema controleru Users i metodi Manage, nego taj link nam pokazuje hijerarhiju komponenti koje su tu uključene.

Tako na pvoj razini egzistira komponenta “Servis”.
Ta komponenta “Servis” može imati na prvoj razini ispod sebe koliko god komponenti. Recimo neka su to sljedeće komponente:

• AmazonTool
• OnlineRacun
• Oglasnik

Kao što vidimo, te sve komponente su nekakvi servisi i zato ih je očito Servis uključio ispod sebe.
No ideja je da svaka ta uključena komponenta egzistira nezavisno od drugih komponenti koje postoje na istoj razini.
Znači developeri komponente Oglasnik sve da i žele strgati nešto u komponenti AmazonTool to nebi smjeli moći. Što znači da moraju biti blokirani da rade FILE_WRITE akciju po strukturi tih paralelnih komponenti.
Isto tako ne smiju raditi nikakav FILE_WRITE po Servis komponenti, pošto je ona u hijerahiji iznad. Dok komponenta Oglasnik smije raditi kakav želi file_write po komponenatama koje će biti uključene u njezinoj hijerarhijskoj grani ispod nje.

E sad, kako sam imao iskustva sa virusima koji ne samo da su se širili unutar jednog projekta…nego su skakali sa projekta na projekt unutar host računa…te to nisam uspio zaustaviti postavljanjem ftp permissiona. …sve se nekako bojim da se gornji task ne može rješiti na toj razini.
Iako bi to bilo idealno. …ali i u tom slučaju bi framework morao moći upravljati ftp permissionima, što nisam siguran da PHP može odrađivati?

Kako god, imam neki osjećaj da za gornju specifikaciju zadatka sam poprilično stjeran u kut i da se ne nudi previše opcija?
Padaju mi neke na pamet, ali zadržat ću ih zasad dok ne čujem koje su solucije sve u igri?

Pa eto, pucajte. Hvala.

[tony]

Ubij me ako sam skuzio koji problem imas:)

Ono kako sam shvatio je da te brine sto kod dodavanja vanjskog paketa u PHP aplikaciju postoji sansa da je taj paket maliciozan i pise po filesystemu i mijenja sadrzaj ostalih (PHP) datoteka?

Ako da, zasto ne rijesiti to na razini filesystem permissiona?
Onom useru koji treba citati php datoteke das read-only prava nad istima, odnosno maknes dozvole za pisanje.

Jel bi ti to rijesilo problem?

[bozoou]

Ubij me ako sam skuzio koji problem imas:)

Da sam ja ubijao kada me netko ne skuži…bilo bi ovdje odveć mrtvih.

Ono kako sam shvatio je da te brine sto kod dodavanja vanjskog paketa u PHP aplikaciju postoji sansa da je taj paket maliciozan i pise po filesystemu i mijenja sadrzaj ostalih (PHP) datoteka?

Ne brine me radi dodavanja vanjskog paketa…ali dođe na slično.
Želim napraviti modularnost tako da je sustav skalabilan i da onoga na vrhu hijerarhije ne mora brinuti tko i što radi ispod njega. A da tako onda sustav može biti razvijan od koliko god treba developera, gdje svatko po istoj tehnici može uključivati novu ekipu ispod sebe.

Osim toga, imam još neke direktne potrebe gdje ću to koristiti. Razvijam jednu online platformu gdje bi omogućio da community razvija pluginove i da se samostalno nakapčava na centralni sustav … pa je logična potreba da svatko tko se ukopča, da mora biti neovisan. Zaštićen od drugih i u nemogućnosti da našteti drugima.

Ako da, zasto ne rijesiti to na razini filesystem permissiona?

Pa to bi bilo najidealnije. Ali kao što rekoh, imao sam već neke avanture sa virusima koji su upravo radili to…pisali po file-ovima i nisam baš imao puno sreće sa filesystem permissionima. Morat ću to bolje proučiti.

Ali ako bi išao sa time, PHP bi morao moći automatizirano postavljati permissione.
Ili eventualno kada bi se mogao napraviti neki programčić koji bi se nalazio uz PHP i koji bi po nekom trigeru dodavao automatski te permissione. Svakako bi bila lijepša opcija da se nitko ne miješa uz PHP.

[costlyDeveloper]

DI = dependency injection + modularan pristup

Leveli u modulima su dobar pristup i tako bi i trebalo biti 1. Level ne smije ovisiti o modulu iz levela 2. Dok modul iz levela 2. Moze ovisiti iz modula iz levela 1.

To je bussines logic, u frameworku bi mozda bilo zgodno, ali framework je ogranicen.

[bozoou]

Leveli u modulima su dobar pristup i tako bi i trebalo biti 1. Level ne smije ovisiti o modulu iz levela 2. Dok modul iz levela 2. Moze ovisiti iz modula iz levela 1.

To se traži. Struaj teče od viših slojeva prema nižima. Niži imaju uvjet, ono što im zapovjedi struja iz visoka, dok obratno ne može.

u frameworku bi mozda bilo zgodno, ali framework je ogranicen.

Bilo bi sigurno zgodno i vjerujem da ima način. Znam jedan način, ali mnogima bi se naježila koža ovdje samo od ideje
Prvo bi volio čuti što se nudi…da ne uzburkam u startu temu sa svojom solucijom, hehe.

[costlyDeveloper]

Pa zar za to treba framework? Taj model se moze koristiti u svome solution-u, bilo u nekom frameworku ili ne. I zajedno s layerima. Što bi framework diktirao ili olaksao? OOP po sebi olaksava taj model i bez frameworka. Ako definiras intuitivne namespace-ove interface-ove klase, lakse se snalaziti.

[bozoou]

Iskreno ne kužim poantu zadnjeg posta. Kako ćeš bez frameworka raditi išta? Kakvu god da radnu okolinu imaš, to je već nekakav framework.

U ovom slučaju ta radna okolina mora moći omogućiti modularni pristup koji će se slagati od više različitih strana.

U pozadini te radne okoline će se naravno koristiti OOP principi da se tok podataka što bolje kontrolira od modula do modula. I tu postoji sigurno raznih problema osim spomenutog file_write problema.

Ali ako gledaš file_write problematiku, kakve ona ima veze sa OOP principima?
Bitno je ograničiti koji dio aplikacije može “šarati” po kojim djelovima aplikacije.

Osim toga, onaj tko spaja svoj modul na centralnu aplikaciju…on u ovom slučaju naravno ne može imati ftp pristup aplikaciji, nego smije imati pristup samo svom modulu. Također kod postavljanja svog modula mora ispoštovati određena pravila setupiranja tog modula da se može kompatibilno ukapčati na ostatak aplikacije. Stoga kroz taj proces integracije u centralni sustav ga mora voditi nekakvo sučelje. A to sučelje je opet dio frameworka…u ovom slučaju interface koji će voditi developera da se ukapča u centralni sustav. Što znači da je framework zadužen da omogući tu modularnost na što praktičniji način za sve strane.

Ja moguće imam prošireno shvaćanje riječi frameworka. Bukvalno ako si to prevedem, kaže da je to nekakav “radni-okvir”. Stoga nebi riječ framework ograničavao samo na strukturirani code kao radnu okolinu … u framework po meni spadaju i svi alati koji dolaze skupa sa tim codom i omogućavaju njegovu jednostavnu manipulaciju i upotrebu.
I kao što vidimo, današnji mnogi frameworci dolaze sa svojim GUI sučeljem koji se učitavaju paralelno sa stranicom…i hvale se tim značajkama svog frameworka.
Tako da je pojam framework zaista u bukvalnom smislu “radna-okolina”…te ne postoji kodiranje bez “radne okoline”. Samo je pitanje koliko je ona primitivna ili nije.

[jorgovan]

Deploy se obično radi sa nekom skriptom automatski koja podešava i prava file-ova.

Meni se ne sviđa više dubina.

Framework je skup library-a, alata i svega ostaloga koji čine neku cijelinu.

Ako misliš napraviti neki mini framework, onda ti je dosta imati glavnu klasu npr. app ili application, view, db, router i helper. Iako se loader odvaja, routing se isto odvaja itd…

U app stavis glavnu metodu koja se uvijek poziva, auto load, loader za modele, pluginove, module, config. Sve ovisi kakav framework zelis.

U db ide metode za bazu, npr.
Da mozes pozvati
$this->db->insert(‘table’, $data)

U helper ti ide npr. generiranje route-a, pagination, breadcrumbs itd. Helper moze biti jedna klasa ili vise njih. Opet ovisi o tebi.

Kako si mislio automatski registrirati modul?

Arhitekturu sam slazeš kako ti odgovara , ali postoje i razno razne arhitekture i sl.

Trebas dobro složiti i routing, da ima beautiful links. Mozes koristiti neki gotov router uz doradu ili uzeti od nekog frameworka i preraditi ga.

Isto tako po mogućnosti imati auto route.

Mozes koristiti i DI i neke od patterna, ali onda se komplicira.

[jorgovan]

Jedna od mogućnosti jest i da koristis dio gotovih stvari + sve moraš upakirati.

Npr. Neki gotov router, doctrine, smarty ili twig itd.

[bozoou]

Deploy se obično radi sa nekom skriptom automatski koja podešava i prava file-ova.

Deploy radim automatski kroz framework. Framework mi prati koji file-ovi su se izmjenili i na jedan klik gumba ide publish tih file-ova. Uz dodatne opcije konfiguracije prilikom publishanja. U suštini imam to dosta primitivno bez nekakvih testova i verzioniranja da se tu izvrti…ali doći će i to. Kako god, radi effort-less…i dijeli me manje od 3 sekunde da izmjene koje sam napravio lokalno da ih vidim u produkciji.

Meni se ne sviđa više dubina.

U suštini, nisu simpatične te dubine, jer nose mnogo razne problematike …tko što smije raditi. Sustav će se interno morati ponašati kao da je svaka komponenta API drugoj komponenti.
Isto kao kada se radi recimo sa Facebook API-em, ne može ni u ludilu onaj tko koristi njihov API pristupiti direktno bazi Facebooka, nego mora sve raditi kroz metode koje je taj API omogućio.

Tako će i ovdje morati strogo biti kontrolirano tko što smije raditi.
Mislim da je to u startu veliki zalogaj za odraditi…s druge strane mislim da to stvara onda jednu veliki skalabilnu mašineriju i da se početni uloženi trud kasnije višestruko vraća. Vidim razne opcije koje se time otvaraju. Will see.

Ako misliš napraviti neki mini framework

Ovo će biti sve, samo ne mini framework.
Svoj framework razvijam još od negdje 2011-te godine (i aktivno koristim ) i sada je ovo samo step da ga podignem na jednu novu razinu.

Daljnji cilj koji se nadoštukava na ovo je omogućiti da se kroz framwork mogu instalirati komponente koje objedinjuju front-end i backend funkcije. Te komponente se mogu najbolje zamisliti poput WP plugina. Znači komponenta koja može raditi i u backendu sa bazom i u frontendu sa user interface-om. (UI). Ajmo nazvati takve komponente “Full Around Web Component” ili ti ga skraćeno: “FAWC”

Te da su takve komponente međusobno kompatibilne, tome će uvelike pripomoći normJS standard koji će im propisati pravila po kojima će moći biti kompatibilne.

Znači svaka komponenta će osim svog frontend djela imati i svoj backend dio…i propisane protokole kako će backend dio i frontend dio komunicirati. To je u većinskom smislu popis metoda koje moraju biti dohvatljive na backendu koje će fronted requestati putem ajax-a. (Iako ima još tu djelova koje će backend morati osigurati za rad frontend djela komponente)

I kada se taj protokol točno opiše između backend djela komponente i frontend djela komponente …onda jedna FAWC komponenta je isto što i dvije komponente (posebno frontend i backend) …ali koje znaju po kojem protokolu mogu komunicirati.
Tako da bi taj pristup omogućio izradu direktno FAWC komponenti, ili zasebnih fronted/backend komponenti koje po zadanom protokolu se mogu kompatibilno uklopiti u cjelinu. Taj protokol je opet ništa drugo nego standard koji će propisati normJS, koji se neće ograničavati samo na fronted.
Jer kao što sam često pisao vezano uz normJS, takav pristup modularnosti komponenti će omogućiti da se prave mnogo kompleksne komponente koje su sačinjene od mnogih drugih već gotovih komponenti. E pa, ta kompleksnost uopće nije ograničena samo na fronted…nego može ići do tog stupnja da je neka komponenta kompleksna kao WP plugin i da odrađuje veliki i kompleksan zadatak…a da je u svojoj strukturi izgrađena od mnogih drugih komponenti. Te tovrac neke kompleksne komponente se neće morati trošiti da izgradi sve te podkomponente svoje komponente…nego kreće sa gotovim komponentama i siguran je dok su svi unutar normJS standarda.

Kakve to ima veze sa ovom temom?
Pa zato jer se ista problematika vezana uz prava pristupa… preslikava i na rad tih komponenti. Pošto će tu biti komponente koje će u svom backend djelu trebati raditi sa bazom …onda treba nekako osmisliti kako će se ograničiti prava pojedine komponente. A to dođe poprilično isti vrag i kako će se ograičiti prava neke razine modula frameworka.

I koji je benefit svega toga?
Pa osim skalabilnosti i bezbrižnosti da uposlimo nekoga na svom frameworku…
Otvara se fina mogćnost da putem frameworka instaliramo gotovu komponentu u sustav identično po principu kako se instalira WP plugin. Tj. da se na effort-less način unutar zajednice djele poprilično kompleksni moduli. Vrlo vjerovatno će se tu otvoriti i mogućnost da netko prodaje komponentu koju izmisli/napravi…a to je sve već viđeno da se dešava unutar WP zajednice.

E sad…intuicija mi govori da to i jeste direktno u smjeru onoga što jeste WP. Tj. da WP po svojoj strukturi nije ništa drugo. I s tim sam zapravo sasvim ok, štoviše…to mi je jasan znak da razmišljam u ispravnom smjeru, te ne vidim razloga zašto bi WP bio samo “jedan”. Ionako se puno pljuje da je iznutra katastrofalan…

Iskustvo mi je do sada pokazalo da su najveći sistemi najčešće i poprilično loše napravljeni.
Dok su mnogi u iluziji da su veliki zato jer su jako dobro napravljeni…ili čak da su savršeni…oni su zapravo samo jako veliki jer su pogodili najveću potrebu, pa je njihova velična uzrokovana tom potrebom, unatoč katastrofalnom pristupu rješenju.

Remember that.
Zašto je to bitno? Pa zato jer ako je nešto veliko samo radi društvene potrebe…i još ako nema puno igrača na tom polju…onda prodor u takvo tržište je dječja igra, makar se u startu može činiti nemogućim i teško se odlučiti na takav pokušaj.

I da bude jasno…ja uopće ovo ne radim da budem “WP” …nego imam direktnu potrebu. Samo nekako vidim da se to kreće u smjeru onoga što je WP…i tko zna koliko bi se moglo zalaufati ako se temelji dobro postave.

[bozoou]

Kako si mislio automatski registrirati modul?

Saznat ću.

Znam koji je koncept.

Onaj koji se spaja na neki centralni sustav…koji je već online.

1. Downloada taj sustav sebi lokalno. (Prilikom downloada sustav mu isporuči samo one djelove koje mu želi isporučiti …i koji su dovoljni da on to može upogoniti lokalno)

2. U lokalnom radu taj developer slijedi dokumentaciju i zna koju strukturu mora ispoštovati da ugnjezdi svoju komponentu. Ima svakako opciju i da mu framework generira blank_komponentu od kuda on nastavlja razvoj iste.

3. Tako taj developer može lokalno testirati kako se njegova komponenta ponaša u cjelom sustavu.

4. Taj developer jednim klikom na publish button putem frameworka uploada svoju komponentu u centralni sustav koji je online.

I to sve nije problem…naravno, magija se dešava nakon koraka 4. Nakon što centralni sistem koji je online dobije publish nove komponente, on ju provlači kroz svoju logiku i smješta je unutar sustava na propisan način. Taj smještaj komponente ne mora biti siti kao onaj koji je bio kod tog developera u lokalnom radu.
Nakon toga smještaja, komponenta smije moći naštetiti sustavu samo onoliko koliko je dobila permissiona da mu našteti.