Aktív témák
-
cucka
addikt
azért nem ette meg, mert a return array($valtozo) kifejezéssel létrehozol egy tömböt, aminek a 0-s indexénél található meg a $valtozo értéke, jelen esetben egy újabb tömb. (ez ugyanaz, mint amikor számokból csinálsz tömböt, mondjuk array(1,2,3) )az array_keys lefuttatása a függvény visszatérési értékére, akkor egy darab 0-t fogsz kapni
-
cucka
addikt
-
-
cucka
addikt
rossz oldalról nézed.
a php a get-ben vagy post-ban átadott változókat egyszerű szövegként kapja (a get-nél egyértelmű, mert ott a változók az url-ben találhatók). namost az a php jófejsége, hogy gyengén típusos nyelv, ezért a paraméterként átadott számokat használhatod számként (is), meg hogy a tömbös formából igazi tömböt csinál, de a ''false'' string-el nem nagyon tud mit kezdeni, ezért az bizony marad string, aminek a logikai értéke igaz.
tapasztalatok alapján célszerű mindig kiírni az összehasonlítást az if feltételében, jelen esetben mondjuk if ($valami===true). a php nem típusos nyelv, ezért az ilyesmire bizony oda kell figyelni, cserébe rugalmasabban kezelheted a változókat, csomó nyűgtől megszabadulsz.
egyébként a php minden hibát kiírhat, error reporting beállítás kérdése. függvény paramétereinek pedig megadhatsz típust és hibát fog dobni, ha más típusú paraméterrel hívod meg.
[Szerkesztve] -
cucka
addikt
két nap után legfeljebb azt a következtetést vonhatnád le, hogy nagyon nem értesz ahhoz, amit épp fikázol.
lássuk csak: php-ból kiírsz egy html/js kódot, ami nem úgy működik, ahogy szeretnéd. hol van a bug a php-ban? ha notepad-al írod ki ugyanazt a html/js kódot, akkor az is bugos, mert szar kódot írtál?
egyébként érdemi segítség reményében esetleg megmutathatnád nekünk is, mi nem működik. -
cucka
addikt
megpróbálhatsz valami olyasmit is, hogy a gomb onclick-jére kötöd rá az eseményt. ha az ellenőrzés sikertelen, akkor természetesen return false. ez egészen biztos kell működjön.
Mostmár kezdem érteni, a php-ban nem csak bugos scriptet lehet írni, hanem már maga a nyelv is bugos.
erre a következtetésre a html formokkal és a javascript-es submit-al történő küzdelem során jutottál? na de komolyan, milyen bugot találtál?
-
#4589
cucka
addikt
Tele von Zsinór
#4587
cucka
addikt
válasz
Tele von Zsinór
#4587
üzenetére
sehogy. vicces is lenne, ha kliens oldalról csak úgy meg lehetne hívogatni a php fileokban található függvényeket
-
-
cucka
addikt
-
cucka
addikt
és a session-ba tárolni a ilyen modon az információkat menniyre biztonságos?
eléggé
És a megjeleníthető fájlok nevét tárolom el ( szabad.php ; szabad_2.php) ey tömben) és oldalhívásnál megnézem szerepel -e a fájlnév a tömben és már kész is?
bármit eltárolhatsz. mondjuk $SESSION['user']['jogok'] tömb, aminek az elemei sima stringek. a védett file tudja, hogy milyen jog kell a megjelenítéshez (például 'adatbázis adminisztráció'), és megnézi az adott tömbben, hogy van-e olyan eleme. valójában mindegy, hogyan jelölöd a jogokat (számok, stringek, filenevek), a lényeg, hogy a védett file el tudja dönteni a session alapján, hogy a júzernek van-e joga őt megnézni.
[Szerkesztve] -
cucka
addikt
sikeres login-nál betolod a session-be a júzer jogait is, aztán amikor a kérdéses oldalt szeretné megnézni, akkor kimazsolázod, hogy szabad-e neki. ha nem, akkor die(), hibaüzenet, vagy amit akarsz. ugyanezt csinálod mondjuk a menünél is, hogy ne legyenek ott a júzernek a számára nem elérhető menüpontok.
-
cucka
addikt
namost ha adott idokozonkent kuldesz uzenetet, akkor el kell tarolnod az uziket, majd mikor lefut a frissites akkor selectalsz
igen, ezzel tisztában vagyok
viszont ha nem kened vagod az ajaxot, akkor szerintem nem kene talalgatnod, hogy a beszelgetopartnered mennyire, vagy mennyire nem ert hozza.
nem találgatok (egyáltalán, volt valami sértő abban, amiket írtam? szerintem nem, de ha mégis, akkor elnézést..). ha valaki okosabbnak bizonyul nálam, akkor attól igyekszem tanulni, ennyire egyszerű. ajax-al mondjuk úgy, hogy kevés tapasztalatom van, elsősorban php-val foglalkozok.
písz -
cucka
addikt
tudom, hogy az ajax-nál kliens oldalról indul a kapcsolat, és a kliens kérésére a szerver válaszol, fordítva nem működik. ettől aszinkron ugye..
a folyamatos kapcsolat nem rossz ötlet egyébként, de kérdés, hogy sok felhasználó esetén megéri-e sebesség szempontjából? néhány másodpercenként lekérni sok üzenetet vs. minden új üzenetet elküldeni az összes kliensnek.. sok kliens esetén a fölösleges ajax kérések száma szerintem igen alacsony, talán ezért nem elvetendő dolog az.
(comet-nek meg utánanézek, annyira azért nem kenem-vágom az ajaxot, tehát nem árt tanulni egy kicsit)
lynx-el egyébként szerintem fölösleges foglalkozni, aki azt szeretné böngészésre használni, az megérdemli. -
cucka
addikt
-
cucka
addikt
szerintem manapsag mar ahol van javascript engedelyezve, ott van java plugin telepitve.
tévedés. manapság a javascript minden egyes böngészőben alapból ott figyel bekapcsolva, gyakorlatilag a júzernek semmi dolga nincs vele, elindítja a böngészőt és működik. java plugin-hez el kell látogatni a java oldalra, le kell tölteni, el kell indítani, fel kell telepíteni, szóval csupa olyan dolog, amit a lúzer júzereknek el kell magyarázni, ezen túl egyáltalán nem biztos, hogy a júzer ezt meg is fogja csinálni..
valószínüleg még nem nagyon foglalkoztál ajax-al. a http kapcsolat pont arra lett kitalálva, hogy http request-eket küldözgessünk amire http response érkezik, és pont ez az, ami ajax-nál történik. ez távolról sem nevezhető folytonos kapcsolatnak. ha java applet-el valósítod meg a chat-et, akkor az is pont ilyen http csomagokat fog küldeni/fogadni, mint amilyeneket ajax-al küldenél. a tcp meg nem tudom, hogy jön ide, az alacsonyabb szint, a http a tcp fölött működik.
irc szerver azért nem tutijó megoldás, mert bár sokat tud, illik nagyon ismerni a lelkivilágát ahhoz, hogy klienst írj hozzá. ehelyett lehet saját szerver cuccost írni szinte bármilyen nyelvben (c++, java, satöbbi), lehet, hogy hamarabb megvan. ezen kívül irc-nél gond lehet a kliens oldalon található tűzfallal is, míg ajax-nál ez a gond nem létezik. -
cucka
addikt
java applet-el az a baj, hogy kell hozzá java, ami nincs minden gépen. a véglény-júzereknek pedig elég nehéz elmagyarázni, hogy töltsenek le egy java-t ha chatelni akarnak. pont ezért jobb megoldás az ajax, mert a javascript a böngészők többségén be van kapcsolva. namost lehet szórakozni ajax-os irc kliens írásával, vagy lehet írni saját chat daemont, mindkettő szép feladat
.
a harmadik megoldás lehet mondjuk egy php-ben írt chat szerver, ami lassú ugyan, de hamar kész van és ha okosan van megírva, akkor alacsony látogatottság esetén (értsd: ~100ember) nem fogja két vállra fektetni a szervert. -
cucka
addikt
válasz
CsodaPOK
#4182
üzenetére
Azt gondoltam van egy parancs ami szépen frissítené az oldalt.
szerintem is hagyd egyelőre, ha ilyen kérdéseid vannak. első körben jó lenne megérteni, hogyan működik egy php-s oldal, hogyan kerül bele a böngésződbe a php-s weboldal.
konyhanyelven: amikor a böngésződ lekér egy weboldalt, akkor átküldi az url-t a webszervernek. a webszerver az url-ből kitalálja, hogy te egy php-s oldalt akarsz futtatni, ezért meghívja a megfelelő php filet. a php futás közben csinál ezt-azt és kiírja a szabványos kimenetére a weboldal kódját (html, css, js kódokat). a webszerver a php kimenetéről fogja az adatokat és visszalöki a böngészőnek, amely megjeleníti ezt.
statikus oldalnál annyi a különbség, hogy a webszerver nem hívja meg a php-t, hanem az url-ben szereplő filet felolvassa és visszaküldi a böngészőnek.
namost ha ezt megértetted, akkor rá fogsz jönni, hogy php-ból sehogy sem fogsz oldalt efrissíteni, mert az arra jó, hogy a szerver oldalon végezzen műveleteket és weboldal kódot generáljon. mindent, ami a kliens oldalon történik, javascript-ből kéne megoldani, ami nem nagy tragédia, mondjuk két sorban megcsinálhatod, h x másodpercenként frissítse be az oldaladat.
chat-nél a következő lenne a felállás: a szerver oldalon van egy program, ami eltárolja a beírásokat. mivel a php csak oldalkérésnél fut l egyszer, ezért file-ban vagy adatbázisban kell tárolni a hozzászólásokat. kliens oldalon pedig van egy js kód, ami időnként megkérdezi a szervert, hogy ''heló, jött új üzenet x időpillanat óra? ha igen, küldd át'', valamint ha beírsz valamit, akkor pedig elküldi a szervernek.
van egy '' Building responsive web applications - ajax and php'' című könyv, a Wrox adta ki és ott az egyik fejezetben pont chat-et készítenek, mint példaprogram. a könyv megértéséhez kell némi php tudás, de alapvetően a nem triviális részeket mindenhol elmagyarázzák benne. -
cucka
addikt
uhh, ezt a 'minden sorban kinyitom-bezárom a php-t' technikát honnan lested el? abszolut fölösleges. egyébként most vagy nem értem a problémádat, vagy 1 darab print-en akadtál el.
első körben nem ártana, ha megpróbálnál néha gondolkozni.
if ($sor[''nev''] == '') { } else { print $sor[''nev''];}
itt mégis mi indokolja az if használatát?
valami hasonló kéne legyen a kód:
while ($sor = mysql_fetch_array($eredmeny)) {
...if ($sor['megj']=='') $sor['megj']='_';
...$sor['tel']=str_replace('_', '', $sor['tel']);
...print implode('\t', $sor).''\n'';
}
ez megcsinálja, amit szeretnél, kiírja tabulátorokkal a mezőket, és újsor karaktereket is odarakja. tabulátor helyett azért ír ki csak egy szóközt, mert a böngésző átalakítja - ha azt akarod, hogy ne tegye, akkor használd a <pre> tag-et. file-ba íráshoz print helyett nyilván fwrite-ot kell használni.
[Szerkesztve] -
#4143
cucka
addikt
paramparya
#4142
cucka
addikt
válasz
paramparya
#4142
üzenetére
a szögletes zárójelelkbe 0-9 helyett ofkorz [0-9a-fA-F]
egyébként vajon ez így nem működne?
([0-9a-fA-F]{2}:){5}[0-9a-fA-F]!
(nagyon rég kellett bonyolult regexp-eket írjak, de emlékeim szerint ilyesmi jó kéne legyen)
[Szerkesztve] -
-
cucka
addikt
a fastruktúrához mindegyik elemnek el kell tárolni a szülőjét.
mutatok egy primitív módszert. rekurzív függvény, ami egy tömbbe rendez.
az eredmeny tömbben kapod vissza sorba rendezve az értékeket, a gyökér elem szülője legyen a -1es sorszámú elem, ami nyilván nem létezik. csak nagyjából írom le, a többi remélhetőleg menni fog.
function gyerekkeres($szulo_id, &$bemenet, &$eredmeny){
..foreach ($&bemenet as $csucs){
....if ($csucs['szulo_id']=$szulo_id){
......eredmenybe_kiir($eredmeny, $csucs);
......gyerekkeres($csucs['id'], $bemenet, $eredmeny);
......}
....}
..}
ezt meghívod -1-es szülő_id-ra és jólesz
ekkor az eredmenybe_kiir függvény sorfolytonosan meg fogja kapni a fát, innen úgy írod ki, ahogy akarod. szerintem a referenciákat elrontottam de most nincs energiám kipróbálni a kódot, szóval sok sikert :) -
#4124
cucka
addikt
Tele von Zsinór
#4122
cucka
addikt
válasz
Tele von Zsinór
#4122
üzenetére
igen, a te módszered a fapados megoldás.
az elgondolás az, hogy ha történik egy post-olás, akkor a rendszer találja ki automatikusan, melyik függvényt kell meghívni, amelyik lekezeli az eseményt.
az első, rekurzív megoldásnál maga a form veszi észre, ha elpost-olták, a másodiknál pedig egy olyan osztály, amelyik ismeri az oldal összes formját, és tudja, hogy melyiknek kell továbbdobni a labdát. előbbinél elég sok fölösleges függvényhívás történik, cserébe elegáns, utóbbi ilyen szempontból hatékonyabb, de kell hozzá az a plusz osztály.
[Szerkesztve] -
cucka
addikt
válasz
Protezis
#4116
üzenetére
van egy másik megoldás is. az előbb leírtak helyett itt nem az objektumaid hívogatják egymás feldolgozó metódusait, hanem van egy függvényed/osztályod ami megteszi ezt. feldolgozza a request tömböt, majd az alapján hívogatja az illetékes objektumok feldolgozó metódusait.
ja és az A osztályt link helyett szerencsésebb lehet anchor osztálynak hívni, már csak azért is, mert az a annak a rövidítése.
[Szerkesztve] -
cucka
addikt
válasz
Protezis
#4116
üzenetére
úgy nagy vonalakban.
ha készítesz egy formot, mondjuk 'urlap' névvel, és a form elemeinek a neve 'urlap[elem_neve'![;]](//cdn.rios.hu/dl/s/v1.gif)
formában van, akkor a php van olyan okos, hogy feldolgozásnál a post tömbben asszoc tömböt készít ezekből.
namost minden osztályodnak lehet feldolgozó függvénye, ami kiszedi a $_request-ból a rá vonatkozó részt majd megcsinálja a dolgát, pl. beírja a szükséges adatokat egy mysql táblába. az alapértelmezett viselkedése a feldolgozó függvénynek, hogy nem csinál semmit. feldolgozás után pedig továbbdobja a labdát a hierarchiában alatta lévő osztályoknak. namost neked csak annyi a dolgod, hogy miután felépítetted a weboldalt képező obejktum-fát, elindítod a gyökér objektum feldolgoz függvényét. nyilván ahol valóban történik feldolgozás, azt neked kell megírnod külön, mert nem automatizálható csak speciális esetekre. -
-
cucka
addikt
válasz
Protezis
#4112
üzenetére
igen, úgy látom, hogy részben helyes az elgondolásod. ugyanakkor az elemi html tag-eket is osztályokkal reprezentálni az felesleges pöcsölés szerintem. mittomén, van menü osztályod, akkor miért kell alá berakni az ul, li, a tag-ek osztályait? nem egyszerűbb a menü osztály kiirató kódjában egyszerűen kiírni a cuccot?
.
egyébként van kb. 100 html tag, ezekből olyan 30-40et rendszeresen szokás használni, mindegyiknek akarsz egy osztályt?. ne feledd, ezek még nem jók semmire, ezeken túl kell rengeteg fajta osztály, amit kiraksz.
más - a júzer interakciót (gombnyomogatás) hogyan kezeled le? honnan tudja a rendszer, hogy ha megnyomok egy gombot az oldaon, akkor mit kell csinálni? -
cucka
addikt
válasz
Protezis
#4110
üzenetére
Minden html tagnek irok egy php osztaly
na itt álljunk meg . szerintem itt van elrontva az egész. az oop-nak az a lényege, hogy bonyolult de logikailag összetartozó dolgokat gyűjtsünk osztályokba. egy html tag minden csak nem bonyolult. gondolj bele, mi lenne, ha befejeznéd az osztályokat. a weboldal generálás semmivel sem lenne egyszerűbb, csak ahelyett, hoyg kiírnál egy tag-et print-el, létrehozol neki egy osztályt amivel kiírod. bonyolult kód és borzalmas memóriaigény lenne az eredménye a keretrendszerednek. valid html kódot nem nehéz kézzel írni, ezért értelmetlen ezt ennyire alacsony szinten kezelni és rengeteg energiát elpocsékolni egy olyan probléma megoldására, ami valójában nem is létezik .
mondok egy példát egy értelmes oop-s fejlesztésre. a weboldaladra dobozokat raksz ki, tehát van egy alap ősosztályod. ez nem tud sokat, de ebből származik a többi osztályod. a doboznak van neve, van kiíró függvénye és lehetnek benne további dobozok. a kiíró függvény egyszerűen végigmegy a dobozokon és meghívja a kiíró függvényüket.
namost a feladat, hogy szeretnéd kilistázni egy adatbázis tábla tartalmát. erre írsz egy dbtabla nevű osztályt, ami a dobozból származik. ennek az osztálynak vannak paraméterei (melyik tábla, melyik mezők, satöbbi) és van egy kiíró függvénye ami egyszerűen kiprinteli a táblában található adatokat.
ha az oldaladon ki kell írni egy ilyen táblát, akkor egyszerűen létrehozol egy ilyen objektumot, felparaméterezed és meghívod a kiíró függvényét. na ez pl. olyan absztrakció, aminek értelme is van. sokfajta eleme lehet egy oldalnak (űrlapok, galéria modulok, táblák, menük) de alapvetően mindegyik doboz. az, hogy a menü vagy az űrlap osztályod milyen html kódot generál, az teljesen mellékes. ha jól megcsinálod az egészet, akkor a html kódodban annyit kell csinálj, hogy a megfelelő helyen meghívod mondjuk a menü dobozának a print függvényét és a többit megoldja a keretrendszer.
valamennyire érthető, hogy miért gondolom rossz ötletnek az általad leírtak megvalósítását? -
cucka
addikt
még valami a példa kóddal kapcsolatban, illetve csak hogy tisztázzam, miért tűnik szar megoldásnak a statikus adattagok örököltetése: ha a Foo osztályban megváltoztatod a statikus adattag értékét, akkor az az AbstractContainer-ben is meg fog változni, szóval igazából nem tudom, milyen feladat az, ami ezt ígényli
a foo-ba ez kerül be: public function setChilds($p_childs){self::$maychilds=$p_childs;}
a kiírások előtt pedig $f->setChilds('alma');
próbáld ki.. -
cucka
addikt
válasz
Protezis
#4106
üzenetére
itt egy példa kód, absztrakt osztály statikus adattagjainak felüldefiniálásával kapcsolatban, próbáld ki és nézd meg, miket ír ki, szerintem meg fogod érteni. ha valami nem világos, akkor kérdezz
<?php
//az absztrakt ősosztály
abstract class AbstractContainer{
protected static $maychilds='AbstractContainer::maychilds';
public function getChilds(){return self::$maychilds;}
}
//itt felüldefiniáljuk az ős statikus adattagját
class Table extends AbstractContainer{
protected static $maychilds = 'Table::maychilds';
public function getChilds(){return self::$maychilds;}
}
//itt nem definiáljuk felül az ős statikus adattagját
class Foo extends AbstractContainer{
public function getChilds(){return self::$maychilds;}
}
$t=new Table();
$f=new Foo();
print AbstractContainer::getChilds().'<br />';
print $t->getChilds().'<br />';
print $f->getChilds().'<br />';
?>
mod: az más kérdés, hogy mire akarod ezt használni, esetleg megoszthatnád velünk, hogy milyen rendszert tervezel és miért pont így
[Szerkesztve] -
#4105
cucka
addikt
paramparya
#4103
cucka
addikt
válasz
paramparya
#4103
üzenetére
azért talán nem kéne rászoktatni az embereket az ilyen részletes válaszokra
a php manual pedig pont hogy nagyon felhasználóbarát és könnyen kezelhető. a mysql doksija, na az száraz és érthetetlen..
[Szerkesztve] -
cucka
addikt
Az $id paramétert nem értem. - a mysql_query egy resource id-val tér vissza, ami tulajdonképpen egy szám. na ez a resource id kerül az általad említett függvény paraméterébe.
Tehát ha nem osztályt használnál, ''csak struktúráltan'' programoznál, akkor egy query-t sokszor követne egy fetch_array, vagy num_rows aminek a paramétere a ''result'' lenne.
ha strukturáltan programozna, akkor nem lenne osztály, de a mysql query ugyanúgy egy resource id-val térne vissza, amit berakna a mysql_fetch_row paraméterébe és egyenként szedegetné ki a sorokat. -
#4095
cucka
addikt
Tele von Zsinór
#4094
cucka
addikt
válasz
Tele von Zsinór
#4094
üzenetére
a tömbös trükk akkor jó, ha több osztályt szeretnél használni, vagy tovább akarod fejleszteni az egy szem adatbázis osztályodat valamilyen keretrendszer-szerűséggé. mivel a tömbbel való feltöltés általános (kb. 3 sor az egész, nem nagy cucc) ezért berakhatod egy ős-osztályba, amelyből minden más származik.
szerintem előbb deklaráld a dbclass osztályt és utána állítsd be az értékeit, ez így logikusabb, nem? plusz egy egyszerű mozdulattal kidobod azokat a ronda global változókat. (ilyen helyzetben global-t használni az kb. olyan, mint ha a ciklusokat goto-val váltanád ki. működik, de azért elég szar megoldás ).
ezen kívül jól jársz, ha áttérsz php5-re, sokat fejlesztettek az oop-s részén (értsd: egy fapados trágya rendszerből csináltak valami jót és használhatót). -
#4093
cucka
addikt
Tele von Zsinór
#4090
cucka
addikt
válasz
Tele von Zsinór
#4090
üzenetére
ennyi erővel a db_settings.php-ben egyből példányosíthatnád az osztályodat
egy apróság, amivel szerintem nagyságrenddel olvashatóbb lesz az értékekkel való feltöltés - az objektumnak ne úgy állítsd be a mezőit, hogy egy függvénynek írsz egy kilométeres paraméterlistát. készíts egy setValues függvényt, ami egy tömböt vár paraméternek. a tömb mezőnév => érték alakban legyenek az adatok. a függvénnyel pikkpakk fel tudod tölteni az objektum mezőit, és rengeteg hibalehetőséget kiszűrsz így. ez egyébként bármilyen osztályra használható, főleg akkor jön jól, ha sok mezője van az osztálynak.
mod: lehet, hogy kicsit homályosan írtam le, ha valami nem világos, írok példát.
[Szerkesztve] -
cucka
addikt
öö azt hiszem rosszul fogalmaztam meg a kérdést, csak már nem lehet javítani
szóval a lényeg, hogy nem értem, miért használsz globális változókat. az adatbázis eléréssel kapcsolatos értékek kizárólag az adatbázis osztályra kell tartozzanak, nem pedig globálisak. ebben a formában létrehozod az osztályt, majd az oop elveit szájbarúgva minden mezőjéhez készítesz egy globális változót, és azokból töltöd fel, ami nagyon nem szép
szerintem a helyes gondolatmenet a következő: a program elején létrehozol egy példányt a db_class-ból, ami természetesen globális, létrehozáskor vagy utána pedig beállítod a kapcsolathoz szükséges értékeket (user, host, satöbbi). így logikusabb lesz az egésznek a felépítése, mert az adatbázis osztály mezői valóban csak az adatbázis osztályban léteznek. létre tudsz majd hozni több adatbázis kapcsolatot, ami ritkán kell, de akkor jól jöhet.
másik bővítési lehetőség egy általános adatbázis osztály írása. itt meglesznek azok az adatok, mert azok bármilyen adatbázis kapcsolathoz szükségesek, illetve néhány általános célú függvény. ebből az osztályból származtatsz egy mysql_db_class-t, ahol megírod a mysql specifikus dolgokat. az ősben minden olyan elemet, amit örököltetni szeretnél, célszerű protected-re állítani, így meglesznek a származtatott osztályban is. satöbbi satöbbi.
[Szerkesztve] -
#4088
cucka
addikt
Tele von Zsinór
#4086
cucka
addikt
válasz
Tele von Zsinór
#4086
üzenetére
köszönet. első kérdés, hogy az init-ben miért van a global kulcsszó a változók előtt? ez php4 alá készült osztály, ilyesmivel még nem foglalkoztam, ezért tűnik furcsának. igazából beállítani ezeket a konstruktorban vagy az init-ben kéne, méghozzá ezeknek a függvényeknek a felparaméterezésével.
esetleg érdemes lehet átírni php5 alá
[Szerkesztve] -
#4085
cucka
addikt
Tele von Zsinór
#4084
cucka
addikt
válasz
Tele von Zsinór
#4084
üzenetére
én is kiváncsi vagyok arra az osztályra
-
-
cucka
addikt
válasz
vakondka
#4064
üzenetére
még egy kis okosság így korán reggel:
ha igazán királyra és újrafelhasználhatóra akarod csinálni a függvénykönyvtáradat, akkor érdemes írni egy adatbázist reprezentáló osztályt. mondjuk kitalálod, hogy milyen függvényekre van szükséged egy adatbázis kezeléséhez, írsz egy absztrakt osztályt, amiből leszármaztatsz egy mysql adatbázis kapcsolat osztályt. ha később át akarsz térni mondjuk mysqli használatára, esetleg mysql helyett postgre, oracle alá kell írni valamit, neadjisten arra lesz szükséged, hogy odbc-n keresztül beszélgess az adatbázissal, akkor az ősből le tudsz származtatni egy olyan osztályt is.
ha jól csinálod meg az osztályt, akkor a kódod szép és tiszta lesz, eltűnnek belőle az adatbázis specifikus függvények. az, hogy a programod milyen adatbázist használ, attól függ, hogy melyik adatbázis-osztályodat példányosítod be. -
cucka
addikt
válasz
vakondka
#4064
üzenetére
egyrészt nem túl szerencsés minden egyes lekérdezés előtt újra csatlakozni az adatbázishoz. másrészt egy hasonlót meg lehet írni sokkal elegánsabban is, mert ezt így nagyon kusza - van egy függvényed, ami visszatérhet mysql hibaüzenettel, mysql hibakóddal, sorok számával, az 'adat' dobozba pedig adatok helyett bepakolod a query által visszaadott resource id-t. normális esetben egy függvény egyvalamit ad vissza, ha valamilyen hiba történik, akkor pedig visszatér false-al.
nem mondom, működik így is, de php-ban pont hogy neked kell odafigyelni arra, hogy szép és olvasható kódra, mert a nyelv bizony támogatja az ilyen write only cuccok írását. igazából ez nem kötekedés hanem jótanács, úgy kell megírni a kódot, hogy később is ránézésre látszódjon, mit akar csinálni.
ah és mégvalami - a function-t magyarul függvénynek hívjuk, nem funkciónak. -
#4063
cucka
addikt
Forest_roby
#4062
cucka
addikt
válasz
Forest_roby
#4062
üzenetére
oké, eddig a szövegbe való behelyettesítésekről volt szó.
mivel fogalmam sincs, hogy mit szeretnél berakni, ezért csak annyi okosat tudok mondani, amit te is tudsz: szar a lekérdezés, amit összeraksz.
na innen a te dolgod debugolni - kiiratod a lekérdezést, megtalálod benne a hibát, satöbbi. -
#4061
cucka
addikt
Forest_roby
#4059
cucka
addikt
válasz
Forest_roby
#4059
üzenetére
hát ebből sok nem látszik, de esetleg próbálj meg debugolni, hasonlítsd össze az eredeti szöveget a behelyettesítés utánival. egyébként meg mi köze ennek a mysql-hez?
-
cucka
addikt
válasz
VladimirR
#4051
üzenetére
homály oszlatás:
string-eket sima és dupla idézőjellel is megadhatunk. a különbség, hogy a dulpa idézőjelest a php kiírás előtt parse-olja, a simát pedig nem.
$i=2;
print 'i= $i';
print ''i= $i'';
az első sor kimenete az lesz, hogy i=$i, a második kiírásnál pedig be lesz helyettesítve a $i értéke. hasonlóan működik ez a speciális karakterekre is (újsor, tab, ..) . a kapcsos záróljelekkel megadott változó behelyettesítések szintén nem működnek sima idézőjeles stringekkel.
a meglepő az egészben, hogy mérések alapján nem lassab dupla idézőjeleket használni. még régebben olvastam valahol, tehát linkkel nem szolgálhatok a témában, de komoly cikknek tűnt.
[Szerkesztve] -
#4050
cucka
addikt
Forest_roby
#4049
cucka
addikt
válasz
Forest_roby
#4049
üzenetére
ha sima idézőjelek közé rakod a szöveget, akkor a szövegben szereplő dupla idézőjelet nem kell lezárni és ez fordítva is igaz. a lenti szerintem emiatt nem működik.
a str_replace pedig elfogad paraméterként tömböket is, szóval minden adott ahhoz, hogy a borzalom favágó kódodat kicsit kulturáltabb kinézetűre cseréld
(nem mellesleg gyorsabb, ha egyszer hívod meg a str_replace-t 40 elemű tömbökre, mint 40szer egyszerűstringekre).
és egyébként is, programozó nem írja le 40-szer ugyanazt. ha valamit kettőnél többször kell leírni, akkor oda ciklust vagy egyéb megoldást használj.
[Szerkesztve] -
#4023
cucka
addikt
paramparya
#4021
cucka
addikt
válasz
paramparya
#4021
üzenetére
például átírod az url-t, vagy a formhoz tartozó hidden mezőket (amiket rendeltetésszerű használat esetén nem lenne szabad piszkálni). mindez potenciális veszélyforrás lehet.
-
#4020
cucka
addikt
Forest_roby
#4019
cucka
addikt
válasz
Forest_roby
#4019
üzenetére
a legfontosabb, hogy minden olyan információt le kell ellenőrizni, amit a júzer visz/vihet be. ilyen pl. belépési form-nál a szövegmezők tartalma. le kell pl. zárni a speciális karaktereket (mysql_real_escape_string függvény), illetve ide tartozik még a magic_quotes_gpc, olvass utána, le van szépen írva, hogy mi az és mire jó
. egyszerű és hatékony, ha a kizárólag számot tartalmazó mezőket leellenőrzöd az is_numeric függvénnyel.
a másik dolog, amivel keveseknek jut eszébe, hogy a _GET és a _POST is könnyedén hamisítható, tehát ezeknél is ellenőrzés kell.
kb. ennyi, dióhéjban. -
#4017
cucka
addikt
Forest_roby
#4016
cucka
addikt
válasz
Forest_roby
#4016
üzenetére
pedig ez nem olyan bonyolult.
a form-odat ugyanazzal a file-al dolgozod fel, mint amivel kiiratod. ebben az esetben ha a PHP_SELF és a HTTP_REFERRER különbözik, akkor valami nem stimmel, elképzelhető, hogy valaki kívülről próbál adatokat betolni a formodba. gyakorlatilag ez egy plusz biztonsági fícsör, ami valószínüleg nem sokat ér.
ezt a livehttpheaders kiterjesztést pedig megnézem, még nem hallottam róla. -
#4012
cucka
addikt
Forest_roby
#4011
cucka
addikt
válasz
Forest_roby
#4011
üzenetére
tulajdonképpen nem zavart, csak jobban szeretném ha csupa érdekes kérdés lenne ebben a topikban
. talán kicsit túlságosan leszóltalak, de mondjuk ilyen problémát tényleg nem nehéz egyedül megoldani. a következő a gondolatmenet:
1. hibát dob az átirányítás.
2. az átirányítás a header függvénnyel történik
3. megnézem, hova irányít át a header, hátha valami nem stimmel vele. ez egy egyszerű kiiratással a leggyorsabb
4. siker, megvan a hiba
5. készítek egy teszt oldalt, ahol átirányítok egy olyan oldalra, ami meghívja a phpinfo() függvényt. (ez két darab egysoros php file, fél perc alatt megvan). ezt azért, hogy megtudjam, melyik változóban található a keresett érték, vagyis az oldal neve, ahonnan átirányítottak
6. a tesztoldal működik, megkapom a phpinfo kimenetét, ahol kereséssel (ctrl+f) megtalálom a kérdéses változót
7. javítom a hibás kódot
ez most szájbarágós lett, de szerintem sokkal több sikerélményt nyújtana a programozás számodra, ha megpróbálnál egyedül debugolni. nem utolsósorban így az agyad is jobban rááll a php-ra, egy idő után egyre könnyebben fogod megtalálni a helyes megoldásokat a kérdéseidre. egyszóval vedd ezt bíztatásnak és építő jellegű hozzászólásnak.
[Szerkesztve] -
#4009
cucka
addikt
Forest_roby
#4007
cucka
addikt
válasz
Forest_roby
#4007
üzenetére
a logout.php-ben a PHP_SELF értéke véletlenül pont logout.php, vagyis végtelen ciklust generálnál, ezt védi ki a hibaüzenet.
egyébként tök király lenne, ha legalább megpróbálnál kicsit gondolkozni.
például megnézed mi van a PHP_SELF-ben, mondjuk úgy, hogy kiiratod a képernyőre, neadjisten elolvasod a help-ben hogy mi kell ott legyen. akkor némi agymunkát bevetve rájönnél, hogy butaságot írtál a kódba.
mod: ofkorz elkéstem
[Szerkesztve] -
-
#3944
cucka
addikt
paramparya
#3943
cucka
addikt
válasz
paramparya
#3943
üzenetére
nem írtál pontos kódot
nem is fogok, főleg nem egy ennyire általánosan megfogalmazott kérdésre.
egyébként ebben a topikban rengeteg olyan kérdés van, amelyek megoldásához nem kell más, mint egy kis fantázia és valamennyi utánaolvasás. -
cucka
addikt
például egyszerű matematikai képlettel kiszámolod, hogy melyik csík milyen széles kell legyen és odaraksz egy akkorára méretezett div-et, aminek beállítod a színét.
mondjuk egy 120px széles dobozba akarod rakni a csíkokat, két oldalon 10-10px helyet hagysz, hogy ne nézzen ki szarul. ezután ha egy válaszra mondjuk 40% klikkelt akkor kiraksz egy 40px széles dobozt piros háttérszínnel.
másik megoldás, ha képkezelő függvényeket használsz, a php manuál vonatkozó részében leírja mindegyiket, szerintem nem túl bonyolult kitalálni, hogy melyikre lesz szükséged. -
cucka
addikt
válasz
D4rkm4n
#3875
üzenetére
van rengeteg php könyv, olvass vissza, nemrég volt szó ezekről, hogy ki mit szeret/ajánl. alapvetően az a helyzet, hogy ha programoztál már más nyelv(ek)ben, akkor a fekete könyv megfelelő lesz, ha nem, akkor valamelyik kezdőknek szánt könyvvel jobban jársz (php 24 óra alatt, ilyesmi..)
-
cucka
addikt
válasz
vakondka
#3874
üzenetére
imagejpeg függvény paramétereivel mondhatod meg neki, hogy hova mentse a filet.
imagejpeg($image_p, 'atmeretezett.jpg', 85); esetén a megadott file-ba fogja menteni. persze ilyenkor fölösleges a content-type beállítás, mert az output bufferbe nem fog semmit küldeni.
mod: egyébként ezt a php manual imagejpeg függvényról szóló részében szépen leírja, én is onnan tudom
[Szerkesztve] -
cucka
addikt
és ha valami nem megy, vagy nem tudsz megoldani, akkor szólj.
rossz, rossz, rossz. helyesen úgy lenne, hogy ha valami nem megy, akkor keress rá a php.net-en, nézd meg könyvben, próbáld megtalálni google-ben a választ, és ha egyik sem vezet eredményre, akkor kérdezz.
D4rkm4n - egyszerű. beszerzel egy php-val foglalkozó könyvet (régebben volt szó könyvekről a topikban, olvas vissza), és elkezded olvasni, tanulni. amikor már elég sokáig eljutottál, kezdj el gondolkozni a saját oldalon, hogy szeretnéd megvalósítani, stb. ha van programozási tapasztalatod, akkor viszonylag könnyen fog menni, ha nincs, akkor azért csöppet meg fogsz szenvedni a dologgal. röviden ennyi a lényeg. -
-
cucka
addikt
bocsánat, nem tudtam, hogy már élesben megy az oldal. egyébként azon az 1 hozzászóláson kívül semmi rosszat nem csináltam és nem is fogok.
ahogy mondtam, sql injection a hiba. nézd meg a mysql_real_escape_string nevű függvényt. ha valami nem világos, vagy érdekel, mi volt a hiba, akkor szólj és magyarázok -
cucka
addikt
-
cucka
addikt
válasz
VladimirR
#3849
üzenetére
a timestamp átalakítását ember által olvasható string-re meg lehet oldani mysql-ből is, tehát a sebességgel nincs gond. előny még, hogy így egyszerűen tetszőleges formára alakíthatod a dátumot, tehát nem kell megmaradni a mysql datetime formátumánál.
további előny, hogy a timestamp-ben való tárolással függetleníted magad a szerveren beállított dátumformátumtól. -
-
cucka
addikt
akkor járnál a legjobban, ha fognád a php manualt és megpróbálnád kideríteni, megérteni, hogy mi a hiba azokban a kódokban. osztályokról konkrétan a Classes and Objects (PHP 5) című fejezetben írnak. 600 oldanyi php olvasás után ennyi azért elvárható lenne, nem?
(mert hiába jó az a könyv, egészen biztosan nem ír le mindent, amit a php tud. valószínüleg bele fogsz futni olyan problémába, amit a manual-ból pár perc alatt megoldhatsz, tehát a php.net-el érdemes már most szoros baráti viszonyt ápolni). -
#3723
cucka
addikt
s7evcsenko
#3715
cucka
addikt
válasz
s7evcsenko
#3715
üzenetére
azért lassú mert a rengeteg fölösleges hozzászólás miatt nagyon le van terhelve a szerver
-
#3689
cucka
addikt
Tele von Zsinór
#3688
cucka
addikt
válasz
Tele von Zsinór
#3688
üzenetére
kicsit jobban utánaolvastam és valóban lefut. ma is okosodtam
-
cucka
addikt
már hogyne menne, csak az yyyy-mm-dd formátum a megkötés. gondolkozz egy picit, és belátod, hogy működni fog.
(1000 alatti évszámokat természetesen ki kell pótolni nullákkal, hogy 4 számjegyesek legyenek, de hát ki akar 1000 évvel ezelőtti dátumokat hasonlítgatni?
)
sőt, most kapaszkodj meg, ha a dátumhoz hozzácsapod az időt hh24-mm-ss formátumban, akkor úgy is menni fog string-es összehasonlítással.
mod: az más kérdés, hogy a mysql tudja-e a stringek összehasonlítását, hamarosan utánanézek.
[Szerkesztve] -
cucka
addikt
-
cucka
addikt
válasz
raczger
#3660
üzenetére
igen, php 24 óra alatt c. könyv hasznosabb lehet, ha előtte nem programoztál. ami jó benne, hogy az alapfogalmakat is részletesen magyarázza, ami rossz, hogy ennél komolyabb mélységekbe nem merészkedik.
mivel én nem a php-val kezdtem programozni tanulni, ezért nekem sokkal jobban bejött a fekete könyv. -
cucka
addikt
nem nagy reklám, mert elég ismert könyv.
peter moulding írta, és még a php4-el foglalkozik, cserébe szerintem nagyon érthetően magyaráz, ugyanakkor nem viszi túlzásba a szájbarágós stílust. mindezek mellett nyilván nem mindenkinek jön be ez a könyv.
megvenni szerintem bármilyen nagyobb könyvesboltban, nem egy ritkaság. fekete a borítója és k** drága, meg fogod ismerni
egyébként rengeteg egyéb könyv van a témában, biztosan találsz megfelelőt, legtöbbet úgyis netes példákból/tutorial-okból lehet tanulni, persze ha az alapokkal tisztában vagy.
[Szerkesztve] -
cucka
addikt
nekem a php fekete könyv bejött, de neten is rengeteg tutorial található. doksiból ott van a php.net-en a teljes referencia, azt sokat fogod nézegetni
html/css ismeret nem árt, ha weboldalt szeretnél készíteni php-vel, ezen kívül előnyös, ha ismesz már valamilyen strukturált programozási nyelvet (pascal, c, egyebek). ha adatbázist is szeretnél matatni php-ból, akkor az nyilván nem fog menni sql ismeretek nélkül. dióhéjban ennyi. -
-
cucka
addikt
válasz
tkazmer
#3567
üzenetére
egyrészt ha ilyen gondod van, akkor irasd ki a lekérdezést. valószínüleg a lekérdezésben található változók néha nincsenek definiálva, ez lesz a gond.
másrészt ha egy string-be egy tömb értékét akarod belerakni, akkor valahogy így próbáld:
'szoveg'.$tomb['index'].'szoveg'
esetleg így
''szoveg{$tomb['index']}szoveg'' -
cucka
addikt
válasz
Newborn
#3568
üzenetére
egyik lehetőség, hogy levéded a levélküldés oldalt, vagyis csak regisztrált és belépett felhasználók tudják használni.
ha nem akarod levédeni, akkor meg általában a legjobb megoldás, ha a form mellé generálsz egy képet, amin betűk-számok találhatók és nehezen olvasható. levélküldéshez be kell írni egy dobozba, hogy mit ír a képen, ezt a spam robotok nem tudják megcsinálni. biztosan láttál már ilyet valahol a neten, elég elterjedt megoldás.
fenti megoldás akár egy esetleges regisztrációs űrlapnál is használható. -
cucka
addikt
válasz
tkazmer
#3553
üzenetére
igen
van egy ''filenev'' nevű file típusú meződ, amivel kiválasztja a júzer a feltölteni kívánt filet.
ekkor php-ben a $_FILES['filenev']['name'] értéke a feltöltött file neve.
szövegszerkesztők: notepad++, med, editplus, ultraedit. van még rengeteg, ízlés szerint választhatsz. nekem az első kettő bizonyult kényelmesnek. (főleg a notepad++ a code folding miatt)
[Szerkesztve] -
cucka
addikt
válasz
tkazmer
#3539
üzenetére
a függvény lényege, hogy kap néhány bemenő paramétert és azok segítségével előállít valamilyen értéket, amivel visszatér. függvényből globális változókat piszkálni áltlában favágó módszer. (van azért, amikor indokolt lehet használni, de ez elég ritka szerintem).
VladimirR : tudtommal a register globals mást jelent, ha kikapcsolod, akkor is lehetnek globális változóid.
[Szerkesztve] -
cucka
addikt
még egy ötlet: ha az útvonal jó, akkor azt kell megnézni, hogy van-e egyáltalán jogod az illető könyvtárat olvasni/írni. ha nincs, akkor 1. áthelyezed az adatokat olyan helyre, ahol van jogod ezekre a műveletekre. 2. szólsz a rendszergazdának. (ingyen vagy fapados tárhelyen felejtsd el
) -
cucka
addikt
na végre valamivel konkrétabb kérdés. a hibaüzenetek lényege, hogy (szintaktikailag) rossz útvonalakat próbál használni a program. tulajdonképpen annyi a megoldás, hogy meg kell nézni, miért lesznek ezek az útvonalak rosszak. pl. a file_exists függvénynek a következőt adod paraméterként: $_include_path . DIRECTORY_SEPARATOR . $params['file_path'
. itt ha jól láttam elakad, tehát a 3 változó konkatenációja értelmetlen útvonalat eredményez. meg kell nézni, hogy pontosan melyik a hibás ezek közül, és azt természetesen javítani.
a lényeg, erre fórumon elég nehéz válaszolni. ki kell iratni a változókat, meg kell nézni, hogy pontosan mi a tartalmuk, rá kell jönni, melyikkel van a gond, egy szóval debugolni kell.
a hiba oka valószínüleg az, hogy új szerverre telepítetted: lehet, más oprendszer, máshol vannak bizonyos könyvtárak, satöbbi. egyszerűbb átírni a php kódot, mint a szervert átalakítani, hidd el.
az azért túlzás, hogy annyira otthon vagyok a témában
[Szerkesztve]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
formában van, akkor a php van olyan okos, hogy feldolgozásnál a post tömbben asszoc tömböt készít ezekből.
Aktív témák
Hirdetés
- Bestbuy játékok
- PROHARDVER! feedback: bugok, problémák, ötletek
- Azonnali informatikai kérdések órája
- Óvodások homokozója
- Medence topik
- Donald Trump azt mondja, hogy megtalálta a TikTok vevőjét
- Vivaldi (böngésző)
- Teljes verziós játékok letöltése ingyen
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Hardverkemping június végén
- További aktív témák...
- LENOVO ThinkBook 13s - 13.3" FullHD IPS - i5-10210U - 8GB - 256GB SSD - Win11 - MAGYAR
- BESZÁMÍTÁS! Intel Core i7 4790 4 mag 8 szál processzor garanciával hibátlan működéssel
- Update 06.27. Bomba árak 2025-ben is! Üzleti - Consumer laptopok DELL FUJITSU HP LENOVO
- IPhone 15 Pro 128GB Szép Állapot! Akku:88% Jótállás: 2026.04.09.-ig
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest