Aktív témák
-
Lortech
addikt
:: akkor kell, ha nem peldányon keresztül akarsz (tudsz) elérni egy mezőt (pl konstans az ''static'') vagy osztályszintű függvényt. Vagy ha felülírod az ős egyik metódusát a kiterjesztett osztályban, akkor ezután az ős::ős_eredeti_metódusa névvel tudsz rá hivatkozni.
tehát a osztaly_2 definiálásánál meghivom az osztaly_1 et és használom ahogy kell?
Nem meghívod, hanem deklarálsz egy osztaly_1 típusú mezőt, majd definiálod / példányosítod, és rajta keresztül elérheted a függvényeit. Vagy ha osztályszintű függvényekről van szó, akkor erre sincs szükség, egyszerűen csak osztaly1::fgv névvel hívhatod a függvényeit.
[Szerkesztve] -
#4991
Lortech
addikt
Tele von Zsinór
#4989
Lortech
addikt
válasz
Tele von Zsinór
#4989
üzenetére
Vagy a substr_count fv.
Megelőztek.
szicsu: pl. egyik lehetséges megoldás az öröklődés kiküszöbölésére az objektum összetétel. Felveszel egy olyan típusú mezőt az osztályba, aminek a függvényeit használni akarod.
Pl. osztály1 {}
osztály2
{
osztály1 peldany;
}
[Szerkesztve] -
Lortech
addikt
Fgets sorvégéig olvas (ha nem adsz meg hosszt paraméternek), és mivel csak egyszer fut le (nem tetted ciklusba), ezért nyilván csak az első sor végéig fogja kiírni a fájl tartalmát.
Fgets manuáljában az első példában szépen le van írva ami neked kell: [link]
A fájl megnyitása is szebb megoldás, mert a handleben úgyis null lesz, ha nem sikerült megnyitni, mert fopen azt fog visszaadni ha gond van. Valamint a file_exists nem feltétlenül elegséges a megnyitáshoz, mert ha éppen használatban van akkor nem lehet írásra megnyitni, és egyből hibát kapnál fopennél pedig file_exists-en átment.
<?php
$handle = @fopen(''/tmp/inputfile.txt'', ''r'');
if ($handle) {
while (!feof($handle)) {
$buffer = fgets($handle, 4096); // a második paraméter nem feltétlenül kell neked
echo $buffer;
}
fclose($handle);
}
?>
[Szerkesztve] -
-
#4770
Lortech
addikt
Tele von Zsinór
#4769
Lortech
addikt
válasz
Tele von Zsinór
#4769
üzenetére
Persze, hogy csak akkor rakja be ha eljut addig a vezérlés. Viszont ez mindkettőnél ugyanúgy van! Szerintem.
Gondolj bele, hogy lehetne futás előtt / nélkül kiértékelni egy esetleges if-et aminek feltétele alapján kell require()?
Pl1:
<?php
echo ''fute'';
if (false) require_once(''valami.php'');
echo ''fute'';
?>
Kimenet : ''futefute'', és nem történik olvasás, próba sincs! Akár létezik valami.php, akár nem.
Pl2:
<?php
echo ''fute'';
if (true) require_once(''valami.php'');
echo ''fute'';
?>
Kimenet : ha nem létezik valami.php, akkor: ''fute'' aztán warning majd fatal error, és itt meg is áll, a második echo már nem fut le. Ha létezik valami.php, akkor: ''fute beincludeolt valami fute''.
Van olvasási próba mindkét esetben értelemszerűen, de csak amikor ráesett a vezérlés.
Ha utóbbi példában require helyett include lenne, és nem találja a fájlt, akkor kimenet fute warning fute.
Szóval nem futás előtt rakja be a require se.
[Szerkesztve] -
Lortech
addikt
válasz
Korcsii
#4767
üzenetére
Manuál elég jól leírja őket, röviden.
Hibakezelésben különbözik a require és include. Ha require-rel megadott fájlt nem lehet betölteni, akkor az fatal errort okoz, és leáll a futás, ha csak simán include lett volna, akkor csak warningot ad, de megy tovább a futás. A -_once párja ugyanez, annyi különbséggel, hogy csak egyszer töltődhetnek be, hiába többször vannak esetleg meghívva ugyanarra a fájlra, csak az első alkalommal lesz beszúrva a fájl.
Alkalmazásuk a leírt különbségekből adódik szerintem. -
Lortech
addikt
válasz
tkazmer
#4606
üzenetére
Nem értem, mi lehet. Én azzal az egy darab ;-vel ki be tudom kapcsolni a modult, semmi mást nem csinálok. Ugye az extensionöknél az mbstring előrébb van mint az exif? Alapból így van, de a biztonság kedvéért, hátha. Tényleg nem értem.
Saját magad raktad fel külön-külön a szervereket vagy valami webszerver csomag?
[Szerkesztve] -
Lortech
addikt
válasz
tkazmer
#4604
üzenetére
Nem értjük egymást, ez nem fogja megoldani a problémádat a modul betöltésével, viszont így látni fogod, hogy a php.ini módosításának van-e hatása. Mert ha nincs akkor mégiscsak valami nem kóser a beállításával, ha rendben változik a phpinfo()-nál amit változtattál, akkor nincs ötletem.
-
#4600
Lortech
addikt
Tele von Zsinór
#4597
Lortech
addikt
válasz
Tele von Zsinór
#4597
üzenetére
Én is jártam így régebben, a php könyvtárban lévőt módosítgattam, de a windows könyvtárban lévővel dolgozott.
tkazmer: tipp: írj át valami más beállítást a php.ini-ben, és nézd meg phpinfo-val, hogy változott-e. -
Lortech
addikt
Nincs ilyen definiálva nyelvi szinten, nem is igen lehet egy ilyen típusú nyelvnél.
Vannak viszont reguláris kifejezésekkel operáló függvények.
[link]
Nekem nem világos egyébként a példád alapján, hogy mi a célod a joker karakterekkel. Milyen mintát akarsz illeszteni mire? Mit ismersz (hossz vagy minta), mi az output stb. -
Lortech
addikt
Én nem mondtam, hogy szét kell venni két változóra, úgy helyes ebből a szempontból ahogy raczger leírta. A +változó vsz. még mindig kisebb bünti, mint a kétszeres függvényhívás, ami cserébe még matematikailag is hibás.
A példádon miért kéne szétvenni két változóba? Itt még egy változó sem kell, mivel csak egy date hívás és csak egyetlen logikai kif. van. Ez így jó ahogy van.
[Szerkesztve] -
Lortech
addikt
<= 7 az nem jó, mert akkor a 7 óra után de még 8 óra előtt is megfelelne a feltételnek.
Valamint a változó kiküszöbölése gyakorlatban 99.9..%-ban helyes ugyan, de programozástanilag helytelen, mivel a két fgv hívás eltérő eredményt adhat, és így matematikai esélye van, hogy rossz eredményt adjon a script.
[Szerkesztve] -
#4475
Lortech
addikt
Tele von Zsinór
#4473
Lortech
addikt
válasz
Tele von Zsinór
#4473
üzenetére
Úgyis csak 32 lesz belőle használva.
... és varchar esetén úgyis csak annyi lesz eltárolva, nem 120. Szóval nincs jelentősége, kivéve ha char típust választott. -
Lortech
addikt
válasz
raczger
#4340
üzenetére
Le van írva nagyjából a megoldás. Magát a session cookie-t úgy kell beállítani, hogy x ideig legyen jó , meg a session élettartamát is x időre kell állítani.
pl:
session_set_cookie_params(x);
ini_set('session.gc_maxlifetime', x);
session_start();
Problémák: -a cookieban nem lehet megbízni, bármikor eltűnhet.
-a cookie x ideig élni fog, ha a böngésző (/user) ki nem szedi, de a session nem feltétlenül x ideig fog élni, mert mint írtam az előző hsz-ben, ha pont az adott sessionnel volt egy php futás / lekérdezés, akkor annak a sessionnek az élettartama kezdődik újból, ez nem is lenne baj, lehet hogy pont ez a jó, viszont a cookie lejárata marad a session létrehozása + x idő. Szóval meg kéne minden lekérdezéskor újítani x időre a cookie-t, hogy szinkronban legyenek. -
#4337
Lortech
addikt
Tele von Zsinór
#4333
Lortech
addikt
válasz
Tele von Zsinór
#4333
üzenetére
Azt is. Meg azt is, hogy kézzel írod be a sid cookie-t, és saját magad rendeled össze egy sessionnel, aztán adatbázisból vagy fájlból szeded ki a hozzá tartozó adatokat ''kézzel''. Vagy módosítod a session dirt, és akkor már saját magadnak kell gondoskodnod a takarításról, mert nem szedi ki a gc. Elég sok bajom volt a php-s munkamenetkezeléssel, nehéz jól kiismerni. Főleg ez az élettartamos megoldás zavart:
-minden lekérdezésnél a php.ini-ben megadott valószínűségi érték alapján lesz gc takarítás, vagy sem. Ez a valószínűség alapesetben (session.gc_probability = 1
session.gc_divisor = 100) 1 / 100, 1%. Ha épp bekövetkezik egy gc, akkor azokat a sessionöket kiszedi, amiknek a session.gc_maxlifetime -ja meghaladta a megadott értéket. De ha épp az a session hívódott meg, aminek már egyébként lejárt volna az élettartama, és épp gc-t sikerült produkálnia, akkor sem bontódik le, hanem indul újra a számlálója. Ezért írtam sajátokat, amik azt csinálták mindig, amit akartam. Ez félig már válasz raczger kérdésére is. session.gc_maxlifetime-ot két hétnek megfelelően kell állítani, hogy ne takarítsa ki. De én továbbra is lebeszélném egy ilyen megoldásról egy publikus oldal esetén. Mi van, ha nyilvános géptermekből, netcaféból használják az oldalt? Ha véletlenül nem lépnek ki szabályosan, akkor bárki más belép az oldalra ugyanarról a gépről, és látja, hogy hoppá, be vagyok jelentkezve más néven, változtassuk csak meg a jelszót, meg írjunk hülyeséget, hogy bannolják az eredeti tulajt.
Benmartin: Attól, hogy nem olvastál setcookie-ról a munkamenet kapcsán, a SID cookie ugyanolyan cookie bejegyzés, mint a többi, és a háttérben egy setcookie-val állítódik be, vagy egy nagyon hasonló függvénnyel.. Persze nem mindig van így, mert mint helyesen mondtad van, amikor url-ből vagy űrlapból van átküldve a sid. De te is megemlíted, hogy ''amit lehet sütiben...'' stb., akkor meg nem értem, mi a probléma. Valami félreértés lehet, én egy szóval nem mondtam, hogy a munkamenet adatok ügyfél oldali cookieban tárolódnak, csak a szerver oldalon tárolt munkamenet adatokkal az összerendelést megvalósító SID v. PHPSESSID egy ugyanolyan cookie mint a többi. (már amikor cookie-ban tárolódik a SID)
[Szerkesztve] -
#4327
Lortech
addikt
Tele von Zsinór
#4326
Lortech
addikt
válasz
Tele von Zsinór
#4326
üzenetére
Nekem nem kell bemutatni a session működését. Csináltam én már mindenhogy, többféleképpen saját megoldással is, beépítettel is. Meg egyébként is, ''sima'' cookies megoldás alatt nem csak a kliens oldali session adattárolást lehet érteni (ami egyszerűen nem lehet megoldás semmilyen esetben sem), hanem akár ugyanazt, ahogy a session is van, csak saját session kezeléssel.
Utólag is gratulálok az indexes programozónak.
Én is javítottam már ki több ismerősöm munkáját hasonló okokból, jellemzően munkamenettel és biztonsággal foglalkozom. Volt aki bedobta simán cookieba a usernevet, de még a uid-t is, én meg 20mp alatt admin voltam. Jellemzően munkamenettel és biztonsággal foglalkozom. -
#4324
Lortech
addikt
Tele von Zsinór
#4323
Lortech
addikt
válasz
Tele von Zsinór
#4323
üzenetére
Aha, úgy látszik, hogy te gondoltad jól, nekem nem állt rá az agyam, mert több szempontból is nonszensz ötlet. Példakódnak vagy nagyon speciális környezetben elképzelhető ilyen, de egy publikus oldalon elég merész.
Benmartin: vagy amíg ki nem rakja a sessiont a gc. Másik, hogy a session is süti. -
#4320
Lortech
addikt
Tele von Zsinór
#4319
Lortech
addikt
válasz
Tele von Zsinór
#4319
üzenetére
Szerintem ( vagy remélem ) nem arra gondolt, hogy ebben a kliens oldali cookieban tárolja a sessionhöz tartozó felhasználónevet, hanem hogy itt is, de ez csak arra legyen használva, hogy emlékezzen a felhasználóra. Úgy értve, hogy a cookie tartalmát alapból belerakja a login textboxba, hogy majd azzal lehet bejelentkezni, de közben a két hét alatt nem marad bejelentkezve az illető.
De azt nem tudom, hogy a kérdező eredetileg mire gondolt: belépve maradjon-e az illető és jegyezze meg a sessiont, vagy csak a user + jelszót aztán be lehessen lépni vele, vagy csak a legutóbb bejelentkezett felhasználó nevét jegyezze meg..(?) Én utóbbira tippeltem. -
-
Lortech
addikt
válasz
Benmartin
#3601
üzenetére
Összehasonlító operátorra akkor sincs szükség, mivel maga a változó logikai és a változó vagy a negáltja a szükséges feltétel. A !== -re meg főleg nincs, teljesen felesleges logikai kifejezést kreálni belőle, típus(nem)egyezés vizsgálat meg megint értelmetlennek tűnik, mivel a true egy literál, típusa adott.
Működni persze működik. -
Lortech
addikt
A szerző odaírhatott volna egy dátumot a cikkéhez. Mert a java (nyelv) fejlesztők sem a töküket vakargatják azért. Sok gyermekbetegségét kinőtte az idők folyamán, és nem igazán lehet egy ilyen témáról örökérvényű cikket írni. A főcímmel problémáim vannak, mert a két nyelvet (java, c++) hasonlítja össze, pedig az nem egyenlő feltétlenül a megvalósításaival. Egy .net c++ köztes kód sem lehet olyan gyors, mint egy virtuális futtatórendszer közbeiktatása nélkül futó natív c++ kód. Nyilván nem azt akartam mondani, hogy milyen überbrutál jó és gyors a java (akkor én is azt használnám), hanem hogy összevehethető a többi mai nyelvvel, és a régi szemlélet, hogy java=szar lassú, nem hatékony program, már idejétmúlt. Természetéből és technikájából fakadóan sosem lesz gyorsabb az a Java, amiről beszélünk, mint egy közvetlen bináris kód, de azzal nem értek egyet, hogy nagyságrendileg azonos sebességet nem lehet (majd) elérni vele.
No de ez itt a php topik.. -
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De azért te is elrontottad.. 
Aktív témák
Hirdetés
- 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
- Kerékpárosok, bringások ide!
- AliExpress tapasztalatok
- Hitelkártyák használata, hitelkártya visszatérítés
- Napelem
- 3D nyomtatás
- További aktív témák...
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- BESZÁMÍTÁS! Apple MacBook Pro 16 M4 Pro 24GB RAM 512GB SSD - garanciával hibátlan működéssel
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Honor Pad X8 64GB, Wi-Fi, 1 Év Garanciával
- Xiaomi Redmi Note 13 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged