Ömmm....
1.) Nem kell SSH, meg semmi ilyesmi. Mivel a Laravel egy composer projekt, így valóban kell a telepítéséhez composer (és preferably néhány beállításhoz is jó). Azonban, ezt elég megtenned lokálisan. A composer nem más, mint egy dependency (vagy package, akárhogy is hívjuk) manager, ergó megadod egy JSON fájlban, hogy te milyen függőségeket akarsz használni, majd az install goaljával ezeket letölti egy central repositoryból. Ezért láthatod azt, hogy ha létrehoztál egy laravel projektet, akkor csak egy skeleton van, majd miután elindítottad a composer install parancsot, létrehoz egy vendor mappát. A composernek itt kb ennyi a lényege, semmivel sem több. Ebből az következik, hogy mivel itt javarészt PHP fájlokról beszélünk, ha a lokálisan telepített Laravel instance-odat te FTP-n keresztül feltöltöd egy webtárhelyre, az működni fog.
Milyen esetben érdekes a beSHH-zás?
- Ha olyan dependencyket használsz, amit te lokálisan a saját gépedről nem tudsz letölteni, mert nem engedélyezett (pl.: ha outsourcing-gal dolgozol egy cégnek, nem fogják egy publikus repóba felrakni a saját dependencijeiket. Ilyenkor kell az, hogy a szerveren kell lefuttatni a parancsot, mert a szerver vagy közvetlen eléréssel rendelkezik a repóhoz, vagy esetleg eléri a jumpszervert ami pedig már eléri a repót. Jelen esetedben nem hinném, hogy erről lenne szó, így csak lokálban composer install, majd FTP-n felmásolod az egész laravel mappát.
- Ha fontos a database migráció.. Az artisannak ugye van egy commandja, ami a migrációs scripteket csekkolja, hogy miket futtattál le és miket nem, így tudod verziózni a DB-det. Első sorban akkor fordul ez elő, ha egy adott környezetbe (pl. test, int, pre-prod stb) többen is deployoltok, és nem akartok kézzel módosítani a DB-n, mert esetlegesen összegányolnátok egymás munkáját. Te esetedben szerintem ez sem must have dolog, így tudod kézzel baszogatni az adott sql szervert (gondolom mysql).
- Ha deployoló alkalmazást használsz, mert akkora alkalmazás és annyian dolgoztok rajta, hogy az hihetetlen, pl DeployR vagy bármi ilyesmi. Szerintem ez sem játszik nálad.
2.) Nem mondanám frameworknek a smartyt, inkább egy lib, ami egy viszonylag okés template engine-t provideol neked. Mire jó ez? Vannak a weboldalakon ugye dinamikus szövegek, mint például a felhasználó nevét nem hardcodeolhatod bele a markupba. Ezeket a plain old "php in html" styleal csinálták egy ideig, ahol nyitottak egy php taget, kiírták a felhasználót, majd zárták és jöhetett a markup tovább. Na ez gány, ezért inkább "makrókat" hoztak létre, így egy egyszerű kis jelzéssel, szavacskával, kifejezéssel be lehet helyettesíteni a kívánt szöveget. Nem rossz dolog, van aki használja, mert egyszerű, de ha már laravel, valamint mindenképp server-side renderinget akarsz használni, akkor ott van a laravel beépített template engineje, a Blade. Nagyon egyszerű, alapból tudja a laravel, valamint amúgy nem is olyan borzasztó a performance-a.
+1:
Nem hiszem, hogy erőltetni kéne a server-side renderinget, fordulj inkább a Kliens -> Rest Interfész irányba. Kliens lehet egy egyszerű HTML weboldalacska pár fancy JS-el vagy akár jQueryvel, míg a Laravel az csak rest interfészeket adjon (endpointokat), de semmi képp ne rendereljen felhasználó által látható view-t (kivéve nyilván ha pdf kell, vagy bármi ilyesmi, azt ne kliens oldalon csináld
![nagyon boldog :D](./images/smilies/icon_e_biggrin.gif)
).
Itt egy kép, hogy hogyan működika restful implementáció, és láthatod, hogy ez miért jó így. Egy laravel alapú szerver kiszolgálja a weboldaladat, a tabletedet, az iOS alkalmazásodat, az android alkalmazásodat, vagy akár a Counter-Strike 1.6 szerveredet is, mert PAWN-ból is tudsz pl HTTP kéréseket küldözgetni.
Btw, jelölj nyugodtan, nincs ebből baj, viszont légyszíves ha nekem szóló kérdésed van itt a fórumra kirakva (és általába a tiédet leginkább én tudom megválaszolni
![nagyon boldog :D](./images/smilies/icon_e_biggrin.gif)
), akkor egy privátot dobj légyszi a linkkel együtt, mert nem tuti, hogy észreveszem.