MVC in PHP

 ( sharky | 2012. november 26., hétfő - 23:26 )

Nemreg nekikezdtem foglalkozni a fent emlitett modszerrel.
Atnyalaztam egy nehany tutorialt, de meg van egy nehany dolog amit nem ertek. Biztos vagyok benne, hogy akad itt olyan aki valami utmutatot tud adni ( tutorial, tipp, konyv, stb. ).
Amit nem ertek es a neten sem talaltam semmi hasznalhatot: megnyitom pl. a SITE/Article/View/Param linket, az Article->View(param) vegre lesz hajtva. A rendernel betolti a header.php / $view.php / footer.php -t. Ez eddig tiszta, de ha en azt szeretnem, hogy legyen egy menu.php is, ami pl. a Menu->generate_list($curr_active) -bol toltodik fel adatokkal, ezt hogy lehet elegansan ( es helyesen meghivni )?
Tehat: nem csak 1 aktiv controller -re lenne szuksegem, az a megoldas nem tetszik ( valoszinu, hogy nem is helyes ), hogy pl. az Article controller-ben meghivom a Menu controllert.
Koszonom!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A header/footer.php-t és hasonló ökörségeket felejtsd el. Legyen egy osztályod, ami az egész oldal szerkezetét legenerálja behelyettesítve a tartalmat a megfelelő helyre, abból opcionálisan lehet származtatni és/vagy objektumkompozíció.

Idővel, mikor jönnek az egyedibb oldalak, rá fogsz jönni, hogy jobb ez így, még ha elsőre bonyolultabb is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, szerintem is okorseg. Irtam mar 1-2 dolgot PHP -ban ( nem hasznaltam MVC -t ), de ott egy tucatnyi fajlbol tevodik ossze a tartalom. Az a gond, hogy nekem most egy kicsit nem atlathato a dolog, hogy a View reszt hogy kell megoldani ( pedig ugye ez tunik a legegyszerubbnek ).
Jelenleg valahogy igy tortenik ( roviden ): megnyitom az app -ot, feldolgozom a kapot URL -t, ellenorzi, hogy letezik a kert controller es method, ha igen futtatja azt az adott parameterekkel. A controllerben tudja, hogy milyen view -et kell betolteni es rendereli azt. Valamit lehet, hogy nem ertettem, de nekem innen nem tiszta, hogy hogy tudok ganyolas nelkul osszerakni egy view -t ami tobb fajlbol all. Arra gondoltam, hogy Joomla szeruen kesziteni egy DB tablazatot, hogy milyen oldalon milyen "modulokat" kell betolteni es lenne egy helper ami URL -tol fuggoen tolti be tartalmat. Tovabba ami meg nem tiszta, hogy a fajlstruktura hogy legyen. Jelenlegi fajlstruktura: "application", benne annyi konyvtar ahany osztaly ( pl. User, Product stb. ), azokon belul "Controller", "Model", "View".
Ha peldaul keszitek egy helpert ami a menut generalja le, akkor a menunek a HTML kodjat milyen fajlba tegyem?
Megprobaltam nagyon kulonvalasztani a dolgokat, lehet, hogy tulzottan is.
Ket dolog a cel: 1.) tanuljam meg helyesen alkalmazni az MVC pattern -t 2.) keszitsek egy alap framework -ot amit a kesobbiekben szinte barmilyen wepp app alapjakent fel tudom hasznalni.

Nézz szét itt, én ezzel nézegettem az MVC-t: http://www.yiiframework.com/doc/api/
Ha letöltöd a frameworkot, van benne egy yiiblog nevű példaprogi, megnézheted működés közben.
Doksija is van: http://www.yiiframework.com/files/yii-blog-1.1.0.pdf

Koszonom! At fogom nezni.

A konkret esetben a Menu-t nem controllerkent kellene megvalositani, hanem helperkent, mert te valojaban nem vezerelni akarsz, hanem csak generalni egy listat.

Siman controllerbol meghivod a helpert, az eredmenyt kirakod egy valtozoba, amit megkap a view, a view meg ez alapjan kirendereli a menut. Ennyi. De a Menu-nek nem kell kontrollernek lennie, nem kell kintrol kulon elerhetonek lennie. Gondolom a menu ugyis inkabb valamifele hash-t ad vissza, nem konkret HTML kodot.

Ha esetleg olyan a helper, hogy a view kontextusabol kell neki meghivodnia (nem tudom, miert kellene ilyen...), akkor hivhatod view-bol is, de ekkor a helper osztalyod legyen egyszeruen peldanyosithato, es a peldanyt magat kuldd at a view kontextusaba (Smarty eseteben ez ugye egy $smarty->assign-ot jelent)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szukseg lehet Menu controller is ( ha letre akarok hozni egyet, modositani stb. ) . Ne erre a konkret esetre fokuszalj, hanem globalisan. A lenyeg az, hogy tobb controllert kell futtatni, hogy az most Menu, User, Product stb stb. az mind1.

Te meg arra probalj meg fokuszalni, hogy MVC-nel nem letezik a tobb kontroller fogalma. Ha ez felmerul, akkor tutira rosszul van szervezve az appod.

Valoban szukseg lehet Menu controllerrre - a CRUD muveletekhez. De amit te irtal, az tipikusan helper funkcionalitas, nem pedig controller.

Az megint mas kerdes, ha az utvonalban szerepel tobb conroller, pl. /categories/25/product/15 de ekkor is a ProductController -t kell elovenni, es majd o banyassza elo a megfelelo kategoriat es termeket a modellekkel. Tehat meg ilyen esetben sincs tobb kontroller meghivasa.

Globalisan: egy keres - egy controller.

MVC tekinteteben egyebkent ajanlom tanulmanyozni a Ruby on Rails rendszert. Noha nem PHP, eleg sokat meg lehet erteni az MVC szemleletbol vele.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ertem. Esetleg ha tudnal ajanlani egy ertelmes tutorialt, az idealis lenne. Az eddigiekkel amikkel talalkoztam, enyhen szolva hianyosak. Mindenki a controller -re es a model -re teszi a hangsulyt. A view resz pedig annyirol szol, hogy van header.php, footer.php meg egy $view.php amit osszerak es csokolom. Ez messze nem eleg.
Azert gondoltam, hogy szukseg van tobb controller egyideju futasara, mert pl. egy online boltban egy oldalon a kovetkezo dolgok jelen(het)nek meg: kategoriak , globalis menu ( kapcsolat, termekek, rolunk stb. ), bevasarlo kosar, felhasznalo ( login form vagy informaciok ). En valahogy ugy kepzeltem ( valoszinuleg rosszul ), hogy ezek mind controllerek es mindegyiket kell futtatni ( $category->get_category_list($parent_id); $menu->get_menu_list($active_menu); $cart->get_cart_content(); $user->get_cur_user_info(); )

Rosszul kepzeled.

Ha a webboltos peldat veszem alapul, akkor a kovetkezo van:

- A kapcsolat csak a kapcsolat oldalon jelenik meg - ignore
- Rolunk: detto, vagy max statikus szoveg => valami helper felolvassa, es kirakja egy widgetbe
- kosar: ez mar alaphangon is egy model, userhez kotve. $current_user->get_cart(), helloka.
- kategoriak: Category::list_categories() (ez ugye a Category modell
- menu: ezt ahogy mar mondtam, vagy kirakod helperbe, es eleve HTML-t kuldesz vissza, vagy a modelbol eloallitod a hash-t, es a view-en belul rendereled le egy partial view-vel
- $current_user = User::find_by_id($_SESSION['user_id']). Ezt ki lehet pakolni helperbe vagy filterbe.

Ahogy latod, sehol nincs szukseg kontroller fellovesere. A kontrollereken - joreszt - csak olyan fuggvenyek vannak implementalva, amiket a webrol meg lehet hivni. Ez alol ketto kivetel van: a before/after filterek, amik kozvetlen a request-tel dolgoznak (tipikus pelda erre az authorizacio: before filterben ellenorzod, hogy az aktualis usernek (aki akar null is lehet anonnal) van-e joga elerni az adott eroforrasokat, ha nem, elredirecteled).
Nalam amugy meg csak peldanyositasra sem kerulnek olyan kontrollerek, amiket nem erint az aktualis request.

A partial view az egy olyan cucc, amit beinclude-olsz a fo layoutodbol. Ugyanis a header/footer.php mint olyan, kozvetlen NEM letezik MVC alatt.
A kontroller mindig egy darab view-t renderel ki, meghozza a megfelelo akciohoz tartozo view-t. Ezen a view-n belul mar lehet kulonbozo partial view-eket hivni, amik pl. a header/footer.php-kat helyettesithetik.

Nagyon ajanlom MVC-hez a Smarty template rendszer hasznalatat, azzal ugyanis ugy tudsz egyseges layoutot csinalni, hogy az egyes view-k kiterjesztik a fo layoutot, igy nem kell allandoan a partial view-ekkel szorakozni. Egy elkepzelt felepites a webshopos peldara (nem mutatok meg minden, ez csak vazlat):

class Product extends Model { /* foo */ };
class Cart extends Model { /* foo */ };
class Category extends Model { /* foo */ };
class User extends Model { /* foo */ };
/* Szerintem ennek egyebkent nem feltetlen kell modellnek lenni */
class Menu extends Model { /* foo */ }; 


class ProductController extends Controller {
    function beforeFilter() {
        $this->current_user = User::findById($_SESSION['user_id']);
        if($this->current_user == null) {
            header('Location: /session/new'); exit;
        }
        $this->menu = Menu::get_menu_tree(); 
        /* Itt esetleg rogton be lehet hivni a MenuHelper-t, es a HTML kodot mar itt kigeneralni */ 
    }

    function show() {
        $category = Category::findById($this->params['category_id']);
        $product = $category->get_product($this->params['product_id']);
        $cart = $this->current_user->get_or_create_cart();

        $smarty = TemplateEngineHelper::getEngine();
        $smarty->assign(array(
            'user' => $this->current_user,
            'cart' => $cart,
            'category' => $category,
            'product' => $product,
            'menu_tree' => $this->menu,

        ));
        $smarty->display('products/view.tpl');
    }
}

### view.tpl ###
{extends "layout.tpl"}
{block 'cart'}
{foreach $cart->items as $item}
bla...
{/foreach}
{/block}
{block 'userbox'}
Welcome, dear {$user->name}!
<a href="/session/destroy">Logout</a>
{/block}
{block 'menu'}
blabla
{/block}
{include file='aboutus.tpl'}

A tobbit mar kepzeld el magadnak. Ahogy latod, gyakorlatilag mindent modelleken keresztul hivtam be. Ha akarod, es tudod, hogy bizonyos dolgokra minden metodusban szukseged lesz, azokat behivhatod before filterben is, lasd menu. A before filter ugye meg _azelott_ fut le, hogy az aktuakis akciohoz tartozo metodus meghivasra kerulne.

Amik affele aranyszabalyok:
- Controllerben vegezzuk az uzleti donteseket, hozzaferes engedes/tiltas, atiranyitasok, stb.
- Modellben lehetoleg csak adatbazishoz kapcsolodo kodok legyenek. Nested modellek eseteben (pl. Category-Product) lehet olyat csinalni, hogy egy modell egy bizonyos metodusa egy masik modellt adjon vissza (fent: $category->get_product(), $user->get_or_create_cart()), ilyenkor ugyanis a parent modellnek mar szinte minden adata rendelkezesre all, ami alapjan meg tudja szulni a nested modellt, hiszen reszben ugyis a sajat parametereivel kell dolgoznia, felesleges mindig a Product::findByCategory($category->id) utvonalat vegigjarni. Ez esetleg egy egynel tobb parameter alapjan kapcsolodo modellek eseteben akar meg nyugos is lehet.
- A view-t ugyan szet lehet bontani, azonban a controller mindig csak egy view-t renderelhet ki (esetleg ha akarsz JSON outputot is, akkor lehet valasztani, hogy view vagy JSON, de mindig csak egy lehet), a tobbi view vagy kiterjesztessel (ha a template engine ezt lehetove teszi), vagy inkludolassal kerul meghivasra. Erdemes widgetekben gondolkodni, ahol pl. az aboutus az pl. amugy is egy doboz valahol, tehat kivaloan widgetesitheto. Ezeket egyebkent azert hivjuk partial view-nek, mert ha csak siman kirenderelned, akkor nem kapnal egy komplett, onallo oldalt, hanem csak valami HTML fragmentet. Ezzel szemben a normal view-ek kirenderelve egy komplett oldalt adnak ki.

Nem tudom, hogy ez mennyire felel meg az MVC szotari definiciojanak, en mindenesetre altalaban igy implementalom az MVC-t, mert ez tobbe-kevesbe teljesiti a kriteriumokat, es nem is tul bonyolult implementalni.

--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Koszonom a kimerito valaszt! Ezen at kell ragjam magam egy nehany alkalommal. Ugy latom, hogy - tobbek kozott - megprobaltam tulsagosan kulonvalasztani az osztalyokat.

Nagyon szivesen. Ha van kerdes, told ide nyugodtan. A PHP kodjaim eleg csunyak, szoval azt tenyleg csak affele pszeudokodkent hasznald, a HUP editora nem teszi lehetove, hogy ertelmesen szerkesszek kodot.

Ha erdekel, van egy sajat framework-kezdemenyem, messze nincs meg kesz, de mar valamennyire hasznalhato, otletelesre jo: https://github.com/hron84/html5-smarty-boiler
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Van valami oka annak, hogy ha már saját frameworkot irsz berántod a smartyt is? Szerintem felesleges, hiszen mindent el lehet végezni szűz php-val is. Manapság amit én láttam inkább sima php a view része is a dolgoknak.

Nem kötekedni próbálok, csak kíváncsiskodom.

____________________
http://szoftvervasarlas.co.hu - elérhető árú, legális szoftverek itthon

abbol elobb utobb ganyolas lesz ha nem figyel oda az ember... egyszemelyes csapatkent meg te magadat tudod kontrollalni hogy azert ne irj mar barmit abba aminek a viewnak kene csak lennie, de mikor csapat van meg hataridok akkor mar nehezebb mindenkit rugdosni hogy ugyanmar ne epitsen minden szart a "template" phpba... Szemely szerint ezert szeretek template enginet hasznalni foleg (bar en inkabb twig parti vagyok phpban smarty helyett, a koncepcio ugyanaz)

Bar felettem elhangzott egy hangzatos - es nem mellesleg talalo - erveles, en ennel joval prozaibb okok miatt csinaltam: utalom a PHP templatinget, mert szerintem nehezkes. Nem mindenutt van engedve a short_open_tag, az asp_tags meg foleg, az meg, hogy allandoan printelgessek, nem fekszik. A Smarty intez mindent nekem, sot, van hozza egy csomo hasznos helper fuggveny is.

Ja, es nyers PHP template-nel nem tudsz orokolni layoutot, Smartyban meg igen.

Ugyanakkor a Smarty csak egy template engine, semmi tobb. Lehetne akar twig is, vagy akarmi mas is. A keretrendszernek ez csak egy apro kis resze, amit nem voltam hajlando leimplementalni, volt eleg dolgom.

Valahol van egy commit a gepemen, ami mar kicsit kibontja ezt a Smarty fuggest a frameworkbol, de azt meg nem tudtam tesztelni, ezt a cuccot a nem letezo szabadidomben fejlesztem ugyanis.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

+ még Smarty-nak nagy előnye, hogy megvalósít egyfajta sandboxot, azaz korlátozható benne a PHP - mind az elérhető adatok körének, mind az adatokon végezhető műveletek körének tekintetében. Nem feltétlenül jó ötlet, hogy a designer lefutó PHP kódot szerkesszen, a template-ben viszont garázdálkodhat nyugodtan.

A designer herkesszen HTML kodot, a tpl fajlokat meg hagyja a frontend fejlesztore, oks? Kb. koze nincs hozzajuk.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Bölcsen szóltál - vállon veregedheted magad! :D

Nezd, nekem komolyan ez a velemenyem, akkor is, ha viccesen fejezem ki. Lehet velem nem egyet erteni, nem fogok megsertodni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Biztosíthatlak róla, hogy eszem ágában sincs "nem egyet érteni" becses személyeddel ebben az egyszerre viccesnek és komolynak tálalt kérdésben. Bár ha megsértődnél, akkor esetleg ...ááá nem, akkor sem!
:-D

Azert jo, hogy egyetertunk (bar neha egyet-mast meg nem ertunk)... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Vagy méginkább a PS/Fireworks/stb-nél. A HTML szerintem inkább frontendes feladat.

Szerintem meg nem kizarolag. A frontendeshez inkabb mar a JS tartozik, meg a HTML/CSS csiszolgatasa. De a designer - ha kepes ra - nyugodtan eloallithatja az oldal alapjait HTML-ben, ezzel csokkentve a frontendes terheit + ilyenkor buknak ki azok a reszei a dizajnnak, amiket nem lehet bongeszoben reprezentalni. Azt attervezni pedig ugyis dizajneri feladat, szoval felesleges koroket sporol ez. Persze, van olyan ember, akitol meg egy body { background: white; } -t se latok szivesen, mert meg azt is kepes elrontani...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Lehet igazad van, olyan sok tapasztalatom nincs. Egyszer dolgoztam junior frontendesként, ott a grafikusnak nem volt feladata a html, csak a fireworksben matatás. Ebből gondoltam.

Ne kepzelj belem tul sokat: nekem sincs tul sok tapasztalatom. De tudom, hogy egy frontendesnek amugy is rengeteg munkaja van egy oldallal, tehat ha a grafikus akar annyit is tud erte tenni, hogy osszerakja a html+css-t igenyesen, az nagyon felgyorsithatja a munkat. Neki utana amugy is csak minimalis munkaja lesz a keszulo oldallal, szoval belefer.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

View != Template.

Smarty meg az egyik legnagyobb fasság, amit ki lehetett találni PHP-re. Ugyanazt valósítja meg amire a PHP indult eredetileg. Felesleges overhead.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

saxus írta (2012. november 28., szerda - 14:26):
Smarty meg az egyik legnagyobb fasság, amit ki lehetett találni PHP-re. Ugyanazt valósítja meg amire a PHP indult eredetileg. Felesleges overhead. (Kiemelés B.Z.)
@

Kedves saxus, egyetértek Veled abban, hogy egy fórum alkalmas lehet bizonyos mértékig a frusztráció levezetésére, mindezek melett szabadjon felhívnom a figyelmed, hogy zéró informatikai ismerettel is kimutatható zagyvaságot sercintettél ide. A Smarty 'fasságára' vonatkozó állításod nincs a formál logikának megfelelő érvvel alátámasztva, különös tekintettel arra, hogy a PHP induláskori állapotát hasonlítod a Smarty funkcionalátáshoz, indirekten utalva arra - egyébként a valóságnak megfelelőn - hogy azóta a PHP funkconalitása megváltozott [jelentős expanzion ment át]. Tehát miért lenne 'fasság' a Smarty által reprezentált funkcinalitás ebben a megváltozott relációban? Erre írod - gondolom - hogy 'felesleges overhead'. Oké! De nem látom, hogy miböl derül ki, hogy overheadről van szó, és ez az overhead - ha van - nem szükséges, hanem viszont felesleges jellegű!?

- +1 függőség
- +1 nyelv, amit meg kell tanulni
- előbbiből adódóan +1 olyan felesleges dolog, amire egyébként nem lenne szükségem.
- ugyanazt a funkcionalitást meg lehet valósítani PHP-ben
- időnként egyszerűbben
- attól, hogy beletúrtak OOP-t meg sok egyebet a PHP-be még mindig egy "template nyelvnek" indult.
- az echo "<html>" és a smarty között azért vannak még más utak is
- ha meg már MVC: mi kerül neked a View-be? Amit megkapsz a külvilágból adatokat, azokat átlapátolod a Smartyba? Kissé nonszensz. (Ismételten megjegyzem: template != view)
- ha bugot kell vadászni, lehet vadászni még egy rétegben
- overhead
- véleményem szerint a megjelenítés logikájának nem a templateben van a helye
- egyéb olyan személyes jellegű kisebb-nagyobb szívások, amelyek fel se merültek volna, ha nem egy megörökölt Smartys kódot kellett volna használnom. pl. class constant vs {if}
- nem láttam egy érvet sem a használata mellett.
- külön öröm, mikor jön egy smarty fanboi egy olyan 4-5 éves projekt közelébe, amelynek megvan a maga template, modul és sok egyéb dologra a kész megoldása, de az arc kitalálja, hogy smarty a tuti és - bár hiába nem illeszkedik bele sehogy se a meglévő koncepcióba - egy két soros HTML darab kijelzésére is beránt egy teljes smartyt, csak mert azt szokta meg. (Az egyéb széttúrásokat hagyjuk.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Huhh, megint sikerult vihart kavarnom, pedig nem szerettem volna. Szogezzunk le rogton par dolgot:
- Nem mondom, hogy MVC rendszerben kotelezo a Smarty hasznalata. En ezt valasztottam, mert nekem ez volt kezenfekvo, a template nyelvet mashonnet mar lenyegeben ismertem, magaval a smartyval pedig volt mar korabban is kapcsolatom.
- Fokeppen nem tartom mely szakmai dontesnek. Rolam koztudomasu, hogy rendszergazda vagyok, talan megbocsathato, hogy kedvelek egy ilyen "felesleges" keretrendszert
- En is hulyesegnek tartom egy 2-3 soros HTML kodert templatezni. Viszont az esetek donto tobbsegeben ennel nagyobb/hosszabb/bonyolultabb kod megy ki a kliensnek.
- En is elitelem azt, aki egy mar meglevo, alapvetoen nem Smarty-s rendszerbe Smarty-t akar rakni. Az ilyentol ket hetre legalabb el kell venni a billentyuzetet. A templating rendszer kemenyen strukturalis kerdes, es nem alsogatya, amit naponta cserel az ember.

A view reteg erdekes kerdes. Mivel en alapvetoen az egyszerusegre torekszem, nalam nincs kimondott view reteg, a megjelenitessel kapcsolatos dontesek megoszlanak a kontroller es a template kozott. Ami nem egyszeru dontes, pl. tobb parameter egyuttese kell hozza, vagy olyan objektumon alapszik, melyet a vegen a template mas okbol nem kapna meg, azt a kontrollerben rendezem le, minden mas a template-be kerul. Ez lehet, hogy nem a legmegfelelobb eljaras a temaban, talan ha PHP-t hasznalnek templatingra, akkor amugy is elkelne egy tisztesseges view reteg, szoval ott talan kiszervezhetoek lennenek ezek a dontesek. Viszont egyelore ilyenre szuksegem meg nem volt - tegyuk hozza, PHP-ban en nagyon bonyolult appokat nem csinalok. Talan erre is kihatassal van, hogy en nem vagyok programozo, nekem ez a modszer tokeletesen megfelel a celnak.
Nem mellesleg a Rails hasonlo paradigma menten mukodik alapbol, de persze azt lehetove teszi, hogy a template kirendereleset egy kulon objektumbol vegezd - vannak erre is megoldasok. Nekem ez az elv egyszeruen nem jott be.

"- az echo "" és a smarty között azért vannak még más utak is"
Ez viszont erdekelne. Mint irtam, ismerem mind a short_open_tags mind az asp_tags altal biztositott elonyoket - csak nem mindig van lehetosegem kihasznalni oket, ilyen vagy olyen okbol - ezt most ne feszegessuk.

ez a komment eredetileg hosszabb volt, es joval reszletesebb, csak az internet kimaradas megette a felet
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ezek inkább általánosságok és nem Smarty specifikus dolgok. Smarty már a nagy emvécézés előtt is volt, és megjósolom utána is lesz. Szerintem a Smarty a legjobb dolog a PHP -ben, míg pl MVC kapcsolatban meglehetősen vegyesek az érzelmeim.

+1 függőség
Ez butaság. Nem plusz egy függőség. Ha nem pure PHP -t használsz, hanem valami template-t akkor ugyan úgy megvan ez a függőség, csak mástól. Ilyen erővel az adatbazis is plusz egy függőség! Akkor ne használjunk adatbázist?

+1 nyelv, amit meg kell tanulni
Ugyan! Aki isemri HTML -t meg PHP -t, annak ez nem okozhat gondot.

előbbiből adódóan +1 olyan felesleges dolog, amire egyébként nem lenne szükségem.
Előző érvek imsétlése, feleleges bekezdés.

ugyanazt a funkcionalitást meg lehet valósítani PHP-ben
Minthogy a Smarty PHP -ben van írva, így ezzel nem mondtál újat :-).

időnként egyszerűbben
Ad abszurdum előfordulhat, de az 'időnként' pont azt jelzi, hogy általában viszont szerinted sem lehet egyszerűbben. ;-D

attól, hogy beletúrtak OOP-t meg sok egyebet a PHP-be még mindig egy "template nyelvnek" indult.
Ezt az előbb már tisztáztuk. Aki rossz papagáj módjára egyre csak arra hivatkozik, hogy minek indult a nyelv tízen x évvel ezelőtt, az egyszerűen nem hajlandó a jelen helyzetet tudomásul venni.

az echo "" és a smarty között azért vannak még más utak is
Nem kétlem. És?

ha meg már MVC: mi kerül neked a View-be? Amit megkapsz a külvilágból adatokat, azokat átlapátolod a Smartyba? Kissé nonszensz. (Ismételten megjegyzem: template != view)
Azok az adatok kerülnek a Smartyba amiket meg akarok jeleníteni, vagy amik szükségesek ahhoz, hogy a template el tudja dönteni, hogy mi jelenjen meg. Vagyis ami a megjelenítési logikához kell.

ha bugot kell vadászni, lehet vadászni még egy rétegben
Nincs még egy réteg. Lásd az első bekezdés.

overhead
Ez az 'overhead' csak egy blöff. Számos formában értelmezhető függően attól, hogy mi a programozási feladat. Pl a fejlesztési folyamatra is érvényes. Más jelentése van egy csúcsra járatott site esetében, ahol hardver már alig bírja a terhelést, és más ahol tucatjával kell készíteni a céges weboldalakat, amiket jó ha 1000-en megnéznek egy nap.
A Smarty intelligens megoldás, hisz a templatet PHP kódra fordítja és amíg nem változik a template addig a lefordított PHP kódot injektálja a folyamatba. Ha változik a template akkor újrafordítja PHP -re. Ezen felül még saját cache rendszere is van, amivel igazán be lehet gyorsítani az oldalt.

véleményem szerint a megjelenítés logikájának nem a templateben van a helye
Érdeklődéssel várom ennek kifejtését!

egyéb olyan személyes jellegű kisebb-nagyobb szívások, amelyek fel se merültek volna, ha nem egy megörökölt Smartys kódot kellett volna használnom. pl. class constant vs {if}
Nyilván ha más megörökölt rendszerrel kellett volna dolgoznod, akkor azzal szívtál volna, és ugyan így elmondhatnád, hogy azok a szívások sem merültek volna fel, ha nem azt a rendszert kell használnod, tehát ez egy általánosság. Fogalmam sincs mi lehetett az a probléma ami 'class constant vs. {if}' relációban merült fel, vagy h ezek hogy jönnek egyáltalán egymáshoz.

nem láttam egy érvet sem a használata mellett.
Ez nem igaz. Hisz még válaszoltál is a 2012. november 27., kedd – 22:06 -ei bejegyzésemre.

külön öröm, mikor jön egy smarty fanboi egy olyan 4-5 éves projekt közelébe, amelynek megvan a maga template, modul és sok egyéb dologra a kész megoldása, de az arc kitalálja, hogy smarty a tuti és - bár hiába nem illeszkedik bele sehogy se a meglévő koncepcióba - egy két soros HTML darab kijelzésére is beránt egy teljes smartyt, csak mert azt szokta meg. (Az egyéb széttúrásokat hagyjuk.)
Ez nettó bugyutaság. Nem róható fel a Smartynak, ha valaki azt nem megfelelően használja. Ha olyan helyen erőltetik a használatát, ahol az nem célszerű valamely oknál fogva, akkor ez annak a hibája aki erőlteti és nem a Smarty -é. És mint ilyen természetesen ez nem Samrty függő, hanem általánosság, ami mindenre igaz.

Kozbeszurnam, hogy en lattam mar olyan MVC felepitesu oldalt, ahol a View az nem kozvetlenul a template volt, hanem egy kulon osztaly, ami kirenderelte a PHP alapu templatet. Nem lattam melysegeben a kodot, igy azt mar csak tippelni tudom, hogy ez elsosorban scoping okokbol volt igy, egy instance method-on belul jol el lehet kuloniteni a valtozok hatokoreit, plusz igy be lehet vinni egy csomo helper method-ot a PHP template-be.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ez nem scoping okok, hanem a View része a megjelenítés. Az nincs definiálva, hogy miben jeleníti meg. Lehet az XML fájl, CSV, kép, akármi.

A template meg csak HTML kód, ami a program szempontjából nem más, mint adat, amivel dolgozol és amiből a kimeneted összeáll. Ez mondjuk valamivel jobban kijön mondjuk egy MVVM patternnél, ahol a View meg a ViewModel szét van választva.

Szóval mivel ez számodra csak adat, és a megjelenítési logika szerintem a program része, ezért ellene vagyok mindenféle ilyen Smarty és egyéb "komolyabb" kódolási logikát felvonultató tákolmánynak.

(Ugyanígy a modell messze nem egyenértékű az adatbázissal, modell osztályod lehet bármi, ami jelentéssel bír a rendszeredben. Az, hogy többnyire DB-ben tároljuk, az csak egy dolog.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A modell eseteben persze, tiszta a dolog, a view az, ami szamomra kerdeses.

Megint csak a Rails-t tudom felhozni peldanak, mert csak ezt ismerem behatobban. Itt az "ortodox" metodika szerint 4 fele modon lehet kimenetet generalni:
- Template-vel: ekkor egy Smarty-felepitesu template rendszeren keresztul nyomod ki a cuccot, tipikusan HTML alapokon (tobbfajta template nyelv is tamogatott, de az alapkoncepcio ugyanaz)
- Builder: ez van a bonyolultabb XML/JSON tartalmak kirenderelesere. Ez valojaban egy kulon "modul", ahol a kimenet eloallitasa zajlik, teljes mertekben az alkalmazas nyelven (Ruby).
- Az ActiveRecord modellek beepitetten rendelkeznek XML es JSON szerializacios kepessegekkel. A tobbinel van erre kulon inkludolhato modul (mixin), akkor csak egy metodust kell implementalni, amiben megmondod, hogy mely attributumokat akarod szerializalni. Az AR modelleknek ez ugye egyszeru, mert ott a default az adatbazis oszlopok, ehhez lehet hozzaadni/elvenni plusz attributumokat.
- Vegul eloallithatod a kimenetet kezzel is.
- A bonusz opcio, hogy nem allitasz elo kimenetet, csak statuszkodot kuldesz, ilyenkor csak egy header blokk megy ki, a content-length nulla lesz.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Ugyan! Aki isemri HTML -t meg PHP -t, annak ez nem okozhat gondot. "

Nem azt mondtam, hogy nem lehet megtanulni, hanem azt, hogy még egy dolog, amivel foglalkozni kell, ha használod.

"Fogalmam sincs mi lehetett az a probléma ami 'class constant vs. {if}' relációban merült fel, vagy h ezek hogy jönnek egyáltalán egymáshoz. "

Pl. hogy nem működik és az összes létező megoldás valami ronda, csúnya workaroundot javasol. Illetve a franc tudja, hogy megoldották-e azóta, az összes találat workaroundot javasolt.

"Ez nem igaz. Hisz még válaszoltál is a 2012. november 27., kedd – 22:06 -ei bejegyzésemre. "

http://www.smarty.net/docsv2/en/language.function.php.tpl

"Érdeklődéssel várom ennek kifejtését! "

Miután csodálatos módon eljutottunk odáig, hogy végre ne összebarmoljuk a HTML kódot a PHP-vel a csodás Smarty segíségével visszajutnk oda, hogy ismét kódot barmolunk bele a HTML-be. Kössz nem, a logikát intéző kód a és a HTML kód legyen szépen elválasztva egymástól.

"Nyilván ha más megörökölt rendszerrel kellett volna dolgoznod, akkor azzal szívtál volna, és ugyan így elmondhatnád, hogy azok a szívások sem merültek volna fel"

Ez úgy hangzana helyesen, hogy ha nem egy PHP funkcionalitását duplikáló és annak képességeit hiányosan megvalósító template nyelvvel kellett volna szenvedni, hanem lehetett volna egyből normálisan PHP kódot írni, akkor fel sem merültek volna azok a szívások, amelyek Smartyval felmerültek.

"Ez nettó bugyutaság. Nem róható fel a Smartynak, ha valaki azt nem megfelelően használja."

Szerintem a Smarty fanboizmus Smartyval kapcsolatos probléma. Nélküle nem létezne. :)

De komolyan, hallanék arról is érveket, hogy mi szükség van a Smartyra.

"az egyszerűen nem hajlandó a jelen helyzetet tudomásul venni."

Kódoltam már eleget PHP-ben az elmúlt közel 11 évben, hogy tudjam jól, hogy mi a helyzet ezzel a nyelvvel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Csak kerdes: akkor jol ertem, hogy te az olyan view rendszer hive vagy, ahol a HTML kodba gyakorlatilag PHP-bol helyettesited be a tartalmakat (pl. str_replace('%FUBAR%', $fubar))?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Lényegében.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

hát.. grat :)

--
CyclonePHP

En nem tartom rossz megoldasnak. Ha jol van megtervezve az oldal, talan meg egyszerubb is lehet egy ilyennel dolgozni, mint Smartyval. Persze, oldala valogatja.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem azt mondtam, hogy az str_replace a legüdvözítőbb megoldás, de azt sem, hogy üdvösnek tartom, hogy foreach halmok meg if hegyek a _templateben_ szerepeljen.

Miért?
1) nem ott van a helye
2) pont az alapvető problémát nem oldja meg: a HTML és a működési logika szétválasztása.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Viszont igy esetleg kismillio darabra kell szabdalni a template-t, vagy viszonylag bonyolult modon duplikalni a tartalmakat, mondjuk egy sima tablazat eloallitasahoz. En szemely szerint a foreach-et valasztom, mert nekem fontosabb a gyors eredmeny, mint a minden szempontbol szep. De itt mar melyen benne jaruk az izlesek es pofonok volgyeben.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

mvvm ? knockoutjs ?

szép napokat
zsömi

MVC, a knockoutjs-t meg nem tudom mi.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tetszőleges keresővel megtalálható:

http://knockoutjs.com/

Rövid előadás (ASP.NET csak az ellenség megtévesztéséért van említve):

http://channel9.msdn.com/Events/MIX/MIX11/FRM08

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A "Nem tudom mi" ez esetben azt jelentette, hogy nem ismerem, nem hasznalom.

Oszinten az MVVM modell nekem nem tetszik, mar Androidnal se jott be. De ez megint szemelyes preferencia.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

az elore szabdalas szerintem semmivel sem szebb raadasul roghoz koti a layoutot is akkor

(shrug) nem tudom. Nekem mindenesetre laikus szemmel nem tetszik.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

saxus írta (2012. november 28., szerda - 23:11):
”http://www.smarty.net/docsv2/en/language.function.php.tpl”

[Előzmény: Ez nem igaz. Hisz még válaszoltál is a 2012. november 27., kedd – 22:06 -ei bejegyzésemre.]

Ennek használata beállítástól függ. Ha akarom engedélyezem, ha akarom tiltom [ezért fogalmaztam úgy korábban, hogy PHP funkcionalitása 'korlátozható' és nem úgy hogy korlátozott.] Engedélyezhetek külön PHP fügvényeket, illetve saját fügvényeket is tudok regisztrálni, amik aztán elérhetőek lesznek a template-ben. A Smarty képességeit egy plugin rendszeren keresztül kiterjeszthetem. Amúgy {php}{/php} tag már deprecated az új verzióban.

saxus írta (2012. november 28., szerda - 23:11)::
”Miután csodálatos módon eljutottunk odáig, hogy végre ne összebarmoljuk a HTML kódot a PHP-vel a csodás Smarty segíségével visszajutnk oda, hogy ismét kódot barmolunk bele a HTML-be. Kössz nem, a logikát intéző kód a és a HTML kód legyen szépen elválasztva egymástól.”

Attól tartok itt siklottál félre. A megjelenítési logikát kell elválasztani az üzleti logikától. A template-ben is szükség van vezérlési szerkezetekre. Szükség van template szintaxisra is, épp azért, hogy ne lehessen PHP utasításokat írnia a front-end fejlesztőnek.

saxus írta (2012. november 28., szerda - 23:11)::
”Ez úgy hangzana helyesen, hogy ha nem egy PHP funkcionalitását duplikáló és annak képességeit hiányosan megvalósító template nyelvvel kellett volna szenvedni, hanem lehetett volna egyből normálisan PHP kódot írni, akkor fel sem merültek volna azok a szívások, amelyek Smartyval felmerültek.”

[Előzmény: Nyilván ha más megörökölt rendszerrel kellett volna dolgoznod, akkor azzal szívtál volna, és ugyan így elmondhatnád, hogy azok a szívások sem merültek volna fel...]

Hajtogathatod ezt a baromságot, de én nem fogok reagálni rá többé.

saxus írta (2012. november 28., szerda - 23:11):
”De komolyan, hallanék arról is érveket, hogy mi szükség van a Smartyra.”
Már eddig is írtam, most is írtam érveket.

saxus írta (2012. november 28., szerda - 23:11):
”Kódoltam már eleget PHP-ben az elmúlt közel 11 évben, hogy tudjam jól, hogy mi a helyzet ezzel a nyelvvel.”
Nem kétlem, ugyanakkor érzékelhető, hogy úgy fogalmazol meg sarkos véleményt a Smartyval szemben, hogy nem vagy tisztában annak sem a céljával, sem a lehetőségeivel.

"Attól tartok itt siklottál félre. A megjelenítési logikát kell elválasztani az üzleti logikától. A template-ben is szükség van vezérlési szerkezetekre. Szükség van template szintaxisra is, épp azért, hogy ne lehessen PHP utasításokat írnia a front-end fejlesztőnek."

Miért kell a megjelenítési logikát a templateben implementálni? Miért nem implementálhatod azt php-ban, és ekkor a template egyetlen feladata, hogy a php által előállított adatokat behelyettesítse a nyers html-be és kiküldje outputra.

azert meg iszonyatosan inflexibilis, minden porszemert vissza kell menni felsobb retegbe, es akkor jonnek az ilyen kerdesek hogy pl formazast hol vegzel? Tehat kontrollerben akarsz turkalni hogyha egy datumot ugy jelenitesz meg hogy yyyy-mm-dd vagy ugy hogy yyyy mmm d, es akkor ezutan azert is hogyha pirosan szeretned? (es akkor visszajutottunk az egy fileban mindenhez csak eppen most kontrollernek hivjak). Persze mondhatod hogy ha a piros azt lehet htmlben csinalni tehat az biztos oda tartozik, de akkor ennyi erovel timestampbol meg tudsz datumot csinalni javascriptben (szoval itt nem az a lenyeg hogy mit tud vagy mit nem).

Controllernek megis mi koze van a datumformazashoz? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

hat pont ezaz... semmi

Nem azt mondtam, hogy a kontrollerben implementáld a megjelenítés logikáját, hanem azt, hogy ne a templateben. Magyarul miért ne lehetne php kód a nézetben is? Vagyis nézet = template + logika, azaz nyers html + php. Smarty is ezt csinálja végső soron, szóval miért ne hagyhatnád ki ezt a köztes réteget?

ja ertem, sima felreertes, en speciel azert akarom kihagyni azt hogy php kodot irjak a templateben mert az tul sok "szabadsagot" ad a fontendeseknek, meg a vegen olyan otleteik tamadnak hogy mast is nekiallnak piszkalni mint amit kellene, pl mibol all db connection functionoket irogatni ha mar egyszer php, aztan masnak kell kipucolni mert valaki tulbuzgo volt es ugy gondolta hogy o majd onnan kapcsolodni fog a dbhez mert "miert ne"... igy gyakiolatilag azert szeretek valami plusz template enginet hasznalni mert resztriktiv a kepessegeit tekintve, igy boztosabb hogy nem lesz ilyen gond

A Smarty - de gondolom mas template rendszer is ilyen - csak ahhoz enged hozzaferest, amit te explicite atpasszolsz neki. Ha egy komplett DB objektumot passzolsz at, akkor van hozzaferes a DB-hez, ha nem, nincs. De mondjuk a PHP-nak is le lehet szukiteni a scope-jat, hogy mihez ferhessen hozza, vannak ra ugyes technikak.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, pontosan ezt mondom enis, hogy resztriktiv, nem enged barmit megcsinalni es ez jo dolog (mint ahogy feljebb anno mar kitargyaltuk :) ), pont ezert szeretek template enginet (en speciel twiget ugye) hasznalni

hrgy84 írta (2012. november 29., csütörtök - 13:03 ):
"PHP-nak is le lehet szukiteni a scope-jat, hogy mihez ferhessen hozza, vannak ra ugyes technikak."

Húúúú ez érdekelne! Én csak a runkit -es Sandboxról tudok! És éppen ilyesmin agyalok.

Hat elso korben include fuggvenyen belul. Akkor ugye csak a fuggveny scope-jat kapod meg. A require meg ennel is szukebb scope. De en nem vagyok PHP programzo, majd saxus vagy valaki megmondja a tutit, en csak olvastam ilyenekrol - cimszavakban, es iszonyat regen.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ha a frontendes nem erti,h ogy nem nyulkal kozvetlen oda, ahova nem kell (vagy akarmelyik programozo) az az az eset, amikor azt az embert ki kell hajitani a francba, mert nem programozonak valo.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Erti vagy sem, az eselyt se szabad megadni. Szerintem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tokelete megoldas nincs, ameddig fizikailag nincs lehetetlenne teve szamara a dolog.

Ergo, marad az, hogy aki ganyerpituka, annak ra kell lepni a tokeire.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

nyilvan egy extrem peldat valasztottam, termeszetesen nem kell ennyire durvan oda nem illonek lennie ahhoz hogy csak "kicsit" nem oda illo legyen. A felreertesek elkerulese vegett, egyszerubb mar a lehetoseget is elvenni, talan akkor mar az irany is kirajzolodik az illeto elott ha netan ketsegei lettek volna hogy azt oda rakja vagy sem legkozelebb. Valakinek pedig nem kell hulyenek lennie ahhoz hogy ilyet csinaljon, csak szimplan tapasztalatlan juniornak

BaT írta(2012. november 29., csütörtök - 12:20):
"Magyarul miért ne lehetne php kód a nézetben is?"

pl hogy a front-end fejlesztő ne lophassa el a back-end kódot, mielött kifizetik ;-(

lol, ez jo volt :)

"Attól tartok itt siklottál félre. A megjelenítési logikát kell elválasztani az üzleti logikától."

Akkor most egy pillanatra terjunk vissza arra, hogy a tema az MVC.

"Szükség van template szintaxisra is, épp azért, hogy ne lehessen PHP utasításokat írnia a front-end fejlesztőnek."

Aztan, amikor valamihez mar keves a Smarty limitalt keszlete, akkor jon az, hogy PHP oldalrol adunk at plusz adatot, amivel ismetelten jol osszebarmoltunk mindent.

"illetve saját fügvényeket is tudok regisztrálni, amik aztán elérhetőek lesznek a template-ben."

Tudom, "csodas" megoldas. Epp csak egyvalamit nem lattam szinte senkitol, az pedig a htmlspecialchars() hasznalata a kimeno adatokra.

"Hajtogathatod ezt a baromságot, de én nem fogok reagálni rá többé."

Egyszer nem fejtetted ki tetelesen, hogy ez miert baromsag, csak, hogy baromsag. Ugyanigy egyszer nem reagaltal arra, hogy megis mi a retket keres a templateben a megjelenitesi logika, azon kivul, hogy jaj mert smartyval igy lehet. Mint ahogy arra sem reagaltal, hogy miert a Smartyban van a helye es miert nem a View-ben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Asszem - de nem vagyok benne biztos, ne verj meg, ha megse - mintha a 3-as smarty mar default futtatna htmlspecialchars-t (pontosabban az ennek megfelelo, ezt hivo smarty filtert) a kiirt adatokra. De mondom, lehet, hogy keverem valamivel.

De egyebkent ez meg nem a Smarty sara, hanem bizony a fejlesztoke. A kettot keretik nem keverni, es nem razni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem is tudom, honnan származik: "A számítógép segítségével rengeteg olyan problémát megoldhatunk, ami számítógép nélkül nem is létezne." ;)

"Nem tudom, hogy ez mennyire felel meg az MVC szotari definiciojanak, en mindenesetre altalaban igy implementalom az MVC-t, mert ez tobbe-kevesbe teljesiti a kriteriumokat, es nem is tul bonyolult implementalni."

Én azt nem tudom, hogy az kinek a hibája, hogy ahány fejlesztő, annyi MVC elképzelés. Vagy aluldefiniált, vagy nem univerzálisan implementálható, vagy csak könnyű félreérteni, vagy valami más oka van?

(Félre ne értsd, nem azt állítom, hogy te rosszul értelmezed, csak te sem vagy biztos benne, hogy amit csinálsz, az az MVC definíció szerinti alakja.)

Egy PhD disszertációhoz (a Smalltalk-os Naked Object framework/pattern kifejeszlesztéséről szól) írt bevezetőben írja az MVC kitalálója, hogy gyakorlatilag az ő általa kitalált elvet nem nagyon sikerült eltalálnia és talán az a framework állt hozzá a legközelebb :)

BlackY

Nagyon más a szerver-oldali mvc és a desktop mvc, továbbá sokan keverik a 3 rétegű architektúrával. Mivel a framework vendorok is gyakran különböző dolgot értenek rajta, így aztán teljes a káosz. A módosított változataival (MVVM, MVP) meg aztán főleg :P

--
CyclonePHP

Na igen. Az en interpretaciom teljes egeszeben a Ruby on Rails MVC-ertelmezeset veszi alapul, a frameworkomet a Rails-hez hasonlo szempontok alapjan probaltam felepiteni, itt-ott meg szerkezetileg is kozelitve hozza. Az elv bizonyitott mar sokszor, szoval annyira azert nem egy elszallt dolog...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hi!
olvasgattam, es igazabol en is most tettem ossze egy sajat elgondolast erre!
Valojaban az en valasztasom az volt, hogy megirtam az mvc -t de kicsit mvvm lett belole :)
szoval van egy modellem ami jelenleg vagy van vagy nincs, mivel az sqlbol visszakapott assocc tomboket sok esetben modelnek tekintem es json formaba alakitom. A controller az egyertelmu szamomra ami valojaban egy jol csoportositott muveletgyujtemeny. Amit a templatekhez hasznalok az a phpsavant.com -n elerheto template motor, amiert van az meg az, hogy itt phpban tudom leirni a meg ide kikerulo logikat (ami jelen esetben mvvm miatt igen keves). Ehhez kliens oldalon jquery + knockoutjs -t hasznalok, utobbinak a binding resze nagyon jo es pont ezt kerestem.
szoval a template a html leirason kivul kb. adatok atadasara szolgal.
A header, footer dolgokat a kontrollerbol visszakapott objectbol szedem ki, hogy kell e, igy az ajaxos csak adatkeresek is itt tudnak jonni, mivel a controller tudja magarol, hogy mit csinal. A menu detto, es bekerult nalam a headerbe.
Ha van ra igeny es idom ma holnap szivesen atteszem valami free repoba, akar hasznalat akar megvizsgalas vegett.

szép napokat
zsömi

szerk: termeszetesen css is van a kodban :D + mysqlbol jonnek az adtok de ez igazabol mindegy is

Érdekelne. :)

Lassan, de biztosan haladok egy sajat framework irasaval ( sajnos nincs tul sok szabad idom ezzel foglalkozni ), remelem jo iranyba. Igyekszem helyesen "dolgozni", hogy az elejen szokjam meg azt, hogy nem ganyolok ( nagyon nagy a kisertes ), annak ellenere, hogy egy kissebb-kozepes projektet ganyolva hamarabb el lehet kesziteni ( a mellekhatasairol nincs ertelme beszelni, mert elegge evidens ).
Eleg sok kerdes merul fel menetkozben es nehez konkret valaszokat talani, mert mindenki maskepp csinalja :). Az egyik kerdes amire nem talaltam konkret valaszt/peldat az az lenne, hogy:
adott ugye pl. egy termek controller, save metodussal, a mentes ugy tortenik, hogy a form action -je az APP/product/save - abban szinte mindenki egyetert, hogy a redirect a controllerben van, tehat mentes utan jo lenne atiranyitani az APP/product/item?id=NEW_PROD_ID -re - ezzel sincs gond, de mi van akkor ha szeretnem azt is megoldani, hogy pl modositok egy termeket es mentes utan ne tortenjen semmi ( vagy esetleg egy TRUE/FALSE erteket teritsen vissza ) mivel a product->item -bol egy AJAX hivassal tortenik a modositas?
A valasz egyszerunek tunik, legyen pl egy save_AJAX{ .... return $error; } fuggveny is, de ez mar szerintem a ganyolas kategoria, mert akkor ugyanarra funkciora ket fuggvenyem is van. Valami javaslat? Mennyire elegans parameterben atadni a mentes tipusat ( pl &type=AJAX ) es a metodus ennek fuggvenyeben kezli az atiranyitast/visszateritesi erteket?

Az ajax hívást a header alapján a framework routing részének kéne lekezelnie. Konvenció alapján a normál hívásnál $product->saveAction, ajaxnál $product->saveAjaxAction hívódjon meg.

Nem!

Az oldal legyen transzparens, es a logika dontse el, mit kell tenni. Tehat, ha nekem van egy save action-om, akkkor azon belul lehet/kell eldonteni, mi tortenjen, valahogy igy:

if(!$request->isAjax()) {
  header('Location: /products/item?id=' . $product->id);
}

Ezzel ugyanis nem kell kodot duplikalni (peldaul fogadok, hogy a saveAjax es a save kodja 98%-ban megegyezik.

Egyebkent erdemes lehet ajax keresnel egy sima ures json tombot (print "{}") visszaadni, nehany js framework szereti felreertelmezni az ures outputot.

Egyebkent, ha mar MVC es szep URL-ek, legyunk REST-ek; valamint az akcio ne save legyen, hanem create es/vagy update, ehhez kapcsolodoan erdemes lehet a PUT/DELETE metodusokat is kezelni (figyelve az ezt nem tamogato bongeszokre is, peldaul egy _method magikus POST valtozo kezelesevel).
A save ugyanis nem biztos, hogy egyertelmu.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nézd én nem tudom ki vagy, de amiket ide írni szoktál az alapján nekem nincs kedvem veled vitatkozni.De.. Egyáltalán nem traszparensebb egy szétiffelt kódrészlet, mint egy funkciókra bontott. Duplikációról szó sincs, a közös részek kiemelhetők. De éppenséggel a duplikációnak is lehet létjogosultsága. Mindegy! Ha esetleg megtennéd, hogy a jövőben nem reagálnál arra, amit írok, azt megkösszönném, cserébe ígérem én sem fogok arra, amit te írsz! Oké?

Rendben van, bar szerintem osszekeversz valakivel.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

+1 REST-nek lenni jó ;)
+1 jobb ha egy save metódus van csak és annak a belsejében van szépen logikusan lebontva, hogy milyen típusú kérés esetén mi történjen.

________________________________
blog: http://horvathjanos.wordpress.com

Csak kíváncsiságból kérdezem, hogy miért jó ez neked, és miért nem használsz egy kész framework-öt, Laravel, Codeigniter, CakePHP vagy valami hasonlót? Direkt magad akarod összerakni, hogy tanulj belőle, vagy valami speciális feladatra kell?

________________________________
blog: http://horvathjanos.wordpress.com

Koszonom a fenti valaszokat, de ez igy nagyon sokat nem segitett, mert tobben tobbfelet allitanak :)) . Szvsz mindkettojuknek igazuk van valamiben:
- BehringerZoltan megoldasa elegansabb
- hrgy84 allitasa pedig "saveAjax es a save kodja 98%-ban megegyezik" igaz

Tobb oka van, hogy miert akarok sajat framework -ot:
- tanulas ( nincs nagy gondom a PHP -vel, turheto kodokat irok, de nem az igazi ... szeretnek "by the book" dolgozni ( kar, hogy nincs ilyen konyv :)) )
- mivel kesobb fel szeretnem ezt hasznalni, ezert: security by obscurity es sebesseg ( sokan panaszkodtak a nagyobb framework -okra, hogy egy kicsit lassuak )

Értem, világos, a tanulás részét támogatom is, és valahol a többit is.-

Volt idő, mikor én is írtam magamnak dolgokat, hosszú időket töltöttem vele, de egy idő után beláttam, hogy nem éri meg sajnos sem anyagilag sem máshogy. Persze a kész dolgok közül nem ész nélkül kell használni mindent, hanem csak tényleg azt és oda ahová éppen való.
Igazából mivel kerülni akarod a gányolást, és rendesen OO akarsz maradni így szép munkát tudsz végezni, csak sajnos tényleg sok idő és energia az ilyesmi.

________________________________
blog: http://horvathjanos.wordpress.com

Nagyon sok idot meg tudnak takaritani, ha talalnak egy jo konyvet/leirast, rengeteg peldaval. Az a gond, hogy szazan szazfelet mondanak, nincs egy standard. Nem talaltam olyan cikket ami reszletesen leirna mit/hogy/miert, csak alapkoncepciokat gyenge peldakkal, ami annyira jo, hogy egy form -bol ments a DB -be es olvass onnan. Ha ennel tobbet akarsz tudni, akkor bizony sokat kell keresni es utanajarni. Sajnos.

Hát igen, ingyen semmit nem adnak, na de tanulás szempontjából ez valahol jó is így, legalább rendesen beleásod magad. :)

________________________________
blog: http://horvathjanos.wordpress.com

A problema az, hogy ez nincs jol igy. Pont ebből fog születni ezer meg ezer egymással inkompatibilis es/vagy elganyolt megoldas. Az, hogy a 0. lépésre vannak példák, de ahhoz nincs dokumentáció, hogy mik a rendszer mögötti koncepciók es útmutatás arra, hogy hogyan hozzunk letre *jol* komplex rendszert, az nem oda vezet, hogy legalább megismeri a fejlesztő a rendszert, hanem többnyire oda, hogy megoldják a problemat valahogy... Na a valahogy részével szoktak lenni a gondok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Tobbek kozott ezert is megy ennyire lassan a fejlesztese, mivel a gondokat nem "valahogy" szeretnem megoldani ( pedig mint mar mondtam, sokkal egyszerubb lenne - most ) es mert ezen kivul van sok mas dolgom. Mielott nekifognak valaminek az implementalasaba jol meggondolom, hogy jo a kezdeti elkepzelesem vagy sem. Szerintem nagyon fontos, hogy annyira bontsuk szet amennyire csak lehet es csak nagyon kis mertekben fuggjenek egymastol a funkciok, mert ha elb***ok valamit, akkor ne kelljen a fel projektet urjairni.
Egy nehany honapon belul lesz egy >=kozepes nagysagrendu munka, amiben ezt mar fel szeretnem hasznalni, remelem addigra a koncepcio eleri _nagyjabol_ a vegleges formajat amire aztan lehet epiteni.

Elarulok egy titkot: sosem lesz teljesen jó. :)

Mindig lsez, ami nem jo valamire vagy van ra jobb megoldas vagy szimplan az adott feladatra nem alkalmas. En tobbek kozott ezert is hagytam fel anno a sajat CMS-semmel az idohianyon kivul.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Látod most bőven egyetértünk! (legalábbis remélem, hogy te is így gondolod)

Én azt mondom, ami kész framework-ök vannak azok közt van egy-kettő de legalább egy ami megfelel általában jópár problémára, és biztos talál az ember olyat is, ami speciálisabb helyre kell, esetleg nagyon minimal fw. mondjuk egy nagyon alap MVC + REST kombó és semmi több, vagy csak még minimálisabb ha csak olyasmi kell.
Nagyobb feladatokra, meg tényleg nem éri meg sajátot fejleszteni hónapokon át, hogy aztán a végére kezdhessük előröl, mert támadt jobb ötletünk, születtek új igények stb. Ráadásul valahol kidobott idő is, és felesleges szívás is lehet. Annyi mindent kellene szem előtt tartani, hogy saját jó fw vagy cms-t írjunk, hogy az már nem éri meg.

________________________________
blog: http://horvathjanos.wordpress.com

Egyetertek veletek, DE:
Nagyon basic framework -ot keszitek, semmi kulonleges. Amit el szeretnek erni, az az, hogy legyen megfelelo session kezeles ( valaszthato DB vagy file ), log -ok ( akar SQL -t is logolja, ha ugy akarom ), megfelelo error handling ( ne kapjak 500-as hibakat, hanem ertheto hibauzenetet generaljon ), fajlkezeles ( torles, feltoltes, image resize, thumb generalas, stb ), tudjon tobb nyelven ( pl. egy ini fajl hozzadasaval "tanuljon" ), generaljon pdf -et, kezelje az AJAX hivasokat megfeleloen ( JSON ), legyen jol megirva az absztrakt resze ( nem akarom ismetelni magam,pl. egy nehany kulonleges esetet kiveve a save("table",$object) az mentsen el szinte barmit, ACL, e-mail kezeles ( ennek meg nem ugrottam neki, valoszinu, hogy phpmailer lesz ).
Mint emlitettem, ugy probalom elkesziteni, hogy ha utkozben meggondolom magam valamivel kapcsolatban, akkor ne kelljen ujrairni csak egy kissebb reszet.
Ha rajovok, hogy barom voltam es semmit sem er, ez van. Legalabb tanultam 1-2 erdekes dolgot.

Ez mind-mind olyan probléma, amit már jól-rosszul megoldottak. :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, ez igy van. Viszont ha en csinalom, akkor _BIZTOS_ , hogy ertem mikent es miert mukodik ugy ahogy, gyors, nincs tele haszontalan fuggvenyekkel, stb stb.
Sok idom ramegy, de _NEKEM_ megeri. :)

A PHP mogott pont koncepciok nem nagyon vannak, hanem "csinaljuk meg valahogy" alapon van osszerakva az egesz. A C API-k fole 1:1 reteget huztak (talan SWIG csinalna ilyet...), van negyfele elnevezesi konvencio, a parameterezesre nincs is semmilyen... szoval ezt igy nehez megideologizalni. Meg lehet, persze, csak iszonyat nehez. Hianyzik az egeszbol a rendezoelv.

--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

sub
>>A Linux olyan mint az asszony, már fogalmad sincs miért választottad.<<

Nem tudom, hogy van-e ertelme egy ujabb temat letrehozni, ezert inkabb ezt folytatom ( naaagyon lazan kapcsolodik a temahoz ).

Verziokezeles: hogyan?
Nem arra vagyok kivancsi, hogy hogyan kell egy uj projektet letrehozni X verziokezelovel, mivel el tudok olvasni egy how-to -t. Amit szeretnek tudni, hogy ti hogyan kezelitek(kezelnetek) a folyamatot.
Jelenleg ketfele munka van nalunk: egyszemelyes ( a webdesign -t is egyszemelyesnek tekintem, mivel 1 szemely elkesziti a PSD -t, 1 HTML/Joomla/etc. template -be pakolja stb ... a lenyeg, hogy egszerre inkabb csak 1 valaki dolgozik rajta ) es tobb szemelyes ( adott egy app - pl. vtiger -, ahhoz kulonallo modulok, mindenki a sajat moduljat feljeszti ).
Az egyszemelyes projektet nem bonyolult kezelni, a masodik esethez kapcsolodik inkabb a kerdes.
Jelenlegi helyzet: van egy webszerver amin tobb web app van, ha irodabol dolgozunk akkor NFS, ha nem akkor SSHFS -el mount -oljuk a projekt konyvtarat ( pl. /var/www/projectX/ ) es mindenki vegzi a maga dolgat. Ha meg szeretnenk mutatni valamit a kliensnek akkor keszul egy masolat a publikus konyvtarba ( /var/www/public/projectX ) vagy pedig egy masik szerverre.
Ezzel a modszerrel addig semmi gond nincs, amig egy app -ot egy kliensnek adunk, de most mar kezd valtozni a helyzet. Tobb app es 90% -ban megegyeznek, szoval mindenkepp el kell kezdeni verziokezelest hasznalni.
Hasznaltam mar SVN -t Java projektekhez ( oda megfelelo volt ), de ez mar egesz mas eset.
Ami jo lenne:
- hasznalhato legyen NetBeans -el
- ne sokat valtoztassunk a jelenlegi proceduran
- legyen gyors a kezelese ( ne kelljen minden save utan commit -olni ahhoz, hogy ervenyesuljon a modositas a web szerveren is )
- ne kelljen mindenkinek sajat webszervert hasznalnia
- ne rohadjon le ha egy projekt tartalmaz 10k+ fajlt

Elozo minden nkahelyemen is es most is ez volt a szisztéma:
- Mindenki saját gepen fejleszt, esetleg helyileg van közös db (kb. 20-30 gb-k)
- Webserver es minden helyileg (mgj.: Windowson, csak hogy bonyolódjon a helyzet)
- SVN
- Az éles oldal mellett van egy játszótér, ahol mar az utolsó teszteket lehet végezni, de nem fejleszteni.
- Az éles oldal es a teszt is SVN-hol frissül. (Pontosabban nehany script mar kore van építve, amely az SVN-t hivja)
- Frissítés minden esetben kézi, sose tudunk bele csak ugy az éles oldalba.
- Szukseges doksi, design, stb szinten megy verzikezelesbe.

Persze, mi most egy saját oldalt tartunk karban (pontosabban van tobb is, de azok pici kiegészítő dolgok), de tobb nagyobb oldalt is igy frissitettunk rendszerint az előző munkahelyemen. (Ez egyebkent hihetetlen mod leegyszerűsítette es meggyorsitotta a frissítést.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

- Központi fejlesztő szerver, rajta LAMP, Git, FTP. Ide kerülnek be a fejlesztés alatt lévő oldalak/alkalmazások meg minden, megy be a Git-be. FTP nagyon nincs is használva, minden pullolva meg pusholva van normál esetben és kész.
RAID-be vannak a vinyók, és időközönként még egy plusz vinyóra készül mentés.

- Mindenki aki dolgozik a saját gépén végzi a munkát. A gépeken van egy git kliens. Elkészül a munka kezedetén a repó a szerveren, beállítja magának mindenki a gépén, és nyom egy pullt. Innentől kezdve lehet dolgozni, mindenki kommitol meg pushol pullol.
Mindenkinek a gépén van apache, mysql, php, és beállított saját virtual host kezelés. Adatbázis mysql esetén viszont közös a fejlesztő szerveren ott nem megoldott a verziózás, csak backup van, avagy sql dump. Erre valami okos ötlet jó lenne.

Mikor kész a fejlesztés és a tesztszerveren minden lezárult, az ügyfél is átnézte használta kipróbálta, és minden oké, akkor kerül fel az oldal a végleges helyére. A tesztszerveren az oldalak publikussága a fejlesztés stádiumától függően változik, persze ha vége és az éles helyen van már akkor htaccess letiltás + keresők elől elrejtés megtörténik.

Nem tudom, lehet kihagytam valamit, talán nem..

________________________________
blog: http://horvathjanos.wordpress.com

NFS-t/SSHFS-t surgosen felejtsetek el, mert igy felesleges a verziokezelo kb. Csak egy momentum: race condition, ha ket kulonbozo ember ugyanazt a konfig fajlt akarja modositani. Az alkalmazas - a konfigtol fuggoen - akar ervenytelen allapotba is kerulhet a kozos munkaterulet miatt.

A sajat webszerver amugy miert gaz? Mind Windowsra mind Linuxra konnyu felrakni egy apache-t, es ha a webapp konfigja nincs verziokezeles alatt az mar eleve egy nagy fekete pont. Raadasul pont apache-n konnyu branchelni a konfigot windowsra es linuxra.

"ne kelljen minden save utan commit -olni ahhoz, hogy ervenyesuljon a modositas a web szerveren is"

Ti nem akartok verziokezelot hasznalni. Ez eleg nagy problema lesz a verziokezelo bevezetese soran.

Szoval ennyit a "ne sokat valtoztassunk a jelenlegi proceduran" pontrol.

Lassuk mi az, amit en ertelmes konfignak tartok, itt-ott figyelembeveve a szempontjaidat.

En Gitet hasznalok, es ezt is ajanlom. Aki akar, tud lokalban fejleszteni, lokalis webszervert rakni hozza, etc. A lokalis branchek miatt mindenkeppen ajanlott kategoria, sot, lehetoleg mindenki kulon branchen dolgozzon, es egy ember feleljen a development es egy a master agba torteno mergelesert. A ket ember lehet egy is, de megbizhatonak kell lennie - vagy projvezetonek
A jelenlegi csapatnak kell az okitas, mert nem csak a commitra kell odafigyelni, hanem a pushra is - de egyebkent ezek szerintem megugorhato lepcsofokok.

A szerveroldal:

- Webszerveren mindenkinek kialakitani egy vhostot, melyek a verziokezelt konfig alapjan epultnek meg, es kizarolag a DocumentRoot, CustomLog, ErrorLog, ServerName apache valtozok tekinteteben ternek el.
- Ha apache es mod_php, hasznaljatok mod_itk -t, mindegyik fejlesztonek dedikalt vhost az adott fejleszto userevel fusson. Ha FPM, akkor minden fejlesztonek legyen sajat workere, pm=ondemand beallitassal.
- Minden fejleszto kap egy ssh user accot a szerverre, hogy kedvere tudjon branchokat checkoutolni
- Legyen egy cron script, ami adott idokozonkent (pl. 2 perc) elnyom minden vhoston egy git pull -t.

A kliensoldal:
- SSH kliens (Putty, vagy beepitett)
- Git kliens (NetBeans-ben van), Windowson a GIT_SSH kornyezeti valtozot be kell allitani a plink.exe utvonalara
- Mindenki kulon branchen fejleszt (erdemes lehet topic brancheket hasznalni, itt irtam ossze, hogy nalam mi valt be. Ehhez azonban az szukseges, hogy 1 feature-n mindig csak 1 vagy nehany fejleszto dolgozzon (akik konnyen ossze tudjak egyeztetni a munkajukat)
- Amikor befejezte a fajl(ok) szerkeszteset, commitol egyet, ha vegzett a feature osszerakasaval, pullol es pushol is (ebben a sorrendben, mert az esetleges konfliktusokat fel kell oldani - viszont a Git ezt eleg intelligensen kepes megoldani az SVN/CVS-hez kepest), keves esetben kell kezzel kozbeavatkozni.
- Vagy kivarja a 2 percet, amig a szerveren automatan lefrissul a cucc, vagy kezzel nyom egy pull-t, hogy ervenyesitse a valtozast
- Teszteli, stb.
- Amikor oda jut egy feature, hogy keszen van, akkor azt a develop aghoz kell mergelni (erdemes a szerveren erre kulon vhost-ot kialakitani, amihez ugyan senkinek nincs hozzaferese, de automatikusan frissul gitbol), es kuldeni egy korlevelet, hogy legyen kedves mindenki rebase-lni arra az agra
- Amikor eljut elesitesig a projekt, akkor a develop agra nem mergelunk tobb feature branchet, csak hotfixeket, ezeket addig, amig az eles rendszer ossze nem all
- Az elesites soran eloszor a develop agat raeresztjuk a master agra, ez lesz az uj eles site alapja
- Elesites soran a master agat valaki kezzel lepullozza a valtozasokat a master agbol. A tobbi az alkalmazas elesitesi procedurajatol fugg.
- Nagyon figyeljetek arra, hogy az elesen direktbe ne modositsatok semmit. Ha megis szukseg van az eles site apro modositasara (nem valtozhat feature! Azt vegig kell vinni a cikluson!) akkor csinaljatok a master-bol egy hotfix branchet, es ez a branch legyen visszamergelve mind a develop, mint a master branchbe, ezzel elkerulve, hogy a kovetkezo elesites soran nagymerteku konfliktusokkal kelljen foglalkozni.

Szoval ez az, amit igy alapvetonek tartanek egy jo fejlesztesi folyamat kialakitasaban. Azonban van nehany buktato:
- Be kell tanitani az embereket, nem csak a Git, de a verziokezeles alapjaiba is. Ez mental change-t jelent, ami nem lesz egy egyszeru folyamat, erdemes lehet projvez segitseget kerni, sokszor csak hatalmi szoval lehet ezeket attolni.
- Meg kell ertenetek, hogy a verziokezeles mire valo, es miert jo. Ne csak a backup celjara hasznaljatok verziokezelot, vagy azert mert a projvez igy latja, hogy ki mit csinalt (az egyikre backup szoftvert javaslok, a masikra pedig ticketrendszert). Azert hasznaljatok verziokezelot, mert verziokezelni akarjatok az alkalmazast. Epuljon be a fejlesztesi folyamatokba.
- Igyekezzetek nem koztes allapotokat fenntartani. Ne legyen olyan, hogy ezt verziokezeljuk, azt nem. Legyen egy jol definialt ido, amikor nincsenek fejlesztesek, csak a verziokezelesre valo atteres van. Nem kis munka, meg egy egyszerubb projektnel sem, 2-3 napot siman tervezzetek ra, az idealis az 5 nap.
- Sem a Git sem az SVN nem igenyel kulonosen hatalmas ismereteket, de mindenkeppen legyen rendszergazdai oldalrol is tamogatas a valasztott verziokezelohoz (azaz a rgazda ismerje valamennyire).

Elnezest, hogy ilyen hosszu lett. De az ilyesmirol konyvek szolnak, szoval annyira nem is hosszu... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Koszonom a kimerito valaszod! At fogom ragni magam rajta.

Meg annyit tennek hozza - mar nem tudtam, hova illesszem be - hogy a feature brancheknek mindenkepp szerveren kell lenni, hogy mindenki hozzaferjen - a sajat brancheknek viszont nem szuksegszeru.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal