ugrás a tartalomhoz

Symfony telepítése, hajtépés

inf · 2010. Ápr. 4. (V), 03.44
Sziasztok!

Próbálom eldönteni, hogy Symfony-t használjak e egy projecthez, vagy cakePhp-t, viszont ehhez szeretnék 1-2 dolgot megcsinálni mindkét rendszerben, hogy össze tudjam hasonlítani őket.
A cakePhp-vel nem volt semmi gondom, csak bemásoltam, és minden jól ment, a Symfony-val viszont bajom van. Nem kívánom most szidni a peart meg a symfonyt, csak szeretnék eljutni addig, hogy feltelepítem őket mindkét helyre. Nem szeretnék parancssort használni semmiképp, és úgy szeretném feltenni peart és a rá épülő symfonyt, mintha egy olyan szerverre tenném őket, amin gyakorlatilag semmihez nincs jogom. Szal pl nincs ini fájl írás meg parancssor futtatás meg hasonlók. Az a bajom, hogy nem találtam semmi ilyen bemásolós includolós beüzemelési módszert, pedig rászántam legalább 10 órát a témára. Mindenhol csak parancssor van leírva, és nincs leírva az sem, hogy hogyan lehet tesztelni, hogy fent van e a rendszer vagy sem. (sem symfony sem pear esetében)
A pear és symfony csomagokat a projekttől teljesen elkülönítve szeretném feltenni, szal ./symfony, ./pear, ./webroot mappákba, ha erre van bármi lehetőség. Egyelőre annak is örülnék, ha fel lehetne tenni másolósan a két rendszert.
Pear ugye alapkövetelmény symfony-hoz (legalábbis azt olvastam), viszont jó lenne az mdb2 kiegészítőjét is használni, mert nem találtam normális ORM-et a php-hez, szal kénytelen leszek írni egyet, az említett persistence layer meg sok időt megspórolna nekem.

Előre is kösz, ha valaki tud segíteni.
 
1

minek neked?

nova76 · 2010. Ápr. 4. (V), 07.13
Én úgy fejlesztek symfony alatt, hogy van egy fejlesztőkörnyezetem, ahol van parancssor. Anélkül ugyanis még csak félkezű sem vagyok. Ezeknek a keretrendszereknek a lényege, hogy a kód közel 90%-át maguk legenerálják. Most Te pont ezt nem szeretnéd kihasználni? De akkor minek neked az egész?
Természetesen ha a fejlesztőkörnyezeten elkészültél a munkáddal, onnan már másolhatod tovább a fájlokat, miután kiadtad a symfony freeze parancsot. Esetleg, ha használsz svn-t, akkor attól is megszabadulhatsz a másolás elött. Nem beszélve a cache, log fájlokról. :-)

A cakephp-nál még ok ez a másolósdi, bár parancssor ott is van, és emiatt ott is ajánlatos a fejlesztőkörnyezet használata. De symfonynál az esetleges pluginok installálását is sokkal körülményesebb kézzel végezni (100 helyen be kell jegyezned mindenféle kódot). Márpedig ha a pluginokat sem fogod használni, akkor aztán tényleg minek neked?

Ráadásul ha még csak most ismerkedsz ezekkel a keretrendszerekkel, akkor a kódgenerálást semmiképp ne hagyd ki, mert a legtöbbet a legenerált kódokból tanulhatsz. Ott szembesülhetsz azzal, hogy a fejlesztők maguk, hogyan képzelték el az egész keretrendszer használatát.
3

Okés, de minek ehhez parancssor?

inf · 2010. Ápr. 4. (V), 17.02
Az addig rendben van, hogy generálja a rendszer a kódot, de ehhez minek kell parancssor? (Én úgy képzelem el, hogy a generálást is ugyanúgy php függvényekkel végzik, azokat meg simán meg lehet hívni egy php fájllal.)

Azt nem mondtam, hogy a plugineket nem használom, annyit mondtam, hogy valszeg az ORM-et megírom mdb2 alapon, mert nem vagyok elégedett a php-s ormekkel. De ha tényleg ennyire körülményes parancssor nélkül, akkor itthoni gépen meg tudom oldani, aztán majd másolok. Annyi a bajom, hogy azt olvastam, hogy windowsról linuxra másolásnál lehetnek gondok, mert máshogy konfigurálja a két rendszert (vagy a pear vagy a symfony, már nem emlékszem melyik). Svn-t természetesen akarok használni.
2

Symfony: lehet másolni!

N0r3i · 2010. Ápr. 4. (V), 11.54
Szia!

Bár nova76-tal teljesen egyetértek a parancssor kérdésben, de ettől még másolással és PEAR nélkül is tökéletesen működőképes a dolog.
A Symfony oldaláról töltsd le a rendszert tgz vagy zip formátumban, csomagold ki a neked tetsző könyvtárba (lehetőleg ne a webroot alá!), készíts egy projectet (akár kézzel, bár ehhez tényleg sokkal szerencsésebb a parancssoros kódgenerátor) és már működik is a dolog.

Egyébként pedig a parancssoros dolog lényege az, hogy a fejlesztő környezetedben van parancssorban futtatási lehetőséged, és azt ki is tudod használni, az éles szerveren viszont nincs, oda már a kész kódot másolod fel.

Egyébként miért akarod tesztelni, hogy fent van-e a symfony, ha egyszer te magad tetted fel?
Ugye nem gondoltad komolyan, hogy ORM-et fogsz írni? Miért nem jó neked a Doctrine vagy a Propel?
Konkrétan mi az az 1-2 dolog, amit mindkét rendszerben össze akarsz hasonlítani? Tedd fel kérdésként, és szerintem találsz itt olyan embereket, akik megmondják, hogy a te szempontjaidnak melyik rendszer a megfelelőbb.

Sok sikert!

Üdv: Norbi
4

De, komolyan gondoltam...

inf · 2010. Ápr. 4. (V), 17.49
De, komolyan gondoltam, hogy ORM-et írok. Propelről azt olvastam, hogy lassú, és emiatt váltottak doctrine-re, a doctrine meg egyszerűen nem tetszik. Nem szeretem az olyan rendszereket, amikben feleslegesen találnak ki új nyelveket, amikor mondjuk YAML helyett simán használhatnának XML-t, stb...
(De mondhatnám azt is, hogy én mielőtt használnék egy kódtárat, belepörgetek a kódjába, és ha találok 50 sornál hosszabb függvényt, akkor törlöm az egészet. Doctrine-ben a YAML parser-ben van pl egy 250 soros függvény.)


Amiben össze akarom hasonlítani őket az többek között a cache kezelés, az, hogy mennyire kényelmes a bennük való fejlesztés, mennyire skálázhatóak, ugyanazt a feladatot mekkora idő alatt végzik el, stb... Ha ez megvan, akkor utána átnézem a plugineket, hogy mi az, ami használható, aztán döntök, hogy melyik rendszer kell nekem. (Egyelőre cakePhp a szimpatikusabb, mert jobb a dokumentációja.)
5

Kohana

Ustak · 2010. Ápr. 4. (V), 18.32
Miért pont e kettő között döntessz? Pl a Kohana nem tetszik? Php5 és van benne ORM.
Üdv:
Gábor
7

Nincs végtelen időm

inf · 2010. Ápr. 4. (V), 22.48
Szia!

Hát még ott van codeIgniter meg zend is, de nem tudom mindet kipróbálni. Symfonyról hallottam, hogy nagy rendszerekhez is jó, cakePhp-t pedig mindenki dícsérte. Egyszerűbbnek tartottam azt, hogy először fórumok alapján leszűkítem a kört, aztán megnézem azokat, amik megmaradtak. De ha te úgy gondolod, hogy a Kohana egy jó rendszer, akkor megnézem azt is.
9

Nem vagyok

Ustak · 2010. Ápr. 5. (H), 09.13
nagy php guru, sőt. Viszont codeigniterrel csináltam pár oldalt, és az nagyon tetszett.(Bár azt mondják, az első framework amit megszeretsz, az lesz a kedvenc :-)). Na most a kohana az a codeigniter utódja, ugyanaz gyakorlatilag, csak szigorúan php5. Mikor én választottam, a CakePhp-ra azt írta, hogy még mindig kompatibilis a php4-el, és emiatt zavart (tuti nem vettem volna észre semmit mert azon a szinten amin én dolgozom nem igazán számít szerintem a skálázhatóság - csak zavart, tudom hülyeség :-)) És ezért a Kohana mellett döntöttem. Persze én a kódba nem nagyon nézegettem bele, de amiket csináltam vele eddig mindig jól működött és gyorsabban haladtam mint a plain php-ben.
Üdv:
Gábor.
11

:-)

inf · 2010. Ápr. 10. (Szo), 15.03
Hát átnéztem pár rendszert, és a Prado az, ami most legjobban tetszik. Bár eddig amit megnéztem az a dokumentáció minősége, és az ORM felülete. ORM hasonló, mint amit én csinálnék, csak még 1-2 dologgal kibővíteném. Majd még folytatom az a rendszerek átnézését, egyelőre Prado,Symfony,cakePhp,Kohana,codeIgniter,Zend amik a listámon vannak. Pradoban az a szimpatikus, hogy ránézésre tudom, hogy mi mit csinál, és kb milyen metódusai lesznek, ha belenézek a dokumentációba. Konfigurálásra meg másra is sok XML-t használ más kitalált nyelvek helyett. Egyelőre ez állt legjobban kézre, de van még olyan rendszer, amit egyáltalán nem néztem meg a listából.

(Ettől függetlenül most cakePhp-t használok egy webshophoz pár napig, mert találtam egy szakdolgozatot, amiben a srác cakePhp alatt csinált hasonló webshopot, mint ami nekem kell, aztán egyrészt cakePhp-t már jobban ismerem, mint a többit, másrészt meg szorít a határidő.
Mondjuk az egyes szám, többes szám dolog, és a php4 kompatibilitás tényleg zavaró cake-ben, úgyhogy valszeg komolyabb, nagyforgalmú projectekhez nem fogom használni.)
6

és még mindig a propel a gyorsabb

nova76 · 2010. Ápr. 4. (V), 21.41
A yaml sokszor visszatér a symfony használata folyamán. Ha ez kizáró ok nálad, akkor bele se fogj. Az XML-t amúgy sokkal bonyolultabb használni. Ha valami bonyolult tömböt akarsz letárolni, akkor gépelhetsz egy csomót. Mert ügye ha XML, akkor legyen valid, mert másképp egyes programozók leszólnának :-)

A doctrine meg azért nem gyorsabb annyival. Sőt, egyes mérések szerint lassabb olyan 10%-al, mint az 1.4 propel. Nem mindegy melyik verziót hasonlítod össze melyikkel.
De ha nagyon sebességre élezett rendszert akarsz, akkor a propel generátorával lesz gondod. Általában úgy generálja le a kódot, hogy egy kapcsolt tábla rekordját soronként lekéri. Tehát egy kapcsolt táblában akár 600 query is lehet (soronként ahány kapcsolás van) LEFT JOIN használata helyett. Amúgy, mivel kb 0,0001 sec alatt fut le egy, ez nem is olyan lassú művelet :-) Természetesen a propel segítségével is csinálhatsz join műveletet, de egy komolyabb lekérdezés megírására akár egy napod is rámehet. Viszont ahol szűrés, paginátor, stb van, ott érdemes elszöszmötölni vele. Állítólag ez a része egyszerűbb a doctrinenak, én még nem ismerkedtem meg vele.

Egyébként első ránézésre tényleg jobb a cake, ha megbarátkozol a gondolattal, hogy a model nem önmagát (osztályt), hanem tömböt ad vissza (és ebből kifolyólag a visszaadott tömbnek nincsenek függvényei) és az kerül ki a viewba. Ha bármilyen két, vagy több mezővel összefüggő adatot kell kiírnod, akkor azt minden egyes alkalommal meg kell tenned. Míg propelnél írsz egy függvényt a modelbe és azt hívogatod, mert symfonynál a viewba a model osztály kerül. Ugyanez a hiányosság mentésnél is fennáll, ott sem tudsz egy mező módosítására egy külön triggert írni. Meg ami nekem nagyon nem tetszett a cakeben, hogy elég sok a megkötés. Bele lehet örülni egyesszám-többesszám elnevezésekbe, meg hogy egy modelt hogyan kapcsolsz össze egy másikkal. (nem kötelező, csak az egyszerűség kedvéért erősen ajánlott) Különösen egy kapcsolótáblával teheted próbára a CakePHP-t. Néhány projektem nekem is van, mert nagyon egyszerű a megjelenítés, a form (bár a symfony widgetei is vannak olyan jók), és az ajax is roppant egyszerű. A paginátora is sokkal jobb lenne a CakePHP-nak, csak nem használ sessiont :-(. A nézet menüpont legenerálása is egy jó pont volt nálam a CakePHP esetében. A symfony nem csinál nézet menüpontot. Itt nem a mezők kiírásán, hanem a kapcsolt táblák megjelenítésén van a lényeg. Viszont Symfony esetében vannak szűrök és a routing is sokkal összetettebb. A generátora pedig sokkal jobb és könnyebben módosítható. Szóval a kettőből lehetne egy jó keretrendszert készíteni. :-)

Amúgy ami a leginkább indok a symfony mellett, az a plugin. Cakeben is van, de ahogy olvasgattam az nem egészen ugyanaz. A plugin fejlesztésbe szerintem az a jó, hogy oda olyan dolgok kerülnek, amiket később több projektben is felhasználnál. A symfony arra lehetőséget ad, hogy alkalmazás szintjén felülírd az egyes osztályokat/fájlokat. Tehát nem az egész plugint, hanem csak az oda külön lefejlesztett egyes osztályt, vagyis egy-egy fájlt kiszedve a pluginból. Azokról készítesz egy másolatot az alkalmazás szintjén és akkor már azokat olvassa be és ott nyugodtan módosíthatod. Ezzel a plugin karbantartása válik egyszerűbbé. Hiszen nem feltétlenül kell azt a fájlt az összes projektedbe ugyanúgy módosítanod. Ezért létre kell hozni egy üres fájlt az osztály fában, amit ha szükséges felül lehet írni. Viszont egy másik fájlban (a közös kódban) történő javítás az összes projektedre jótékony hatású lehet.
8

hát nem tudom, hogy mi a gyorsabb

inf · 2010. Ápr. 4. (V), 23.02
Hát én a symfony saját oldalán olvastam egy fejlesztéssel kapcsolatos bejegyzést, hogy váltanak doctrine-re, mert az gyorsabb és stabilabb. Mondjuk a bejegyzés szerintem régebbi volt, mint 2 év, és nem most néztem, csak következtettem, hogy ha már ők a rendszer fejlesztői, akkor csak jobban tudják.

Az ORM nem 100%, hogy kelleni fog, mert úgy tudom, hogy a view-ek jóval gyorsabbak, mint a szimpla adatbázis kérések.

A cake-ben valóban idegesítő ez a többes szám, egyes szám dolog. Teljesen felesleges bonyolítása a dolognak. Ha gyűjtemények miatt kell többes szám, akkor simán oda lehet írni az osztály neve után, hogy Collection, ha meg más miatt, akkor meg lehet egyes számot is használni.

A tömbös dologgal szerintem nem lesz gond, de majd meglátjuk.

XML-el nekem nincsenek gondjaim.
10

tömb példa

nova76 · 2010. Ápr. 6. (K), 12.59
A tömbök problémájára egy példa:
Ha nem a "name" mező az, ami "megjelenít" egy recordot, akkor be kell állítanod a displayfieldet. De ez csak mint mező adható meg, képlet nem lehet.
(pl ez nem lehet: $regisztaltak['Regisztralt']['vezeteknev'].' '.$regisztaltak['Regisztralt']['keresztnev])
Tehát ezt az összes view esetén meg kell csinálnod, vagy létrehozol egy plussz mezőt, ahol össze van írva. De akkor a mentésnél kell erre odafigyelni. De tegyük fel utólag kitalálják hogy legyen titulus is.
echo $regisztaltak['Regisztralt']['titulus'].' '.$regisztaltak['Regisztralt']['vezeteknev'].' '.$regisztaltak['Regisztralt']['keresztnev']
Ezt az összes viewban utólag kell módosítanod, ami azért nehézkes, mert már foglamad sincs hova írtad bele.
Ezzel szemben ha a modeled egy osztály, akkor echo $regisztralt->getName() vagy mégjobb a echo $regisztralt és a modelben egy helyen megírod ezt a függvényt (public function __toString() {return $this->getKeresztNev().' '.$this->getVezeteknev()}). Megvan a helye, véletlenül sem tudod elfelejteni, elrontani, nem gondolni rá.