WebPillangó főoldal

Oldalak: 1 [2] 3 4 ... 10
 11 
 Dátum: 2012. 08. 08. - 21:13:01 
Indította Tupacko - Utolsó üzenet: írta spier
Üdv,

@Tupacko: Rendben, ha lesz időm készítek egy doksit és átküldöm.

Lehet egyszerű a probléma amivel szembe találtam magam de egy hibás variációnál anniyra leragadtam, hogy nem tudok tovább lépni.
3 táblát szeretnék összehozni.
1: arak: id, box_id, tab_id, nev, ar
2: tab: id, box_id, nev
3: box: id, nev

A célom az lenne, hogy a boxok maga az egység ami magában foglalja a többi elemet. Ezt vmi foreach szerkezettel szépen amennyi box van körbejárom, "box" tábla.
A következő cél, hogy minden box tartalmaz tabokat. jQuerys-t tab gondolom nem kell túlságosan részleteznem. Vannak fülek és az alatta lévő tartalom változik a fülre kattintva, "tab" tábla.
Eddig még alapvetően elég könnyű is. Box, benne tab és a tab-nak lehet több füle is. Tartalmat hozzárendelek az adott tab fülhöz és az jelenik meg ha átkattintok.
Viszont minden tab tartalma egy ugyan úgy foreach szerkezetes "arak", ahol egymás alá van feltüntetve a név-ár páros és mind ez a megfelelő box-on belül a megfelelő tab tartalmához rendelve.
Tehát körbe kell járnom az összes box-ot, tab-ot és árakat és mindezeket a megfelelő helyre helyezni.

Ötlet esetleg vkinek? Táblákat össze tudom így kapcsolni, hogy aztán foreach-el végigjárjam? Vagy egymásba ágyazott foreach és tömbbe vele? Esetleg külön tömbbe mind és kiíratásnál adjam a feltételek?

Üdv.

 12 
 Dátum: 2012. 06. 12. - 07:15:11 
Indította Tupacko - Utolsó üzenet: írta Tupacko
Remek, ha tesztelt dolog es jol mukodik, akar irhatnal egy vendeg bejegyzest is a WebPillangora, roviden bemutatni a keretrendszert es leirni a te megoldasod a problemara. Biztosan sok fejtorestol megkimelned az utanad kovetkezoket Mosolyog

 13 
 Dátum: 2012. 06. 10. - 14:26:53 
Indította Tupacko - Utolsó üzenet: írta spier
Köszi a választ, ennyi elég is volt a cache-hez. Ha esetleg valaki használná a programot:

Az Introduction szerint (http://twig.sensiolabs.org/doc/intro.html) a következő a Basic usage felépítése:
Kód:
require_once '/path/to/lib/Twig/Autoloader.php';
Twig_Autoloader::register();
$loader = new Twig_Loader_Filesystem('/path/to/templates');
$twig = new Twig_Environment($loader, array(
    'cache' => '/path/to/compilation_cache',
));

$template = $twig->loadTemplate('index.html');

echo $twig->render(array('name' => 'Fabien'));

A következő fájlok és API kiegészítéssel dinamikusan generált oldalakhoz is tudunk egyedi cache tartalmat generálni.
Beépített metódust nem találtam ennek meghatározására.

1. /path/to/lib/Twig/Environment.php fájlhoz hozzáadjuk a következőt:
Kód:
public function setKey($value)
    {
        $this->loader->setKey($value);

return $this; // Fluence interface
    }

2. /path/to/lib/Twig/Loader/Filesystem.php fájlhoz hozzáadjuk a következőket:
Kód:
protected $key;

    public function setKey($value)
    {
        $this->key = $value;
    }

3. Itt módosítjuk a már meglévő metódust erre:
Kód:
    public function getCacheKey($name)
    {
return $this->findTemplate($name).':'.$this->key;

        // return $this->findTemplate($name);
    }

4. Az Basic API a következő lesz (fluence-t használtunk az egyszerűsítéshez (return $this)):
Kód:
require_once '/path/to/lib/Twig/Autoloader.php';
Twig_Autoloader::register();
$loader = new Twig_Loader_Filesystem('/path/to/templates');
$twig = new Twig_Environment($loader, array(
    'cache' => '/path/to/compilation_cache',
));

$template = $twig->setKey('egyedi_azonosito_az_adott_oldalhoz')->loadTemplate('index.html');

echo $twig->render(array('name' => 'Fabien'));

Az egyedi azonosítót letárolhatjuk adatbázisban vagy előállíthatjuk valamelyik szegmensből vagy a teljes url-ből például, fontos, hogy adott oldalhoz mindig ugyan az a kulcs legyen, így biztosított az egyedi cache tartalom.

Mosolyog

 14 
 Dátum: 2012. 06. 10. - 11:29:38 
Indította Tupacko - Utolsó üzenet: írta Tupacko
Cache: szvsz rossz az, ha csak a sablon neve alapjan keszul a gyorsitotar. Biztosan van valami beallitas/bovitesi lehetoseg a keretrendszerben, amit hasznalsz. Ha nincs, akkor vagy megprobalod kiboviteni vagy mas utan nezel. A velemenyem ugyan az, mint a legutobbi valaszomban.

Routing: a WP-nel tudott a routing szerkezet es a bejegyzesek egy bizonyos sablon szerint kerulnek kiertekelesre. A lenyeg ott csak annyi, hogy az URL minimum 1 resze legyen egyedi azonosito a posztra nezve, a tobbi dolog nem szamit. Nem is teljesen MVC rendszer, szerintem, igy kar is osszehasonlitani. Mas-mas a cel. A te esetedben az jelentene egy megoldast, hogyha az os-osztalynak lenne egy alap routing kezelese, amit felul lehetne irni/be lehetne injektalni. Tobbfele design pattern is van erre, pl. itt jol mukodne a strategy. Miert segitene ez? Azert mert igy a kontrollerek tobbsege menne az alap controller/action/args elven, ahol a controller-t a keretrendszer keresne ki, az /action/args meg menne tovabb a controller routing megoldo strategiajanak. Ez alapbol szepen kivalasztana az action-t es az argumentumokat. A kapcsolat kontrollerben lehetne egy sajatos routing kezeles, ami kivalasztana a megfelelo szegmenseket es asszerint kezelne a lekerdezest.

 15 
 Dátum: 2012. 06. 09. - 23:23:09 
Indította Tupacko - Utolsó üzenet: írta spier
Szia.

Nem fogalmaztam megfelelően részletesen, kibővítem így a kérdésemet.
Routing:
Készítettem egy alap MVC keretrendszert és ehhez kapcsolódóan esetemben a controller/method/args koncepciót használom. Opcionálisan ez lehet még a language/controller/method/args felépítés is. Eddig világos és érthető is. Az első szegmens a domain után a controller. Megkeresem a megfelelő controller fájlt és osztályt a kapott paraméter alapján. Ha nincs második szegmens akkor jön az alap index metódus, ha van, akkor az lesz a kért metódus. Az args egy tömb lesz, amiben 1-től szerepelnek a kapott értékek a 3. szegmenstől felfelé, ha üres akkor null.
Ez a része teljesen egyértelmű, rengeteg tutorial található light mvc-vel.
A problémám ott van, hogy ha adminban elmentek egy új oldalt, tételezzük fel Kapcsolat néven, akkor a controller itt a KapcsolatController osztály lesz a fájl neve pedig KapcsolatController.php - természetesen névterekkel egyszerűsítünk így csak Kapcsolat osztály és Kapcsolat.php lesz. Ebben az osztályban a konstruktorban meghatározom a kapcsolódó modell és egyéb előre beállítandó dolgokat. Itt adom meg pl. milyen helpereket töltsön be. Tételezzük fel nem adtam meg neki további szegmenst így az index metódus meghívódik, és a végén a sablont kezelőnek átadom a változókat egy tömbben, meghatározva némi egyéb paraméterrel.

A gondom ott kezdődik mikor többszintű szegmens struktúrát akarok dinamikusan felépíteni.
Tételezzük fel az adminisztrációs felületen megadom hogy a Kapcsolat legyen az oldal, de további szegmenseket is meghatározok, mint pl cég a második szegmens és a harmadik pedig a dolgozól. Az url esetünkben a következő lesz www.valami.hu/kapcsolat/ceg/dolgozok.
Talán már érted is a gondomat. A controller a kapcsolat mert a koncepció adott a kapott adatok dinamikusak, de én nem a ceg metódust akarom meghívni és nem egy dolgozok paraméterrel hanem egy kapcsolat controllert de mint oldal tartalom a dolgozókhoz tartozó rekordot adja be az adatbázisból. Mivel dinamikus a dolog így ha még további 3 szegmenst megadok akkor legyen az utolsó előtti szegmens a metódus és az utolsó egy id, de a köztes szegmensekkel 2. 3. ne foglalkozzon. És ezekkel össze vissza lehessen manipulálni. Nem tudom mennyire érthető a dolog, egyáltalán kivitelezhető-e. Valahogy a joomla vagy wp-ben is megcsinálták. De nem tudok rájönni miként.

Cache:
Mivel sok jó sablon kezelő van és ki is próbáltam párat a Twig mellett tettem le a voksomat jelenleg. Egyrészt mert jónak tartom a Symfony-t és hát ezt is ők készítik továbbá jó sebesség és kezelhetőségi paraméterekkel rendelkezik.
Mindegyik sablonkezelőnél azonos volt a problémám így továbbiakban, hogy Twig vagy más nem foglalkozom.
Ahogy láttam fájlnév alapján generálódik a cache tartalma és mappaszerkezet mindenhol.
Esetemben van egy DefaultController ami olyan oldalakat klezel amit dinamikusan hoztak létre adminból, tehát nem tartozik hozzá külön controller osztály és fájl stb. Itt a betöltött tartalom a controller alapján megy tehát a kiválasztott DefaultController hozza, de az első szegmenst alapján kapom/kérem az oldalra az adatokat megjelenítésre. Tehát ha pl. /kapcsolat akkor a kapcsolat oldalt hozza, ha /szolgaltatasok akkor a Szolgáltatásokhoz felvitt tartalmat hozza be de a controller mindig a default nevű. Más ötletem nem volt, hogy a dinamizmust megtartsam és szabadon lehessen oldalakat létrehozni mindenféle névvel.
Mivel azonos a controller mindig így azonos a sablon fájl is csak $content az adatbázisból kapott tartalomtól függően változik.
És itt a probléma. Mindig ugyan az lesz a cache generált fálnév és mappaszerkezet és azt hiszi hogy változik valami. Jól is gondolja mert változott, de nem tudom megmondani neki hogy ez új oldal azért változott ne cacheld hanem ami megvan azt töltsd és mindig rátölti a default.tpl-ből létrehozott fájlra az újat. Tehát mindig frissíti a cache-t, mivel a sablon nem változik csak a lekért tartalom.
Remélem jól körül írtam a dolgot. Vagy, hogy mire nem tudok rájönni.

Előre is köszi a segítséget, útmutatást Mosolyog.

 16 
 Dátum: 2012. 06. 09. - 15:57:25 
Indította Tupacko - Utolsó üzenet: írta Tupacko
Szia!

Az MVC routing kerdessel kapcsolatban, ez keretrendszertol fugg. Lehet, hogy a "kapcsolat" controller elfogad barmilyen hosszu parameter sorozatot, amit pl. egy tombben kap meg az alap action es akkor sajat routing rendszert hasznalhat, hogy eldontse mire van szukseg.

A cache problemaval kapcsolatosan, nem az szamit, hogy milyen template-bol van generalva, hanem hogy milyen requestre felel, mi a tartalom. Sot, lehet reszleges gyorsitotarazas is, pl. miden azonos fej- es lableces oldalnak csak 1x tarolod a kozos reszeket, a tartalmi reszt meg kulon-kulon. Cachelesre is van kismillio rendszer, ismetelten keretrendeszertol vagy weblodal motortol fuggoen.

Udv,
Tupacko

 17 
 Dátum: 2012. 05. 25. - 19:42:20 
Indította Tupacko - Utolsó üzenet: írta spier
Lenne egy cache-el kapcsolatos kérdésem is.
Maga a cache egy nem túl bonyolult feladat. Adott a sablon fájl amit betölt és ezt lementi cache-be ha van változás vagy adott idő után újratölti a cache tartalmát és azt tölti be.
Igen ám, de mi van ha dinamikusan tudok létrehozni oldalakat adminisztrációs felületen, tehát van pl. egy default.tpl nevű sablonom és az alap odalakat ahol csak a tartalom változik - tehát dinamikusan adminból létrehozol egy sima szöveges oldalt -, akkor ez itt fog megjelenni ezen a sablon alatt, csak mindig más szöveget tölt be. De ezzel a megoldással nem tudok cache-t alkalmazni mivel a template mindig ugyan az, csak a tartalmi rész változik. mindig újratölti a cache-ben a fájlt, mert azt hiszi változott valami - változott is. De a gyorsítótárazás így nem működik.
Ötlet esetleg ennek megvalósítására?
Van pár lehetőség amiben gondolkoztam:
1. Ne legyen dinamikus lap minden betölthető oldalnak külön template (ezt azért mégse).
2. Valami egyedi azonosítót létrehozni minden oldalnak és ez hozzáfűzni a cache token-hez.
3. Az egész koncepció hibás ahogy felépítem az oldalt...
4. Generálok egy alap fájlt adott néven minden oldal létrehozáshoz (ez azért elég kucig).

Nézegettem Joomla és Wordpress motorokat, de nem sokra jutottam vele.

Köszi a segítséget. Mosolyog
Üdv.

 18 
 Dátum: 2012. 05. 25. - 08:13:48 
Indította Tupacko - Utolsó üzenet: írta spier
Hello.

Kicsit elakadtam az mvc routing-al. Van esetleg valakinek ötlete, hogy többszintű linknél, miként válasszam ki és adjam meg a betöltendő oldalt és a többi paramétert?
Ugyebár az alap formájában most van a:
www.valami.hu/controller/action/id és ezt ki lehet egészíteni egy www.valami.hu/nyelv/controller/action/id formára.
Ez eddig nem is nehéz. Viszont ha többszintű szerkezetet akarok dinamikusan arra nincs "elegáns" ötletem.
Tehát hol a controller/action/id hol egy /controller/szegmens/szegmens/action/id struktúra kellene stb. stb.

Alap koncepciónál a www.valami.hu/kapcsolat -nál a kapcsolat a controller az action meg index mert az üres hozza az alapot, és lekezelem.
De ha szeretnék olyat, hogy a www.valami.hu/kapcsolat/negyedikemelet/harmadikszek akkor a controller a kapcsolat de a le kellene követnie a többi értéket is ami még nem az action és az id hanem egyéb paraméter és csak ezután jön az alap index action.

Üdv.

 19 
 Dátum: 2012. 05. 11. - 00:30:57 
Indította Tupacko - Utolsó üzenet: írta liptakrobi
Hmm... köszi.

 20 
 Dátum: 2012. 05. 09. - 18:20:53 
Indította Tupacko - Utolsó üzenet: írta Tupacko
Egyreszt a spam vedelem mas tema. Masreszt a

Kód:
SELECT * FROM `termek`,`csoport` WHERE `termek`.`cs_id` = `csoport`.`id`

az is join, csak nem irod ki explicit. Ez annyi mint egy full inner join.

Ha dinamikusan akarsz kategoriakat is hozzaadni, akkor sokkal lassabb lesz, mint ha a tabla szerkezete elore ki lenne gondolva. Ez azert tortenik, mert a lekerdezeshez meg kell talalni azt is, hogy mi alapjan tortenik majd a lekerdezes. A flexibilitas es a gyorsasag egy egyenes ket kulonbozo pontjan helyezkednek el. Az alkalmazasod lehet nagyon flexibilis, de kevessbe kepes kiszolgani nagy terheles, vagy szuper gyors de nehany megkotessel.

Idézet
ez ezer autónál akár 20 ezer soros 2 es táblát jelent

20 ezer sor semmi manapsag, ebbol ne csinalj gondot. Inkabb az a gond, ha 1000 auto utan van 20 ezer sorod. Ott valami elkepzelheto, hogy egyszerusitheto meg.

Oldalak: 1 [2] 3 4 ... 10