- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- Milyen TV-t vegyek?
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Léghűtés topik
- Nvidia GPU-k jövője - amit tudni vélünk
- Bluetooth hangszórók
- Hobby elektronika
- NiMH akkumulátor
- AMD Navi Radeon™ RX 5xxx sorozat
Új hozzászólás Aktív témák
-
#6644
Sk8erPeter
nagyúr
lesaux
#6643
Sk8erPeter
nagyúr
Ha megmutatod, hogyan használod a mail függvényt (akár kicsillagozva is lehetnek persze az adatok), segítünk, hogyan ültesd át PHPMailerbe ugyanezt.
Igazából azért érdemes ilyen kicsit komplexebb levelezőrendszerbe átrakni (ott van még a SwiftMailer is, az is nagyon jó!), mert nagyon könnyű testreszabni, és a fejlesztői elég sok mindenre gondoltak, így megoldották az általánosan jellemző problémák nagy részét, amivel emiatt a levelezőosztályt felhasználóknak nem kell szenvedniük. -
#6642
Sk8erPeter
nagyúr
lesaux
#6639
Sk8erPeter
nagyúr
Nem, a PHPMailer nem "telepítős", hanem csak fel kell másolni tárhelyre a PHPMailer osztálynak a megfelelő fájlját (legyen pl. class.phpmailer.php
), az osztályt a megfelelő helyen include-olni, példányosítani, beállítgatni a különböző dolgokat (küldő, fogadó, tárgy, tartalom, stb., sokkal kézenfekvőbb, mint a sima mail() függvénnyel szarakodás) és használni, és ennyi. 
Itt van egy egyszerű példa.Furcsa, hogy a vipmail visszadobja. Most hirtelen annyit tudok mondani rá, hogy akkor ne arra küldd.
De hogy értelmesebben reagáljak, meg tudod mutatni, hogyan használod a mail() függvényt? -
#6637
Sk8erPeter
nagyúr
lesaux
#6636
Sk8erPeter
nagyúr
itt van egy ilyen:
"511 sorry, can't find a valid MX for sender domain (#5.1.1): You must provide a valid domain within the From address contained in the sender's mail envelope. The sender's domain is considered to be valid if the lookup for an MX record succeeds. If no valid MX record exists, then our email system will assume that no mail should be accepted for a domain that can not receive email."szóval mintha a küldő cím (From mező) nem lenne érvényes.
Amúgy javaslom a PHPMailer osztály használatát, nagyon kézenfekvő a használata, és kicsit használhatóbb, mint a sima mail() függvény. -
#6627
Sk8erPeter
nagyúr
fordfairlane
#6626
Sk8erPeter
nagyúr
válasz
fordfairlane
#6626
üzenetére
Nem kell megsértődni, ha nem ért veled egyet valaki.
Szakmai vitának van értelme. -
#6625
Sk8erPeter
nagyúr
fordfairlane
#6623
Sk8erPeter
nagyúr
válasz
fordfairlane
#6623
üzenetére
"Jelen esetben pl. az isset hiánya nem okoz működési problémákat"
Csak rossz programozási gyakorlatot mutat be.
Pl. ha C-ben inicializálatlan változót próbálsz felhasználni, eléggé elszáll a progid (már ha a fordító nem jelez előre). (Ja, ez nem C, de szerintem azért vannak dolgok, amiket be kell tartani.)"a noticeok viszont sokszor akadályozzák, hogy haladj a munkában, vagy épp bemutass valamit a megrendelőnek stb."
Nem igazán értem, miért olyan nagy dolog kiiktatni a notice-okat. Eleve rossz a kód, ha ilyen előfordul benne, azt meg ki kell javítani. Legtöbbször ráadásul a notice-ok kiiktatása nem egy túl időigényes feladat, csak oda kell figyelni.(#6624) Tele von Zsinór:
"Igenis legyen E_ALL|E_STRICT, csak prod környezetben nem kiiratva, hanem logolva és fejlesztőnek automatikusan küldve."
Na ja, ez a legjobb megoldás, most már nekem is van egy hibakezelő osztályom, ami MINDEN hibát elkap, logol és elküld emailben nekem, hogy rögtön tudjak róla, és egyből tudjam javítani. Így a legjobb, nyilván a felhasználók 98%-a nem fogja jelezni a fejlesztőnek, hogy valami hibát tapasztalt az oldalon, screenshottal, hibajelenség leírásával kiegészítve, hanem egyszerűen másik menüpontra lép, vagy simán elhagyja az oldalt, mert elkezdi zavarni.
Az meg nem jó se a megrendelőnek, se a felhasználónak. -
#6621
Sk8erPeter
nagyúr
fordfairlane
#6620
Sk8erPeter
nagyúr
válasz
fordfairlane
#6620
üzenetére
Nem csak az elméletről beszélek... pont hogy eléggé gyakorlatias dolog az, hogy leszarod a notice-okat, aztán majd nézel, hogy mégis mi a francért nem egészen úgy működik a kódod, ahogy elvárnád...
-
#6619
Sk8erPeter
nagyúr
fordfairlane
#6618
Sk8erPeter
nagyúr
válasz
fordfairlane
#6618
üzenetére
De az ilyen jellegű notice-okat az ember nem véletlenül kapja, az az egészséges, ha ilyenek nincsenek, főleg, ha egyszerűen megoldhatóak. Még hacsak notice-ról is van szó, nagyon sokszor vezetnek az ilyet okozó apróbb hibák is nagyobb problémákhoz hosszú távon (tapasztaltam).
Szerk.: nyilván élesben működő oldalon ne legyenek bekapcsolva a notice-ok, fejlesztésnél, debuggolásnál viszont szerintem mindenképp - hogy még akkor megoldd ezeket, amikor kell, vagyis amíg nem élesben próbálod ki.
-
#6617
Sk8erPeter
nagyúr
fordfairlane
#6608
Sk8erPeter
nagyúr
válasz
fordfairlane
#6608
üzenetére
"vagy kapcsolt ki a notice-ok kijelzését."
Azért remélem ez csak vicc akart lenni.(#6609) Brown ügynök: ez komoly? ennyit fogtál fel abból, amit írtam?
Úgy látszik, kár volt jártatnom a számat, mivel utána pont azért hálálkodtál, amiről én is beszéltem korábban, sebaj, ezek szerint semmit nem értettél meg abból, amiről vakerásztam.
-
#6607
Sk8erPeter
nagyúr
Brown ügynök
#6606
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6606
üzenetére
Igazából most kb. ugyanazt írtad le, mint korábban...csak a lényegre nem válaszoltál.
A "másik kért url-nél" valszeg nincs beállítva a $_GET['id'], nem jó az átirányítás .htaccess-ből, vagy valami hasonló probléma van, mindenesetre ha a $_GET['id'] nem létezik, az 'id' indexen nyilván nem is fog elérni semmit a $_GET-ből, így kapsz egy notice-t.
Érdemes lenne inkább leellenőrizni minden esetben, hogy egyáltalán létezik-e a $_GET['id'] változó, be van-e állítva (isset), ezt átadni egy változónak, aminek minden esetben van valami ilyen default értéke - nem tudom, nálad hogy van megoldva, de lehetne egy alapértelmezett cikk, amire mutat, pl. cikk1, vagy cikk0, vagy csak simán cikk.
Példa:
$id = 0; // default érték, de úgy csináld meg, hogy stimmeljen, legyen alapértelmezett cím, amit ilyenkor megmutat
if( !empty($_GET['id']) ){ /// isset($_GET['id']) is lehetne, de így két legyet ütsz egy csapásra: ha nincs beállítva (!isset), ez az ág úgysem lesz igaz, ráadásul ellenőrzi, hogy nem üres-e; igazából ide még plusz ellenőrzéseket is illene betenni
$id = $_GET['id'];
}
if( $uri == ...........){
........
}
elseif ($uri == '/blog/cikk'.$id){
mutató_függvény($id);
}
.......Persze ez így nem igazán szép megoldás, hogy alapértelmezett cikk.$id útvonalat nyit meg, lehetne inkább pl. úgy megoldani, hogy amennyiben nincs beállítva a $_GET['id'] változó, akkor valami olyan oldalra irányít, ahonnan kiválaszthatja a felhasználó a kívánt cikket (esetleg hibaoldal, stb.).
Pl.
if( empty($_GET['id']) ){
mutatom_a_cikkeket_hogy_ott_valaszd_ki_fv( ); // ne legyen ekkora neve :D
}Így a korábbit csak azért írtam, hogy lásd, hogy a $_GET értékek meglétét MINDEN esetben ellenőrizni KELL, és annak megfelelően cselekedni, különben ha nincs beállítva (bármilyen probléma okán!), akkor NEM fog működni, legalábbis nem úgy, ahogy szeretnéd, és az ilyen lehetséges hibajelenségekre fel KELL készülni, hogy nagyjából minden hibalehetőséget kiszűrj. Ráadásul ellenőrzés nélkül közvetlenül átadni egy felhasználótól kapott adatot, a legrosszabb gyakorlat.
Remélem nem azt fogod most erre reagálni, hogy "de ez így akkor is működik, nem változtatok rajta".
Ha továbbra is fennáll a gond, akkor meg egy kicsit konkrétabb választ írj, ne ugyanazokat írd le másképp, amiket korábban. -
#6603
Sk8erPeter
nagyúr
Brown ügynök
#6602
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6602
üzenetére
Nem ártana tudni, hogy egyáltalán hogyan nyered ki adatbázisból a dolgokat, a $row['id'] vajon létezhet-e, a lekérés eredményeként megkapod-e az id-t, asszociatív tömböt kapsz-e a lekérdezés során, egyáltalán konkrétan melyik sornál jelentkezik a hiba, biztos nem a $_GET['id']-val van-e baja (a $row['id']-ra dobja a hibát?!), ha a $_GET['id']-val, akkor valszeg nincs ilyen rész a lekért URL-ben, ha a $row['id']-val, akkor rossz a lekérdezésed, stb... Ezeket nem árt tisztázni, legalábbis szerintem így csak sötétben tapogatózás.
-
#6591
Sk8erPeter
nagyúr
RedSign
#6590
Sk8erPeter
nagyúr
válasz
RedSign
#6590
üzenetére
Pont az imént volt szó róla.
>> [link]
kiegészítem, van még pl. a TIME() függvény is MySQL-ben, ami a konkrét időt szedi ki a time-ból vagy datetime-ból, a linken látható formában.
De itt találsz még rengeteg átalakító függvényt.
Érdemes már MySQL-ben átalakítva lekérdezni az eredményt, így annál kevesebbet kell majd átalakítgatni PHP-ból (persze úgy is lehet, de minek, ha megkaphatod nagyon gyorsan MySQL-ből is az eredményt formázva). -
#6589
Sk8erPeter
nagyúr
RedSign
#6588
Sk8erPeter
nagyúr
válasz
RedSign
#6588
üzenetére
"lehet, hogy PHP-ben pár karakterrel hosszabb a kód"
Már miért lenne hosszabb?
Pont azt mondtam, hogy így nyugodtan kihagyható az UPDATE esetén a kódból, hogy foglalkozz egyáltalán a dátum beállításával, vagyis PHP-oldalról nem kell lekérdezni az aktuális dátumot (pl. a date() függvény használatával), és ezt átadni az SQL-utasításnak - valamint SQL-ben sem kell mindig explicite odaírni a ´timestamp´=NOW() (ha ´timestamp´-nek nevezted el a mezőt) kódrészletet.
Magyarul így pont, hogy rövidül a kód (PHP-ben, SQL-ben sem foglalkozol a dátumbeállítgatással), ráadásul nem is felejted el beállítani a módosulást az időpontban, ha a default érték mindig az aktuális időpont. -
#6586
Sk8erPeter
nagyúr
Alukard
#6585
Sk8erPeter
nagyúr
válasz
Alukard
#6585
üzenetére
Ha már újratervezés, érdemes lehet megfontolni, hogy TIMESTAMP formában tárold az időpontot, az elég jól átlátható, könnyen kibányászható belőle az időpont (év-hónap-nap óra:perc:másodperc), meg beállítható úgy, hogy automatikusan frissüljön az aktuális időpontnak megfelelően, MySQL-nél:
CREATE TABLE `teszt_tabla` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`valami` VARCHAR( 256 ) NOT NULL DEFAULT 'blabla',
`timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_hungarian_ci;Vagy ha UPDATE-nél a `timestamp` = NOW() kódrészletet rakod bele a query-be (de mivel a fenti mutatott táblában a default a jelenlegi idő, ki is hagyható teljesen a kódból a timestamp beállítása).
Így talán egyszerűbb és átláthatóbb lehet a kódod, és ha nem PHP-ből kéred le az időt, hanem MySQL-ből, az nem valószínű, hogy túl sokáig foglalná az adatbázis esetleg korlátozott erőforrásait.Én mostanában legalábbis már így csinálom, gondolom mindkét gyakorlatra lehetne érveket felhozni. De a fentivel legalább semmiképp nem ronthatod el az időformátumot, meg nem kell babrálni annak a mezőnek a beállításával.
-
#6579
Sk8erPeter
nagyúr
klinnsy
#6575
Sk8erPeter
nagyúr
válasz
klinnsy
#6575
üzenetére
Példa a kód utólagos formázására:
http://beta.phpformatter.com/
>> Format >> Copy to Clipboard
http://pastebin.com
>> Syntax Highlighting: PHP
>> Submit
>> Eredmény: [link]Mondjuk ez nem változtat a tényen, hogy ocsmány a kód.
A lényeget Tele von Zsinór kolléga leírta. -
#6577
Sk8erPeter
nagyúr
klinnsy
#6575
Sk8erPeter
nagyúr
válasz
klinnsy
#6575
üzenetére
Jó, hát akkor használd a Programkód gombot (többek közt itt is leírtam, hogyan kell) a kódod kijelölése után, mert ilyen formázatlan, indentálatlan kódot kétlem, hogy bárki át fog nyálazni itt a topicban (hacsak nem rakja be mondjuk NetBeans-be vagy dobja be PHPBeautifierbe, stb, és autoformáz), én legalábbis biztosan nem. De persze előfordulhat, hogy valaki mégis veszi a fáradságot, de előbb inkább te tedd meg ugyanezt a kód megfelelő formázására.
Meg nem ártana, ha leírnád, te milyen körülmények közt próbáltad, mert a "Már néztem több gépről, nekem nem működött, mi lehet a baj?" mondatrészből számomra legalábbis nem derül ki. (Pl. egyáltalán működő webszerverrel próbáltad-e, te mit tapasztaltál, nálad mi történt, egyáltalán lefutott-e a PHP-kód, és így tovább...)Szerk.: csak belenézve a kódodba, számomra elég durván fájó kódrészletek vannak, pl. csak ez szúrt szemet:
echo "<tr><th><font color=ffffff size=2><div align=center>Válaszok</th><th><font color=ffffff size=2><div align=center>Szavazatok aránya</th><th><font color=ffffff size=2><div align=center>Szavazatok száma</th></tr>";
Eleve a <font> tag használata nagyon nem ajánlott ma már (CSS), na meg az attribútumok esetén eléggé ajánlott az idézőjelek használata, pl. align=center helyett align="center", de még jobb, inkább ezt az align attribútumot ne is használd. -
#6574
Sk8erPeter
nagyúr
Tele von Zsinór
#6573
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6573
üzenetére
Az lesz.
Csak egy kis idő kellene hozzá. Mondjuk egyelőre élvezem azt, hogy mindent megírok magamtól, aztán majd úgyis jól rájövök a komolyabb keretrendszerek használatakor, hogy nem biztos, hogy sok értelme van mindent ab ovo megírni, ha már más úgyis megtette helyettem, mert akkor nekem csak a megfelelő függvényeket kell jól hívogatnom, és a megfelelő módosításokat elvégezni, aztán gyorsabban kész vagyok.Igen, én sem úgy értettem, hogy MVC-t csak OOP-szemlélettel lehet írni (ezért is csak azt írtam, hogy "eléggé megkönnyíti a munkát az MVC-nél"), de szerintem procedurálisan megírva azért sokkal önszívatósabb, nehezebb átlátni.
Mondjuk nem véletlenül találták ki az OOP-t, ha már hasonlít az emberi gondolkodás működéséhez, használjuk is ki. -
#6572
Sk8erPeter
nagyúr
Tele von Zsinór
#6571
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6571
üzenetére
Sejtettem, hogy ilyesmi, meg értem én az MVC-szemléletet nagyjából, csak azt hittem, hogy nálad mégsem fordul elő az említett F5-ös frissítgetős probléma, és az nem állt össze, hogy hogyan lehet, ha nem redirectelgetsz minden esetben.
(de ezek szerint a probléma fennáll)
Szerintem az én koncepcióm sem mond amúgy ellent az MVC-szemléletnek.Mostanság igyekszem én is nagyjából errefelé tendálni, meg teljesen OOP-szemléletre átállni, ami szerintem eléggé megkönnyíti a munkát az MVC-nél (én legalábbis nehezen tudom igazán elválasztani tőle), bár még bőven van mit tanulnom.
-
#6570
Sk8erPeter
nagyúr
Tele von Zsinór
#6569
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6569
üzenetére
Igen, a keresés get-tel okés, ott nem para az esetleges frissítés, de még mindig vannak oldalak, ahol post-olják a keresőmezőben megadottakat (most hirtelen az ncore jut eszembe, ahol kifejezetten zavar). Meg ugye a get-tel történő kereséskor kapott cím lementhető, könyvjelzőzhető, átküldhető másnak, szóval ezer szempontból praktikusabb.
Az első felére reagálva: na, akkor úgy tűnik, félreértettem, sorry.
"a form actionja ugyanaz a file és függvény lesz" - innen elsőre úgy értelmeztem, hogy ugyanabba a fájlba irányítod vissza az adatokat, tehát ugyanott dolgozod fel.
"Ha invalid, vissza ugyanahhoz a view-hez, csak most már hibaüzenetek is vannak"
Ez hogy néz ki nálad a gyakorlatban?
Pl. van a foo.php fájl, amiben megtörténik a kiíratás (ezt a címet kérte le a júzer), és van egy formod:
<form action="bar.php" method="post" ..........>..........</form>
Ekkor az action szerinti bar.php fájlba irányítja át a formot. Itt csekkolod, hogy valid-e, ha nem, egyből kiíratod a formot? Mert akkor megint felmerül az F5-ös probléma. Vagy pedig van a foo.php fájl, és az action-ben is ugyanez a fájl található, és itt nézed meg a validitását? Igazából itt is felmerül az F5-ös para. A visszairányítós játéknál nyilván nincs ilyen probléma, de ott meg már elvész a post-olt adat (amennyiben nem mented sessionbe).Most hirtelen nem értem, hogyan éred el, hogy validálod az adatokat, fel tudod használni azonos kéréssel a $_POST tömb adatait (tehát a felhasználónak nem kell begépelnie újból azokat), kiíratod, nem mented el sessionbe a dolgokat, és még az F5-ös frissítgetős para sem merül fel?
-
#6568
Sk8erPeter
nagyúr
Tele von Zsinór
#6567
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6567
üzenetére
A felvázolt megoldásban nekem egyedül az nem szimpi (persze ízlés kérdése), hogy ugyanabban a fájlban történik a validálás, mint amiben a form kiíratása - én pont azért tértem át inkább arra, hogy még a validálás során is redirectelgetek (még ha nem is lenne feltétlenül muszáj/praktikus sessionben tárolni az adatokat, bár nem hiszem, hogy ezen múlnának a teljesítménybeli különbségek), mert nagyon zavar, amikor egy form elküldésekor F5 (frissítés) lenyomása hatására a böngésző visszakérdez (Opera általában nem teszi), hogy elküldje-e még egyszer a $_POST-adatokat. Engem ez legalábbis felhasználóként is zavar: ha bármi miatt úgy döntök, hogy frissíteni szeretnék, és nem probléma, ha elvesztem a begépelt adataimat, akkor hadd tegyem ezt visszakérdezés nélkül.
(Bár hozzáteszem, pl. Gmailnél el nem mentett levél elküldésekor, vagy szerver felé történő függőben lévő kérés megszakítási kísérlete esetén, vagy épp a stackoverflow oldalán történő hsz.-íráskor jól jön, hogy figyelmeztet, hogy még nem mentettem/küldtem el, amit akartam. DE ez szándékos és indokolt fejlesztőoldali dolog, nem a böngésző egyéni döntése, hogy most akkor jól figyelmeztesse a felhasználót, szerintem egészen más a kettő "hangulata". )Sok oldalon a keresőmezőkbe beírtakat is azonos oldalon dolgozzák fel, olyankor is sűrűn előfordul az F5-nyomkodásos probléma, az még zavaróbb, az ember adott esetben többször keres, mint amennyiszer mondjuk hozzászól adott oldalhoz, cikkhez, ilyenkor F5 nyomkodására mindig megakasztja a böngészést a figyelmeztető ablak a post-adatok újbólli elküldéséről.
Mostanában nagyon sokszor megpróbálom inkább AJAX-szal megoldani a dolgokat, mert az úgy szebb felhasználói szempontból, mint az egészoldalas frissülés - ráadásul akkor az F5-ös és redirectelős probléma egy része is megoldódhat, AJAX-os feldolgozásnál lehet egyből kiíratni is (máskor is lehet, de mint fentebb mondtam a Wordpress-es példát, nem túl szép a külön hibaoldal, majd visszanavigálási kényszer).
-
#6566
Sk8erPeter
nagyúr
Tele von Zsinór
#6565
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6565
üzenetére
Ja, nyilván attól függ, hogy oldod meg. Nálad nem tudom, hogy van konkrétan, azt nem írtad.
Van egy formod, az elküldi a post adatokat egy másik fájlnak, ott meg hiba esetén megint ugyanúgy kiíratod a formot, meg az oldal többi részét, vagy hogyan?Amúgy az szerintem ultraronda megoldás, ami a Wordpress-motort használó weboldalak többségénél szokott lenni adott cikkhez történő hozzászólásnál fellépő hiba esetén, hogy dob neked egy hibaoldalt, egy pici keretben kiírva a hibaüzenetet, az oldal egyéb részei egyáltalán nem látszanak, és csak a böngészőben az eredeti oldalra való visszanavigálást követően tudod megfelelően módosítani a form kitöltését. (Persze egyes böngészőknél ilyenkor a visszanavigálásnál törlődik is az eredeti hsz., fasza.)
-
#6564
Sk8erPeter
nagyúr
Speeedfire
#6563
Sk8erPeter
nagyúr
válasz
Speeedfire
#6563
üzenetére
Abban az esetben nem is kell, ha
1.) a formok feldolgozását ugyanott végzed, ahol maga a form kiíratása van (tehát nem külön fájlban, így a POST adatokat egyből közvetlenül fel is tudod használni a formmezők kitöltésére - de ez szerintem gány megoldás),
2.) ha átmeneti adatbázis-bejegyzést hozol létre a felhasználó által megadott adatokkal, amit csak akkor hagysz meg, ha a felhasználó véglegesíti az adatokat (korlátozott lehet az adatbázisban elérhető kapcsolatok száma)
3.) vagy akkor, ha egyszerűen nem foglalkozol vele, hogy a felhasználónak ki kell-e töltenie újból az űrlap egyes mezőit, vagy sem
4.) ha bejelentkeztető űrlapról van szó, ahol pl. csak felhasználónév-jelszó párost kell kitölteni, itt nyilván az esetek többségében nem kell megjegyeztetni semmit
5.) biztos van olyan eset, ami most nem jut eszembe.DE érdemes bevetni a session képességeit ilyen esetekre is, igazából mi másra lenne használható, mint adatok átmeneti tárolására, akár egy egész session erejéig, vagy csak rövidebb időtartamra.
Nyilván formadatokat is csak addig tároljunk session-változókban, amíg nagyon szükséges. -
#6562
Sk8erPeter
nagyúr
Speeedfire
#6559
Sk8erPeter
nagyúr
válasz
Speeedfire
#6559
üzenetére
"Nem szokták"
Kik nem szokták?
Nyilván van, aki átmeneti adatbázis-bejegyzést hoz létre ilyenkor, de én nem pazarlom ilyenekre az adatbázis korlátozott erőforrásait, épp ezért is használom legtöbbször a sessiont ilyen célra (is). Persze csak addig tárolom, ameddig nagyon szükséges - leginkább hiba esetén. A form adatait mindig külön feldolgozó fájlban dolgozom fel, és amennyiben ezt nem AJAX-szal oldom meg (azért úgy a szép, de működjön annál is, akinél ki van kapcsolva a JavaScript), akkor ha nincs hiba, eltárolom az adatokat adatbázisban, ha mégis hiba történt, a form adatait elmentem session-változókba, hogy a felhasználónak ne kelljen újra begépelnie az adatokat (szerintem ez elég fontos, engem is halálra idegesít, ha nem így oldják meg), majd visszairányítom a júzert az eredeti oldalra (ahonnan a formot elküldték), és ott a form megfelelő mezőibe kiíratom a session-változókban tárolt korábbi űrlapadatokat, majd ezután rögtön meg is szüntetem ezek tárolását (a formon már úgyis látszik, majd a felhasználó elküldi újból ugyanezeket az adatokat, ha nagyon akarja).
Érdemes ezeket az adatokat egy többdimenziós megoldással tárolni, hogy könnyű legyen őket megszüntetni is, valahogy így (egyszerű példa):
$_SESSION['form_data'] = array();
$_SESSION['form_data']['user_name'] = $_POST['user_name'];
$_SESSION['form_data']['user_address'] = $_POST['user_address'];
// ....
Ha meg akarod szüntetni az eltárolt formadatokat, elég ennyit csinálni:
unset($_SESSION['form_data']); -
#6554
Sk8erPeter
nagyúr
Speeedfire
#6553
Sk8erPeter
nagyúr
válasz
Speeedfire
#6553
üzenetére
Hát ha nem dob warningot vagy fatal errort, akkor lennie kéne ilyen függvényednek, aminek lehet, hogy referenciaként van átadva a tömb.
-
#6551
Sk8erPeter
nagyúr
biker
#6549
Sk8erPeter
nagyúr
A shuffle_assoc()-ot leszámítva teljes körű kódnak számít, működőképes (persze ha az eredeti angol2() fv.-t is kiveszed)...
DE az nem tűnt fel, hogy ilyenformán:
shuffle_assoc($Cimke);
a shuffle_assoc rohadtul nem változtat a $Cimke tömbön semmit?
A függvény egy tömbbel tér vissza, az meg így csak elvész az éterben.
Legfeljebb így működik:
$Cimke = shuffle_assoc($Cimke);(#6540) Speeedfire: neked is javaslom a fenti javítást.
(már ha nálad a shuffle_assoc() fv. nem referenciát kap paraméterként, ahol a $list tömbön végzel változtatásokat - pl. function shuffle_assoc(&$list) { ..... } ) -
#6544
Sk8erPeter
nagyúr
Speeedfire
#6542
Sk8erPeter
nagyúr
válasz
Speeedfire
#6542
üzenetére
Én a VirtualHostot így csináltam a httpd.conf fájlban:
NameVirtualHost 127.0.0.1
ServerName localhost
## Próbálgatásokhoz
<VirtualHost 127.0.0.1>
ServerName proba.local
DocumentRoot "d:/Honlap/www/proba"
<Directory "d:/Honlap/www/proba">
Options All
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>itt ebben a példában a http://proba.local címen elérem a "d:/Honlap/www/proba" elérési úton található könyvtárat, amennyiben beteszek egy ilyen megjegyzést a hosts fájlba (Windows alatt: C:\Windows\System32\drivers\etc\hosts):
#Próbákhoz
127.0.0.1 proba.localÍrd át a neked megfelelő elérési utakra és nevekre, ha gondolod, szerintem érdemes.
"Hogy érted azt, hogy nem célszerű kiírni?"
A felhasználóknak semmi köze az adatbázissal kapcsolatos pontos hibaüzenetekhez, azt inkább csak a fejlesztőnek kell tudnia.
Úgy lenne érdemes, hogy még a kiíratások előtt vizsgálgatod, hogy elérhető-e az adatbázis, meg annak megfelelő lekért sorai, és amennyiben valami gond lenne, akkor egy ennek megfelelő hibaoldalra irányítod át a júzert, vagy átirányítás helyett simán csak a fő tartalomrészbe kiíratsz egy felhasználóbarát hibaüzenetet, mint pl. "Sajnos para van az adatbázissal, gyere vissza később, csá". A hibaüzeneteket meg naplózod és/vagy elküldöd magadnak e-mailben, hogy tudj róla, de a felhasználó lehetőleg ne lássa, mi is történik a háttérben (pl. melyik tábla nem elérhető, miért, stb.). Ez is egyfajta biztonsági rés lehet, de ami lényegesebb szempont, hogy nem túl szép, ha a felhasználó az arcába kap egy warningot, fatal errort vagy hasonlót. -
#6543
Sk8erPeter
nagyúr
Speeedfire
#6540
Sk8erPeter
nagyúr
válasz
Speeedfire
#6540
üzenetére
"Kellene még egy másik tábla, ahol el lenne tárolva ez mind"
Ezt hogy érted?
Engem is érdekel a gyorsítás, de ezt most nem értem, mire gondolsz.
Szerk.: jé, közben pont írtál nekem, mindjárt elolvasom.
-
#6533
Sk8erPeter
nagyúr
Alukard
#6532
Sk8erPeter
nagyúr
válasz
Alukard
#6532
üzenetére
Ehelyett a szerintem csúnya megoldás helyett jobb kikapcsolni a magic_quotes_gpc beállítást php.ini-ben (PHP 5.3.0-tól deprecated beállítás):
magic_quotes_gpc Off
esetleg .htaccess fájlból:
php_flag magic_quotes_gpc Off
vagy pedig egy korábban mutatott módszerrel elintézni (fordfairlane írta, én most csak beraktam egy függvénybe):function check_magic_quotes() {
if (get_magic_quotes_gpc()) {
function stripslashes_gpc(&$value) {
$value = stripslashes($value);
}
array_walk_recursive($_GET, 'stripslashes_gpc');
array_walk_recursive($_POST, 'stripslashes_gpc');
array_walk_recursive($_COOKIE, 'stripslashes_gpc');
array_walk_recursive($_REQUEST, 'stripslashes_gpc');
}
}a kódod elején (a függvénydefiníció után) lehetőleg hívd meg a függvényt így:
check_magic_quotes();Egyébként félreértés ne essék, a Te megoldásod (vagyis hát a másolt) is működik, nincs azzal olyan nagy baj, csak szerintem nem túl szép megoldás.
Közben találtam egy egész értelmes magyarázatot: [link]
itt a végén épp a Te kódodban látott részt mondja gyors alternatív megoldásnak, de alapvetően ő is azt javasolja, hogy a fentiek legyenek kikapcsolva. Kábé ugyanazt írta le, mint én (franc, egyszerűbb lett volna egyből linkelni), mondjuk a fenti függvényt nem írta bele, az még igen hasznos lehet. -
#6531
Sk8erPeter
nagyúr
Alukard
#6530
Sk8erPeter
nagyúr
válasz
Alukard
#6530
üzenetére
sebaj, majd utólag remélhetőleg észreveszed ezeket, és rájössz, milyen viccesek a régi kódjaid...
legalábbis én akárhány régi kódomat látom, mindben azonnal látom a hibát, meg hogy most már mit csinálnék másként.
na, de a dolgon nem változtat, hogy a kódodban tök felesleges az ob_start()...
mondjuk ez is kemény így rögtön egymás után:
$username = stripslashes($username);
$password = stripslashes($password);
$username = mysql_real_escape_string($username);
$password = mysql_real_escape_string($password);
tényleg ez egész gány -
#6529
Sk8erPeter
nagyúr
Alukard
#6525
Sk8erPeter
nagyúr
válasz
Alukard
#6525
üzenetére
Csak kíváncsiságból kérdezem:
MINEK használod az ob_start();, ob_end_flush(); függvényeket? Van rá valami különleges okod? Ha nincs, csak szólok, hogy annak felesleges használata sajnos gányolás.
Az esetek igen nagy többségében tényleg nincs rá szükség.
Nyilván ki lehetne találni valami különleges okot a használatára, de az általad mutatott kód, és az "átlagos" webfejlesztés egyáltalán nem teszi indokolttá az igénybe vételét (habár szerintem még az advanced alkalmazásfejlesztés nagy részében is elkerülhető). Főleg, ha az MVC-szemlélet konkrét alkalmazására gondolunk. -
#6516
Sk8erPeter
nagyúr
Brown ügynök
#6515
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6515
üzenetére
Nem ártana tudni, hogy ezt az "Object not found" hibaüzenetet egész konkrétan melyik kódsorra írja, valamint hogy egyáltalán kipróbáltad-e a javasolt módszert a .htaccess fájl módosításával.
-
#6514
Sk8erPeter
nagyúr
Sk8erPeter
#6510
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6510
üzenetére
"Amúgy milyen jó lenne, ha már a .htaccess fájlból is el lehetne indítani egy időmérést."
Igazából nem is tűnik olyan nagyon hülye gondolatnak (hogy saját magamnak reagáljak).Találtam egy ilyen cikket: [Measuring Apache request processing time]
Ez alapján plusz az Apache vonatkozó hivatalos oldala alapján (mod_headers):
ha ezt a két Header direktívát beteszem a .htaccess fájlba:# %t: The time the request was received in Universal Coordinated Time since the epoch (Jan. 1, 1970) measured in microseconds. The value is preceded by t=.
# %D: The time from when the request was received to the time the headers are sent on the wire. This is a measure of the duration of the request. The value is preceded by D=.
Header set Ekkor_kapta_a_kerest_ms_1970_jan_1-hez_kepest: %t
Header set Keres_feldolgozasi_ideje_us: %D
akkor hozzáadja a HTTP-fejlécekhez ezeket is (szándékosan adtam most ilyen jó hosszú, de beszédes neveket).
Ebben az esetben a következő fejléceket látom a Firebug Net fülén:
Ekkor_kapta_a_kerest_ms_1... t=1301593430575379
Keres_feldolgozasi_ideje_... D=539031Tehát eszerint 539031 us = 0.539031 s ideig tartott az Apache-nak, hogy kiszolgálja a kérést.
A t=1301593430575379 azt jelenti, hogy ennyi mikroszekundum telt el 1970. jan. 1-je óta.Ezek a fejlécek feldolgozhatók PHP-ból is (most itt a tömbben a fent megadott, jó hosszú nevű index-szel érhető el a kívánt érték, mindenki nevezze át ízlése szerint):
<?php
$headers_array = get_headers('http://'.$_SERVER['SERVER_NAME'], 1);
// headerek kiíratása:
echo 'HEADERS:------------<hr />';
echo '<pre>';
print_r($headers_array);
echo '</pre>';
$request_rec_time = $headers_array['Ekkor_kapta_a_kerest_ms_1970_jan_1-hez_kepest'];
// levágjuk a "t=" részt
$request_rec_time = str_replace( 't=', '', $request_rec_time );
// mikroszekundumban kapjuk meg, azt átalakítjuk másodperccé (s) (1 s = 1 000 000 ms)
$request_rec_time /= 1000000;
// átalakítva olvasható dátummá:
echo date('Y.m.d H:i:s', $request_rec_time).'<br />';
?>Igazából az utóbbi, a kérés ideje nem túl pontos, mivel integer értéket kapunk, így megegyezik a $request_rec_time változóval formázott fenti date() kimenete a sima date('Y.m.d H:i:s') kimenetével, aminek a második paramétere az alapértelmezett time() kimenet.
Létezik azonban a $_SERVER['REQUEST_TIME'] változó is, amit szintén felhasználhatunk, ez szerintem kicsit pontosabb, mert talán nem csak a .htaccess fájlhoz érve kezdi számolni az időt...
Így azt is átalakíthatjuk olvasható formátumra:echo date("Y.m.d. H:i:s", $_SERVER['REQUEST_TIME']).'<br />';
De sajnos ez is csak másodperces eltéréseket fog mutatni, nálam legalábbis az "u" (mikroszekundumot jelző) formátum karakter hozzácsapása ( date("Y.m.d. H:i:s.u") ) csakis csupa nullát eredményezett.
Ha valaki tud még jobb, még pontosabb módszereket, ne tartsa magában.
Kösz! -
#6513
Sk8erPeter
nagyúr
Brown ügynök
#6511
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6511
üzenetére
.htaccess fájlba mehet:
<IfModule mod_rewrite.c>
# Először is kapcsoljuk be a RewriteEngine-t
RewriteEngine on
# Kiindulási hely
RewriteBase /
# NEM fájl és NEM könyvtár
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# illeszkedik a "/komment/show" és "/komment/show/" query stringre is (a perjel a különbség)
RewriteRule ^(/komment/show(/)?)$ /komment/index.php [L,QSA]
# előbbinél a QSA flag egyelőre felesleges, de hátha később szeretnél átadni query stringeket, amiket később feldolgozol PHP-ben
# az NC flag egyébként arra lenne jó, hogy case-insensitive módon fogadja el a címet, tehát mindegy, hogy /KoMmENt/ShOW vagy épp a helyes /komment/show címet írod be, ezt döntsd el, hogyan szeretnéd
</IfModule>Viszont ez a rész tök felesleges, ha már Apache-ból intézed el a dolgokat:
$uri = $_SERVER['REQUEST_URI'];
if ($uri == '/komment/') {
index();
}
elseif ($uri == '/komment/index.php') {
funkcio() );
}
...Tulajdonképpen itt nem vágom igazán, mit szeretnél, ha már mod_rewrite-ot használsz.
-
#6510
Sk8erPeter
nagyúr
Tele von Zsinór
#6509
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6509
üzenetére
Valóban, ez teljesen igaz! És bocsi, nem voltam túl pontos és egyértelmű, azt akartam mondani, hogy sokszor JÓVAL többet várok, tehát mintha a szerver túl sokat szarakodna az általad említett dolgokkal, aminek része az Apache-szerver felőli dolgok elintézése, így pl. a .htaccess fájl vizsgálata is, és ezért merült fel bennem, hogy esetleg a reguláris kifejezés vizsgálgatásával is elszöszmötöl egy darabig.
De rájöttem, hogy ez hülyeség, mert annyira azért nem komplikált a reguláris kifejezésem, hogy pont ez lenne a probléma. Igazából ingyenes tárhelyről van szó, előfordulnak olykor problémák, amikor lassú a szerver, valószínűleg ez lehet ritkán a baj. Amúgy meg van, hogy rohadt gyorsan lefut az egész. Úgyhogy bocsi, tárgytalan! Nem tudom, miért pont erre feküdtem rá...
Amúgy milyen jó lenne, ha már a .htaccess fájlból is el lehetne indítani egy időmérést.
---
Holnap megpróbálom a többszörös kondícióvizsgálgatást .htaccess-ben mod_rewrite-hoz, ma már nem volt időm rá. -
#6508
Sk8erPeter
nagyúr
cucka
#6501
Sk8erPeter
nagyúr
Köszi a választ.
Igen, épp a bottleneck-eket szeretném megragadni, és felmerült bennem, hogy esetleg az Apache-csal ilyen módon való regexpes szarakodás esetleg lassíthatja az oldalbetöltést, mert tárhelyen szándékosan elhelyeztem egy időméregetőt, először az elején hívom meg a fv.-t, majd a kiíratások legvégén megint, és az eredményét kiírom, és van, hogy többet várok, mint a kiírt eredmény (a script maga jó), ami mondjuk következhet abból is, hogy valamiért lassan reagál a szerver a kérésre, vagy f#ngom sincs.Amúgy itt az időméregető:
<?php//Oldal generálási idejének számolásához ( http://weblabor.hu/cikkek/idezojelek )
function getmicrotime() {
list($usec, $sec) = explode(" ", microtime());
return ((float) $usec + (float) $sec);
}
$time_start = getmicrotime();
/// blablabla, vizsgálgatás, kiíratás, stb.
// oldal legvégén:
$time_end = round( getmicrotime() - $time_start , 5 ) ;
echo '<small>|| Oldalgenerálás: '.$time_end.' s ||</small>';
///... HTML-kód befejezése (pl. </body></html>)"A RewriteRule-ok alapból így működnek. Fentről lefele halad a .htaccess fileban egészen addig, amíg talál egy megfelelő sort, ami alapján átírja az url-t"
Sejtettem, csak még sajnos a gyakorlatban nem volt időm megtapasztalni, hogy is van ez, addig azért kérdeztem, hátha van valakinek erről már tapasztalata korábbról, mert egyelőre azt sem tudom, hogy olyan feltétel esetén, ami stimmel, megáll-e egyáltalán a vizsgálat. (Szerk.: valszeg erre való az [L] flag használata. Itt egész jó lista van a flagekről: [link]. Meg egy igen alapos leírás a mod_rewrite-ról, aminek mondjuk tisztában vagyok az alapjaival, csak ezt a többes feltételt nem próbálgattam.)
Mindjárt megpróbálok utánanézni. -
#6507
Sk8erPeter
nagyúr
cucka
#6504
Sk8erPeter
nagyúr
Jé, ezt az fpassthru() függvényt még soha nem használtam, ez miben más, mint a többi, kép kiíratására használható módszer?
(Pl. akár a readfile() - meg most hirtelen az imagepng() jut eszembe, de az mondjuk nyilván azért nem jó, mert képtípusfüggő az eredménye (pl. beadok neki egy jpg-t, akkor false-t ad vissza, az nem túl jó.) -
#6506
Sk8erPeter
nagyúr
Speeedfire
#6496
Sk8erPeter
nagyúr
válasz
Speeedfire
#6496
üzenetére
Miért nem használod fel a $_GET['phpoldal'] változót?
Úgy értem, akkor minek adod át ennek a query stringnek a címet?http://localhost/!!!szapar.hu/
Ehelyett meg létrehozhatnál egy bejegyzést a hosts fájlban, meg apache-beállításokban egy VirtualHost-ot, és lehetne a címe http://szapar.local Így azé' szebb, meg nem kell annyit pötyögni a cím beírásához. $valogatas = "select * from szapar_alias where eng = '".$uri."' ";
Itt azért az $uri változót nem ártana escape-elni, az SQL Injection elkerülése érdekében!$i= 0;
foreach ($valogat as $ertek) {
if ($i != 0) {
parse_str($ertek);
}
$i++;
}
Ezt nem is értem, minek csinálod, ha utána egyáltalán sehol nem használod fel az $ertek változót?
Vagy felhasználod, csak valami include-olt fájlban? Vagy csak benne maradt?if (!mysql_query($valogatas,$con)) {
die('Hiba: ' . mysql_error());
}
Itt a die() helyett érdemesebb lenne inkább valami felhasználóbarátabb hibaüzenetet, hogy nem elérhető az adatbázis, látogasson vissza később. Ráadásul a felhasználónak semmi köze a konkrét hibaüzenethez. Nem célszerű kiírni! Főleg, hogy nem is túl szép.
Az ilyen jellegű hibákat amúgy nagyon faszán le lehet kezelni kivételkezeléssel, ha valami kritikus jellegű hibád van, azonnal dobsz egy kivételt, hogy ne is futkorásszon tovább a kód, nem is kell bonyolult és ronda if-else blokkokat csinálni, egyszerűen valahol elkapod a kivételt, megfelelő módon kezeled, és kész.Saját kivételtípusokat is definiálhatsz, ha származtatsz az Exception osztályból, azt is érdemes, hogy el tudd dobálni, és tudd, hogy egész pontosan milyen kivételt kell kezelned, így akár végtelen mennyiségű kivételt is elkaphatsz.
Példa:class Kiskutya extends Exception {
//nem is feltétlenül kell, hogy bármi más legyen benne
}
/// ... valahol a kódban
try{
// ...
$hiba = true;
if($hiba){
throw new Kiskutya('elég nagy gáz van, kiskutyákat dobálok! :D');
}
///...
$legyen_meg_kivetel = true;
if($legyen_meg_kivetel){
throw new Exception('ha az előbb nem dobáltam volna kivételt, akkor még idáig is eljutna, de ezt a kivételt is elkapnám a catch-ben! Bruhahahahh.');
}
} catch (Kiskutya $e) {
echo 'Kiskutya kivétel elkapva! Konkrét hibaüzenet: '.$e->getMessage();
} catch (Exception $e) { // fontos a sorrend! Az ősosztály (Exception) később legyen, mint a származtatott!
echo 'Általános jellegű hiba: '. $e->getMessage();
}if (!empty($valogat['url']) and isset($valogat['url']))
Ennek a feltételvizsgálatnak így nem sok értelme van, itt elég lenne a !empty() részt vizsgálni, nyilván ha nem üres a változó (nem is NULL, nem is üres string, stb.), akkor be van állítva, tehát a második feltétel már felesleges. Sőt, itt előbb célszerű lenne inkább megvizsgálni, hogy van-e kapott eredményhalmaz, vagy sem, ha már úgyis lekérdezed a kapott sorok számát a mysql_num_rows() függvénnyel.Na, a többi részéhez most nem volt türelmem.
(#6494) Speeedfire:
"Amelyik táblában az url-ek vannak cachelve van."
Hogyan bírod rá így külön az adatbázist, hogy cache-elje? Tudtommal default cache-eli, indexeléssel lehet esetleg segíteni a lekérdezés gyorsaságát. -
#6491
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Hali!
Apache mod_rewrite-ot használok egy .htaccess fájlon keresztül, és egy viszonylag komplex RewriteRule-t használok - sok a vagy feltétel, plusz az, hogy ha az egyik feltétel megvan, akkor mi szerepelhet még a következő alakban; ha a reguláris kifejezésnek megfelelt a felhasználó által beírt cím, akkor átadom query stringként (tehát viszonylag kötötten) az index.php mögé a megfelelő kifejezéseket (pl. ........ index.php?page=$1&lang=$4&dog_id=$7 [QSA]), egyébként pedig dobok egy 404-et. Utóbbit is úgy, hogy beletettem egy
ErrorDocument 404 /index.php?page=404
sort.
Jó esetben viszont ezt:
.../eng/home
átalakítja ilyen formára:
.../index.php?lang=eng&page=homeKérdéseim:
1.) Ez a fenti ilyenformán jól működik, mégis felmerült bennem, hogy tulajdonképpen melyik a gyorsabb, az, ha Apache-csal vagy PHP-vel dolgozom fel a címet?
Tudtommal egy ilyen szintű reguláris kifejezés már eléggé lassíthat, ezért gondolkoztam rajta, hogy talán lehetne gyorsítani rajta. De az is lehet, hogy sebesség szempontjából még így is ez a leggyorsabb megoldás, nem tudom, mert nem mértem.
Nektek mi a tapasztalatotok, hogyan használjátok, mit javasoltok?2.) Tulajdonképpen ez a szerkezet így eléggé megköti a fejlesztő kezét, mert az értékek átadásának sorrendje határozza meg, melyik változóhoz lesznek rendelve a címek.
Mégis tudtommal legtöbb helyen a "felhasználóbarát URL-ek" miatt ezt a módszert alkalmazzák.
Ti hogy látjátok a kérdést? Másképp használjátok, vagy muszáj elfogadni, hogy ez egy viszonylag kötött szerkezet, jól kell kitalálni az elején, és nem érdemes változtatni rajta később? Mi van pl., ha a júzer már úgy könyvjelzőzte az oldalunkat, hogy http://blabla.hu/eng/home, mégis mi kitaláljuk közben, hogy valójában jobban tetszik az a sorrend, hogy http://blabla.hu/home/eng, tök mindegy milyen okból.3.) Több RewriteRule-t hogyan adtok hozzá úgy, hogy helyesen működjön?
Pl. ha nem illik az egyik reguláris kifejezésre a cím, ugorjon a következő feltételre, és vizsgálja meg, arra illik-e.
Egyébként így széjjelszedve a feltételeket gyorsabb lehet a dolog?Előre is köszönöm a konstruktív javaslatokat!
-
#6488
Sk8erPeter
nagyúr
Speeedfire
#6487
Sk8erPeter
nagyúr
válasz
Speeedfire
#6487
üzenetére
És mire hivatkozva akarnak lebeszélni róla? Én mint teljesen pártatlan kérdezem, még nem próbáltam.
================================
(#6483) abteam2008 : legközelebb használd a "Programkód" gombot a bemásolt kódod kijelölése után, mert így nagyon nehéz áttekinteni, én legalábbis ha ilyen kódot látok, többnyire meg sem próbálom megérteni, mert annyira zavaró, hogy mindenféle formázás, indentálás nélkül van csak bemásolva. Szerintem ezzel itt a legtöbben így vannak.
-
#6482
Sk8erPeter
nagyúr
abteam2008
#6481
Sk8erPeter
nagyúr
válasz
abteam2008
#6481
üzenetére
Tehát azt várod, hogy az adatbázisod és a konkrét kódod ismerete nélkül lekódolja neked bárki is, amit szeretnél? Nem fog menni. Tartok tőle, hogy senki sem fogja ilyen munkára szánni a szabadidejét amúgy sem, de így konkrétumok nélkül meg aztán garantált, hogy senki nem fog foglalkozni a dologgal.
Olvasgass ezzel kapcsolatos tutorialokat - pl. adatbázisból való kiolvasás módjai, majd az adatbázisbeli elemek lekérdezése PHP-n keresztül, stb., kódolj, juss el valameddig, aztán ha elakadtál, mutass kódot, akkor segítünk kijavítani. Vagy ha már munkát ajánlasz, akkor azt tálald úgy.------
(#6480) Scobbyka:
hát ennyi alapján úgy tűnik, mintha az új szerverre nem lett volna megfelelően telepítve az eAccelerator.
Egyébként konkrét használat során van tényleges haszna ennek az eAcceleratornek? Én egyáltalán nem ismerem, nem hallottam még a hatékonyságáról. -
#6397
Sk8erPeter
nagyúr
Sk8erPeter
#6395
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6395
üzenetére
Korrigálnám magam annyiból, hogy tulajdonképpen valamilyen szinten mégiscsak "létrehoz" dinamikusan függvényeket a PHP, a lényeg:
http://php.net/manual/en/language.oop5.overloading.php
"Overloading in PHP provides means to dynamically "create" properties and methods. These dynamic entities are processed via magic methods one can establish in a class for various action types.The overloading methods are invoked when interacting with properties or methods that have not been declared or are not visible in the current scope. The rest of this section will use the terms "inaccessible properties" and "inaccessible methods" to refer to this combination of declaration and visibility.
All overloading methods must be defined as public."
Mellesleg most látom, hogy tulajdonképpen Tele von Zsinór már korábban leírta tömörebben a lényeget.
Na sebaj, elmondtam másféleképpen.---
(#6396) j0k3r!: pont a fentebb linkelt oldalon mutatják be a __call használatát!
-
#6395
Sk8erPeter
nagyúr
Speeedfire
#6394
Sk8erPeter
nagyúr
válasz
Speeedfire
#6394
üzenetére
"van-e az adott néven ilyen függvény, ha van akkor meghívja ha nincs akkor elkészíti"
Nem készít el semmilyen függvényt.
Függvényt legfeljebb meghív. [call_user_func()]"Nem lenne célszerűbb már a __get() résznél megvizsgálni a dolgokat? dátum, név stb? Mert így feleslegesen dolgozik utána még a __set() is."
Másra való a kettő! A getter függvényekkel lekérdezel bizonyos attribútumokat, változóértékeket, a setter függvényekkel pedig beállítod azok értékét.Ha be akarnám állítani vagy épp le akarnám kérdezni a "pityipalko" változó értékét, akkor arra nyilván kivételt dobna, mert nincs ilyen (ha beállítottad volna a konstruktorban, akkor lenne ilyen! példa:
$this->_tulajdonsagok['pityipalko'] = null;).
De a $_tulajdonsagok tömbben létezik 'nev' és 'szuletesidatum' index is, így azokhoz tartozik egy érték, azok beállíthatók, lekérdezhetők.Amikor ezt írod:
$obj->szuletesidatum = '1985-08-27';
Akkor tulajdonképpen a "mágikus" __set függvény hívódik meg, a __set $tulajdonsagnev paramétere megkapja a 'szuletesidatum' sztringet, az $ertek pedig az '1985-08-27' értéket.Ezután az array_key_exists() függvénnyel megvizsgáljuk, hogy a $_tulajdonsagok tömbben beállítottunk-e egyáltalán 'szuletesidatum' index-szel bármit (ami a konstruktorban egyébként null értéket kapott [lásd $this->_tulajdonsagok['szuletesidatum'] = null;], de ezzel már létrejött ezen az indexen egy érték), ha nem, kivétel, ha igen, megyünk tovább.
Ezután megvizsgálja, létezik-e az osztály adott példányában ($this) $tulajdonsagnev . 'Beallitas' nevű függvény - tehát esetünkben szuletesidatumBeallitas nevű függvény (mivel konkatenálja a $tulajdonsagnev változó értékét a 'Beallitas' sztringgel, majd megvizsgálja, van-e ilyen metódus ( method_exists() függvény).
Ha létezik ilyen metódus, akkor meghívja azt, különben pedig csak simán beállítja a $tulajdonsagnev nevű indexen található értéket a $_tulajdonsagok tömbből.Remélem valamennyire érthetően mondtam el.
-
#6387
Sk8erPeter
nagyúr
shaggy
#6385
Sk8erPeter
nagyúr
akkor ne a rövidet használd, tehát ne a <? nyitótagformát, hanem a <?php változatot.
Rendesen le is van zárva a kód ?> jellel?
Milyen címen próbálod elérni? Fizikailag hol van a fájl?
NE használd a PHP4-et, inkább visszafelé ne haladj az időben, maradj csak a PHP5-nél.
Egyébként ahogy a többiek is mondták, lehet, hogy inkább le kéne szedned az eddigi feltelepített Apache-ot és PHP-t, aztán felrakni sokkal egyszerűbben egyszerre, jól bekonfigolva az összes csomagot, mégpedig a WAMP vagy AppServ segítségével.
Ezek pár kattintással felmennek, viszont faszán telepít mindent, és nem kell vele szívni. Tégy vele egy próbát. -
#6367
Sk8erPeter
nagyúr
jeges
#6362
Sk8erPeter
nagyúr
Ciklussal kapcsolatban: programozási kérdésekben az ilyen jellegű alapfogalmak elég ritkán sokértelműek, jelen esetben is egyértelmű a jelentése, és programozásnál meg főleg nem mindegy, hogy egy adott szót a tényleges jelentése alapján használsz, vagy csak saját definíciót találtál-e ki rá, képzeld el, mi lenne pl. csapatmunkánál, ha mindenki más és más értelemben használná a fogalmakat.
A Wikipédiás meghatározás a ciklusra:
Ciklus (programozás)
"A ciklus, vagy iteráció a számítógép-programozás és az algoritmusok egyik alapvető eszköze, amely az ismétlődő (azonos vagy hasonló) tevékenységek megvalósítására szolgál. A ciklus beépítését a programba ciklusszervezésnek is nevezik. A ciklust az egyes programozási nyelvek különböző kulcsszavakkal valósítják meg, de a működési módjukat tekintve három alaptípusba sorolhatók aszerint, hogy hányszor futnak le: ezek az elöltesztelő, a hátultesztelő és a számlálós ciklus."Ne vedd kötekedésnek, nem azért mondtam, hanem csak hogy tisztázzuk.
"különösebb galibát egyébként az első esetben nem okoz"
Hát ha nincs kivétel, akkor valóban nem probléma, de ellenkező esetben elég para."az, hogy a try/catch-ben vizsgált jelenség utáni lépést a szerkezetbe vagy utána teszed, környezetfüggő."
Hát nekem most a try-catch blokkokkal kapcsolatban nem jut eszembe olyan környezet, ahol a logikának teljesen ellentmondó megoldást kéne alkalmazni. De mondj ilyet, ha van rá ötleted.
A try-catch esetén még az osztály példányosítását is a legtöbb esetben belepakolják a blokkba, mivel még a konstruktornál is történhet kivétel, ha valamiért nem sikerül a példányt létrehozni, ennek a kivételét is kezelni kell.
Az említett példában a köszöntéssel kapcsolatos függvény pont szervesen hozzátartozik a korábbiakhoz, tehát nagyon nem logikus, ha épp a try-catch blokk után teszed annak a függvénynek a meghívását, aminek a lefutása épp attól függ, hogy volt-e kivétel vagy sem.
"a példa szempontjából majdnem mindegy."
Többek közt a fent említett indokok miatt nagyon nem. -
#6359
Sk8erPeter
nagyúr
Tele von Zsinór
#6358
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6358
üzenetére
Ja tényleg, az meg a másik. Tehát magyarul ha lenne is kivételdobálás, akkor is le akarna futni az $obj->koszontes(); függvény, mert teljesülne, hogy nem létezik az $e változó.
-
#6357
Sk8erPeter
nagyúr
jeges
#6342
Sk8erPeter
nagyúr
"szerintem próbáld külön a köszöntésig egy ciklusba (megjegyzem, logikailag nekem egyébként is az tűnik egy teljes ciklusnak)"
Hol van itt ciklus?
try {
$obj->szuletesidatum = '1985. 08. 27.';
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
} if (!isset($e)) {$obj->koszontes();}???
a köszöntésnek épp a dátum után kéne lennie...
if (!isset($e)) {$obj->koszontes();}
Ennek meg a végén bocsi, de totál semmi értelme.
Így pont a try-catch szép logikus blokkját bontod meg.
Amennyiben kivételt dobunk, akkor úgysincs köszöntés, tehát egy tök felesleges feltételvizsgálatot tettél a végére.Meg még ezt írtad:
try {
$obj->szuletesidatum = 'piros';
$obj->koszontes();
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
} if (!isset($e)) {$obj->koszontes();}
Főleg úgy nincs értelme, hogy amennyiben nem lenne kivétel attól, hogy beállítod "piros"-ra a változót, kétszer futna le a köszöntés. -
#6356
Sk8erPeter
nagyúr
Speeedfire
#6341
Sk8erPeter
nagyúr
válasz
Speeedfire
#6341
üzenetére
Szerintem speciel az "1985. 08. 27." pont nem egy érvényes dátum, amit megeszik az strtotime függvény.
"1985 08 27" - ez sztem megint nem érvényes dátumformátum, így jogosan dobja a kivételt.
Mellesleg így elsőre nekem úgy tűnik, hogy a könyv az OOP-s részt kezdőknek feleslegesen elbonyolítja, mert így csak nézel, hogy mi a bré van...
Én annak idején C++-ból értettem meg elég jól az OOP-t, elsőre ilyen magic függvényekkel "varázsolni" fura lett volna, tuti nem vágtam volna elsőre, mi a pálya. Így utólag belátom, hogy ezek könnyíthetik a melót, de elsőre érdemes sztem a hagyományos módszerekkel tisztában lenni, hogy értsd, de ez mondjuk csak egyéni vélemény. Ezért fura a könyv felépítése. -
#6333
Sk8erPeter
nagyúr
rt06
#6332
Sk8erPeter
nagyúr
Ja, most a szintaktikai hibát pont nem a kapcsos zárójeles megoldásra értettem.
Persze, nem feltétlenül pont a kiíratás milyenségén kell lefaragni, de ahol lehet sebességet növelni, ott sosem árt, főleg, ha a kényelmi szempontokat nem rontja (jelentősen).
Pl. lehet, hogy csúnya, de a kódomban sokszor keverem a statikus HTML-megjelenítési formákat a PHP-vel, pusztán sebességbeli megfontolásokból (bár lehet, hogy nem dob sokat, nem mértem), hirtelen példaként (alternatív szintaktikával):
<?php
// .....
foreach($valami as $key => $value) :
?>
<div>blabla sokszor: <?php echo $value;?>
................
</div>
<?php
endforeach;
?>Persze ezt csak akkor, ha nagyon muszáj (pl. nagyon sok kiírandó HTML-kód van), mert különben gány lesz a kód.
Nyilván mindent egybevéve kell a sebességen javítani, ahol lehet, de olykor apróságok is számíthatnak sok kicsi sokra megy alapon.Az, hogy a kiíratást valaki kapcsos zárójellel vagy egyéb módon csinálja, tényleg csak ízlés kérdése.
-
#6330
Sk8erPeter
nagyúr
Speeedfire
#6327
Sk8erPeter
nagyúr
válasz
Speeedfire
#6327
üzenetére
Ha sok HTML-kód kerül az outputra, nem is árt, ha az aposztrófos megoldást választod.
(Jó fárasztó és csúnya escape-elni a sok idézőjelet az attribútumoknál.)(#6329) Siriusb: állítólag az aposztrófos megoldás a kiértékelés szükségességének hiánya miatt (de jól hangzott) gyorsabb lehet, mások szerint urban legend.
Személy szerint jobban szeretem inkább összefűzögetni, és aposztrófot használni, részben a fenti okok miatt (pl. esetleges sebességkülönbség plusz HTML-kód kiíratása), részben meg amiatt, hogy így szerintem sokkal jobban elkülöníthető a kód, ha böngészgetem a kódot - még ha a fejlesztőkörnyezet ki is emeli az idézőjelben elhelyezett kiértékelendő változót, akkor is sokkal inkább egybefolyik a többi kóddal. Ráadásul tömbindexelésnél vagy egyéb esetben is szintaktikai hiba lehet belőle, az összefűzögetésnél könnyebb elkerülni (számomra).Többiektől kérdezném, ha már erről van szó:
echo-zásnál mennyire használjátok azt a változatot, hogy vesszővel elválasztva íratjátok ki a különböző változókat, sztringeket, és nem konkatenálva?
Eszerint itt is lehet sebességbeli különbség, mégpedig a vesszővel elválasztott módszer javára.
Lehet, hogy értelmesebb, mint az állítólag lassúnak számító sztring-összefűzögetés, és érdemes lenne esetleg erre a módszerre átszokni. -
#6319
Sk8erPeter
nagyúr
Tele von Zsinór
#6318
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6318
üzenetére
Ja, az ötleted jó a noscript áthelyezésére, pl. milyen jó lenne erre JavaScript használata.
Igen, én is úgy csinálom, hogy megírom először teljesen JS nélkül működőképesre az oldalt, és csak azután módosítgatom az oldalt úgy, hogy AJAX-szal is működjön. Természetesen pluszmunka, de szerintem a használhatóság miatt megéri. Pl. amikor egy form-ot küldök el, akkor engem felhasználói szemmel nagyon szokott zavarni a teljes oldal-újratöltődés. Minek, amikor csak pár adatot küldök át (ha épp nem fájlfeltöltésről beszélünk, ott felőlem lehet újratöltődés, bár a Flash-es vagy iframe-es megoldás itt is sokkal szebb) - az adatok fogadásáig meg megjelenítek egy forgolódó kis ikont, hogy a felhasználó azért tudjon róla, hogy valami tényleg történik a háttérben.
Tipikus példa lehet akár a stack overflow. Tele van JavaScriptes, AJAX-os megoldásokkal, és épp ezért kényelmes a használata. Ezért mondom azt, hogy manapság az igazán modern honlapok esetén elkerülhetetlen, vagyis inkább szükséges az AJAX használata - pusztán a felhasználói élmények növelése érdekében. -
#6317
Sk8erPeter
nagyúr
LW
#6311
Sk8erPeter
nagyúr
Előző kommentekhez hozzáfűzve:
ha már JS-függő site, és cikkírások, akkor érdemes megfontolni azt a megoldást is, amit a Gmail és pl. akár a stackoverflow is alkalmaz: levél/hozzászólás/... írása esetén időszakos mentéseket készít az addigi piszkozatról, így nem vész el az irományod. Gmailnél mondjuk meg is marad véglegesen. Felhasználóhöz kötve tehát érdemes lehet piszkozatot is készíteni bizonyos cikkekről, így később is folytatható, valamint nem vész el - legalábbis nem teljesen, ha közben lejár a munkamenet. Természetesen a legjobb megoldás az, amit mostanában Neptunnál is alkalmaznak végre, hogy a munkamenet lejárta előtt figyelmeztet annak lehetséges megújítására - ha 1 percen belül nem kattintasz arra a gombra, ami ezt elintézi neked, akkor kiléptet; na, a kiléptetés előtt lehetne közvetlenül piszkozatként elmenteni a cikket.
Manapság az AJAX-os megoldások szerintem elkerülhetetlenek, nagyságrendekkel felhasználóbarátabbá és akár programozói szempontból is kényelmesebbé tehetik az oldalakat (a programozói szopásoktól most eltekintve). -
#6316
Sk8erPeter
nagyúr
Tele von Zsinór
#6315
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6315
üzenetére
"cserébe ne feledd figyelmeztetni az ilyenre a felhasználót egy jól elhelyezett noscript taggal."
Pont ezt alkalmazom az egyik egyelőre csak tesztoldalamon, de időközben az jutott eszembe, hogy akkor esetleg ezt is indexeli a Google, az meg furcsán mutathat a találatoknál, hogy szerepel rajta egy figyelmeztetés arról, hogy be kéne kapcsolni a JavaScriptet, vagy olyan böngészőt használni, ami támogatja azt.
Mi a véleményetek erről? -
#6303
Sk8erPeter
nagyúr
zka67
#6302
Sk8erPeter
nagyúr
Szerintem elég gányolós megoldás kiíratni a hozzászólást egy fórum esetén <pre> tagekkel ellátva, és ennek a stílusát megváltoztatni CSS-sel utólag, hogy ne az alapértelmezett betűtípussal jelenjen meg. Tök másra való a <pre>, nem véletlenül más a betűtípusa sem, és nem véletlenül nem ezt szokták használni ilyen esetben - a JS-alapú szövegszerkesztők (lásd TinyMCE) is általában <br /> sortörésre alakítják a szöveget Shift+Enternél, vagy új bekezdést (<p>) hoznak létre sima Enternél. Nyilván jelen esetben az elsődleges cél a(z) (X)HTML-ben való megjelenítés, akkor ennek megfelelően is tároljuk el, és ne utólag gányoljunk a szöveggel. Szerintem.
-
#6139
Sk8erPeter
nagyúr
j0k3r!
#6138
Sk8erPeter
nagyúr
Van "tmp" nevű könyvtárad a rootban? Ha nincs, akkor atw-n sikertelen a fájlfeltöltés PHP-vel.
http://atw.hu/gyik#gyik5
"Miért nem működik a file feltöltés PHP-vel?A munkamenet fájlokat a PHP minden esetben a gyökérkönyvtárad alatti 'tmp' könyvtárban tárolja, ezért nincs más dolgod, mint létrehozni azt."
-
#6135
Sk8erPeter
nagyúr
Inv1sus
#6134
Sk8erPeter
nagyúr
válasz
Inv1sus
#6134
üzenetére
Azt nem tudom, mennyivel rontja a teljesítményt, ha egyáltalán észlelhetően rontja, mindenesetre semmiképp sem jó gyakorlat kihagyni a változók meglétének ellenőrzését, ha olyanról van szó, ami esetleg hiányozhat, mint pl. a $_GET értékek.
Ezeket is érdemes lehet inkább átadni egy másik változónak, aminek pl. van egy alapértelmezett értéke, de ha pl. a $_GET be van állítva, és "valid" (a saját feltételeid szerint), akkor az annak megfelelően módosul.
Pl. ha van egy $_GET['page'] változó, amire számítasz, akkor azt ellenőrzöd, pl. így (leegyszerűsített példa):<?php
// ......
try{
$page = 'home';
if( isset( $_GET['page'] ) ){
if( is_valid_page( $_GET['page'] ) ){ //feltételezzük, h megvan az is_valid_page() függvény.
$page = $_GET['page'];
}
else{
throw new Exception('Hibás címet adott meg!');
}
}
// .......
} catch (Exception $e){
// kivétel kezelése... pl.:
echo $e->getMessage();
}
?> -
#6133
Sk8erPeter
nagyúr
Inv1sus
#6132
Sk8erPeter
nagyúr
válasz
Inv1sus
#6132
üzenetére
Egyrészt lehet, hogy az újabb XAMPP verzióban (php.ini-ben) a default beállítás az volt, hogy notice jellegű hibákat is dobjon, ha pl. vizsgálgatsz olyan változót, ami nincs is definiálva, és előtte nem végeztél isset() ellenőrzést (tipikusan pl. a $_GET változók lehetnek ilyenek; megjegyzem, ezt a hibajelzést érdemes is bekapcsolni tesztelés idejéig, mert a fejlesztő hibája, ha ezek a hibák megjelennek), másrészt újabb PHP-verzió is lehet, aminél egyes deprecated függvényeket/globális változókat/stb. megszüntettek biztonsági vagy egyéb szempontok miatt. Egyéb ok is lehet, de ezek a valószínűek, ha egyébként sikeres volt a telepítés.
-
#6123
Sk8erPeter
nagyúr
Sk8erPeter
#6121
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6121
üzenetére
Na, már megint rosszat írtam:
"Van viszont read loop, ahol gyorsabb a for ciklus."
helyesen:
"Van viszont read loop, ahol gyorsabb a foreach ciklus." -
#6121
Sk8erPeter
nagyúr
Sk8erPeter
#6120
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6120
üzenetére
Ja jó, most látom, hogy itt épp az a lényeg, hogy pl. egy tömb minden elemének megváltoztatása esetén milyen rossz eredmények tudnak kijönni a foreach ciklusra a forral szemben, lásd Conclusion:
"Conclusion:
Proof in this example shows how functionally murderous the foreach() loop can be."DE ez a modify loop-ra vonatkozott.
Van viszont read loop, ahol gyorsabb a for ciklus."Conclusion:
In all cases I've found that the foreach loop is substantially faster than both the while() and for() loop procedures. One thing to note is that when using an entire loop from the start it's extremely good to use the reset() function in all examples."Érdekes eredmények jönnek ki egyébként minden frissítésnél, pl. több frissítés után már az idézőjel vs. aposztróf kérdés is megfordult.
"Is a there a difference in using double (") and single (') quotes for strings. Call 1'000x
[...]
Conclusion:
In today's versions of PHP it looks like this argument has been satisfied on both sides of the line. Lets all join together in harmony in this one!" -
#6120
Sk8erPeter
nagyúr
Frigo
#6114
Sk8erPeter
nagyúr
Thanks, pl. ez is elgondolkodtató:
$a = 'aaaaaaa';
echo 'aaaaaaa'.$a.'aaaaaaa'.$a; // 606 µs
$a = 'aaaaaaa';
echo 'aaaaaaa',$a,'aaaaaaa',$a; // 589 µsTehát vesszővel ennyivel gyorsabb. Mondjuk előbbiről korábban is láttam már írást, de ezen azért meglepődtem:
echo 'aaaaaaa'.'aaaaaaa'.'aaaaaaa'.'aaaaaaa'; // 218 µs
echo 'aaaaaaa','aaaaaaa','aaaaaaa','aaaaaaa'; // 562 µsItt a vesszővel kiíratás meg ennyivel lassabb, mint a konkatenálás, ezt egyelőre nem is értem...
Szerk.:
még egy:
hogy mi van? A foreach ennyivel lassabb, mint a for ciklus (216 µs vs. 64 µs)?!
Korábban pont azt olvastam, hogy a foreach gyorsabb működési elven alapszik, de majd megkeresem az erről szóló írást. -
#6112
Sk8erPeter
nagyúr
Speeedfire
#6111
Sk8erPeter
nagyúr
válasz
Speeedfire
#6111
üzenetére
Azt nem tudom, mekkora lehet a konkrét különbség, ha egyáltalán az általad említett példánál mérhető, de szerintem minél kevesebb kiíratást kell a PHP-ra bízni, és minél több a statikus tartalom, annál gyorsabb lehet. Tehát itt a 2. eset egy ennél azért hosszabb tartalomnál szerintem mérhetően gyorsabb lehet.
Nem szórakoztam még ezeknek a méregetésével, majd egyszer, ha nagyon ráérek... (akkor elmegyek inni
) -
#6109
Sk8erPeter
nagyúr
Tele von Zsinór
#6107
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6107
üzenetére
És erre mi a bizonyíték? Mert amúgy logikusnak tűnik, hogy legyen különbség, mivel gondolom meg kell vizsgálni, tartalmaz-e egyáltalán változónevet.
Amúgy meg már csak a HTML-elemek miatt is érdemes szerintem sima aposztrófot használni, csak egy példával élve nem mindegy, hogy néz ki a következő:
<?php
//aposztróffal:
echo '<img src="/images/misc/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31" width="88" />';
//idézőjellel:
echo "<img src=\"/images/misc/valid-xhtml10-blue.png\" alt=\"Valid XHTML 1.0 Strict\" height=\"31\" width=\"88\" />";
?>utóbbi elég ocsmány.
-
#6103
Sk8erPeter
nagyúr
Dave-11
#6070
Sk8erPeter
nagyúr
válasz
Dave-11
#6070
üzenetére
"Csináld így:
echo "<h3>"."Szöveg"."</h3>";"Minek fűzögeted össze ennyiszer? Lehet így is:
echo '<h3>Szöveg</h3>';"szerintem egyes idézőjelek ' ' helyett használj kettősöket " " ha szöveget akarsz kiírni."
Rossz tanács.
A sima aposztróffal való kiíratás gyorsabb lehet, mivel nem kell megvizsgálnia a "fordítónak", hogy van-e behelyettesítendő változó.
Nem mindegy, hogy írod:<?php
$var = 'akármi';
echo 'Itt a változó: $var'; //Kimenet: Itt a változó: $var
echo 'Itt a változó: '.$var; //Kimenet: Itt a változó: akármi
echo "Itt a változó: $var"; //Kimenet: Itt a változó: akármi
?>Itt van egy kis teszt a Weblaborban, a teszteredmények vagy relevánsak vagy nem, a lényeget leírja: ["Karaktersorozatok sebessége" PHP-ben].
-
#6043
Sk8erPeter
nagyúr
Inv1sus
#6041
-
#6013
Sk8erPeter
nagyúr
Speeedfire
#6012
Sk8erPeter
nagyúr
válasz
Speeedfire
#6012
üzenetére
Pont úgy viselkedik, ahogy elvárható lenne, mert nem tetted ciklusba a mysql_fetch_assoc függvényt.
Így lenne helyes:$query = 'SELECT fid, COUNT(fid) AS mennyi FROM `linkek_tartalom`
GROUP BY fid HAVING COUNT(fid) >= 10';
$result = mysql_query($query);
if(mysql_num_rows($result)) { //ha van egyáltalán megjeleníthető eredmény
while( $row = mysql_fetch_assoc($result) ) {
$felhasznalo_tomb[] = $row; //tömbbe gyűjtöd az adatokat - de akár egyből ki is írathatod a megfelelő mezőt
}
// ... (pl. felhasználhatod a tömböt, újabb ciklussal kiíratod [erre a kellően gyors foreach javasolt])
}
else {
echo 'Nincs bejegyzés...';
} -
#6011
Sk8erPeter
nagyúr
Tele von Zsinór
#6009
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6009
üzenetére
"Amúgy én úgy szoktam csinálni, hogy minden projektnek létrehozok egy-egy apache VirtualHost-ot, projektneve.local néven, megfelelő DocumentRoottal, és ezt felveszem a /etc/hosts-ba is. Innentől külön domainen futnak, elkerülve például az ilyen problémákat."
A számból vetted ki a szót Pont ezt akartam javasolni, még csak a múlt hónapban csináltam meg, azóta már csak így használnám, ezerszer kényelmesebb, mint a korábbi megoldás, amikor a localhostnak megfelelő könyvtárba pakoltam mindent, azonbelül is külön könyvtárakat kellett létrehozni a projekteknek, annál többet bepötyögni a böngésző címsorába, stb., szóval több szempontból is nagyon macerás.
Így meg teljesen egyedi neveket tudok létrehozni, és oda állítom be az elérési útjukat, ahová csak akarom.
Kezdetben próbálkoztam azzal is, hogy különböző portszámokhoz rendeltem a localhoston belül az egyes projekteket, aztán gyorsan rájöttem, hogy az megint macera (pl. nem túl beszédes a neve annak, hogy http://localhost:1234). -
#6004
Sk8erPeter
nagyúr
Tele von Zsinór
#6002
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6002
üzenetére
vagy inkább radio button.
-
#6000
Sk8erPeter
nagyúr
Speeedfire
#5991
Sk8erPeter
nagyúr
válasz
Speeedfire
#5991
üzenetére
"Valami olyasmi lenne a cél mint a ph-s képfeltöltő, csak nem ajaxos."
Az sem AJAX-os, hanem iframe-es.Amúgy AJAX-szal nem is lehet fájlt feltölteni, csak ilyen iframe-es trükközéssel, az AJAX-os képfeltöltők nagy része is így (vagy Flash közreműködésével) működik.
-
#5964
Sk8erPeter
nagyúr
Speeedfire
#5963
Sk8erPeter
nagyúr
válasz
Speeedfire
#5963
üzenetére
Az aposztrófot nem escape-elted!
echo '
<a href="'.$file.'" class="w" onmouseover="o(13, \''.$file.'\');" onmouseout="f(13);">
<img src="'.$file.'" alt="'.$file.'"></a>
';Így okés.
-
#5962
Sk8erPeter
nagyúr
Speeedfire
#5960
Sk8erPeter
nagyúr
válasz
Speeedfire
#5960
üzenetére
A tabulátor \t, ha idézőjelbe (nem aposztrófba) rakod, hasonlóan a \n-hez, látszik a forráskódban.
A HTML-kimenetnél csak akkor látszik majd a tabulátor, ha a <pre> taget használod. Egyébként csak egy whitespace látszik belőle max. -
#5959
Sk8erPeter
nagyúr
Speeedfire
#5958
Sk8erPeter
nagyúr
válasz
Speeedfire
#5958
üzenetére
Én is Notepad++-ról álltam át NetBeans-re, és most már csak akkor használom a Notepad++-t, ha rövid, gyors változtatásra van szükség a kódban, mert a Notepad++-nak csak az erőforráskímélő, gyors működése az előnye a NetBeans-szel szemben, de cserébe a NetBeans mindenféle egyebet nyújt, amit a Notepad++ nem.
Notepad++-ban az automatikus kiegészítés gagyin volt megoldva a NetBeans-hez képest, pl. PHP-projektben csak PHP-függvényneveket tudott kiegészíteni, HTML-elemeket, JavaScript-kódot nem volt hajlandó, míg NetBeans erre is képes. Még jQuery-hez is használom! CSS-fájlokban is működik az automatikus kiegészítés.
Osztályok használatánál is nagyon nagy segítséget nyújt, meg ha pl. függvénydefinícióra akarsz ugrani, akkor elég a függvény használatánál a neve fölé vinni a kurzort, és Ctrl+klikkel oda is ugrik. Ezenkívül tud automatikus formázást is az Alt+Shift+F-fel, ami szépen rendbeszedi, indentálja a széjjeldobált kódot.
Arra is van mód, hogy egy "palettáról" bedobálj kész HTML-elemeket, mint pl. táblázat, rendezett és rendezetlen lista, képhivatkozás, formok, stb., nem kell tökölni a manuális beírogatással, így igazából Dreamweaver-alternatívának is használható.
Ctrl+Space-szel kiegészíti a kódot, ha pl. egy switch-case szerkezetet szeretnél gyorsan létrehozni, azt is meg tudod tenni úgy, hogy beírod pl. a switch kulcsszót, aztán nyomsz egy Ctrl+Space-t, és felkínálja a lehetőséget arra, hogy létrehozza az egészet.PazsitZ is írt pár szempontot, az is mind igaz, ezenkívül tényleg annyi lehetőség van, hogy lehetetlen lenne itt kifejteni. Én nagyon megszerettem a használatát, nem térnék vissza az alap szövegszerkesztők használatára.
Egyetlen hátránya (számomra legalábbis eddig csak ez tűnt fel) a NetBeans-nek tényleg az, hogy zabálja a memóriát (nem is meglepő), meg kicsit lassan indul be, meglehetősen erőforrás-igényes, de annyi előnye van, hogy bőven megtérül a használata. -
#5920
Sk8erPeter
nagyúr
Brown ügynök
#5919
Sk8erPeter
nagyúr
válasz
Brown ügynök
#5919
üzenetére
Hali!
Van a Web Developer-nek Chrome-bővítménye is, de valami oknál fogva nálam nem hajlandó működni a Validate Local HTML (Chrome 9.0.597.19 beta, Ubuntu x86).
A HTML Validator-t viszont most próbálgatom, eddig nagyon fasza, érdemes kipróbálni.
Nálam Chrome-újraindítás után működött csak, pedig elvileg telepítés után mennie kéne gond nélkül, de ez mondjuk annyira nem para.A Firebug - ha nem is feltétlenül teljes értékű - alternatívájaként ott van a Chrome beépített Developer Tools-a.
-
#5904
Sk8erPeter
nagyúr
Brown ügynök
#5903
Sk8erPeter
nagyúr
válasz
Brown ügynök
#5903
üzenetére
Nyilván BOM nélküli UTF-8-kódolású fájlod legyen, a BOM már megjelenít egy kimenetet még a DOCTYPE előtt.
Akkor is ugyanezek a hibák, amikor BOM nélküli UTF-8 kódolásban van, vagy mi?Mindenesetre a "fentartva" szót javítsd már ki...
(fenntartva)Szerk.: Mellesleg nem értem, a függvényednek mi értelme van?
function kapcsolat() {
echo "<p>info@kapcsolat.hu</p>";
}
Ráadásul ez egy osztályba építve, aminek ez az egyik fő metódusa, hogy ezt kiírja? Számomra őszintén szólva nem igazán egyértelmű, amiket írsz. Plusz igencsak feleslegesnek látszik ez a függvény... -
#5881
Sk8erPeter
nagyúr
LW
#5874
Sk8erPeter
nagyúr
"PHP mindig szerver oldalon fut."
Tévedsz. Ilyen kijelentések előtt inkább tájékozódj.http://en.wikipedia.org/wiki/PHP#Usage
"PHP is a general-purpose scripting language that is especially suited to server-side web development where PHP generally runs on a web server. Any PHP code in a requested file is executed by the PHP runtime, usually to create dynamic web page content. It can also be used for command-line scripting and client-side GUI applications."Erre utalt rt06 is.
-
#5545
Sk8erPeter
nagyúr
Tele von Zsinór
#5542
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#5542
üzenetére
"Alternatíva lehet, hogy select * helyett csak azokat jelölöd ki, amik majd kellenek."
Az a baj, hogy így vagy 15-20 mezőt fel kéne sorolnom, az meg nem túl átlátható.
Igazából minden kell, csak ez a duplikált mező gáz, erre nem tudok megoldást, hogy lehetne szépen, úgy, hogy ne kelljen minden mezőt egyesével kiírogatni.A tárolt eljárásnak majd utánanézek, bár első körben nem biztos, hogy könnyű dologról van szó, és csak akkor érdemes ezzel foglalkozni, ha sikerül a view-t létrehozni a duplikált mezők nélkül - erre nem tudom, mi a mód.
-
#5539
Sk8erPeter
nagyúr
D@ni88
#5538
Sk8erPeter
nagyúr
Nem is nagyon értem, mit akarsz helyenként a kódodban... Pl. mit szeretnél azzal a mysql_error(); sorral? Az nem fog neked semmit kiírni... Akkor már az előző sor után tegyél egy or echo mysql_error(); részt, vagy így:
if (mysql_errno()) {
echo 'Hiba a lekérésnél: '.mysql_error();
}Bár ezt inkább logolni kéne, nem a felhasználónak mutatni a konkrét hibaüzenetet.
Az ilyeneket felejtsd el:
$kiir .=
"\n\t\t\t<td class=\"nev\">".$sor["fnev"]."</td>".
"<td class=\"Fnev\">".$sor["Vnev"]." ".$sor["knev"]." </td>".
"<td class=\"tel\">".$sor["telefonszam"]."</td>".
"<td class=\"email\">".$sor["email"]."</td>".
"<td class=\"cim\">".$sor["cim"]."</td>".
"<td class=\"tel\">".$sor["ellenorzott"]."</td>";valami kegyetlenül átláthatatlan, helyette akkor már:
$kiir .= '
<td class="nev">'.$sor['fnev'].'</td>
<td class="Fnev">'.$sor['Vnev'].' '.$sor['knev'].'</td>
<td class="tel">'.$sor['telefonszam'].'</td>
<td class="email">'.$sor['email'].'</td>
<td class="cim">'.$sor['cim'].'</td>
<td class="tel">'.$sor['ellenorzott'].'</td>';Ez már egy pár fokkal jobb.
Mellesleg tök feleslegesen gyűjtöd a $kiir stringbe ezeket a sorokat, ha utána egyből ki is íratod.
Legyen első az adatbázis-lekérdezés, ha az nem ad vissza hibát, akkor mehet egyből az echo-zás.Az adatok kiírásánál nagyon helytelen a táblázatod, a <form> nyitótag előtt lezárod a korábbi sort, és nem is nyitsz újat, még be kéne raknod egy <tr> nyitótagot...
Ja, meg ezek szerint minden egyes felhasználónál akarsz egy külön submit gombot, hogy mindegyiknél el tudd küldeni, ellenőrizte-e már a júzer, akkor a <form> nyitótag tök rossz helyen van, a while cikluson belül kellene lennie, hiszen így minden egyes felhasználóhoz tartozik egy-egy form.
Tehát töröld ki azt a <form> sort a while ciklus elől, és legyen a while cikluson belül (!) egy <tr>, majd a </tr> a while végén, és a sorokon belül oldd meg, hogy legyen a többi adat a submit gombbal együtt... Igazából szabályosan jelen esetben sztem táblázatba ágyazott táblázattal lehetne (persze egyszerűbben is meg lehet oldani, de most arról beszélek, ahogy a Te kódod kinéz).Mindenesetre a lényeg, hogy minden egyes ellenőrizendő felhasználóhoz külön form tartozzon.
Kemény a kódod, belezöldülök, mire átlátom... -
#5535
Sk8erPeter
nagyúr
Tele von Zsinór
#5527
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#5527
üzenetére
Egyelőre ezzel a kóddal az a gond, hogy úgy tűnik, a view létrehozásánál már problémázik azon, ha duplikálva van egy mező, erre ezt dobja:
#1060 - Duplicate column name 'kep_id'
Tehát a "kep_id" mező a problémás, de gondolom a "kutya_id" mezővel is problémája lenne, mert az is kétszer szerepel (van egy tábla a kutyák adatainak (név, stb.), és van egy külön a képeiknek, valamint van egy összerendelő tábla, ami ezeknek az azonosítóit összekombinálja; ezenkívül van még egy külön tábla a törzskönyveknek - de van olyan eset, hogy a törzskönyvre nincs szükség).
Hogyan tudnám megoldani? Alias-t használnék, de nem tudom, hogyan lehet megcsinálni azt, hogy minden mezőt kiválasztok, de egyes mezőknek más nevet adok a lekérdezésnél.
Vagy ezt csak az összerendelő táblában lévő mezők átnevezésével lehet megoldani?A "tárolt eljárás" alatt mit értesz?
---
(#5534) omega88: most nincs ötletem, az fsockopen()-t még nem használtam.
-
#5523
Sk8erPeter
nagyúr
Tele von Zsinór
#5520
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#5520
üzenetére
Na így már viszont érdekesebbnek hangzik.
Van egy lekérdezésem, mely az alábbi, szándékosan hagytam a PHP-s formában, hogy látható legyen, hogy paraméterezéstől függően változhat:$query = '
SELECT *
FROM tbl_img
INNER JOIN (
tbl_ossze
INNER JOIN tbl_kutya ON tbl_kutya.kutya_id = tbl_ossze.kutya_id
AND tbl_kutya.menupont = "'.$page.'" ';
if($data_needed == true){
$query .= 'INNER JOIN tbl_torzskonyv ON tbl_kutya.torzskonyv_id = tbl_torzskonyv.torzskonyv_id ';
}
$query .= '
) ON tbl_ossze.kep_id = tbl_img.kep_id
ORDER BY tbl_kutya.nev ASC ;
';Egy ilyen jellegű lekérdezésre már érdemes lehet VIEW-t írni?
Mindegyik lehetséges paraméterre (pl. a $page lehet jelen esetben négyféle!) külön meg kell csinálni a VIEW-t?
Amúgy ilyenkor mi a szintaktikája, hogyan készíted el a VIEW-t belőle? -
#5518
Sk8erPeter
nagyúr
omega88
#5511
Sk8erPeter
nagyúr
válasz
omega88
#5511
üzenetére
Most esik le, a portszámot miért idézőjelbe rakod? Szerintem az úgy nem megfelelő, az is hibát okozhat.
Próbáld meg idézőjel nélkül:
$fp = @fsockopen( "tcp://.....", 8129, $errno, $errstr, 5);Ja, és debuggolás erejéig írasd ki az $errno, $errstr változókat, ahogy már korábban javasolták, pl. így:
if($fp) {
$stat = "Online";
} else {
$stat = "Offline";
$stat .= 'Error! '.$errno.': '.$errstr; //debuggolás erejéig, utána kiszedhető
}-------
(#5517) fordfairlane: OK, köszi a felvilágosítást, akkor egyelőre azt hiszem, inkább másra fordítom az erőforrásaimat, mint hogy a VIEW működését tanulmányozgassam. -
#5516
Sk8erPeter
nagyúr
biker
#5510
Sk8erPeter
nagyúr
Hát nem tudom, ha tényleg nem kapcsolgatja ki a felhasználó a cookie-k fogadását a böngészőben, vagy nem törli azokat, akkor számomra nem igazán érthető a probléma.
(#5515) fordfairlane: OK, köszi, ez is egy szempont.
Akkor viszont az általános, valóban érzékelhető, eme bolygón született weblapkészítők számára hasznos gyakorlati jelentőségével még mindig nem vagyok tisztában. -
#5506
Sk8erPeter
nagyúr
biker
#5504
Sk8erPeter
nagyúr
Hát ez mondjuk elég furcsa, mert a böngészőnek tárolnia kellene a session cookie-t, akár új lapon/ablakban nyitod meg, akár nem.
Nincsenek ilyen gányolós ob_start jellegű hívások, valahol egy session_destroy, unset függvénybe bepakolt session változók, stb.? Más nem jut eszembe, mint áttúrni a kódot ilyenek miatt. Azért ennyire nem szar még az IE sem, hogy ilyen jellegű probléma legyen (legalábbis én még nem találkoztam ilyennel). Főleg, hogy FF-nál is előfordul.
De lehet, hogy valakinek lesz ennél konkrétabb ötlete, mindenesetre tény, hogy új ablak/fül nyitásától független a dolog.Amúgy nem target=blank, hanem target="_blank".
![;]](//cdn.rios.hu/dl/s/v1.gif)
-----
(#5503) DeltaPower: köszi, közben nézegetek leírásokat a view-ról, ez egész jól összefoglalja, miért jó: [Introduction to SQL Views]
Ez elég jól hangzik, ezek szerint biztonsági szempontok is közrejátszhatnak abban, hogy view-t használjunk. -
#5491
Sk8erPeter
nagyúr
biker
#5490
Sk8erPeter
nagyúr
Mit értesz azalatt, hogy "amit nem illik"?
Ez igencsak igényfüggő...Amúgy ha automatikusan escape-el a magic_quotes_gpc miatt, az se jó (ne bírálja felül a döntésedet), arra fordfairlane írt korábban megoldást: [link]
---
(#5487) Tele von Zsinór: köszönöm, mindenképp átnézem.
-
#5486
Sk8erPeter
nagyúr
biker
#5476
Sk8erPeter
nagyúr
Az empty() függvény miért nem megfelelő?
-----------------
(#5469) Tele von Zsinór: köszi a választ, akkor itt az ideje, hogy én is írjak pár saját hibaosztályt, és ezeket dobáljam a megfelelő helyeken.
Példának okáért milyen esetekre írtál saját hibaosztályt? Csak a gondolkodásmódra vagyok kíváncsi. -
#5464
Sk8erPeter
nagyúr
Speeedfire
#5463
Sk8erPeter
nagyúr
válasz
Speeedfire
#5463
üzenetére
A Newhosting-os szervernél ugyanez tapasztalható! Azt Te is ki tudod próbálni.
-
#5462
Sk8erPeter
nagyúr
Tele von Zsinór
#5460
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#5460
üzenetére
A kivételkezelésre majd mindenképp átállok.
Nálad pl. nagyvonalakban hogy néz ki egy adatbázis-kezelésnél fellépő hiba esetén elkapott kivétel, és egyéb, az oldalon felmerülő hibák esetén dobott kivételek?
Tudsz mutatni egy pársoros gyakorlati mintapéldát, ha nem gond? Tényleg csak nagyvonalakban lennék kíváncsi konkrét példára.A PDO-t egyelőre úgy képzeltem el, hogy MySQL-lel, a régi lekérdezési parancsokkal együtt használnám, így állnék át - úgy olvastam, hogy erre is van lehetőség. Bár ha macerás, akkor inkább kihagyom.
Egyelőre ezeket találtam erről, még nem volt időm átolvasni: [php.net: MySQL Functions (PDO_MYSQL)], [dev.mysql.com: Using MySQL with PDO] -
#5461
Sk8erPeter
nagyúr
Speeedfire
#5459
Sk8erPeter
nagyúr
válasz
Speeedfire
#5459
üzenetére
Most a böngészőfüggetlenséget úgy értettem, hogy arra voltam kíváncsi, az /index cím automatikus KIEGÉSZÍTÉSE az /index.php-re hol történik (még .htaccess nélkül!! tehát hozzábiggyeszti a php kiterjesztést automatikusan! és így a /index beírására nem az index könyvtárat, hanem az index.php FÁJLT nyitja meg) - nyilván ez szerveroldali dolog (nem böngészőtől függ).
Pont emiatt van a problémám, egyelőre NEM a .htaccess miatt, mert ha az egyáltalán nincs is a könyvtárban, akkor is megtörténik a kiegészítés (.php-re) - esetemben emiatt a /contact paramétert a .htaccess segítségével sem tudtam átadni GET paraméternek, mert automatikusan a /contact.php fájlt nyitja meg.
Ennek megoldására voltam kíváncsi, hogy a contact.php fájl átnevezése helyett (pl. ha átnevezem contact222.php-re, akkor csak a /contact222 cím beírásának hatására fog megnyílni ez a fájl, a /contact-re nem) - van-e más megoldás, és hogy pl. Apache-nál ez az automatikus kiegészítés konkrétan miből ered. -
#5458
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Még egy kérdés, bocs, ha kicsit OFF.
Apache-csal kapcsolatos:
van egy contact.php nevű fájlom, és most localhoston próbálgatva csodálkoztam rá, hogy a http://localhost/contact beírására (kiterjesztés nélkül) is megnyitja a contact.php-t, pedig most épp az URL keresőbarátabbá tételével szórakozom, és inkább azt szeretném, ha egy GET változónak lenne átadva a "contact". A hozzátartozó .htaccess már megvan, működőképes is, kivéve ennél a contact.php-nél, mert a /contact-re is azt nyitja meg, nem az index.php GET változójaként adja át, így a mod_rewrite nem működőképes.
Csak úgy változtathatok ezen, ha a fájlnevet átírom? Ez mondjuk csak azért problémás, mert akkor máshol is át kell írni, minden fájlban, amiben hivatkozom rá - mondjuk annyira nem durván para, mert Notepad++-ban csak meg kell nyitni az érintett fájlokat, és egy kattintás az összes doksiban a névcsere, de azért érdekelne: az automatikus névkiegészítés miatt van?Pl. /index esetén is általában ki lesz egészítve automatikusan a php kiterjesztéssel (index.php-re) - ez most böngészőfüggő vagy a szerver intézi így?
-
#5457
Sk8erPeter
nagyúr
Gyuri16
#5456
Sk8erPeter
nagyúr
válasz
Gyuri16
#5456
üzenetére
Tényleg, ha már itt tartunk, Ti milyen módon kezelitek le az ilyen jellegű hibákat?
Gondolom sokan kivételkezeléssel, van, aki más módszerrel.
Bár a kivételkezelés szép, mert elkerülhető vele a sok if-elseif-else ág, és mindig egy helyen kezeled a kritikus problémát.
Milyen esetekben dobtok kivételt?
Én most gondolkoztam a PDO használatán, talán áttekinthetőbb lenne pl. adatbázis-kezelésre.
Sajnos a régi kódjaim tele vannak ilyen mysql_query(...) or die(...) részlettel, amit így utólag már belátok, hogy valóban nagyon csúnya módszer, ezért szeretném lecserélni helyenként. (Még ha látszólag nem is éri meg - van olyan oldal, aminek a kódját áttekinthetőbbé, a futását gyorsabbá szeretném tenni.)
Vicces utólag böngészgetni a régen írt kódjaimat...Egyébként a kivételkezelésnél akkor az egész kritikus kódrészletet bele kell pakolni egy try blokkba, ami szintén nem túl szép, nem? Bár még mindig szebb, mint a sok if-else ág.
-
#5428
Sk8erPeter
nagyúr
Speeedfire
#5425
Sk8erPeter
nagyúr
válasz
Speeedfire
#5425
üzenetére
Firebugban be kell kapcsolni az "XMLHttpRequest események megjelenítése" menüpontot, ha az AJAX-kéréseket szeretnéd figyelni. (Konzol fülre kattintva megjelenik egy kis nyíl, ott lehet kiválasztani.)
A szkripthez pedig lehet betenni breakpointokat, és ott az látszik, hogy a "Tovább..."-ra kattintva a szkript is lefut, abban a pillanatban olyan lesz az oldal kinézete, amilyet linkeltél (a #main-ben a kerettel együtt megjelenik a tartalom), de aztán frissíti az egész oldalt (innentől pedig értelmetlen az AJAX-kérés).Megpróbálhatnád úgy is a ready utáni résznél, hogy
$('.ajaxload').live("click", function () {
$('#main').load($(this).attr('href') );
return false;
});(és nem a load paramétereként teszed be a másik függvényt)
próbát megér, legalább addig jussunk el, hogy ne frissüljön az egész oldal, ha már AJAX.Szerk.:
ja, VAGY pedig ha már az
e.preventDefault();
sort használod, akkor ne a load paramétereként tedd be, hanem azután, ha már... legalábbis így elsőre jobbnak tűnik...$('.ajaxload').live("click", function ( e ) {
$('#main').load($(this).attr('href') );
e.preventDefault();
}); -
#5423
Sk8erPeter
nagyúr
Tele von Zsinór
#5422
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#5422
üzenetére
De ha ez így van, akkor nálam miért működik az elvárt szerint a fentebb írt kód? (több böngészőben is)
Mondjuk igaz, most a próba és az egyszerűség kedvéért csak egy pársoros, egy-egy képet tartalmazó HTML-fájlllal próbáltam ki. -
#5421
Sk8erPeter
nagyúr
Speeedfire
#5420
Sk8erPeter
nagyúr
válasz
Speeedfire
#5420
üzenetére
Akkor csak az lehet a gond, hogy a beillesztendő fájlba (ami jelen esetben a jQuery-kódban a $(this).attr('href') ) include-oltad a keretet is, mert egyébként teljesen jól kell működnie (amennyiben a kód a head részben van elhelyezve, stb.), kipróbáltam, és jól ment.
Magához a betöltéshez nincs szükség a második paraméterre:
<script type="text/javascript">
<!--
$(document).ready(function(){
$('.ajaxload').live("click", function () {
$('#main').load( $(this).attr('href') );
return false;
});
});
// -->
</script>De figyelj arra, hogy az AJAX-os betöltés esetén lehet, hogy a Google nem indexeli a teljes oldalt.
OFF: akármennyire borzasztó és rémisztő is, már a teljes admin oldal valid...
Igazából azért érdemes ilyen kicsit komplexebb levelezőrendszerbe átrakni (ott van még a 
), az osztályt a megfelelő helyen include-olni, példányosítani, beállítgatni a különböző dolgokat (küldő, fogadó, tárgy, tartalom, stb., sokkal kézenfekvőbb, mint a sima mail() függvénnyel szarakodás) és használni, és ennyi. 
Amúgy is minek azt, csak megy vele az idő! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Milyen légkondit a lakásba?
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- Tőzsde és gazdaság
- Milyen TV-t vegyek?
- Samsung Galaxy A56 - megbízható középszerűség
- Eredeti játékok OFF topik
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
- Opel topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Synology NAS
- További aktív témák...
- Csere-Beszámítás! MSI Suprim X RTX 3080 10GB Videokártya!
- Csere-Beszámítás! Sapphire Nitro+ RX 6700XT 12GB Videokártya!
- SZÉP Lenovo ThinkPad P15 G2 Tervező Laptop -75% 15,6" i9-11950H 64/2TB RTX A4000 8GB UHD OLED
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 16GB/512GB FHD IPS
- Eladó Apple MacBook Pro 13" A1706 (Late 2017, Silver - EMC 3163)
- REFURBISHED és ÚJ - Lenovo ThinkPad 40AS USB-C docking station (akár 3x4K felbontás)
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
- BESZÁMÍTÁS! LENOVO Ideapad Gaming 3 notebook - i5 11320H 16GB DDR4 256GB+1TB SSD GTX 1650 4GB WIN11
- Dell és HP szerver HDD caddy keretek, adapterek. Több száz darab készleten, szállítás akár másnapra
- ÁRGARANCIA! Épített KomPhone i5 13400F 32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest