Új hozzászólás Aktív témák
-
cucka
addikt
Gondoltam hogy valaki bele fog kötni. De azonkívül, hogy globális változó mi a baj vele (vagy az is bőven elég)?
A $_POST, $_GET, $_SERVER stb. szuperglobálok tulajdonképpen a szkripted bemeneti adatai. A php engedi a változtatásukat, de annak semmi hatása nincs, tehát célszerű szigorúan bemeneti adatként kezelni.
Ha például nagy rendszerben piszkálod ezeket, akkor később (amikor használni szeretnéd) gondot okozhat, hogy a tömb tartalma nem egyezik meg a júzer által beküldött adatokkal. Természetesen 50-100 soros kis szkripteknél teljesen mindegy, csak jó nem rászokni a gányolásra
.(#3435) Tele von Zsinór
Igazad van, a Session kivétel, meg mondjuk a Cookie is. Általában a lényeg, hogy ha egy bemeneti paraméter módosításának nincs semmilyen következménye (leszámítva önmagát az értékadást), akkor ne módosítsuk. -
#3442
cucka
addikt
Sk8erPeter
#3438
cucka
addikt
válasz
Sk8erPeter
#3438
üzenetére
De mondjuk ez biztonsági szempontból kicsit kevés ellenőrzésnek, nem? De más gépről hogyhogy működhet ugyanaz a Session ID?
Szerintem fogj egy komolyabb könyvet és olvasd el, hogy hogyan működik a php session kezelése.
Úgy működhet ugyanaz a session_id, hogy senki sem ellenőrzi, hogy a kliens gépnének nem-e változott az ip címe vagy a user_agent-je. Ha biztonságos rendszert szeretnél, akkor ezt a kettőt ellenőrizni kell.a feltörésnél igazából még az nem tiszta, hogy ha tételezzük fel megvan az md5-hash-ed, akkor abból miért nem lehet visszafejteni az eredeti jelszót, ha mindig ugyanazon az algoritmuson alapszik a hash legyártása.
Azért nem lehet visszafejteni, mert nem lehet visszafejteni. Ilyen a hash algoritmus, ez a lényege, hogy egy irányú. A pontos válaszok nagyon túlmutatnak ezen a topikon, ez a téma a doktori disszertációk és egyetemi kutatások szintje, teljes megértéséhez elég komoly algebrai ismeretek szükségesek. Amúgy ha érdekel a téma, kezdésnek nézd meg az rsa algoritmusát, a wikin például le van írva, hogy pontosan hogyan működik és miért nehéz visszafejteni. -
#3443
cucka
addikt
Sk8erPeter
#3440
cucka
addikt
válasz
Sk8erPeter
#3440
üzenetére
Hogyan tárolsz képet az adatbázisban?
Például a mysql-ben a különböző blob típusú mezők erre vannak.Valószínűleg azért ajánlják mindenhol a link tárolását az adatbázisban, mert csak azt lehet megcsinálni.
Nem. Azért ajánlják, mert sokkal egyszerűbb megcsinálni.ha valaki megcsinálná azt, hogy mondjuk egy jpeg képnek a szerkesztőben látható tartalmát tárolná el adatbázisban, majd úgy hívná elő, hogy abból jpeg-kép szülessen, akkor hááát igencsak ki lehetne nevetni
Én már megcsináltam párszor, kezdhetsz nevetni.Ott adatot tárolsz, nem konkrétan fájlokat, majd ezeket előhívogatod, ahol szükséged van rá.
Egy file tartalma is adat. -
cucka
addikt
válasz
8nemesis8
#3441
üzenetére
Nevezzük a filmek táblát film-nek, a kölcsönzés táblát kolcsonzes-nek. A kölcsönzésben tároljuk el egy mezőben, hogy a kölcsönzés lejárt-e. (Ez azt jelenti, hogy a filmet visszahozták.)
Ekkor a következő query lesz jó:
select * from film
where not exists
(select * from kolcsonzes
where kolcsonzes.lejart=0 and kolcsonzes.film_id=film.id
)A lejárás feltételét úgy tárolod, ahogy akarod, nyilván a rá vonatkozó feltételt eszerint kell megadni, itt a példa kedvéért a legegyszerűbb megoldást választottam.
[ Szerkesztve ]
-
#3463
cucka
addikt
Sk8erPeter
#3445
cucka
addikt
válasz
Sk8erPeter
#3445
üzenetére
És milyen célból? Nekem elsőre kicsit feleslegesen bonyolultnak tűnik, persze biztos valamilyen szempont nem jutott még eszembe.
Nagy php-s keretrendszer, magas szintű absztrakcióval. Röviden: a file feltöltés ugyanolyan űrlap elem, mint a szöveges, checkbox, legördülő, stb.. Az űrlap elemeinek lehet értéke, az értéket el lehet menteni adatbázisba, tehát a file feltöltéssel felvitt bináris adatot és a szöveges mezőbe beírt szöveget egyenrangúan kezelem.
Amúgy előnye például, hogy az adatbázisban található az összes adata a weboldalnak. Adatbázis automatikus mentése könnyen megoldható, az import/export is egyszerű, tehát ilyen előnyei vannak. Nem kell foglalkozni a filerendszer sajátosságaival, nem kell tudni, hogy melyik könyvtárban vannak a képek, nem kell odafigyelni, hogy különbözőek legyenek a filenevek, nem okoz gondot több százezer kép tárolása, ilyesmi. Természetesen figyelni kell a sebességre, ezért készült hozzá filerendszer alapú cache-elés is.
Ebben a topikban főleg apróbb, egyszerű programokról van szó, ennek a módszernek az előnyei pedig inkább nagy rendszerekben érvényesülnek.(#3446) 8nemesis8
Igen ilyesmire én is gondoltam, de hogyan állapítom meg, hogy visszahozták e!?
Például a visszahozás dátuma az adatbázisban alapértelmezésként NULL. Ha visszahozták, akkor beállítod az aktuális dátumot. MySQL-ben a null-ság ellenőrzését valahogy így oldod meg:
select * from tablanev where mezonev is null
select * from tablanev where mezonev is not null -
#3464
cucka
addikt
Sk8erPeter
#3452
cucka
addikt
válasz
Sk8erPeter
#3452
üzenetére
Ne szerencsétlenkedjé' már..
$nap_hu=array('hétfő', 'kedd', ... 'vasárnap');
$nap_en=array('Monday', 'Tuesday', ... 'Sunday');
$datum=str_replace($nap_en, $nap_hu, date('Y-m-d l H:i')); -
#3465
cucka
addikt
Sk8erPeter
#3462
cucka
addikt
válasz
Sk8erPeter
#3462
üzenetére
Ha a 0-t számnak tekinted, akkor a kódod nem jó, ugyanis az empty() a 0-ra és az üres tömbre is boolean true-val tér vissza. Jelen esetben empty helyett isset-et kéne használni.
(#3460) PazsitZ
Extract() függvény használata nagyon nem javasolt, ugyanolyan okokból, ami miatt a register_globals használata sem. Ha ilyen sok változóról van szó, akkor érdemes egy tömbben felsorolni azokat, majd ez alapján beállítani az összes változó értékét, például így:$elfogadott_nevek=array('nev1, 'nev2', 'nev3');
foreach ($elfogadott_nevek as $nev){
if (isset($_POST[$nev])){
$$nev=$_POST[$nev];
}
} -
#3469
cucka
addikt
Sk8erPeter
#3468
cucka
addikt
válasz
Sk8erPeter
#3468
üzenetére
Itt tulajdonképpen akkor csak arra kell figyelni, hogy a MySQL-kapacitást ne lépd túl.
A korábban említett nagy rendszereknél a mysql kapacitás nem kérdés, ugyanis jellemzően saját szerveren üzemeltek. Átlag párezer forintos webhosting szolgáltatáshoz (mondjuk 1-2 giga tárhely, 100 mega mysql) értelemszerűen ez a megoldás nem igazán jó.Egyébként meglévő adatbázisnál hogyan lehet megnézni, még meddig terpeszkedhetsz?
Passz. Én írnék egy mailt a szolgáltatómnak ezügybenA több százezer kép tárolása adatbázisban mennyivel foglal ilyen módon több/kevesebb helyet?
Nagyjából ugyanannyit foglal, mint külön file-ként. Amire oda kell figyelni, hogy ha select-nél a bináris mezőt is kéred, akkor az nem a leggyorsabb, komoly adatforgalmat generál a szkripted és a mysql adatbázis között. Ezért készítettünk annak idején cache-t is hozzá, ami a filerendszerbe pakolta le a fileokat. Sőt, olyan is volt, hogy az adatbázis és a cache külön gépen futott. -
cucka
addikt
válasz
8nemesis8
#3472
üzenetére
Igen, a kölcsönzés táblában az összes film összes kölcsönzése szerepel, tehát egy filmhez több kölcsönzés is tartozhat, viszont azok közül legfeljebb egy olyan van, ami nyitott. Ennek a feltételnek a teljesülését a php programodnak kell biztosítania, például úgy, hogy ha egy filmre létezik nyitott státuszú kölcsönzés, akkor nem vihetsz fel újabbat addig, amíg le nem zártad az előzőt.
A #3444-ben írt példa lekérdezést direkt úgy írtam, hogy ezt a fenti dolgot tudja: a film kölcsönözhetőségét az dönti el, hogy létezik-e rá nyitott kölcsönzés vagy sem.Ha egy filmből több példányod van, akkor is meg lehet oldani egyszerűen. Például a film táblában ekkor lesz egy példányszám meződ, a film pedig akkor kölcsönözhető, ha a filmre vonatkozó nyitott kölcsönzések száma kisebb, mint a filmhez tartozó példányszám.
-
cucka
addikt
Elvileg a trim-es és a #3505-ben írt preg_replace-es megoldás is jó kéne legyen, kipróbáltam és mindkettő működik.
Debugoláshoz szerintem irasd ki az összefűzött stringet a fölösleges "OR" leszedése előtt és után, hátha kiderül belőle valami. (Bár megmondom őszintén, fogalmam sincs, milyen probléma lehet vele, elvileg jó kell legyen a kód.Amúgy én általában tömbös megoldást használok erre a problémára. Tudom, kicsit lassabb, viszont talán egyértelműbb:
$tmparr=array();
foreach($categories as $category=>$value){
$tmparr[]="intCategory LIKE '%".$value."%'";
}
$categorytext=implode(" OR ", $tmparr);esetleg egy egyszerű ellenőrzéssel:
foreach($categories as $category=>$value){
$categorytext.="intCategory LIKE '%".$value."%'";
if ($category!=end(array_keys($categories))) {
$categorytext.=" OR ";
}
} -
cucka
addikt
válasz
pumatom
#3534
üzenetére
Például lerakod a session-be azokat a képeket, amelyeket már megnézett a júzer.
A kódod utolsó négy sora így fog kinézni:
$imglist = explode(" ", $imglist);
if (isset($_SESSION['viewed_images']) && is_array($_SESSION['viewed_images']) && count($_SESSION['viewed_images'])<count($imglist)){
$imglist=array_diff($imglist, $_SESSION['viewed_images']);
}else {
$_SESSION['viewed_images']=array();
}
$random = array_rand($imglist, 1);
$image = $imglist[$random];
$_SESSION['viewed_images'][]=$image;A kód azt csinálja, hogy ha eddig kevesebb képet nézett meg a felhasználó, mint a képek száma, akkor a képek tömbjéből kivonja a már megnézett képek tömbjét, különben az eredeti képekből dolgozik. Ha a felhasználó már az összes képet látta, akkor a megtekintett képek tömbjét nullázni kell.
-
#3553
cucka
addikt
chubby1980
#3551
cucka
addikt
válasz
chubby1980
#3551
üzenetére
Nem kavar be valami javascript? Az űrlap action-je hova mutat?
Azért furcsa a hiba, mert ha egy php (vagy bármilyen) weboldalt bepakolsz egy frame-be, akkor az a php kód nem is tudja, hogy ő frame-ben van. (Ennek sok kellemetlen következménye van, például ha az egyik frame-ben sikeresen bejelentkezel, a többi frame tartalma erről nem fog értesülni, tehát trükközni kell) -
#3556
cucka
addikt
chubby1980
#3555
cucka
addikt
válasz
chubby1980
#3555
üzenetére
Elképzelhető, hogy a hibás html kódod okozza a problémát. Html-ben a paraméterek értékeit dupla idézőjelek közé tedd, például így:
<form action="valami.php" method="post">Ja, és ezután rögtön kiírattam a $_request-et és ott azt írta, hogy a request method nem post, hanem get.....
A $_REQUEST az egy tömb és nincs benne az, hogy a request method post vagy get-e, pontosan az a lényege, hogy gyakorlatilag nem több, mint a get, post és cookie tömbök összefésülve. (Amúgy meg attól, hogy a request method post, még lehetnek url paraméterek..) -
cucka
addikt
Lehet hülye kérdés de nem tudom hogy hogy érted hogy a kettős pontnál darabolom!
Van egy ilyen sorod, hogy "alma:körte:barack", az elemek kettősponttal vannak elválasztva, a cél kinyerni a 3 gyümölcs nevét ebből a stringből. Nézd meg az explode() függvényt, erre van kitalálva.mod: látom, közben kaptál kész megoldást
[ Szerkesztve ]
-
#3589
cucka
addikt
Sk8erPeter
#3588
cucka
addikt
válasz
Sk8erPeter
#3588
üzenetére
A session-ös megoldás szerintem teljesen megfelelő erre a célra, mivel alapvetően pontatlan látogatószámlálást szeretne az ügyfeled, ezért nem érdemes ezt túlbonyolítani. Úgy oldanám meg, hogy eltárolom a session-ben, hogy rögzítettem-e az aktuális felhasználó látogatását. Ha igen, akkor nem csinálok semmit, ha nem, akkor lerakom az adatbázisba a látogatást és beállítom a session-ben, hogy a látogatást rögzítettem.
-
#3592
cucka
addikt
Sk8erPeter
#3591
cucka
addikt
válasz
Sk8erPeter
#3591
üzenetére
Túlbonyolítod.
function store_user_visit(){
if (!isset($_SESSION['user_visit_stored'])){
mysql_query("insert into user_visit (ip_addr, visit_date, visit_time) values ('{$_SERVER['REMOTE_ADDR']}', '".date('Y-m-d')."', '".date('H:i:s')."')");
$_SESSION['user_visit_stored']=1;
}
}[ Szerkesztve ]
-
#3596
cucka
addikt
Sk8erPeter
#3594
cucka
addikt
válasz
Sk8erPeter
#3594
üzenetére
Akkor ha a konkrét látogatószámra vagyok kíváncsi, akkor csak annyi, hogy csökkenő sorrendbe rendezem a sorokat, és simán kiolvasom az első találat id-jét?
Azt semmiképp, ugyanis nem garantált, hogy az id számozása 1-től kezdődik és az sem, hogy nincsenek benne lyukak. Valami hasonlót inkább:
select count(*) as cnt from user_visits;Tehát a $_SESSION['user_visit_stored'] még véletlenül sem maradhat 1-ben korábbi látogató miatt, ugye?
Nem tudom, mit értesz korábbi látogató alatt. A session akkor szűnik meg, ha
- a php kódban megszűnteted
- timeout-ol (általában 10-30perc szokott lenni). Ez gyakorlatilag azt jelenti, hogy lejár a session cookie.
- a felhasználó törli a session cookie-t, például úgy, hogy bezárja a böngészőt.[ Szerkesztve ]
-
cucka
addikt
válasz
Odiepapa
#3604
üzenetére
2. hogyan tudom visszafejteni a kodot egy esetleges jelszoemlekezteto email kuldese alkalmaval?
Sehogy. Az a lényege, hogy nem lehet visszafejteni.3. Ti hogy oldjatok meg a jelszoemlekeztetot, ha esetleg nem fejtitek vissza a kodot?
Értelemszerűen sehogy. Ha nem tárolod el a jelszót, akkor nem küldhetsz jelszóemlékeztetőt, ehelyett mondjuk kérhet a felhasználó egy új jelszót, amit megkap email-ben.Azert kerdezem, mert egyre jobban parazok a jelszolopasok miatt.
Annyira azért nem kell, a jelszavakat nem így lopják.hogy a session-be belepeskor betoltottem a jelszot is az adatok koze, hogy tudjon valtoztatni rajta (alias lassa a jelenlegit is), de ezt a dolgot kiszedtem, mert attol is parazok hogy a cockie-bol ki lehet preselni ezeket az adatokat.
Nem lehet kipréselni, a cookie-ban csak a session id van eltárolva. Olvass utána, hogy hogy működik a php session. -
cucka
addikt
válasz
Odiepapa
#3613
üzenetére
Viszont egy double hashelest bevetek en is. A jelszoemlekeztetohoz meg kicsit maskeppen/ masmezoben tarolom a dolgokat, hogy vissza tudjam fejteni,
Ennek semmi értelme. Ha szükséged van a jelszóemlékeztetőre, akkor tárold el sima szövegként a jelszót, ellenkező esetben pedig elég a hash.Ujabb biztonsagi kerdes: formbol gondolom keyloggerrel lehet a legegyszerubben kiszedni adatokat
Gondolom egy átlagos weboldalról van szó. Ez esetben a gonosz hackereket egyáltalán nem a jelszó érdekli. Ha én lennék a gonosz hacker és fel szeretném törni a prohardveres felhasználói fiókodat, akkor nem a jelszavad érdekelne, hanem bármilyen más módszer, amivel el tudom hitetni a rendszerrel, hogy be vagyok lépve a te nevedben. Például ellopom a session-ödet, vagy valamilyen sql injection-t használok, ilyesmi.Cucka, megtenned, hogy gyorsan felvazolod ennek a megoldasat?
Már felvázolták. Amikor bejelentkezik egy felhasználó, akkor eltárolod az adatbázisban az ip címét és a user agent-jét. Minden oldallekérés elején ellenőrzöd, hogy változtak-e ezek az adatok. Ha változtak, az azt jelenti, hogy az illető felhasználónak sikeresen ellopták a session-jét, tehát kilépteted és átirányítod a bejelentkezéshez. Továbbá oda kell figyelni arra, hogy az adatok tárolására szolgáló adatbázis táblát karbantartsd, illetve ez a módszer gondot okozhat azoknál a felhasználóknál, akik valamilyen anonimizáló rendszeren keresztül érik el az oldaladat.[ Szerkesztve ]
-
#3628
cucka
addikt
Sk8erPeter
#3621
cucka
addikt
válasz
Sk8erPeter
#3621
üzenetére
az egyes adatmezőknél számít bármit is az, hogy milyen típust határozok meg: VARCHAR, TEXT, stb.?
Igen. Ha nem számítana, akkor miért lennének különféle adatmezők? A mysql manual-ban le van írva szépen, hogy melyik mire jó és hogyan működik.A select count(*) as cnt résznél az "as cnt" csak annyit jelent, hogy a lehívás után cnt-ként hivatkozhatok rá?
Gyakorlagilag az aggregált függvény (count) által létrehozott oszlopot elnevezi cnt-nek, így kulturáltabbal lehet rá hivatkozni. -
cucka
addikt
válasz
Odiepapa
#3623
üzenetére
Ezt a https dolgot minek erőlteted? A weboldalak 98%-a sima http-n megy, talán azért, mert a hálózati adatforgalmat marha nehéz elcsípni és megtalálni benne a jelszót. Nyilván vannak esetek, ahol ettől függetlenül szükséges a https, de gondolom nem banki weboldalt készítesz..
A másik, hogy ha nem igényelsz (pénzért) egy hitelesített cert-et, akkor inkább csak bosszantó lesz az egész a felhasználónak. -
#3805
cucka
addikt
Louloudaki
#3801
cucka
addikt
válasz
Louloudaki
#3801
üzenetére
Egy kis kreativitással meg lehet oldani, hogy villámgyors legyen. Egy n elemű ábécé esetén minden szóhoz hozzá lehet rendelni egy n bites számot, ez alapján lehet keresgélni. Mivel a szótár nagyjából változatlan, ezért az n bites számokat indexelni is lehet, tehát a keresésed elég gyors lesz.
[ Szerkesztve ]
-
#3814
cucka
addikt
Louloudaki
#3807
cucka
addikt
válasz
Louloudaki
#3807
üzenetére
egy többmillió rekordos adatbázisban kb mennyire lesz gyors ha megfelelően van indexelve?
Nagyon gyors lesz, az index miatt.kíváncsiságból kérdem. meg ezt az n bites dolgot hogy gondolod?
Legyen például egy 4 betűs ábécénk, az a,b,c,d betűkkel. A megfeleltetés a következő:
Ha a szóban van a betű, akkor a 4 bites szám első bitje 1, különben 0
Ha a szóban van b betű, akkor a 4 bites szám második bitje 1, különben 0
És így tovább.Például az aaabbb szónak a 0011 fog megfelelni (vagyis az decimálisan a 3-as szám), az acdacd szónak meg a 1101 (decimálisan 13).
Gondolom látható, hogy teljesen mindegy a szó hossza. A feladat arról szólt, hogy olyan szavakat keresünk, amelyek csak a megadott betűket tartalmazzák és a betűk ismétlése megengedett. Az adatbázisban korábban minden szóhoz eltároltuk a neki megfelelő számértéket (a fenti algoritmus szerint). A program úgy működne, hogy a keresett betűkre meghatározzuk a számértéket a fentiek szerint és egyszerűen kikeressük az adatbázisból az ugyanolyan számértékkel rendelkező szavakat. Mivel egy szám típusú indexelt mezőről van szó, ezért a keresés várhatóan villámgyors lesz.
[ Szerkesztve ]
-
cucka
addikt
Sima idézőjelnél a sima idézőjeleket kell escape-elni a szövegben. A változót string összefűzéssel tudod belerakni.
Dupla idézőjelnél a dupla idézőjeleket kell escape-elni. A php a változókat behelyettesíti a szövegbe, tehát nem kell csinálni semmit. Ha nem egyértelmű a helyzet (pl. a változó neve után rögtön betű következik), akkor a szövegben rakd {} közé a változót. Természetesen a string összefűzés is működik. -
cucka
addikt
Egyrészt a termék táblában ott a termék id mezője, tehát nem kell őrizgetni a hozzákapcsolt táblákból a termék_id mezőket.
Másrészt a lekérdezésben meg lehet mondani, hogy milyen mezőket szeretnél kiválasztani. Például:
select termek.*, termek_kep.url, from termek left join termek_kep on (termek.id=termek_kep.termek_id)Ha pedig névütközés van, akkor át tudod nevezni a mezőket. Például ha a termék és a termék_kép táblában is van egy név meződ, akkor az egyiket átnevezed:
select termek.*, termek_kep.url, termek_kep.nev kep_nev from termek left join termek_kep on (termek.id=termek_kep.termek_id) -
#3878
cucka
addikt
Sk8erPeter
#3877
cucka
addikt
válasz
Sk8erPeter
#3877
üzenetére
Amúgy hogyhogy SQLite-ot használsz, és nem MySQL-t? Csak kíváncsiságból kérdezem.
Bár nem engem kérdeztél, de gondolom pontosan azért, mert nem kell hozzá semmilyen adatbázis szerver. (Ugyebár pont ez lenne az sqlite lényege) -
#3880
cucka
addikt
Sk8erPeter
#3879
cucka
addikt
válasz
Sk8erPeter
#3879
üzenetére
Kezdjük ott, hogy abból a téves feltételezésből indulsz ki, hogy a php kizárólag weboldalak készítésére alkalmas. Valójában általános scriptnyelvként is teljesen jó, például százszor inkább ebben írnám a scriptjeimet, mint mondjuk perl-ben.
A másik, hogy nem csak weboldalak használnak adatbázist. Vannak más programok is, amelyek adatbázissal dolgoznak, tehát ha egy adott program SQLite-ban tárolt adataival szeretnél kezdeni valamit, akkor a mySQL-el nem mész sokra.SQLite előnye, hogy nagyon egyszerű, kezeléséhez nem kell semmilyen adatbázis szoftvert feltelepíteni. Mivel file-ként működik (ok, a MySQL is, csak nem ennyire egyszerűen), ezért könnyű vele dolgozni, archiválni, stb. Hátránya, hogy full fapad, kizárólag kis terhelésnél alkalmazható és lassú. Bizonyos feladatokra tehát megfelelő, más feladatokra viszont nem. Ha olyan a feladatod, amelynél az adatokat szöveges file-okban tárolnád, akkor erre ez egy jó alternatíva, ugyanis lényegesen könnyebb használni (írhatsz sql lekérdezéseket pl.), cserébe nem szerkeszthető kézzel.
Pl. egy honlap esetén milyen esetben lehet jobban hasznát venni az SQLite-nak, mint a MySQL-nek, ha feltételezzük, hogy utóbbi szolgáltatás is hiánytalanul rendelkezésre áll?
Semmilyen esetben. A honlapok egyik sajátossága, hogy párhuzamosan sokan használják, tehát olyan adatbázist rendszert érdemes használni, ami erre fel van készítve.[ Szerkesztve ]
-
#3882
cucka
addikt
Sk8erPeter
#3881
cucka
addikt
válasz
Sk8erPeter
#3881
üzenetére
Én ilyet sehol nem állítottam, és még csak nem is gondoltam.
Bocsánat, nekem ez jött lea srác korábbi hozzászólásaiból ítélve azt mertem feltételezni, hogy weblap készítésén munkálkodik.
Lehet, hogy más szoftver által használt SQLite adatbázis adatait is fel kell használnia a weboldal készítésénél. (Vagy mondjuk szinkronizálni a weboldal MySQL adatbázisát az SQLite-al).És mi a gáz a Perl-lel?
Láttál már Perl kódot? . Több helyen úgy hivatkoznak rá, hogy "write only language". -
#3884
cucka
addikt
Sk8erPeter
#3883
cucka
addikt
válasz
Sk8erPeter
#3883
üzenetére
Amúgy tök jó nyelv, jó dolog programozni, csak vannak olyan rövidítései, amelyek miatt nagyon nehezen olvashatóak a perl programok. Odafigyeléssel persze lehet Perl-ben is jól olvasható programot írni.
Ez pont olyan, hogy a php-t is sokan szidják, mert teljes mellszélességgel támogatja a gányolást és a szar kód írását, de szerintem ettől függetlenül odafigyeléssel lehet minőségi php kódot írni. -
#3886
cucka
addikt
Sk8erPeter
#3885
cucka
addikt
válasz
Sk8erPeter
#3885
üzenetére
Hát igen, de végül is minden nyelvben lehet ronda, de működő kódot írni.
Igen, de a Perl kód a különösen ronda kategóriába tartozik. Php-val vagy más átlagos nyelvvel nem tudsz olyan durva dolgokat csinálni, mint amiket Perl-el.Azt még nem tudom, fogok-e valaha Perllel foglalkozni, vagy inkább érdemes-e megtanulni.
Szerintem nem. Amúgy alapszinten könnyen tanulható, az ideális Perl program hossza pedig legfeljebb 1 oldal, tehát ritkán van komoly Perl tudásra szükség.Egyébként most olvasgatok az SQLite vs. MySQL témában, és itt azt hozzák ki, hogy "egyszálú" alkalmazások esetén az SQLite még gyorsabb is lehet.
Abban az esetben lehet gyorsabb, ha a kiadott query-k sebessége gyakorlatilag a diszk sebességétől függ leginkább, ilyen pl. az insert. A MySQL mögött ott egy futó daemon cache-eléssel, tehát olvasásnál szinte minden esetben gyorsabb lesz, mint az SQLite. -
cucka
addikt
Attól függ, hogy mennyi memória van a gépben, mennyire sokan használják egyszerre a php-s szolgáltatásodat illetve hogy milyen egyéb programok futnak a gépen.
Ez a limit egyébként 1 php szál maximális memóriáját jelenti, tehát
- A php annyi memóriát foglal le a scriptednek, amennyire szüksége van. A maximális korlátot azért találták ki, hogy ha egy szerveren több php-s szoftvert is telepítettek, akkor egyik se tudja megenni a szerver memóriáját. (Pl. hosting szolgáltatónál nem fog előfordulni az, hogy egy rosszul megírt kód beakasztja a teljes szervert)
- Miután lefut a script, a php felszabadítja a neki lefoglalt memóriát.
- Ha a php szoftverednek 32 mega memóriára van szüksége, akkor állítsd be úgy. Annyit érdemes beállítani limitnek, ami biztosítja, hogy a futtatott php szoftverek ne fogyjanak ki a memóriából.
- Általában véve igaz, hogy egy bonyolult rendszernél a memóriahasználat leszorítása legalább egy nagyságrenddel drágább mulatság, mint a memóriabővítés a szerverben. Persze, van, amikor muszáj a kódot is átalakítani ehhez, de 32 megás max. memóriahasználat egyáltalán nem tűnik soknak.[ Szerkesztve ]
-
cucka
addikt
válasz
PazsitZ
#3903
üzenetére
Még korábban én is barkácsoltam ilyen rövidítő kódot, de nem olyan egyszerű (még az enyém sincs kész csak félig-meddig ), mondjuk nálam az is szempont, hogy a szövegben lévő tag-ek is érvényesek maradjanak.
Pedig ez nem túl bonyolult feladat, a lényege, hogy szét kell bontani szavakra a szöveget. Kétfajta szó lesz benne: html tag-ek és sima szavak. Ezután végigmész a szavakon és a következő algoritmust használod (kell hozzá egy verem és fontos a sorrend):
- Ha az aktuális szó nem html tag, akkor kiírod az output-ra és növeled a kiírt karakterek/szavak számát.
- Ha az aktuális szó nyitó és záró tag egyben, akkor kiírod az output-ra. (Például ilyen a <br />, aminek nincs záró tag-je, mert már le van zárva).
- Ha az aktuális szó html nyitó tag, akkor kiírod az output-ra és a html tag-et lerakod a verembe. (tehát csak magát a tag-et, az attribútumokat nem). Példa egy veremre: {'span', 'a', 'div'}
- ha az aktuális szó egy html lezáró tag (pl. </div>), akkor kiírod az output-ra és a veremből addig dobálod ki a tag-eket, amíg ki nem dobtad az aktuális html lezáró tag párját.Az iterációnak akkor van vége, ha elfogytak a szavak, vagy a kiírt karakterek/szavak száma elérte az előre meghatározott limitet. Ezután a veremben maradt elemeket kidobálod és mindegyikre kiírod a hozzá tartozó lezáró html tag-et. (Tehát ha a verem tetején egy div tag van, akkor azt fogod kiírni, hogy </div>, ezután pedig kiszeded a veremből.
Az algoritmus pár lényeges tulajdonsága:
- Megőrzi a html tag-eket.
- Csak a képernyőn látható betűket/szavakat számolja, a html tag-eket nem.
- Ha a szövegedben vannak lezáratlan tag-ek, akkor is működik. Ha a szövegben olyan lezáró tag van, aminek nincs nyitó párja, akkor nem működik helyesen, de kiegészíthető, hogy erre az esetre is jó legyen.
- Az algoritmus kimenetében nem lesznek lezáratlan html tag-ek.
- Bizonyos tag-eket a böngészők automatikusan lezárnak (pl. br, hr), ezek felismerésével ki kell egészíteni az algoritmust.[ Szerkesztve ]
-
cucka
addikt
válasz
vakondka
#3905
üzenetére
Mi egy egyedi belső rendszert használunk erre, de amúgy excel-el is nagyon jól meg lehet oldani a feladatot. Egész pontosan mi az, amit nem tudtál vele megoldani?
Amúgy szinte biztos, hogy vannak előre legyártott php alapú projektmenedzsment szoftverek, szóval hajrá .[ Szerkesztve ]
-
-
cucka
addikt
válasz
brunzwik
#3929
üzenetére
Az a baj, hogy amikor a portál rendszered kiírja a menüt, akkor nem állít be target-et a linkeknek, tehát azok a saját frame-ben nyílnak meg. A menü linkekhez egy target="_top" paramétert be kéne valahogy illeszteni a portál által gyártott html-be.
1. megoldás: a portál rendszer ismeri a target paramétert, az általad beillesztett kódba kell egy ilyen sor és kész vagy.
2. megoldás: a portál rendszer nem ismeri ezt a paramétert, a menü kiíró részt át kell írd, vagy esetleg beállítod, hogy a menü minden egyes linkjére ott legyen a target="_top" . (Ez utóbbi nem fogja elrontani az oldalt, klikkelésnél újra fog töltődni a felső banner és ennyi) -
cucka
addikt
válasz
brunzwik
#3932
üzenetére
Jól illesztetted be és nem ismeri, ez látszik az oldalad html kódjában is. (Pusztán annyi van, hogy figyelmen kívül veszi azt az indexét a tömbnek).
Amúgy nem ismerem ezt a portálrendszert, tehát fogalmam sincs, hogy hol kell átírni. Azt kéne megtalálni, hogy hol lesz ebből a menü tömbből html, onnantól egyszerű a helyzet.
-
cucka
addikt
válasz
lamajoe
#3950
üzenetére
Valaki tudna írni egy gyors összefoglalót, hogy mit is kéne tudnom az objektumokról?
Hát a szintaxis magyarázata is legalább 1 fejezet egy könyvben, általában az objektumorientált programozásról pedig rengeteg könyvet írtak. Ne várd el, hogy egy hozzászólásban elmagyarázza neked bárki az egészet. Szerintem vegyél egy könyvet, ahol részletesen le van írva és ha van konkrét kérdésed, akkor arra minden bizonnyal válaszolni fog itt valaki. Még annyit, hogy ha a procedurális programozással nem vagy tisztában (alapvető vezérlési szerkezetek, függvények, stb.), akkor nem érdemes belekezdeni az oop-be.Addig meg van, hogy a class paranccsal hozunk létre egy osztálysablont.
A class egy foglalt szó, nem pedig parancs, és osztályok megadásához lehet használni. A sablon mást jelent. (Php-ben amúgy nincsenek sablonok).Azt olvastam, hogy a var kulcsszóval az osztály összes többi eleméhez hozzárendelhetjük alapértelmezett értékét a változónak.
Nem.
Az osztály képzeld el, mint egy változó típust. Az osztálynak lehetnek adattagjai (vagyis változók) és metódusai (pl. függvények). Arra jó az egész, hogy a logikailag összetartozó adatokat és függvényeket egy helyen tárold. Ezeket adod meg a class kulcsszó után. Ha használni szeretnéd, az osztályt példányosítani kell, erre jó a new kulcsszó, ilyenkor az osztályodból egy konkrét objektum példány lesz.Annak is nagyon örülnék ha valaki felvenne MSN-re, vagy írna PM-et, hogy tudjunk kommunikálni, mert biztos, hogy el fogok még akadni.
Nézd, nem akarlak megbántani, de szerintem senkitől ne várd el, hogy pusztán jófejségből sok-sok órán keresztül megtanítja neked azt, amit bármelyik korszerű php könyvben le van írva. -
#3952
cucka
addikt
Sk8erPeter
#3947
cucka
addikt
válasz
Sk8erPeter
#3947
üzenetére
Mivel lenne olyan max. 6 menüpont, így nem tudom, érdemes-e egyáltalán azonosítószámot rendelni az egyes menüpontokhoz, vagy elég lenne, ha mondjuk lenne két összetartozó elsődleges kulcs, mondjuk PRIMARY KEY (oldal_rovid_neve, nyelv), vagy ez már gagyibb megoldás?
Amiről te beszélsz, azt kompozit kulcsnak hívjuk és jelen esetben igen, gagyibb lenne.Ha normálisan szeretnéd megcsinálni, akkor valamilyen újrafelhasználható megoldásban gondolkozz. Például itt egy táblaszerkezet olyan esetre, amikor 1 menü van az oldalon:
Van egy menü tábla, ahol a menüpontok vannak. A parent_id mező a menü táblában saját magára mutat, így tudsz tetszőleges mélységű menüt létrehozni. A controller mezőben azt tárolom, hogy a menüponthoz milyen tartalom tartozik. (Pl. sima szöveges oldal, kezdőlap, fórum, stb., amire szükség van). A menu_content táblában a menüponthoz tartozó szöveges tartalom található. Nyilván, ha a menüpont nem egyszerű szöveges tartalom, akkor a mezők lehetnek üresek (de pl. a címre szükség van). Ide kerülhet bármi, ami a menüpont függvényében változik az oldalon és nyelvfüggő (pl. fejléc cím, meta tag-ek, utolsó módosítás, vagy amit csak akarsz).Amúgy a menü kérdését én úgy oldottam meg, hogy írtam egy általános fa osztályt, aminek van hozzáadás, törlés művelete, le lehet kérdezni a fa csúcsainak tartalmát, stb.
Írtam hozzá egy serializer interface-t, aminek az a szerepe, hogy feltöltse a fát adatokkal és elmentse a változtatásokat. Írtam még hozzá egy visualizer interfészt, aminek a szerepe, hogy a fából html-t gyártson. Ezáltal van egy olyan fa struktúrám, amit bármire fel lehet használni, a tartalmát tetszőleges helyről tudja beszedni és ugyanoda el is tudja menteni saját magát és tetszőleges módon lehet kiiratni. (A serializer és visualizer osztályokat kell ehhez cserélgetni). Ebből a fából származtattam egy menü osztályt, aminek egyetlen plusz funkciója van, az aktuális url-ből meg tudja mondani, hogy mely menüpont van kiválasztva. Kb. ennyi, ezzel a struktúrával viszonylag egyszerűen bármilyen fa adatstruktúrát könnyen lehet kezelni. (pl. menü, webshop kategóriák, könyvtárstruktúra, stb.).[ Szerkesztve ]
-
cucka
addikt
válasz
lamajoe
#3954
üzenetére
Nem azért akartam felvenni valakit MSN-re, hogy a mentorom legyen, hanem, hogy 1-2 naponta ha elakadok akkor 2 percet szánjon rám, hogy meg tudja válaszolni a kérdésem.
Beírod ide és megválaszoljuk .Bocs, ha a class nem az aminek írtam, valahogy nem érzem a fontosságát annak, hogy a classt a saját fejemben parancsnak vagy kulcsszónak írom le
Szerintem sem érdekes, hogy a te fejedben minek írod le, viszont ha szeretnél megtanulni php-ban programozni, akkor érdemes tudni, hogy a különféle dolgokat hogyan is hívják pontosan. A különféle dokumentációkban és könyvekben az általánosan elfogadott megnevezésekkel fogsz találkozni.
Amúgy olyan, hogy "parancs" igazából nincs is. Általában kezdők hívnak parancsnak bármit, amit begépelnek és ennek hatására a gép csinál valamit, de ezeknek mind van rendes nevük (definíció, deklaráció, függvényhívás, stb.). Például a class az egy kulcsszó, amivel a nyelv egy funkcióját tudod használni, jelen esetben osztályokat tudsz vele definiálni. A kulcsszavak foglalt szóként viselkednek, tehát nem tudsz "class" nevű konstanst, függvényt vagy osztályt létrehozni, viszont változónevet igen. -
cucka
addikt
válasz
lamajoe
#3956
üzenetére
Az érdekelne, hogy ezek mennyire támaszkodnak PHP-re illetve mennyire adatbáziskezelésre?
Nem tudom, hogy egyáltalán php-ban írták-e az említett szoftvereket vagy sem, de az egészen biztos, hogy nem lehet őket megvalósítani szerveroldali programozási nyelv és adatbázisok ismerete nélkül.Csak az érdekelne, hogy mennyire járjam körbe az adatbáziskezelést ha a jövőben ilyet szeretnék csinálni?
Elég komolyan.Érdemes külön könyveket vásárolnom hozzá? Ha igen, milyet?
Passz, gondolom bármilyen könyv megteszi, ami az adott adatbázis szoftverről szól. Webhez mysql-t vagy postgresql-t szokás használni, de azért vannak kivételek.Amúgy szerintem igyekezz kissebb projektekkel foglalkozni. Egy Ikariam színvonalú játék megírásán több profi fejlesztő szokott dolgozni és nem hiszem, hogy bármelyikük rutinfeladatként kirázná a kisujjából.
-
#3963
cucka
addikt
Sk8erPeter
#3960
cucka
addikt
válasz
Sk8erPeter
#3960
üzenetére
A táblakapcsolásokról a képet, amit betettél, milyen programmal generáltad?
Dbdesigner 4 a program neve, ingyenes és néha kicsit bugos. [link]Hmm, hogy érted, hogy magára mutat? Mármint ezt MySQL-utasítások tekintetében hogy kellene elképzelni?
Ugyanúgy, mint ha egy külső táblára mutatna, semmi különbség nincs. A magára mutat alatt azt értem, hogy egy menüpot szülője szintén egy menüpont, tehát a menü tábla parent_id mezője a menü tábla egy másik sorára mutat, vagy nulla ha nincs szülő.Ez igazából csak egy felsorolás, vagy egyfajta leírás magadnak, hogy mi van benne?
Nem, ez mondja meg, hogy az adott menüponthoz milyen típusú tartalom tartozik. Tehát innen tudja a rendszer, hogy ha ráklikkelsz egy menüpontra, akkor szöveges oldal jön be, fórum oldal, kapcsolatfelvétel űrlap, keresési form, stb. Ez az mvc elgondolásból a c betűt jelenti . Amúgy a menü osztályaim struktúrája pont nem mvc stílus, sokkal inkább a hierarchiában található dobozok elgondolásához áll közel. Ezt a kettőt szeretem keverni Tehát ez mindenféle formázást nélkülöz? Mert én arra gondoltam, hogy magát a honlap tartalmát TinyMCE-vel (vagy más JS-es szövegszerkesztővel) lehetne szerkeszteni, és az kerülne bele az adatbázis megfelelő mezőjébe.
Az adatbázis szinten teljesen mindegy, hogy a szöveges tartalmat hogyan kell értelmezni, ez nem az adatbázis vagy a menü dolga. A menu_content táblában a menüpontok nyelvfüggő paramétereit tárolod, az én példámban egy címet, valamilyen hosszú szöveget és egy url-t (a többnyelvű friendly url-ek miatt). Ezeket a mezőket az aktuális feladat szerint kell megválasztani. (Tehát ha az adott honlapon minden menüponthoz kell egy többnyelvű magyarázó szöveg, akkor az is ide fog kerülni)Ez meg ugye nem túl szép, akkor már jobb lenne, ha tart_id és tartalom elsődleges kulcsok lennének, és akkor aszerint lenne rendezve.
Tényleg nem túl szép. Ha egy többnyelvű honlap adatbázisát készíted, akkor legyen egy language táblád, ahol fel vannak sorolva a nyelvek és a többi tábla oszlopai legyenek függetlenek attól, hogy ennek a language táblának mi a tartalma. (Tehát a struktúrád működjön tetszőleges számú nyelv esetén)Az az "url" mező mire kell? Hogy tudj a címre önhivatkozó linket készíteni?
Hogy a menüponthoz tudjak friendly url-t készíteni. Azért van a menu_content táblában, hogy a friendly url többnyelvű legyen. Ha csak 1 nyelvűre van szükséged, akkor ezt helyezd át a menu táblába.A megoldásod, azonbelül a táblaszerkezet és a fa osztály is nagyon okos és rugalmas megoldás.
Igen, a rugalmasság miatt találtam ki. Meg tök jó szemléltetése annak, hogy mire jó az oop, mivel több, mint a sima procedurális gondolkodás.Mellesleg az is eszembe jutott már, hogy simán csak fájlba kellene menteni a tartalmat, amit a felhasználó szerkeszt - vagyis a fájl tartalmát az admin felületen megnyitni, és bedobni egy textarea-ba majd módosításkor felülírni az eredeti tartalmat
Igen, így is lehet csinálni, teljesen jó megoldás. Bizonyos paranoid és/vagy balf*sz rendszergazdák által üzemeltetett szervereken problémásabb megoldás, továbbá nehezebb backup-olni. Továbbá meg kell oldani azt is, hogy ha egy tartalom megtekintéséhez valamilyen jogosultság szükséges, akkor a tartalom file-t se lehessen kintről elérni. (Nem nehéz, csak oda kell figyelni)mert a tartalom várhatóan elég ritkán fog változni, így valószínűleg gyorsabb lenne a megjelenítés.
Nagyjából ugyanolyan gyors lesz.[ Szerkesztve ]
-
cucka
addikt
Ez a két sor bekerült a httpd.conf-ba?
LoadModule php5_module php/sapi/php5apache2.dll
AddType application/x-httpd-php .php
(vagy valami hasonló, netről másoltam . A loadmodule mondja meg az apache-nak, hogy használja a php modult, az addtype pedig azt, hogy a .php file-okat dobja át a php modulnak)Másik megoldás, hogy letöltöd és telepíted az appserv nevű cuccot, ami lényegében egy normálisan beállított apache+php-nak felel meg, nincs benne semmilyen "nem szabványos" cucc.
Oop-t pedig érdemes megtanulni, nagy rendszernél esélyed nincs normális megoldásokat készíteni oop nélkül.
[ Szerkesztve ]
-
#3977
cucka
addikt
Sk8erPeter
#3971
cucka
addikt
válasz
Sk8erPeter
#3971
üzenetére
Jaaaa, akkor már sejtem a parent_id szerepét. Vagyis ez akkor arra való, hogy adott menüpontnak tetszőleges számú almenüpontja legyen?
Igen. Vagyis tetszőleges elemszámú és mélységű menüt lehet vele reprezentálni.
(Sőt, tulajdonképpen tetszőleges mélységű fát lehet vele reprezentálni, tehát nem csak menüre jó, hanem mondjuk webshop termékkategóriákhoz is). Az iskolában nem tanították, hogy hogyan kell gráfokat és azon belül fákat reprezentálni?Na, ez az MVC-szerkezet egyelőre kicsit magas
Pedig eddig is erről volt szó.
Az M betű a modell, ez az osztályaidat jelenti, amelyek általános feladatokra készültek.
A C betű a controller, ez gyakorlatilag az alkalmazáslogika. Itt példányosítod be az osztályokat, itt kezeled le az eseményeket és itt végzed el azokat a műveleteket, amelyek a html kiíráshoz szükségesek.
A V betű a html sablonokat jelenti. Ezekben már nincs alkalmazáslogika, csak html kiírás.De ettől függetlenül valószínűleg mindenképp joinolni kell a language és menu táblát is, hogy ezek azonosíthatók legyenek.
A menü táblához join-olod a menu_content táblát inkább. A language-et csak akkor, ha muszáj.Akkor már nem lenne esetleg jobb/szebb megoldás egy külön összekapcsoló táblát létrehozni erre a célra?
Nem. A menü és a menü tartalom táblák között 1:n típusú reláció van. Ha n:m reláció lenne, akkor lenne szükség kapcsolótáblára. Ezt sem tanították az iskolában?Tehát ha azt mondod, hogy nem lesz gyorsabb attól, hogy fájlból olvasom ki, akkor mindenképp maradok az adatbázisnál.
A file-os megoldás azért jó, mert tudsz olyan oldalt készíteni, amelynél a megrendelő saját maga szerkeszthetik a menüt és a menüpontok tartalmát, mégsincs hozzá szükség adatbázisra. -
#3981
cucka
addikt
Sk8erPeter
#3980
cucka
addikt
válasz
Sk8erPeter
#3980
üzenetére
Most mit kötekszel? Nem arról volt szó, hogy fingom sincs, mi az a gráf vagy fa, hanem arról, hogy jelen esetben Te hogy oldottad meg a gyakorlatban.
Nem kötekedésként írtam. A fa tárolási eljárásom amúgy teljesen szokványos megoldás, nincs benne semmi hókuszpókusz. Azért kérdeztem, hogy tanították-e, mert általában egyetemeken ilyesmiket meg szoktak mutatni gyakorlati órákon, tehát nem kell mindent az alapoktól magyaráznom .A kérdés oka az volt, hogy először úgy képzeltem, hogy a language táblát is azért kell joinolni, mert mondjuk úgy kérdezel le, hogy "... WHERE language.name='en';", és akkor tényleg kellett volna joinolni, mivel akkor különben honnan szeded a nevet?
Egy lekérdezésnél akkor kell bejoin-olni egy táblát, ha szükséged van valamilyen mezőre belőle. A nyelvek kezelését egy nyelvkezelő osztállyal oldom meg, amely a konstruktorában betölti a rendszerben található összes nyelvet. Ha szükségem van arra, hogy a "hu" nyelvnek mi az azonosítója, akkor megkérdezem a nyelvkezelő objektumtól (és nyilván fordítva is, ha mondjuk a 2-es nyelv szöveges nevére van szükség). Így megspórolom, hogy minden egyes, többnyelvű adatot érintő lekérdezésbe bele kelljen join-olni a nyelv táblát is.Igen, viszont így megnő az esélye annak, hogy elcseszi a fájlt, és ha nem ért a HTML-hez, akkor néz, hogy miért nem működik.
Félreértetted. A felhasználó által szerkesztett menü egy xml-ben van, a felhasználó által szerkesztett szöveges tartalom pedig file-okban. Magát a honlap sablonját nem piszkálhatja, egyszerűen csak kap egy fckEditor-t, ahova beírhatja a szöveges tartalmakat. Így nem tud elrontani semmit.Akkor meg már mondjuk az a kérdés is felmerül, hogy miért is ne használjunk adatbázist a saját életünk megkönnyítésére, és alakítunk ki egy jó admin felületet a megrendelőnek, ahol sokkal szebb felületen tudja szerkesztgetni a menüpontokat és a belső tartalmat.
A most említett file-os megoldásom pontosan ugyanazt tudja, mint ha adatbázisból működne a dolog. A korábban említett, oop-s fa reprezentációm pont ezért hatékony, mert a hozzá tartozó alkalmazáslogika, adminisztrációs felület vagy megjelenítés szempontjából érdektelen, hogy adatbázisban vagy xml-ben tárolod a fát/menüt.A file-ban tárolós megoldás azért hatékony, mert sok ügyfél csak egy pár menüpontból álló szöveges honlapot kér. Ezt megfelelő keretrendszerrel ezt 1-2 nap alatt meg lehet csinálni és csak egy php-s tárhelyre van szükség hozzá. Gyakorlatilag csak a html/css részét kell elkészíteni, a többi már kész van, ezért fontos követelmény a programkódnál az újrafelhasználhatóság.
[ Szerkesztve ]
-
cucka
addikt
Azon gondolkodtam a templateengine amit hasznltunk, illetve amit írok anélkül mvc, hogy tudnám jobban mi az mvc, és csak nem is oop.
Egy template engine nagyjából ugyanazt jelenti, mint az mvc view része. Amúgy kevés haszontalanabb dologgal találkoztam eddig, mint a template engine-ek (pl. Smarty). Bár lehet, hogy nem találtam még meg a jó template engine-t.Külön van a megjelenítésért felelős kód, a template-ben csak xml-ek vannak, php nincs, és egyéb dolgokat a php modulok végzik.
Tehát a php és a html közé bevezettetek még egy absztrakciós szintet? Mesélnél erről bővebben, milyen plusz funkcionalitást hordoz?Írnál az mvcről még?
Nagyon sokat nincs mit írni, igazából nagyobb a füstje, mint a lángja. A lényege, hogy külön legyen az adatok reprezentációja és értelmezése (ezek osztályok, segédfüggvények), külön az események kezelése és külön a kiírás. Erre néhány weboldal elkészítése után magadtól is rá tudsz jönni, szóval nem kell túlmisztifikálni, nincs benne semmi extra.
A másik dolog, hogy a szigorúan mvc elgondolás szerintem elég kényelmetlen, fapados, nem eléggé entörprájz, a sokkal magasabb szintű absztrakciót képviselő doboz hierarchia elgondolás közelebb áll hozzám, minél távolabb van a html/css/javascript hármastól, annál jobb . (Valójában keverni szoktam a kettőt, annak függvényében, hogy melyik a hatékonyabb. Például a korábban leírt fa reprezentációm jellemző példa a doboz hierarchiás elképzelésre)[ Szerkesztve ]
-
cucka
addikt
Miért haszontalan? A designernek elég a html kódhoz érteni.
Az adatot meg megkapja.
Eddigi tapasztalataim:
- a dizájner nem tud html/css kódot írni, vagy tud, de az olyan, hogy inkább megírom én helyette
- nincs dokumentálva az oldal minden egyes eleme 100%-os pontossággal
- a pontatlan doksi és a menet közben történt változások folyamatos programozó-dizájner kommunikációt igényelnek, tesztelésnél várni kell a másikra
- a programozó dizájner kommunikáció több időt vesz el, mint ha a programozó megírja maga a html kódot
- a legfontosabb: a sablon csak szintaktikailag különbözik a php+html kódtól, szemantikailag nem. Tehát behozol egy új absztrakciós szintet a rendszeredbe, ami gyakorlatilag semmi másra nem jó, mint hogy bizonyos fogalmakat átnevezzen.Ez utóbbi a legfontosabb ellenérzésem az egésszel kapcsolatban. Gyakorlatilag mindegy, hogy a <modtagcloud> tag-et cseréled le a print_mod_tag_cloud() függvény visszatérési értékére, vagy direktben írod ki azt. Bevittél a rendszeredbe egy nagy, bonyolult, hibalehetőségeket tartalmazó modult, ami annyit tud, hogy a saját szintaxisát lefordítja php szintaxisra.
Ami még problémás, hogy a sablonozás nem igazán felel meg az oop szemléletnek. Hiába vannak objektumaid, azok nem tudják kiírni magukat, pedig pont ez lenne a lényeg, hogy az alkalmazáslogikában az értelmes dolgokkal foglalkozz és az érdektelen dolgok legyenek megvalósítva az objektumban. Ilyen érdektelen dolog a html kiírás.
Tehát ha van egy menü objektumom, akkor az be tudja tölteni az adatait, el tudja menteni az adatait, lehet menüpontot hozzáadni/törölni és ki tudja írni magát html-ben. Az alkalmazáslogikát tartalmazó file-okban nincs semmi, ami a menü belső reprezentációjával kapcsolatos, mint ahogy a sablon file-okban sem. Igazából tök mindegy, hogy az a menü honnan jön, hány szintes, hogyan van belül reprezentálva, ez nem tartozik sem az alkalmazáslogikára, sem pedig a sablonra. Ettől lesz oop-s .
Ennek tükrében az általad említett tagcloud modul az nem egy 100-200 soros lineáris php szkript, hanem egy osztály. Az osztályt példányosítom, felparaméterezem, majd a sablonban szólok neki, hogy írja ki magát. Az osztály hordozható, általános. Ha valamilyen speckó viselkedésre van szükség, akkor származtatok belőle egy alkalmazásspecifikus osztályt, ahol megvalósítom a változtatásokat. Sőt, az ős osztályom származhat egy lista osztályból, ami valamilyen lista kezelésére alkalmas. A tagcloud osztálynál így csak és kizárólag a kiírást kell megvalósítanom, minden más benne van az ősben.
Amúgy tudom, nem csak ezzel az elképzeléssel lehet jól működő weboldalt gyártani, egyszerűen csak jelezni próbálom, hogy az átlag mvc-jellegű megoldásoknál vannak jobbak is .Menünél nem tartom jó ötletnek , ha a user átír egy filet, nagyon nem, elronthatja satöbbi.
Menüszerkesztésnél a júzer nem tudja, hogy mit ír át. Kap egy felületet színes gombokkal, amivel tudja szerkeszteni a menüjét. Az az én dolgom, hogy a változtatásokat file-ban vagy adatbázisban tárolom.[ Szerkesztve ]
-
cucka
addikt
Designer többféle lehet:
Akkor biztos csak nekem nem volt eddig szerencsém a dizájnerekkel.Arra jó az egész, hogy ne legyen a HTML kód phpval teliszórva, illetve fordítva, a php ne legyen htmlel teliszórva.
Tehát a html nincs php-val teleszórva, cserébe tele van szórva sablonkóddal, amihez tartasz egy bonyolult sablonkezelő rendszert csak azért, hogy átfordítsa neked php kódra . Nem azt mondom, hogy szórjuk tele a php-t html kóddal, de az szerintem mindegy, hogy a kiiratásnál php szintaxissal illeszted be a változókat vagy a sablon saját szintaxisával.A sablon, ha XMl alapú, ha bármi el van romolva , akkor vagy a benne lévő szöveget irja ki, vagy tök üres marad a XML element rész és nem is jelenik meg.
Ez előny és hátrány is egyben. Php hibaüzeneteket egyszerűbb azért debugolniHa igy csinalod es a menu nincs db-ben, akkor hogy rendelsz hozza egy menuponthoz pl 10 cikket???? pl. ha ajanlani akarsz valamit?
A menüpontnak van azonosítója, sorrendje, neve, url-je és tartalma. A tartalom mondja meg, hogy mi kerül oda. A tartalom kiiratásnál megkérdezem a menü objektumtól, hogy az aktuálisan kiválasztott menüpontnak mi a tartalma, ez alapján megkérem a megfelelő objektumot, hogy legyen szíves írja ki magát. Elmondva bonyolultabb, mint megvalósítva. -
#3993
cucka
addikt
Sk8erPeter
#3992
cucka
addikt
válasz
Sk8erPeter
#3992
üzenetére
Tessék egy lehetséges megoldás, hogy el tudd képzelni: [link] .
Azért nem másoltam ide, hogy olvasható maradjon a kód. Röviden:
- van egy nyelv osztály, ami a nyelvekkel kapcsolatos funkciókat valósítja meg.
- ebből származtatok egy adatbázisos nyelv osztályt, ami annyit tesz hozzá, hogy az adatokat be tudja olvasni az adatbázisból
- az adatbázis kapcsolat objektumot a $dbconn változó jelenti, ennek létrehozása nincs benne a kódban
- a kód végén van példa 3 fajta példányosításra. Legtöbbször az adatbázisban a nyelv tábla és a mezők neve adott, ezek vannak beállítva default-nak, ugyanakkor meg kell adni a lehetőséget, hogy bármilyen tábla és mezőnevekre is működjön a rendszer.
- írtam bele pár kommentet is, remélem érthető
.
Új hozzászólás Aktív témák
- Yettel topik
- Kormányok / autós szimulátorok topicja
- Milyen videókártyát?
- World of Tanks - MMO
- Futás, futópályák
- Gitáros topic
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- HiFi műszaki szemmel - sztereó hangrendszerek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Vezetékes FÜLhallgatók
- További aktív témák...
