krenuo sam s Laravelom i molio bih malo pomoći oko početnih smjernica dok se ne ufuram :).
Započetak, malo o strukturi foldera. Nakon što sam kreirao novi project “test_laravel”, dobio sam foldere:
…
-public
-vendor
…
E sada, index.php je unutar public foldera.
“Mozak” frameworka je očito vendor. (Nemam pojma da li se naknadno vendor s čime proširuje…ali ovako na prvu, tamo je mozak, ovo ostalo je struktura koju će taj mozak hendlati)
E sad, moj dosadašnji pristup je bio strukture: “project_name”, tako da je index.php odmah bio unutar projekta na prvom levelu hijerarhije. Mozak frameworka je mogao biti odmah unutar projecta, a mogao je biti bilo gdje…a projekt je znao gdje je putem config file-a. Na taj način sam imao jedan mozak koji je hendlao koliko god različitih projekata.
Ako sam projekte slagao unutar xampp/htdocs …onda je sve samo po sebi dobilo linkove localhost/project1 , localhost/project2 …itd. (Zato jer je index.php bio odmah unutar project foldera).
Ako bih online htio imati više različitih projekata nad jednom domenom, onda bi samo u public folder dodao foldere svojih projekata…te bi sve opet radilo dohvatljivo putem: domena.com/project1 , domena.com/project2 …
Sada mi nije baš jasno kako se najbolje poslužiti ovom strukturom koju dobivam sa laravelom.
Zamislimo da netko ima već upogonjenu stranicu: www.userProject.com …i sada mu mi radimo samostalni part za taj web sa laravelom, koji će se otvarati na adresi userproject.com steht zum Verkauf - Sedo GmbH
Dosadašnju strukturu bi samo uploadao u public/myPart i to bi bilo to.
S ovom strukturom laravela radim što?
Mijenjam poziciju index.php-a tako da ga selim na dno hijerarhije…i prilagođavam linkove u index.php-u prema bootstrap folderu? Nakon toga bi (valjda) mogao laravel_folder uploadati u public/myPart …no nekako sumnjam u takvo prčkanje xd
resources\views tu su ti html , npr. pocetna.blade.php, onama.blade.php, kontakt.blade.php, mypart.blade.php
routes\web tu kazes kada user posjeti www.userProject.com/myPart ucitaj view mypart.blade.php
Route::get(’/mypart’, ‘HomeController@index’)->name(‘home’);
a u controleru Http\Controlers napravis Controller u ovom slucaju HomeController i methodu(funkciju) index koja za rezultat vraca taj tvoj view.
public function index()
{
return view('mypart');
}
Taj MVC izraz je prepopularan xd …nemreš drugačije ni raditi a da web ne isporučuješ klesan na kamenim pločama xd.
Hoćem reći, upoznat sam sa MVC strukturom i sve je to ok…ali pitanje nema veze s time.
Zamisli da radiš web part koji će netko koristiti u sklopu svoje wordpress stranice. No mi taj part ne razvijamo u WP-u, nego sa Laravelom. Postavlja se vrlo jednostavno pitanje, kako ugraditi naš web-part na postojeću WP stranicu da sve šljaka… Da je recimo index.php u root-u Laravel projekta, nebi bilo baš nikakvog problema.
Da postoji config parametar koji dovodi u relaciju index.php sa Laravel “mozga” …sve bi opet bilo skroz inutitivno…ovako sam se malo zgrozio svih hvalospjeva o Laravelu, a u startu mu iskaču predefinirani pathovi od foldera do foldera. Umjesto da se takve stvari zadrže “customable” …pa da je stvar fleksibilna.
Pročitao sam upravo dokumentaciju od Codeingitera, i tamo ti na prvu stave upravo tu mogućnost da Codeigniter-aplikaciju držiš pod varijablom $aplication_folder, također napominju upravo tu mogućnost da se zadrži jedan Codeigniter “mozak” povezan sa više različitih aplikacija.
Inače, čitao sam recenzije…Laravel ima puno više toga na svojoj strani…pa rekoh da nešto možda nisam shvatio vezano uz taj public folder i index.php. Mislim, vjerovatno se to prčkanjem da presložiti …no od frameworka ne očekujem da se mora prčkanjem dirati core, nego da je “customable” orijentiran korisniku. Ako je stvarno istina da ovdje nema elegantnog rješenja…odmah me tjera da se u startu zapitam kako su “customable” na drugim razinama.
Al nebum previše sr*** prije nego ga detaljnije proučim.
Mislio sam da hoces postojeci web prebaciti na laravel.
Ti ustvari pravis “neovisan” projekt.
Gledaj, ja sam danas upravo testirato, kopirao citav laravel folder na wamp , www\myProject
i u folder sam ubacio index.php sa ovim dole code-om i radi ok…
Ne znam da li ti je ovo prihvatljivo, i da li se preporucuje iz kojih vec razloga…
Nadao sam se malo diskusije oko toga zašto je tako posloženo da index.php nije u rootu…i čuti zašto je to možda u konačnici tako i praktičnije. Jer sumnjam da bi bezveze tako posložili ako nema razlog.
Kada postavljaš laravel projekt na server, postavljaš fajlove u root folder domene, a folder “public” je u stvari “public_html” ukoliko ti naziv foldera stvara problem možeš googlat “laravel public to public_html”.
Takav pristup sprječava dolazak do fajlova pošto je public_html jedini javan na domeni.
Ne radi se dupli request već se Apache rewrite rules izvedu u tom dijelu primarno.
A da li će request da uzme ~5MB ili 5MB + .5kB, odnosno ~10MB ili 10MB + .5kB to i nije tol’ko značajno.
U samom server.php fajlu postoji objašnjenje (dato od strane kreatora) čemu fajl uopšte.
Edit: evo malo detaljnije o razlozima čemu takva struktura.
Mašiš poentu. Taj odgovor objašnjava zašto je public dir sa index.php (front controller-om) bitan strukturalno.
Btw, koristim vagrant za localhost development i svaka domena mi je podešena na domena.dev te na taj način imam zanemarljive (ili ih nemam uopšte) razlike u odnosu na online server. Link unutar odgovora će reći (pokazaće bitan odgovor na jedno drugo pitanje) kako podesiti sym link prema Apache accessible directory.
S ovim rečenim mogu podesiti dev environment na lokaciji recimo:
I ispada jako elegantno na samom serveru.
Kad se navikneš na korisna rješenja poput bitbucket/github-a, composer-a, (i ne samo uz Laravel) Vagrant-a - život (čitaj programiranje) će ti biti puno lakši. To su bukvalno bazične stvari bez kojih se ne može raditi PHP ozbiljnije.
Sljedeća zbunjujuća situacija vezana uz “php artisan migration”
Napravim new migration file i kreiram schemu tablice “test_table”.
Kasnije ako updejtam schemu i pokrenem migration:refresh , izgubit ću podatke.
Googlanjem dolazim do rješenja da treba napraviti novi migration file i u njemu definirati nova polja u tablici… pročitao sam par članaka na tu temu, ali začudo se još nitko nije zapitao "Želim imati kompletnu schemu tablice (data-sheet) u jednom migration fileu."
Pa jel ima načina? …a da se ne moraju resetirati podaci kod update strukture tablica.
Da li se koristi ovo što Laravel nudi ili ima boljih alata za održavanje database data-sheet?
I pored toga što je data-sheet rasut na hrpu file-ova …nije li ovo naporno kucati komande za sitne preinake tablice? Teorijski sve što bi trebalo kod update db strukture je promjeniti neku sitnicu u data-sheet-u i uživat. Sve ostalo na frameworku…
Da, to i jeste bit migration:refresh komande, i koristit ces ju sve dok si u dev modu i nemas podatke koje ne smijes izgubit (ili imas seedove setupirane). U okolini gdje si ne mozes priustiti gubitak podataka (npr na produkciji) ju neces nikad koristiti.
Ako ne zelis revertati sve migracije nego samo pokrenuti tu novu koju si napravio, onda pozoves php artisan migrate i bit ce izmigrirane sve migracije koje si napisao, u tom slucaju ta jedna jedina, bez da se revertaju sve postojece.
Primjer: imas bazu na produkciji koja ima tablicu users. Zelis dodati polje foobar na tu tablicu. Neces pokrenuti migrate:refresh naravno, nego napisati migraciju koja altera tablicu users i dodaje novo polje, te pokrenut ces php artisan migrate
Nije li to nespretno da struktura tablica nam se na taj način razbije na različite file-ove …samo zato jer smo nešto naknadno dodali u strukturu?
Što se mene tiče, cijeli data sheet baze bi trebao biti na jednom mjestu (ili podjeljeno po sekcijama ,ovisno o podjeli glavnih djelova …tako da određene klase mogu definirati svoj dependency prema potrebnim djelovima baze) …već mi je nespretno da svaka tablica ide u svoj file. …a kamoli da se još i eventualni updejtovi strukture tablica razbijaju na dodatne migracijske file-ove.
To te tjera da vodiš onda posebnu dokumentaciju o strukturi baze, a posebno da tipkaš komande za Laravel …ne kužim zašto bi se moralo dva puta…
Vjerovatno se da složiti da ove migracijske klase čupaju potrebne podatke iz nekog main data sheeta, ali ako se priča o “out-of-box” pristupu, mislim da bi to trebao biti ugrađeni start point hendlanja strukture baze…
Migracije su version-control za bazu. Ima smisla da svaki korak/migracija je u posebnoj datoteci, i da tako commitas u svoj VCS. Tada tocno znas kada se sto migriralo i vrlo lako migriras/revertas ono sto zelis.
Zamisli sljedecu situaciju.
Imas users tablicu, i na toj tablici zelis dodati polje, te iz neke trece tablice preseliti podatke u to novododano polje.
Ako napravis novu migraciju, onda ce izgledati otprilike ovako:
alter users tablice da se doda novo polje
migracija podataka iz trece tablice u novododano polje na users tablici
drop te trece tablice
I deployao si to na produkciju. Tek na produkciji shvatis da tvoje promjene nisu ok, i zelis revertat stvari nazad odmah. Kako ces to uciniti ako je definicija tablice users u jednoj datoteci?
Ovako s migracijom imas down metodu koja je u pravilu “undo” za up metodu migracije.
Pokrenes down te jedne migracije, i bam - revertao si sve na prethodno stanje i stvar radi, odnosno kreirala se opet ta treca tablica, vratili su se podaci u nju, i obrisana je nova kolumna koja je dodana na users tablicu.
Jep, u pravu si…skužio sam na kraju to što se tiče migracija. Sama ta riječ asocira da se radi o migraciji podataka, a ne kreiranju strukture. No pitam se gdje je kreiranje onda?
Jer imamo i drugu situaciju:
Radiš s klijentom proizvod od nule i on se tu i tamo sjeti nekog novog atributa kojeg treba dodati u neku tablicu. Zapravo, dok se projekt razvija, tablice se dinamično mijenjaju. Projekt nije još u production modu, ali client ima online pristup i naklikao je neke podatke koji su se upisali u bazu… (Nisu bitni podaci, ali neka ih tamo…ne želimo ih baciti)
…i sada bi praktički u takvim okolnostima svakodnevno trebalo raditi migracijske file-ove i nemati pod okom strukturu tablica na jednom mjestu…nego sve rasuto.
Znači s migracijom je sve oke, ona ima svoju svrhu…ali nekako mi baš nedostaje pored iste i opcija “update-database-structrue”. Još da se ista može postaviti pod “watch” opciju, tako da Laravel samostalno skuži da se structure file promjenio i samo ga slijedi sa updejtom baze…bez suvišnog kucanja u cmd line…
Ako imas seedove kao izvor podataka - onda si mozes priustiti da mijenjas postojece migracije i refreshas ih koliko zelis.
Ako je rucni rad klijenta izvor podataka u bazi, odnosno klijent stvara podatke, onda moras pisati svaku promjenu na bazi kao novu migraciju, nema refresha migracija nego samo gledas “naprijed”
Ali da mijenjas postojece migracije i da ti je jos klijent izvor podataka u bazi - ne ide. Ni s Laravelom, ni sa Symfonyem, ni s nekim trecim frameworkom.
Ne razumijem baš poantu ovoga…što točno podrazumijevaš pod rečenim… Ali ono što sam ja zamislio…je itekako izvedivo…i do sada sam to tako imao posloženo.
Ali to nema veze sa migracijama…čisto imati automatski “update” baze sa data-sheet-om iste. A ako baš dođe potreba za migracijama podataka u nove strukture…to bih hendalo neovisno o kreiranju strukture baze.
Što god…stigao sam do novih pitanja…pa ako je netko raspoložen…slobodno…
Ovaj ugrađeni webpack u Laravel je zavisan od node i npm. Instaliram tako node na komp i kroz cmd line pokrenem “npm install”. Nakon te npm instalacije laravel projekt je postao težak punih 120MB. (Sa početnih 20MB)
Jel to normalno, ili sam nešto krivo odradio? Taj npm treba instalirati direktno u project ili on možda treba globalno postojati izvan projekta?
