PHP wrong way - Što mislite?

http://codersatwork.com/

Najjača izjava pod sekcijom: Always use object-oriented Programming

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Što mislite?? :slight_smile:

http://www.catb.org/esr/writings/taoup/html/
http://www.catb.org/esr/writings/taoup/html/graphics/taoup.pdf

Nadam se da sam razumeo sta hoce da kazu.
Ukratko moja prica i moje misljenje oko programiranja.

Ukoliko si pocetnik, veoma je bitno koristiti framework, ne zato sto ima puno vec odradjenih stvari, vec zato sto te tera da organizujes svoj kod na takav nacin da projekat moze da se razvija neograniceno.

Ukoliko kao pocetnik radis bez frameworka, naravno i dalje mozes da napravis izuzetno dobar sajt, ali ne toliko dobar ga razvijas neograniceno jer organizacija tvojih fajlova je verovatno prilicno losa da ti to ne dozvoljava da razvijas projekat.

Druga stvar je sto ta organzacija fajlova omogucava da vise developera radi na istom projektu u isto vreme, naravno moguce i sa custom resenje, ali teze, opet zavisi kako organizujes kod.

Zato je tu framework, e sada da li ih treba koristiti kao senior programer, moje misljenje ne, ja nikada niti cu biti za to da se koriste tudji frameworkovi.

Ja sam razvio svoj framework koji je veoma mali, nema ni 10tak manjih klasa koje obavljaju sve sto mi treba, od routinga, do multijezika sa MVC patternom prateci SOLID principe i slicno, nema dodatnih metoda nepotrebnih stvari nista slicno, i to mi obavlja izuzetno veliki posao.

Organizovao sam na taj nacin da je sve u komponentama, klasama, modulima itd, 1 stranica se sastoji od odredjenog broja komponenta, svaka komponenta je za sebe i moze se pozvati gde god zelis, svaka komponenta ima svoj css, js kod, u zavisnosti od url requesta, cache klasa uzima sav css i js kod od koriscenjih kompoenenta i pravi svoj cache css/js file koji se koristi za tu rutu.

Tako da sam na ovaj nacin postigao nekoliko pogodnosti kao sto su, mogu neograniceno da razvijam projekat, svaka stranica ucitava samo ono sto joj je potrebno, nista vise od toga, i ukoliko budem radio drugi projekat sve komponente, module, klase i slicno mogu da prekopiram na drugi projekat po potrebi i iskoristim samo jednom linijom bez ikakvih dodatnih podesavanja.

Ovo sto sam napravio je takodje naravno framework, sto potvrdjuje moje misljenje da je framework izuzetno bitan, ali kao takodje da koriscenje tudjih frameworkova koji imaju brdo brdo klasa, i nepotrebnih metoda, kodova je pogresna stvar, treba sve praviti od 0, po tvojoj potrebi, i potrebi tvog projekta.

Uostalom, jednom kada naucis da pravis custom framework, i shvatis kako zapravo jedan framework funkcionise, mocices da se prilagodis bilo kom frameworku, mnogo brze nego ostali…

1 Like

Nisam početnik.

Radio sam svoje frameworke, radit ću jedan novi gdje neću koristiti jlase, nego samo funkcionalno programiranje kao paradigmu.

Složio sam si router koji automatski prepoznaje parametre u url-u, mogu imati definirane route, a može i auto route. Poziv funkcije sa dinamičkim broje parametara. Parametri mogu biti kao regularni izrazi ili npr. :any, :number i sl. , pa se kasnije to zamjenjuje sa regularnim izrazima.

Ono što mi je palo sad na pamet jest da mi sve validne route zapiše u bazu , ako router nađe validnu route-u, a onda prije routinga da mi potraži route-u u bazu da li postoji.

A ovo znači ubrzavanje app, jer kad nađe route-u iz baze , odradi sve i ne ide više na router.

Nakon nekog vremena kad se sve route zapišu u bazu, koriste se isključivo iz baze sve, ali ako se doda novi članak i sl., naravno da se će se koristiti router ili ako link ne postoji.

???

Baza je uglavnom najsporija karika…iz napisanog uopce nisam skuzio sto ce to magicno biti u bazi, (da se nije moglo drugacije dohvatit?) …i da je toliko magicno da ce iz najsporije karike ubrzati neki proces. I koji točno proces, jer iz napisanog se ne kuzi ni to.

Routanje je dosta sirok pojam…ti za određenu rutu mozes raditi xy razlicitih stvari.
…koje to tocno stvari bi radio i na koji nacin mislis da ce citanje iz baze to ubrzat?

1 Like

Ok…mislim da sam te skuzio nakon par pokusajeva :slight_smile:
Savjet…testiraj razliku sa bazom i sa parsiranjem urla na živo. Kad uvidiš da je dobit svega par ms, onda se zapitaj jel ima smisla nepotrebno podizat kompleksnost sustavu radi takve mikrooptimizacije od par ms.

A ako budeš i išao sa bazom, svakako si ostavi switch da se automatski to gasi kod aplikacija koje neće imat bazu. Budete par puta lupilo u dupe poneki problem koji ces si privuci sa ovim…ali u sustini je ok pristup ako ima uštede.

I jedno pitanjce…u koju bazu trpaš tablice koje su potrebne ovako za funkcioniranje frameworka. Guras li to u posebnu bazu ili u istu gdje su i tablice od projekta?

Ako imaš xy route-a, i svaki request mora na routing u kojoj vrtiš for petlju za sve route.

npr. pattern: /blog/clanak/:id/:any što je jedna route-a i sad zapišeš full linkove u bazu za svaki članak, gdje any zamjenjuje naslov članka, a :id zamjenjuje id članka.

Baza je spora ovisno za što, Query ide ispod 0.5 ms sa filterom gdje se vraća jedan record.

Ako se korsiti redis, to je onda još brže čitanje, a razmišljao sam i u cache, i zapis route-a u jednu tablicu kao backup iz koje se puni cache.

Testirao sam na 10 k route-a, traje 25-30 ms, ušteda za 10 k route-a je minimalno 25 ms.

Sve imam dinamički sa parametrima koji su zapisani u konfiguraciji.

Naravno na 500 route-a ili 1000 route-a možda nema smisla, ali koliko vidim drupal sve drži u bazi.

Ali ono što je bitno jest organizacija, probao sam staviti sve u bazi i sa regularnim izrazima dohvatiti route, ali onda radi full table scan, a na 10 k route-a, tada query traje 100 ms. Tako da mi ovo nije prihvatljivo.

Da bi app imao 10 k route, to mora biti ogromna app.

Mislim da nebi trebalo biti nikakve for petlje kod prepoznavanja route.
Ime kontrolera i akcije trebaš naći direktno iz imena parametra url-a.

A ID koji se nalazi u url-u (npr ID clanka) …routanje nema pojma da je to ID clanka…ono samo zna da je to ID i kao takvog ce ti ga extraktat iz url-a i dovest kao parametar unutar kontrolera.
Tako npr. za url: clanak/show/567 nećeš imati 567 različitih ruta za svaki ID …nego te ruta vodi direktno u kontroler “clanak”, metodu “show” i parametar je ID=567. I sada unutar metode kontrolera ti odlucujes sto ces sa tim IDem…a ovdje ćeš povući taj članak iz baze i prikazat ga.

Ne kuzim zato zasto bi imao igdje zapisane sve linkove prema svim člancima? Osim…kad se odlucis cacheirat izlaze ovisno o ulazima (tj. url-u) …onda ce se negdje taloziti svi url-ovi, skupa sa pripadajućim izlazima.

Netocno. Zato i postoji routing jer ne mozes dohvatiti sve iz url-a.

Npr. gallery/:id/items/:id
A moze biti xyz razlicitih slucajeva.
Za jednostavne stvari moze auto route, za kompliciranije ne.

Routing ima svaki bolji framework.

A linkovi prema svim clancima je samo moje razmisljanje.

I jos jedna stvar, a tice se multi language url-a.

Npr.:
/hr/clanak/detalji/:id/:slug
/en/article/detail/:id/:slug

A jedan i drugi link gledaju na istu route-u, ovo su osnove.:cowboy_hat_face::cowboy_hat_face::cowboy_hat_face:

A sad zamisli da na site-u ima 10 jezika, za jednu route-u, 10 razlicitih linkova koji pozivaju isti conzroller i istu funkciju.

A od kuda ces dobiti input o ruti ako ne iz url-a?

Pa naravno, ali cisto sumnjam da se vrti ikakav foreach kod rutanja :wink:
Izbjeć pod must …jer upravo zahtjevnost tog foreach procesa raste proporcionalno broju ruta…a to ne zelis.

U routes se nalaze patterni i svaki se usporedjuje sa url kad se poklopi tada se nesto odradi.

Pogledaj bilo koji router, ili router u frameworku. Uglavnom se svugdje koristi for petlja i to je brzo zato jer uglavnom nema puno route-a, da je i 10 k route-a, for petlja to odradi za 25-30 ms + matching. Proucio jedno 20 frameworka + najmanje 6 routera.

Za public dio i nema puno route-a, a ako se radi o app kojoj je potreban login, moze i auto route, parsiranjem url-a.

I od kud je onda stigla input informacija, ako ne iz url-a? :wink:

…sto se ostalog tice, ja bi izbjegao foreach…

Ti bi za sve moguce kombinacije radio provjere?
Sretno ti bilo.

Primjer:
/blog/{number}/{number}/{number}
/blog/{number}/{number}
/blog/{number}

Prvi parametar je godina, drugi mjesec, treci dan

Input je iz url-a i radis provjeru za route sto ti je doslo. Ne razmumijem da ne mozes shvatiti da nisi pogledao ili naucio kako to radi.

Baci malo oko na ovo:

https://www.codeigniter.com/user_guide/general/routing.html?highlight=uri

Vise manje je sve meni jasno, ja se samo osvrćem na ovo:

I dalje nisi napisao što to ne možeš dobiti iz url-a? I pobogu, otkuda ti stiže input informacija ako ne u url-u?

Jednostavno pitanje, ne trazi kompliciran odgovor. Ok je i priznati da si se samo krivo izrazio…nikakav grijeh.

Neznas na kojem su mjestu parametri, nadalje za svaku stvar bi morao imati case itd…

Kako znas sto je controller, a sto funkcija , a sto parametri?

Na konem je mjestu funkcija?

Funkcija u url moze biti na 2 mjestu, a moze biti i na trecem , cetvrtom , mozes imati jedan ili vise parametara.

Nadalje , ako ti site podrzava multi language, napisao sam vec, da onda za jedan url za sve jezike moras raditi logiku.

Iz svakog url-a mozes dobiti segmente i onda opet ponavljam za svaku route-u radis neku logiku.

Routing pomaze da sve bude elegancija , sto je nekakav standard.

Pogledaj gore ona tri linka i reci mi sto je funkcija u bilo kojem linku?

Funkcija kao takva ne postoji, nego kod svakog linka se poziva druga funkcija sa dinamickim brojem parametara.

Opet ti sva informacija dolazi u url-u, dalje je sve obrada te informacije.

Naravno, cijeli routing proces jeste informacija o tome kako će se url obraditi.

Samo je pitanje da li radis rucno i mucis se ili je sve automatski kroz routing.

Router mi automatski prepoznaje parametre i pozivam funkciju sa dinamickim brojem parametara. I ne moram raditi magiju. Ako mi dodje u funkciju manje parametara nego sto funkcija prima, javit ce gresku.

Nije uopce pitanje, o tome je tema. Zna se što je routing.