Új hozzászólás Aktív témák
-
#16500
tothjozsi96
addikt
tothjozsi96
addikt
Egy kérdés.
Ez mitől van hogy UTF8 BOM nélkül van beállítva a notepad és a html charset ISO-8859-2 és karakterhibás ami megjelenik ... -
#16499
tothjozsi96
addikt
moltam88
#16498
-
moltam88
tag
válasz
tothjozsi96
#16497
üzenetére
isset() helyett !empty() -t használj. Az empty() true-t ad vissza, ha a változó nem létezik, vagy üres a tartalma (konkrétan false-al való egyezőséget vizsgál).
Bővebb leírás PHP.net-en.
-
#16497
tothjozsi96
addikt
tothjozsi96
addikt
Egy olyan kérdésem lenne hogy van egy ilyen rész:
$title = isset($title) ? ($SITE["name"] . " :: " . $title) : ($SITE["name"]);Na most, az $title adja meg az oldal címét.
Tehát Oldal neve :: Lap címeDe hogyha úgy hívom meg a függvényem hogy fuggveny(""); tehát nem adom meg a title részt akkor is kiírja a ::-ig de ez így nem jó, tudom hogy if-el meglehet oldani de így érdekelne.
A php.net-en azt írják és tapasztaltam is hogy az isset(trim()) nem működik, de máshogy meglehet oldani?
Érdekelne ez a megoldás, if-el megtudom csinálni csak na.
-
#16496
DNReNTi
őstag
tothjozsi96
#16494
DNReNTi
őstag
válasz
tothjozsi96
#16494
üzenetére
Jaja, pontosan. Sot ha uberbiztonsagos akarsz lenni a loginok kezelesre kulon tablat hozol letre, nem pedig a felhasznalo tablajaban tarolod.
Ez mondjuk szvsz egy sima weboldal eseteben mar agyuval a verebre kategoria. -
#16495
wis
tag
tothjozsi96
#16492
válasz
tothjozsi96
#16492
üzenetére
Nem. Ne tárolj felhasználó adatokat cookie-ban semmilyen formában. Amennyiben szükséged van a felhasználó nevére vagy azonosítójára, azt rakd bele a $_SESSION tömbbe. Pl. $_SESSION['user_id'] = $user_id;
-
#16493
DNReNTi
őstag
tothjozsi96
#16492
DNReNTi
őstag
válasz
tothjozsi96
#16492
üzenetére
"Kérdés hogy SQL injektálás szempontból milyen lesz majd."
Wat?"nekem kettő dolog fő a tároláshoz, igazából az egyik a felhasználó ID-je a másik pedig a jelszava megkeverve valamivel"
Wat? Miért kellene ezeket tárolnod? Miért nem elég mondjuk egy minden helyes loginnál generált unique hash, amely alapján azonosíthatod a felhasználót, és 100% biztonságban csak szerver oldalon kezelnéd az id-t jelszót, stb-t? -
#16492
tothjozsi96
addikt
wis
#16491
tothjozsi96
addikt
Igazából oké hogy COOKIE-ban tárol ez is de más, mivel több kulcsot tárol egyben.
De ez így lehet hogy jobb is, mivel nekem kettő dolog fő a tároláshoz, igazából az egyik a felhasználó ID-je a másik pedig a jelszava megkeverve valamivel, még nem tudom mivel ...
Tehát md5($valami.$password.$valami);De a COOKIE-nál ki lehet olvasni a böngészőből, itt pedig nem tehát biztonságosabb az biztos.
Kérdés hogy SQL injektálás szempontból milyen lesz majd.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#16491
wis
tag
tothjozsi96
#16490
válasz
tothjozsi96
#16490
üzenetére
Ugyanolyan "biztonságos", hiszen ez a megoldás is cookie-t használ.
A kliens gépén az egyedi session azonosító tárolódik amit minden kéréskor elküld a szervernek.
Ehhez az azonosítóhoz szerver oldalon társíthatod azt az információt, hogy pl. be van-e lépve.Miért tárolnád a passhash-t cookie-ban? Milyen kulcsok működését nézted meg?
-
#16490
tothjozsi96
addikt
wis
#16489
tothjozsi96
addikt
Aha, nézegetem.
De még mindig nem értem hogy ez mitől is lesz biztonságosabb mint egy $_COOKIE.Az igaz hogy a kliens gépén nincs tárolva "szó szerint" az adat, szóval passhash meg ilyesmi, de mitől jobb?
Megnéztem az alapvető kulcsok működését, nem túl bonyolult.
Tehát egy login-t feltudnék építeni elég egyszerűen. -
#16489
wis
tag
tothjozsi96
#16488
válasz
tothjozsi96
#16488
üzenetére
A PHP alapból tartalmaz session kezelőt, neked a session cookie-val nem kell foglalkoznod közvetlenül.
Próbáld ki a példákat és figyeld meg, hogy létrejön a böngészőben a PHPSESSID cookie.Ha szeretnéd, hogy a böngésző bezárása után törlődjön akkor a session_set_cookie_params függvényben az első paraméter legyen 0.
-
#16488
tothjozsi96
addikt
Sk8erPeter
#16485
tothjozsi96
addikt
válasz
Sk8erPeter
#16485
üzenetére
És szerinted milyen egy biztonságos session?
Olvastam olyant hogy ajánlott a session_id-t elmenteni cookie-ban külön, és ha nem egyezik akkor kiléptet az oldal.
Mint biztonsági elemként nem rossz szerintem.De session-al nem volt még dolgom, azt tudom róla hogy a böngésző bezártával törlődik és újra be kell jelentkezni.
-
#16487
PumpkinSeed
addikt
Sk8erPeter
#16485
PumpkinSeed
addikt
válasz
Sk8erPeter
#16485
üzenetére
Elnézést a késői reakciót, működik. A Linuxos jogosultságok beállítása mellett még annyi hiba volt, hogy a php.ini-ben a feltöltött fájl max mérete 1MB-ra volt állítva, amit úgy tudtam meg, hogy a $_FILES['file']['error']-al tudtam meg.
A kód most így néz ki:
$target= "uploaded_img/";
$file_name = $_FILES['file']['name'];
$tmp_dir = $_FILES['file']['tmp_name'];
if(!preg_match('/(jpe?g|png)$/i', $file_name))
{
$error_msg = 1;
}
else
{
$target = $target.$file_name;
move_uploaded_file($tmp_dir,$target);
} -
#16486
tothjozsi96
addikt
Sk8erPeter
#16485
tothjozsi96
addikt
válasz
Sk8erPeter
#16485
üzenetére
"Elég rosszul van megírva, de mutatok egy examplet.
"Itt úgy értettem hogy ez nem pont az enyém, az sokkal hosszabb, de nincs benne preg_match.
Tehát a str_replace részek a megegyezőek csak, nagyjából ennyi.
Köszi. -
#16485
Sk8erPeter
nagyúr
PumpkinSeed
#16477
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16477
üzenetére
Jó, és a tanácsokat elolvastad, hogy hogyan javítsd ki az útvonalat? Akár relatív útvonalakat használva a webalkalmazáshoz, akár $_SERVER['DOCUMENT_ROOT']-ot felhasználva. Nyilván amíg az elérési utat nem javítod ki, és még egy egyszerű tesztcélú fájlírás sem működik a célkönyvtárba, addig hiába megy az oda-visszaírogatás.
Amúgy meg kéne tanulni az Xdebug használatát, nem pedig kiírogatni, hogy épp milyen a változó értéke, hanem normálisan debuggolni, arra találták ki, hogy egyszerűbb legyen a fejlesztés, és az ember rájöjjön a hibáira. Korábban is javasoltam, a kolléga igen gyorsan rá is jött, hogy kell használni. Követhetnéd a példáját, és akkor menetközben kapásból látnád, milyen útvonalakra próbál írni, az egyes visszatérési értékeket pedig korrektebb módon ellenőrizhetnéd.
Azt sem ártana tudni, milyen HTML-kód van a frontenden. Pl. a mező neve (name attribútum) valóban egyszerűen "file"? Hogy néz ki akkor a most használt, komplett kódod (miután elvileg javítottad)?(#16483) tothjozsi96 :
Hol olvastad ezt a hülyeséget? Nem árt megnézni, az ember milyen forrásokból tájékozódik, és milyen fórumos kommentárokat vesz komolyan. (#16478) tothjozsi96:
Akkor már végképp nem értem, most épp milyen kódról beszélsz, mert
ez a kód, amit ide bemásoltál, tele van preg_match-csel és preg_replace-ekkel. -
#16484
fordfairlane
veterán
tothjozsi96
#16483
fordfairlane
veterán
válasz
tothjozsi96
#16483
üzenetére
Bocs, de ez marhaság.
-
#16483
tothjozsi96
addikt
tothjozsi96
addikt
Csak mert sok helyen nem ajánlották ezt a Session-t, a szervert darálja.
Ezt hallottam ... -
#16482
sztanozs
veterán
tothjozsi96
#16479
sztanozs
veterán
válasz
tothjozsi96
#16479
üzenetére
Valamint ha olyan dolgot szeretnél csinálni, ahol fontos az "egyedi" azonosítás, ott célszerű a session-t nem csak a session tickethez, hanem egyéb más tulajdonsághoz közni (pl ip cím), különben a cookie megszerzésével a belépő felhasználó más álltal megszemélyesíthető.
Kilépéskor a session változót invalidálni kell és mind kliens, mind szerver oldalon kötelezően le kell járani adott idejű inaktivitás után.Ja és akkor még szó sem esett a https-ről...
felhasználó id és md5 password tök fölösleges és veszélyes is - főleg ha nem secure cookie-ről van szó
-
#16481
fordfairlane
veterán
tothjozsi96
#16479
fordfairlane
veterán
válasz
tothjozsi96
#16479
üzenetére
Ha a felhasználó munkamenetével kapcsolatos adatokat akarsz tárolni, akkor az általánosan bevett megoldás az, hogy a kliensnél egy egyedi, véletlengenerált azonosítót tárolsz, pl. hash formájában, minden más adatot a szerveren. A hash azonosítja a klienst minden egyes requestnél, így a többi adat hozzárendelése szerveroldalon könnyedén megoldható. PHP-ban erre való a beépített session-kezelő.
-
#16480
DNReNTi
őstag
tothjozsi96
#16479
DNReNTi
őstag
válasz
tothjozsi96
#16479
üzenetére
Én felhasználó beléptetésre mindenképp a session-t javaslom. Ha pedig engedélyezed, az "emlékezz rám" (ne lépjek ki ha bezárom a böngészőt) funkciót, akkor a kettő kombinációja. Ez esetben jó egy unique hash sütiben ami alapján be tudod léptetni a felhasználót. Sütiket szerintem csak "nem globális" beállítások tárolására érdemes használni, pl mondjuk az előbb említett "emlékezz rám". Továbbá ne felejtsd el, hogy most már fel kell hívd a felhasználók figyelmét arra, hogy sütiket használsz, és mielőtt használod őket, ezt ők el kell fogadják.
-
#16479
tothjozsi96
addikt
tothjozsi96
addikt
Egy kérdés.
Mit érdemes szerintetek cookie-ban tárolni?
Nem tudom mennyire lenne ajánlott egy olyan beléptető rendszer ami SESSION alapú és naponta kb. 1.000 felhasználó lép ki/be.Mit lenne érdemes alkalmaznom?
Jelenleg úgy van megoldva hogy 1 generált hash-t tárolok.Előtte a felhasználó ID-je és a password md5-je volt tárolva.
Nem tudom mi ajánlott, mivel nagy oldal.
-
#16478
tothjozsi96
addikt
Sk8erPeter
#16465
tothjozsi96
addikt
válasz
Sk8erPeter
#16465
üzenetére
Én azt mondtam hogy nem teljesen olyan, de hasonló.
Az enyémben nincs preg_replace, főleg nem preg_match, csak tömbökből kinyert adat, aztán str_replace. -
#16477
PumpkinSeed
addikt
Sk8erPeter
#16476
PumpkinSeed
addikt
válasz
Sk8erPeter
#16476
üzenetére
A $file_name kiíratásakor pedig megvan a feltöltött fájl neve. és mikor kiírom a $target-et akkor pedig kiírja a teljes "cuccot".
Igazából tényleg nem létezik, csak copy-ztam egy ilyen függvényt gyorsba. Amúgy úgy nézz ki, hogy a www mappában van az im_share mappa, majd ebben a .php állományok illetve a css mappa, uploaded_img mappa és profil_img mappa. Az uploaded_img mappa tartalmát az img_share mappában lévő .php fájlokból akarom szabályozni. Szóval szerintem a uploaded_img/ elérési útvonal helyes.
-
#16476
Sk8erPeter
nagyúr
PumpkinSeed
#16475
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16475
üzenetére
Az utóbbi két hibaüzenet alapján elég egyértelmű: a $file_name változód üres. A $target = $target.$file_name; soroddal tehát ez esetben olyan, mintha azt írtad volna, hogy $target = target;, mivel nem fűztél hozzá semmilyen nevet (így marad a könyvtárnév). Így nem csoda, hogy nem tudja mozgatni.
Az első hibaüzenet meg csak annyit mond, hogy nem létezik uploaded_img/people.txt fájlod...
Az igazából nem tudom, hogy jött ide, a lényeg az volt, hogy a célkönyvtárba tudsz-e írni. (file_put_contents() használatát javasoltam) Gondolom valóban nem létezik a people.txt fájl, vagy még mindig rosszul adod meg az elérési útvonalat... Ez esetben nem ártana, ha elmondanád, hogy milyen a könyvtárszerkezet (mi hol van), akkor még meg is tudnánk mondani, mit rontasz el. -
#16475
PumpkinSeed
addikt
Sk8erPeter
#16474
PumpkinSeed
addikt
válasz
Sk8erPeter
#16474
üzenetére
Warning: file_get_contents(uploaded_img/people.txt): failed to open stream: No such file or directory in /var/www/img_share/upload.php on line 62
Warning: move_uploaded_file(): The second argument to copy() function cannot be a directory in /var/www/img_share/upload.php on line 63
Warning: move_uploaded_file(): Unable to move '/tmp/phpSohzUi' to 'uploaded_img/' in /var/www/img_share/upload.php on line 63Ezeket kapom. De a mappa jogosultsága most kb úgy néz ki, hogy nobody, nogroup, 777...
-
#16474
Sk8erPeter
nagyúr
disy68
#16473
Sk8erPeter
nagyúr
válasz
disy68
#16473
üzenetére
Igen, a DIRECTORY_SEPARATOR atombiztos megoldás, de mivel Windows-on is nyugodtan lehet használni a forward slash-t (/) az elérési útvonalaknál (attól még, mert Windows esetén a backslash (\) a bevett konvenció), ezért nem biztos, hogy megéri vele szenvedni (pl. ronthatja az olvashatóságot). Tudsz mondani olyan esetet, ahol a forward slash használata elvérezne?
(Windows+IIS alatt én még nem találkoztam ilyen esettel (vagy csak nem emlékszem
), de ettől még lehet.)(#16471) fordfairlane:
Ja igen, az végül lemaradt, köszi a kiegészítést.
Mondjuk azért az esetek nagy részében a feltöltött kép elég közeli viszonyban van a konkrét webalkalmazással, szóval a webalkalmazás rootjához képest relatív útvonal talán az esetek többségében talán egy fokkal használhatóbb.(#16472) PumpkinSeed :
Mi az, hogy "más lehetőséget oda nem tudok elképzelni"? Ezt mire írtad?
"uploaded_img/-el kezdtem"
Az épp futtatott szkripthez képest az uploaded_img könyvtár elérhető volt, jól adtad meg az útvonalat? Oda tudsz bármit is írni? Pl. csak próbából file_put_contents() segítségével tudsz egy akármilyen fájlt létrehozni a célkönyvtárba? -
#16473
disy68
aktív tag
Sk8erPeter
#16470
disy68
aktív tag
válasz
Sk8erPeter
#16470
üzenetére
Persze ha már hordozható kódról van szó meg útvonalakról, akkor érdemes megemlíteni a php előredefiniált DIRECTORY_SEPARATOR konstansát, ami az adott rendszeren az érvényes elválasztó - még ha a "/" nem is okoz gondot mindenhol.
-
#16472
PumpkinSeed
addikt
Sk8erPeter
#16470
PumpkinSeed
addikt
válasz
Sk8erPeter
#16470
üzenetére
Ezt az utat már körbejártam. uploaded_img/-el kezdtem, szóval más lehetőséget oda nem tudok elképzelni.
-
#16471
fordfairlane
veterán
Sk8erPeter
#16470
fordfairlane
veterán
válasz
Sk8erPeter
#16470
üzenetére
akkor már legyen a webalkalmazáshoz képest relatív
Vagy pedig használhatja a $_SERVER["DOCUMENT_ROOT"] -ot.
-
#16470
Sk8erPeter
nagyúr
disy68
#16469
Sk8erPeter
nagyúr
válasz
disy68
#16469
üzenetére
Mondjuk sokkal jobban is tenné, ha nem ilyen módon adna meg elérési útvonalakat, mint a /var-ral kezdődő, ami igencsak rossz megoldás, akkor már legyen a webalkalmazáshoz képest relatív (és persze az az útvonal legyen helyes is) - pl. ez ilyen módon kb. lehetetlenné teszi egy Windows-os szerverre való átköltöztetést (hacsak ott nincs var könyvtár az adott partíció rootjában (még a forward slash nem lenne probléma az útvonalnál, hiába Windows)).
Szerk.: félre ne értsd, ez nem neked szól, mert Te a lehetséges problémát tártad fel, inkább a kérdezőnek.
-
#16469
disy68
aktív tag
PumpkinSeed
#16468
disy68
aktív tag
válasz
PumpkinSeed
#16468
üzenetére
Ebben:
$target= "var/www/img_share/uploaded_img/";nem inkább /var az útvonal eleje? A perjel nélkül a script helyétől keresné a var mappát és a többit.
-
#16468
PumpkinSeed
addikt
PumpkinSeed
addikt
Már nincs ötletem miért nem megy.
$target= "var/www/img_share/uploaded_img/";
$file_name = $_FILES['file']['name'];
$tmp_dir = $_FILES['file']['tmp_name'];
if(!preg_match('/(jpe?g|png)$/i', $file_name))
{
$error_msg = 1;
}
else
{
$target = $target.$file_name;
$feltoltve = move_uploaded_file($tmp_dir,$target);
echo $feltoltve;
}A move_uploaded_file nem teszi bele a fájlt a megadott mappába. Már végig próbáltam az összes lehetséges cél mappa elérési útvonalat. Illetve ellenőriztem a $tmp_dir tartalmát annak is van értéke. Valami jogosultsági probléma lesz, de viszont Debian alatt megadtam a www-data nevű felhasználót a teljes www mappa tulajdonosának, szóval az apache azt csinál vele amit akar. De mégse akar működni.
-
#16467
Sk8erPeter
nagyúr
DNReNTi
#16466
Sk8erPeter
nagyúr
válasz
DNReNTi
#16466
üzenetére
Nézd meg a linken található kódot, ott nem nagyon van olyan rész, amire ez megoldást jelentene...
Amúgy meg korábban azt írta a srác, hogy megoldódott a probléma, mert eleve feltöltésnél átalakítja a szövegeket (amit párszor korábban is javasoltam neki, de akkor valamiért neki nem jött át ), és akkor nem észrevehető a különbség, szóval most nem tudom, miért került elő újból a probléma... -
#16466
DNReNTi
őstag
Sk8erPeter
#16465
DNReNTi
őstag
válasz
Sk8erPeter
#16465
üzenetére
Az strtr-el elkerülhető ciklus használata. Szerintem ennyivel "gyorsabb". Ki kellene próbálni, hogy ez a gyorsabb, vagy egy while ciklus a behelyettesítési tömbön.
szerk: elírás
-
#16465
Sk8erPeter
nagyúr
tothjozsi96
#16462
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16462
üzenetére
Nem fogsz tudni kitalálni jobb általánosan alkalmazható, bizonyos szabályokat megfogalmazni képes "egyedi kivitelezést". Azért ez nem egy triviális feladat. Maradj csak a könyvtári függvényeknél, vagy max. keress valami komplex library-t... Amúgy a javasolt strtr sem tudom, mitől lenne jelen esetben jobb, mint az str_replace...
Mellesleg a te esetedben pont nem az str_replace a probléma, ami a lassúságot okozza, hanem az iszonyat sok smiley és hozzá tartozó külön-külön reguláris kifejezés, preg_replace-szel annak illeszkedésére való keresgélés és csere... (Magyarul a preg_replace jobban lassít, mint az annál jóval egyszerűbb cserére alkalmas str_replace.)
De ezt már egyszer kifejtettem neked. Ismétlés a tudás anyja. -
#16464
DNReNTi
őstag
tothjozsi96
#16462
DNReNTi
őstag
válasz
tothjozsi96
#16462
üzenetére
Csak kíváncsiságból, pontosan mit jelent az, hogy lassú? Úgy értem mondjuk egy 3.000 karakter hosszú string-nél milyen eredmény jön most ki, és mi lenne elfogadható? Egyáltalán mifajta oldal / alkalmazás az, ahol ennyire számítanak a milisec-ek? Már korábban is írtad valamire, hogy lassú.
Egyébként minek 300 smile? Nem e elég mondjuk 20? (#16463) fordfairlane +1
-
#16463
fordfairlane
veterán
tothjozsi96
#16460
fordfairlane
veterán
válasz
tothjozsi96
#16460
üzenetére
-
#16462
tothjozsi96
addikt
Speeedfire
#16461
tothjozsi96
addikt
válasz
Speeedfire
#16461
üzenetére
Ez is lassú, azért kellene valami egyedi kivitelezés ...
Túl sok BB kódot kell átalakítanom ahhoz hogy gyors legyen.
-
#16461
Speeedfire
félisten
tothjozsi96
#16460
Speeedfire
félisten
válasz
tothjozsi96
#16460
üzenetére
Esetleg preg_replace ?
-
#16460
tothjozsi96
addikt
Peter Kiss
#16459
tothjozsi96
addikt
válasz
Peter Kiss
#16459
üzenetére
Tehát ha POST-ból jön egy ilyen adat "pista 123 pista".
Akkor az 123-at cserélje ki mondjuk arra hogy számok.
Tehát str_replace nélkül.
Igazából a smileyekhez kell, de 300 smileynél már lassú a string replace.
-
#16459
Peter Kiss
őstag
tothjozsi96
#16457
Peter Kiss
őstag
válasz
tothjozsi96
#16457
üzenetére
$szoveg .= $masikSzovegAVegere; //sima concat is megy nyilvan
$szoveg[$valahanyadikKarakter] = $kicserelemMasikra; //nem multi-byte safe
Mire kellene gondolni?
-
#16458
Sk8erPeter
nagyúr
tothjozsi96
#16457
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16457
üzenetére
"Lehet valahogy úgy átalakítani szöveget, tehát nem str_replace-el hanem ilyen fgv.-ek nélkül?"
Direkt idéztem a kérdésedet, csak hogy még egyszer lásd - szerinted mi értelme van ennek a kérdésnek? -
#16457
tothjozsi96
addikt
tothjozsi96
addikt
Egy kérdés.
Lehet valahogy úgy átalakítani szöveget, tehát nem str_replace-el hanem ilyen fgv.-ek nélkül? -
#16456
PumpkinSeed
addikt
PumpkinSeed
addikt
Köszönöm a válaszokat. Igazából nincs is több kérdésem.
-
#16453
Sk8erPeter
nagyúr
PumpkinSeed
#16447
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16447
üzenetére
Szerencsére a többiek elég alaposan válaszoltak az érdemi részre.
"Illetve egy függvény, hogy tud több String típust is visszaadni, például egy adatbázisból kiolvasott név és lakcím adatot például?"
Csak a pontosság kedvéért: nincs olyan, hogy "több String típus", string van, és kész, szerintem Te arra gondoltál, hogy mondjuk több string "értéket" szeretnél visszaadni. Tehetsz ilyet összetett típussal, tömbbel vagy objektummal is vissza tudsz térni egy függvényből. Egy függvénynek egy darab visszatérési értéke van.
Szerk.: ja, most látom, disy68 ezt is leírta neked.
Amúgy ilyen, hogy "adatbázisból kiolvasott név és lakcím adat", tipikusan valami objektumhoz kellene, hogy tartozzon ahhoz, hogy ez normálisan kezelhető legyen (ne pedig többdimenziós asszociatív tömbborzalmakat kelljen kezelned), például van egy Person osztályod (most csak a példa kedvéért), és ezt megfelelően példányosítod (példányosítás után lesz belőle objektum). Ha sok személy van, akkor objektumok tömbje is egy jó megoldás lehet (értsd: egy tömbbel térsz vissza, ebben pedig egy vagy több objektum van).(#16451) disy68 :
Szépen összeszedett válasz!
-
#16452
fordfairlane
veterán
PumpkinSeed
#16447
fordfairlane
veterán
válasz
PumpkinSeed
#16447
üzenetére
Maga az MVC csak nagy vonalakban ad iránymutatást arra nézve, hogy miféle nyelvi elemeket keverhetsz a kódodban. Az nagyjából oké, hogy a html a megjelenítéshez kapcsolódik, de az adott nézetnek számos egyéb funkciója is lehet.
A manapság bevett gyakorlat nagyjából annyi, hogy az oldal szerkezetét leíró html kód többnyire egy template fájlba kerül, amibe csak a legegyszerűbb php, vagy az adott template kezelő nyelvi elemei kerülnek bele. Pl. blokkdefiniálás, iteráció (foreach), beágyazás (include), csak a legegyszerűbb vezérlési szerkezetek. A többi, az adott nézethez kapcsolódó kódrészek mondjuk egy View objectben kaphatnak helyet, ami tisztán csak php utasításokat tartalmaz.
Én úgy szoktam csinálni, ha az adott rendszerben nincs template kezelő, hogy a nézetben a PHP alternatív nyelvi szintaktikáját használom, ezzel is érzékeltetve, hogy ez egy nézetleíró fájl.
<?php if(): ?>
<?php else: ?>
<?php endif; ?>
<?php foreach(): ?>
<?php endforeach; ?> -
#16451
disy68
aktív tag
PumpkinSeed
#16447
disy68
aktív tag
válasz
PumpkinSeed
#16447
üzenetére
Az MVC pattern, ahogy a neve is indikálja külön kezeli az adatot (model), megjelenítést (view), és a kettőt összefogó irányítást (control) - csak így egyszerűen megfogalmazva. Ez által adott, hogy ezeket a részeket külön kezelve, jellemzően külön fájlokként fogod megoldani - sok esetben ez több ezer külön fájlt is jelenthet. Persze itt számít az mvc keretrendszer működése, felépítése stb. (lehet, hogy a keretrendszer alapja áll csupán pár ezer kisebb fájlból és a számodra ténylegesen készítendő fájlok száma ehhez képest elenyésző).
A php / html keverése sokszor alapvetően adja magát, azonban egy template-kezelő működhet úgy is, hogy magában a template fájlban se html, se php kód nem fog szerepelni - persze ezt is php dolgozza fel, ami behelyettesíti a htmlt a template alapján.
MVC esetében, fontos, hogy a szerepek elkülönüljenek. Ez jelenti azt, hogy a controllereid és modelleid jellemzően nem fognak html kódot tartalmazni, csak php-t, míg a view több, mint valószínű, hogy fog mindkettőt. A lényeg, hogy az adott megvalósítás struktúrája fogja meghatározni, hogy a fájlok mit fognak tartalmazni.
--
Amennyiben kevered a html és php kódokat érdemes figyelni az olvashatóságra (a kód karbantartása miatt).pl. e helyett:
<?php
$menupontok = array('egy','kettő','három','négy');
echo '<ul>';
foreach($menupontok as $menupont){
echo "<li>$menupont</li>";
}
echo '</ul>';
?>könnyebben átlátható ez (alternative syntax használattal):
<?php $menupontok = array('egy','kettő','három','négy'); ?>
<ul>
<?php foreach($menupontok as $menupont): ?>
<li>
<?php echo $menupont ?>
</li>
<?php endforeach; ?>
<ul>
?>--
Egy függvény visszatérési értéke pedig egy darab "érték". Ez az "érték" tartalmát tekintve lehet nagyjából bármi. Ha neked egy darab szöveges érték kell, akkor egy string, ha kettő vagy több, akkor lehet array, ami tartalmazza a két vagy több stringet. Ha valami bonyolultabb struktúra kell, akkor lehet tömbök, tömbje, vagy akár egy objektum is, ami tövábbi logikát is tartalmazhat (metódusok).De először a nyelvi alapokat kell mindenképpen megismerni, és utána érdemes nézelődni a különböző programozási paradigmák, programtervezési eljárások és egyéb best-practice megoldások felé.
-
#16449
_ak_
addikt
PumpkinSeed
#16447
_ak_
addikt
válasz
PumpkinSeed
#16447
üzenetére
Nem találkoztam sehol, semmi iránymutató értékekkel, szóval szerintem ez nem ennyire konkrét.
Persze törekedni kell a különböző logikák szétválasztására és legfőképp a kódismétlés kerülésére, de ha aránytalanul több munkával járna a szétválasztás, akkor elfogadható.Nagyjából én így vettem le az elméletet, de egyrészt gyakorlatom alig, másrészt szerintem a project típusától is változhat.
Aztán remélem valaki kijavít, hogy ha hülyeséget mondtam.
-
#16448
DNReNTi
őstag
PumpkinSeed
#16447
DNReNTi
őstag
válasz
PumpkinSeed
#16447
üzenetére
nagy probléma, ha néhány helyen a HTML részben is vannak PHP kódrészletek?
Én ezt nem értem. Ha behúzod a PHP-t külső fájlból akkor is lesz php a HTML-ben. (Illetve a pontosság kedvéért HTML lesz a PHP-ban.) Szóval: wat? -
#16447
PumpkinSeed
addikt
Sk8erPeter
#16439
PumpkinSeed
addikt
válasz
Sk8erPeter
#16439
üzenetére
Erről most nem tudom hogy jutott eszembe, de az érdekelne, hogy nagyobb projekt esetén az MVC-t alapul véve, úgy érdemes-e csinálni, hogy minden php programrész egy külön fájlban van és csak meghívom őket a megfelelő paraméterezéssel, vagy az nagy probléma, ha néhány helyen a HTML részben is vannak PHP kódrészletek?
Illetve egy függvény, hogy tud több String típust is visszaadni, például egy adatbázisból kiolvasott név és lakcím adatot például?
Megmosolyogtató beszélgetést olvashattam az előbbiekben.
-
DNReNTi
őstag
Ez tényleg hasznos lehet. Nem azt mondom, hogy hibátlan, mer' sok helyen bele lehetne kötni, de anno kezdőként sokat spórolt volna nekem egy ilyen olvasmány.
(#16441) honda 1993
Ne csak olvasgasd. Hanem a bevezetőtől kezdve olvasd és csináld is meg a példákat, hiába úgy gondolod, hogy az haszontalan, mert téged csak az 56. érdekel. -
#16445
Sk8erPeter
nagyúr
Speeedfire
#16444
Sk8erPeter
nagyúr
válasz
Speeedfire
#16444
üzenetére
Nagyon szép idézet lett így a végére.
-
#16444
Speeedfire
félisten
Sk8erPeter
#16443
Speeedfire
félisten
válasz
Sk8erPeter
#16443
üzenetére
Lépj már feljebb legalább a nagycsoportos óvodásokhoz.
Nem vagyok rá képes.
Ja értem, tehát attól lesz jó valami, ha sokan csinálják.
(Mr. Bustát is sokan szeretik - leginkább a kiskamasz korosztályból -, aztán mégis szar zenét csinál. A celeblóf@sz és valóságshow műsorokat is sokan bambulják, de attól nem lesz jó. Oravecz Coelho Nóra idézeteit is rengetegen zabálják, pedig röhejesen közhelyesek. Még szerencse, hogy a PHP mindezeknél tényleg sokkal jobb. (Csak hogy félreértés ne essék, hogy összevethető lenne. ))A sex-et is sokan csinálják, akkor az nem jó?
Bustát minek kellett felhozni...?!
Valóban nem attól lesz jó a nyelv, mert sokan használják, de ha sokan használják, akkor megéri vele foglalkozni és időt áldozni rá, még ha vannak hibái is. ---- Speeedfire Coelho
-
#16443
Sk8erPeter
nagyúr
Speeedfire
#16442
Sk8erPeter
nagyúr
válasz
Speeedfire
#16442
üzenetére
Lépj már feljebb legalább a nagycsoportos óvodásokhoz.
"Erre csak azt tudom írni, hogy minden nyelvben vannak pozitív és negatív dolgok."
---- Speeedfire Coelho "Nem lehet azt kimondani, hogy márpedig az xy a legjobb."
Még szerencse, hogy senki nem beszélt arról, mi a legjobb."»» Az nem túl erős érv a nyelv jósága mellett, hogy a weboldalak nagy része PHP-ben íródott.
Márpedig ez egy igen erős indok, szerintem."
Ja értem, tehát attól lesz jó valami, ha sokan csinálják. (Mr. Bustát is sokan szeretik - leginkább a kiskamasz korosztályból -, aztán mégis szar zenét csinál. A celeblóf@sz és valóságshow műsorokat is sokan bambulják, de attól nem lesz jó. Oravecz CoelhoNóra idézeteit is rengetegen zabálják, pedig röhejesen közhelyesek. Még szerencse, hogy a PHP mindezeknél tényleg sokkal jobb. (Csak hogy félreértés ne essék, hogy összevethető lenne. )) -
#16442
Speeedfire
félisten
Sk8erPeter
#16436
Speeedfire
félisten
válasz
Sk8erPeter
#16436
üzenetére
Ja, de tudom, most akkor az erre a szerinted jó reakció, hogy húzzak el, nem fogsz hiányolni.
Húzzál el.Erre csak azt tudom írni, hogy minden nyelvben vannak pozitív és negatív dolgok. Nem lehet azt kimondani, hogy márpedig az xy a legjobb.
Az nem túl erős érv a nyelv jósága mellett, hogy a weboldalak nagy része PHP-ben íródott.
Márpedig ez egy igen erős indok, szerintem. -
#16440
_ak_
addikt
honda 1993
#16438
_ak_
addikt
válasz
honda 1993
#16438
üzenetére
Ezt a tanfolyamot csináld végig és sokkal érhetőbb lesz minden. Magyar, itt-ott elavult, de ahogy elnézem, sokat segítene a dolgok megértésben.
-
#16439
Sk8erPeter
nagyúr
honda 1993
#16438
Sk8erPeter
nagyúr
válasz
honda 1993
#16438
üzenetére
Igen, természetesen PHP-kódot HTML-kódba is lehet ágyazni (nyilván), meg lehet egy csupa PHP-kódból álló fájlod is, amiben egy sor HTML-kód nincs... (és egyébként a záró ?> opcionális, csupa PHP-kódból álló fájlnál nem is érdemes használni egyáltalán) Az viszont nem mindegy, milyen a fájl kiterjesztése, mert ahhoz, hogy például a .html vagy más kiterjesztésű fájlokban is az elvártak szerint lefusson a PHP-kódod, megfelelően konfigurálni kellene a szervert (ami esetedben az Apache, de lehetne ez IIS és más is, tök mindegy, a lényeg, hogy megfelelően kiszolgálja a tartalmat). Alapértelmezetten nem ez a helyzet, .html-kiterjesztésű fájlnál alapból nem értelmeződik a PHP-kód, tehát ha egy .html-kiterjesztésű fájlba beleírsz egy PHP-kódot, akkor azt látni fogod kliensoldalon a forráskódban, amikor megnyitod az oldalt. (Az meg nem jó.
) -
#16438
honda 1993
senior tag
Sk8erPeter
#16437
honda 1993
senior tag
válasz
Sk8erPeter
#16437
üzenetére
Hát, akkor megint sikerült hülyét csinálnom magamból.
Nembaj, már megszoktuk.Azért gondoltam hogy ez a probléma, mert miután észrevettem hogy index.html.php lett a fajl neve, gondoltam hogy akkor megpróbálom hogy eleve egy php fájlt hozok létre. (és így azonnal működött is).
De mielőtt félreértenétek, nem én adtam index.html.php nevet neki, én csak index.php néven mentettem el.
Ez már csak szigorúan elméleti kérdés, nincs semmi problémám, műkodik minden.
De úgy ahogy a CSS-t is lehet a HTML-be ágyazni, illetve külön CSS fájlt is létre lehet hozni ami ugyan úgy működik, gondolom ugyan ez igaz. Php-ra is.
Tehát végül is mindegy hogy HTML-be ágyazom a php kódot, vagy egy külön php fájlba írom nem?
-
#16437
Sk8erPeter
nagyúr
honda 1993
#16434
Sk8erPeter
nagyúr
válasz
honda 1993
#16434
üzenetére
Hogy mi van?!
Tehát szerinted most az számít, hogy a fájlt miben hoztad létre, és konkrétan a PHP Stormnak melyik beállításai alatt? Teljesen mindegy. Akár Notepadben is létrehozhattad volna a .php-kiterjesztésű fájlt, amíg a kód megfelelő benne. Nagyon valószínű, hogy valami mást csináltál, amitől helyrejött, mondjuk úgy tűnik, már sosem fogunk rájönni, mi volt az."A tanacsotokat kovetve letrehoztam egy uj HTML fajlt, aminek .php kiterjesztest irtam a vegere."
Igazából nem értem, minek emelted ki a két félkövérített szót. Ha a fejlesztőkörnyezetben mondjuk véletlenül vagy direkt stylesheetet hozol létre (CSS-fájlt), és utána a fájlkezelőben megváltoztatod ezt a fájlt úgy, hogy a .css-kiterjesztés helyett .php-t írsz a végére, majd beleírsz ebbe a fájlba egy PHP-kódot (persze a <?php azért minimum legyen benne), az is tökéletesen kell, hogy működjön."(Es itt megjegyeznem, hogy direkt kerdeztem hogy ha html fajlt nyitok, akkor miert kell .php-t irni a vegere, es miert nem jo ha php fajlt nyitok, es annak a vegere irom be a .php-t)"
Heh? Erre lásd előbbi bekezdésem."Tehat en most ugy hiszem, hogy amikor megkerdeztem hogy nem -e hulyeseg az hogy a megnyitott html fajlt mentem el .php kiterjesztessel, akkor jogos volt a gyanum, miszerint igen is hulyeseg volt"
Sajnos a gyanúd alaptalan.
-
#16436
Sk8erPeter
nagyúr
Speeedfire
#16422
Sk8erPeter
nagyúr
válasz
Speeedfire
#16422
üzenetére
"Semmi extra, szívből jött.
Néha unalmas, hogy mindenki lehúzza a php-t, holott a legtöbb weblap ez fut. Vannak hibái, de nem szabad elfelejteni, hogy folyamatosan fejlesztik."
Ja értem, tehát szerinted egy szakmai véleményre személyeskedéssel válaszolni pont jó reakció... De örülök, ha ezzel hozzájárulhattam a boldogságodhoz.
Az nem túl erős érv a nyelv jósága mellett, hogy a weboldalak nagy része PHP-ben íródott. Minden jöttment hostingcég is kínál PHP-futtatási lehetőséget olcsón vagy akár ingyen (egy domainnévért cserébe, bár ASP.NET-nél is vannak akár ingyenes lehetőségek, persze korlátokkal), a PHP ingyenes, open source, relatíve könnyű nekiesni a fejlesztésnek a segítségével, a felkapottsága további népszerűséget generált, PHP-fejlesztőből pedig iszonyat sok van, csak a mennyiség ugye nem mindig minőség. Természetesen sok előnye van a PHP-nek, pl. pont a népszerűségéből következő nagyon komoly támogatottsága. Viszont a gyengén típusossága és a nyelv helyenkénti koncepcionális hibái hátrányosak és idegesítőek tudnak lenni. Tudod, hogy én is fejlesztgetek benne, de ettől még látom a hibáit (és szerintem semmiben nem jó az elvakultság). Ja, de tudom, most akkor az erre a szerinted jó reakció, hogy húzzak el, nem fogsz hiányolni. -
#16435
honda 1993
senior tag
PumpkinSeed
#16433
honda 1993
senior tag
válasz
PumpkinSeed
#16433
üzenetére
Amikor meg nem mukodott akkor azt is megneztem, es termeszetesen a 80-as port volt beallitva.
Tehat a lenyeg hogy csak megoldottam, de ettol fuggetlenul is Koszonom hogy megint turelmesek voltatok.
(Bar talan nem pofatlansag azt allitani hogy jelen esetben nem csak az en hulyesegem volt a problema forrasa.)
-
#16434
honda 1993
senior tag
honda 1993
senior tag
Koszonom, de megoldottam.
Az erdekesseg kedveert leirom hogy mi volt a problema.
A tanacsotokat kovetve letrehoztam egy uj HTML fajlt, aminek .php kiterjesztest irtam a vegere.
(Es itt megjegyeznem, hogy direkt kerdeztem hogy ha html fajlt nyitok, akkor miert kell .php-t irni a vegere, es miert nem jo ha php fajlt nyitok, es annak a vegere irom be a .php-t)
Szoval ezek utan fogtam, es szepen a <body></body> reszbe irtam be egy rovidke kis php kodot.
Aztan most veletlen eszrevettem hogy a php storm-ban a fajl neve ez lett: "index.html.php" ( hiszen HTML fajl lett megnyitva). Es ennek a HTML fajlnak adtam .php kiterjesztest.
Tehat en most ugy hiszem, hogy amikor megkerdeztem hogy nem -e hulyeseg az hogy a megnyitott html fajlt mentem el .php kiterjesztessel, akkor jogos volt a gyanum, miszerint igen is hulyeseg volt.
-
#16433
PumpkinSeed
addikt
honda 1993
#16430
PumpkinSeed
addikt
válasz
honda 1993
#16430
üzenetére
Milyen portra van állítva a webservered?
Próbáld meg, hogy localhost:80, vagy azt a portszámot adod meg amire állítva van.
Vagy kipróbálod végre azt a rohadt USBWebservet.
-
#16432
tothjozsi96
addikt
honda 1993
#16431
tothjozsi96
addikt
válasz
honda 1993
#16431
üzenetére
Egyáltalán a favicon megjelenik a böngészőből?
-
#16431
honda 1993
senior tag
fordfairlane
#16429
honda 1993
senior tag
válasz
fordfairlane
#16429
üzenetére
Ertem, azonban itt nincs ilyen mappa, arra viszont mar gondoltam hogy a www mappaban levo dolgokat kitorlom, lehet hogy azok kavarnak be.
Ezek vannak a www mappaban : favicon , index ( ez nem az altalam letrehozott index) ,es egy testmysql fajl is talalhato meg ugyanitt, a www mappan belul.
tehat : favicon, index, testmysql.
es itt van meg az altalam letrehozott valami mappa is, amin belul az index.php van. -
#16430
honda 1993
senior tag
tothjozsi96
#16428
honda 1993
senior tag
válasz
tothjozsi96
#16428
üzenetére
"Remélhetőleg tartalmaz ékezetet vagy valami ilyesmit?
Most nem értem, tehát tök egyszerű a használata.
Veled van a hiba, ez biztos."Tehat mar megint itt tartunk, hogy tok egyszeru, es megis csak ennyit kapok valaszkent, hogy (velem van a problema).
De mivel mindent reszletesen leirtam, (meg a hibauzenetet is bemasoltam, es csak annyit mondasz hogy "pedig ez tok egyszeru es veled van a baj") akkor azert felmerul a kerdes, hogy miert nem kapok toled erdemleges valaszt ?
Egyebkent nem tartalmaz semmi fele ekezetet.WWW mappban van egy valami mappa, ezen belul van az index.php.
Bongeszobe pedig beirom az alabbi szoveget : localhost/valami/index.php
probaltam mar igy is: localhost/www/valami/index.php es igysem tudtam mukodesre birni.
-
#16429
fordfairlane
veterán
honda 1993
#16425
fordfairlane
veterán
válasz
honda 1993
#16425
üzenetére
Én a XAMPP installt úgy szoktam kezdeni, hogy a webroot mappát kitörlöm, utána pakolom oda a saját cuccaimat.
-
#16428
tothjozsi96
addikt
honda 1993
#16427
tothjozsi96
addikt
válasz
honda 1993
#16427
üzenetére
Remélhetőleg tartalmaz ékezetet vagy valami ilyesmit?
Most nem értem, tehát tök egyszerű a használata.
Veled van a hiba, ez biztos. -
#16427
honda 1993
senior tag
Peter Kiss
#16426
honda 1993
senior tag
válasz
Peter Kiss
#16426
üzenetére
A www-ben van egy valami mappa, es a valami mappan belul van az index.php .
-
#16426
Peter Kiss
őstag
honda 1993
#16425
Peter Kiss
őstag
válasz
honda 1993
#16425
üzenetére
Ha az index.php a www-ben van, miért pakolod be az útvonalba a "valami"-t?
-
#16425
honda 1993
senior tag
honda 1993
senior tag
Udv. Sokat probalkoztam ,de valami nem stimmel.
A xampp helyett felraktam a wampservert, es miutan online van, beirom hogy localhost. ( itt meg mukodik ), de aztan amikor beirom a pontos eleresi utvonalat, akkor valamiert hibauzenetet dob ki.
Not Found
The requested URL /valami/index.php was not found on this server.
Apache/2.4.9 (Win64) PHP/5.5.12 Server at localhost Port 80Az eleresi utvonal 100% hogy jol van megadva. ( az index.php fajl a "www" mappaban van)
En arra gondoltam hogy meg be kell allitani valamit a wampwerverben, de sajnos fogalmam sincs hogy mi lehet a problema, mert ha csak localhostot irok, akkor rendben van a dolog. ( csak akkor kapok hibauzenetet , amikor a php kodot szeretnem futtatni )
Legyszives segitsetek hogy megis mi lehet a problema, mert egyszeruen nem jovok ra.
-
#16424
Speeedfire
félisten
fordfairlane
#16423
Speeedfire
félisten
válasz
fordfairlane
#16423
üzenetére
De, valóban OE. Félreírtam.
-
#16423
fordfairlane
veterán
Speeedfire
#16422
fordfairlane
veterán
válasz
Speeedfire
#16422
üzenetére
idén is a BME keretein belül. Nem az OE-n?
-
#16422
Speeedfire
félisten
Sk8erPeter
#16420
Speeedfire
félisten
válasz
Sk8erPeter
#16420
üzenetére
A beépített webszerver egy nagyon gyors megoldás, nyilván nem tud annyit, mint egy apache, de bele lehet fejleszteni.
Mi ez a túláradó jóindulat?
Úgy örülök, hogy hosszú idő után megjelentél, hogy gyorsan lecsapj erre a lehetőségre...
Semmi extra, szívből jött.
Néha unalmas, hogy mindenki lehúzza a php-t, holott a legtöbb weblap ez fut. Vannak hibái, de nem szabad elfelejteni, hogy folyamatosan fejlesztik. Aki nagyon bele akar mélyülni, írhatja a kódot akár zephir-ben is. Ott meg még a sebességgel sincs gond.
Hosszú idő, nem is olyan rég írtam, hogy lesz webconf idén is a BME keretein belül. -
#16421
Zedz
addikt
Sk8erPeter
#16420
Zedz
addikt
válasz
Sk8erPeter
#16420
üzenetére
Most milyen nyelvel dolgozol? Valamilyen C? Java?
-
#16420
Sk8erPeter
nagyúr
Speeedfire
#16419
Sk8erPeter
nagyúr
válasz
Speeedfire
#16419
üzenetére
Amire reagáltál, abban mondjuk én a webszerver megírására gondoltam, nem a kész progi elindítására, mármint ez csak azért volt érdekes, mert nem valami mágia van a hordozható webszerver mögött sem. De végül is ez a beépített webszerver is ezt igazolja.
Mi ez a túláradó jóindulat? Úgy örülök, hogy hosszú idő után megjelentél, hogy gyorsan lecsapj erre a lehetőségre... (#16418) Zedz :
Áh, hosszú, bevallom, lusta vagyok összeszedni a szempontokat, volt is már sok szó a topicban a nyelv furcsaságairól, a gyengén típusosságából és magának a nyelvnek a hibáiból vagy rossz koncepcióiból sok kényelmetlenség adódik. De az tény, hogy nekiesni magának a fejlesztésnek pofonegyszerű a segítségével, ez előnye is és hátránya is egyben. -
#16419
Speeedfire
félisten
Sk8erPeter
#16416
Speeedfire
félisten
válasz
Sk8erPeter
#16416
üzenetére
Ugyan erre gondoltam, mint amit linkeltél.
Nyugodtan menj át dotnet fejlesztőnek, nem fogunk hiányolni. -
#16418
Zedz
addikt
Sk8erPeter
#16416
Zedz
addikt
válasz
Sk8erPeter
#16416
üzenetére
Miért gondolod így?
-
#16417
fordfairlane
veterán
PumpkinSeed
#16410
fordfairlane
veterán
válasz
PumpkinSeed
#16410
üzenetére
A XAMPP feltelepítésénél ez sem egyszerűbb. Annyi az egész, hogy next-next-finish. Ja, és meg kell jegyezni, hogy webroot alaphelyzetben a C:\xampp\htdocs. Van hozzá control panel, ahol indíthatod, service-ként regisztrálhatod a megfelelő komponenst. Eddig még nem láttam olyan embert, akinek problémát okozott volna a XAMPP üzembehelyezése.
-
#16416
Sk8erPeter
nagyúr
Speeedfire
#16415
Sk8erPeter
nagyúr
válasz
Speeedfire
#16415
üzenetére
Hát biztos, én abban tuti nem csinálnék.
(Mondjuk az is igaz, hogy minél többet tevékenykedik az ember tisztességes programozási nyelvekben, annál kevésbé vágyik pl. PHP-ra. ) Amúgy van ilyen is:
http://php.net/manual/en/features.commandline.webserver.php
"As of PHP 5.4.0, the CLI SAPI provides a built-in web server." -
#16415
Speeedfire
félisten
Sk8erPeter
#16414
Speeedfire
félisten
válasz
Sk8erPeter
#16414
üzenetére
PHP - ban is nagyon egyszerű webszervert csinálni.
-
#16414
Sk8erPeter
nagyúr
DNReNTi
#16412
Sk8erPeter
nagyúr
válasz
DNReNTi
#16412
üzenetére
"hogy fut szolgaltataskent?"
Úgy, hogy nem szolgáltatásként fut...
Egy nagyon egyszerű webszervert például Javában vagy C#-ban is össze lehet dobni elég rövid idő alatt. (Most azért írtam pont ezt a két nyelvet, mert ezekhez aztán tényleg nem kell különösen megerőltetnie magát az embernek, hogy összehozza, meg nem szükséges n+1 library-t keresgélni. Meg azért, mert Javában már szórakoztam ilyennel.) Szokásos alkalmazásként fut (ergo nem szolgáltatásként, ami felhasználói belépéstől függetlenül is tudna futni), fogadja és feldolgozza a kéréseket.
Most ez csak azért érdekes, mert azért nem akkora mágia, hogy hogyan tud portable módban futkorászni.Hogy érted, hogy hogy kezel aliasokat? URL aliasokra gondolsz? Vagy a VirtualHostokra?
============
(#16410) PumpkinSeed :
Használtam már XAMPP-ot, nem ennyire szenvedős...============
(#16407) honda 1993 :
Az ilyen szintű türelmetlenség valóban nem nagy erény egy fejlesztőnél. Már feltettem a költői kérdést a másik topicban, mit csinálsz majd, amikor ennél sokkal komplexebb problémákat kell megoldani, meg ennél milliószor bonyolultabb dokumentációkat kell olvasni,hogy megértsd valaminek a működését, és hogy tudj is fejleszteni hozzá? (Mondjuk egy keretrendszer, egy API, egy library vagy akármicsoda.) -
#16412
DNReNTi
őstag
PumpkinSeed
#16410
DNReNTi
őstag
válasz
PumpkinSeed
#16410
üzenetére
Mondjuk a PHP 5.3 engem nem gyoz meg. Meg hogy kezel igy alias-okat? Vagy hogy fut szolgaltataskent?
-
#16411
tothjozsi96
addikt
PumpkinSeed
#16409
tothjozsi96
addikt
válasz
PumpkinSeed
#16409
üzenetére
Amúgy szerintem biztonságilag nincs vele baj, főleg ha az alapja jól megvan írva.
Ellenőrizd hogy minden rendben van-e ... -
#16410
PumpkinSeed
addikt
honda 1993
#16407
PumpkinSeed
addikt
válasz
honda 1993
#16407
üzenetére
Egyetlen kérdésem lenne. Mit szenvedsz a XAMP-al mikor ott van ez a portable webserver. Letöltöd és megy. Nincs baszakodás a konfigurálással, nincs baszakodás a telepítéssel. De ha jól emlékszem már tanácsoltam egyszer.
-
#16409
PumpkinSeed
addikt
Sk8erPeter
#16367
PumpkinSeed
addikt
válasz
Sk8erPeter
#16367
üzenetére
Van amúgy valamiféle biztonsági rés ilyen téren, ha ez túl magasra van állítva?
(#16359) tothjozsi96
Lehet felveszem 3 évre és akkor nem fog sűrűn ledobálni.
-
#16408
#81999360
törölt tag
honda 1993
#16407
#81999360
törölt tag
válasz
honda 1993
#16407
üzenetére
Ha 5 év múlva is így fogsz viselkedni, akkor lehet
-
#16407
honda 1993
senior tag
Sk8erPeter
#16406
honda 1993
senior tag
válasz
Sk8erPeter
#16406
üzenetére
Hat ez nem igaz.
olyanok vagytok mint az elefantok XD. Sosem felejtetek el semmit.
5 ev mulva is a mostani baromsagaim miatt fogtok szivatni ?Egyebkent annyit bevallok, hogy a legnagyobb problemam az az hogy nagyon turelmetlen vagyok, es ha valamit nem tudok megoldani max 5 perc alatt, akkor maris rohanok segitsegert. ( Bar belatom hogy nem tul jo ez a hozza allas.)
-
#16406
Sk8erPeter
nagyúr
Peter Kiss
#16400
Sk8erPeter
nagyúr
válasz
Peter Kiss
#16400
üzenetére
Valszeg jól sejted.
(#16394) DS39 :
Teljesen mindegy, mindkettő kb. ugyanolyan, és nem kellene, hogy ekkora gondot jelentsen a beüzemelése. -
#16405
tothjozsi96
addikt
tothjozsi96
addikt
Valaki tudna ebben segíteni?
Például: 310722 nap - 07:25:05
Ez egy olyan érték ami adatbázisból van kiolvasva, de külön adatbázis bejegyzésekből.
És ezt a felhasználó generálja, de viszont van amikor 1 nap alatt bekerül az adatbázisba mondjuk 10x hogy 5 óra.
Tehát 10x 5 órán keresztül megnyitott mondjuk valamit, ilyesmire kell gondolni, és én ezt 5 órának akarom elkönyvelni, nem pedig 50-nek.Mivel ez egy ilyen összesített érték lenne.
Remélem valaki érti.
-
#16403
fordfairlane
veterán
Peter Kiss
#16400
fordfairlane
veterán
válasz
Peter Kiss
#16400
üzenetére
Hát szerintem is, de én már inkább bele sem szólok, mert akkor megint keletkezik még ezer hsz, mire egy XAMPP install összejön. Eleve a localhost miért a xampp/htdocs/valami/-re mutat, már ez nem kerek, de nem, erős vagyok, nem szólok közbe, nem kérdezek rá. Eleve ha valaki ennyire nem ért hozzá, minek választ custom installt...
-
#16402
#81999360
törölt tag
Peter Kiss
#16400
#81999360
törölt tag
válasz
Peter Kiss
#16400
üzenetére
Eddig minden webes topikban piszkálták valamiért, ne bántsd már itt is.
-
#16401
honda 1993
senior tag
Peter Kiss
#16400
honda 1993
senior tag
válasz
Peter Kiss
#16400
üzenetére
Nem tudom, ha igy erzed akkor olvass sok konyvet.
Ez mondjuk szvsz egy sima weboldal eseteben mar agyuval a verebre kategoria.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
"
Az igazából nem tudom, hogy jött ide, a lényeg az volt, hogy a célkönyvtárba tudsz-e írni. (file_put_contents() használatát javasoltam) Gondolom valóban nem létezik a people.txt fájl, vagy még mindig rosszul adod meg az elérési útvonalat... Ez esetben nem ártana, ha elmondanád, hogy milyen a könyvtárszerkezet (mi hol van), akkor még meg is tudnánk mondani, mit rontasz el.
), de ettől még lehet.)
Új hozzászólás Aktív témák
Hirdetés
- Beszámítás! Apple iPad 11 2025 128GB WiFi tablet garanciával hibátlan működéssel
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025)- 3 Ciklus-3 év gari - MAGYAR
- LG 65BX - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- REFURBISHED - DELL Thunderbolt Dock WD19TBS docking station (210-AZBV)
- Corsair K100 Air wireless (CH-913A01U-DE) DE SN - A1E4G325503IVC
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest