- Akciófigyelő: Humble Games Bundle - Nightdive FPS Remasters
- Call of Duty: Modern Warfare III - Új szezon, újabb ingyenes hétvége jön
- Hunt: Showdown - Jön az engine csere, befutnak az újgenerációs verziók
- Steamre tart a Crime Boss: Rockay City
- The Witcher - Befutott a TV sorozat folytatásának első rövid kedvcsinálója
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz Speeedfire #4751 üzenetére
Azért a fájljaidba a <!DOCTYPE...> elé (!) beszúrhatnád a köv. sort:
<?php
header('Content-Type: text/html; charset=utf-8');
?>Lehetőleg a MySQL-csatlakozást is még előtte intézd el, és a
mysql_query('SET NAMES utf8');
sort is illene az elé pakolni.Ha fv.-be és külön fájlba pakolod a MySQL-csatlakozást, akkor ilyesmi lehetne pl. végeredményként:
<?php
header('Content-Type: text/html; charset=utf-8');
require_once('functions.php');
//MySQL-csatlakozás:
csatlakozas();
mysql_query('SET NAMES utf8');
//...
?>
<!DOCTYPE .....>[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4757 üzenetére
Eddig azt hittem, az már megvolt, hogy maga a fájlod UTF-8 kódolású... Ha az nincs meg, akkor tök feleslegesen erőlködsz, össze-vissza kódolásokkal mindenképp szar lesz a karakterkódolás.
Ragaszkodj egyféle karakterkódoláshoz következetesen, különben szívni fogsz vele (mint látható ).Notepad++ » Kódolás » "Átalakítás UTF-8 kódolásra BOM nélkül" menüpontra klikkelj az összes olyan fájlnál, ami nem UTF-8 kódolású (ld. DeltaPower hsz.-ét). (Itt fontos, hogy az "Átalakítás..." kezdetűre menj, különben megint csak rossz lesz.)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4784 üzenetére
tudsz mutatni komplett kódrészletet? nem nagyon olvastam vissza, de kicsit egyszerűbb lenne látni, miről van szó.
a session_start()-ot a kódod legelején add ki.echo "session_start();"
ennek semmi értelme, ez jól kiírja, hogy session_start();, és annyi.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4787 üzenetére
Csináld úgy, ahogy Tele von Zsinór mondja, de azért azt is mondhattad volna, hol vannak notice-ok, és mi az üzenet tartalma, mert szerintem kizárt, hogy valaki elejétől végéig átböngészi a kódot, hibákat keresve.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4796 üzenetére
Kicsi projektnél is van értelme az átláthatóság növelésének.
A notice szerint már van valahol egy session_start(); hívás. Ha require_once-szal az általad mutatott kódot mindenhol include-olod, ahol szükség van session elindítására és MySQL-csatlakozásra, akkor az összes többi session_start();-ot és MySQL-csatlakozást kiveheted! Akkor már nem fogja dobni a notice-t.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4879 üzenetére
Most nincs időm átnézni a kódot, de az ilyen mennyiségű idézőjel-escape-eléseket elkerülhetnéd (így nagyon áttekinthetetlen szerintem):
echo "<div class=\"margo\"><table><tr><td class=\"num\">\n$lines\n</td><td>\n$content\n</td></tr></table></*div>";
(Itt ez a </*div> amúgy hibás)
sima aposztrófok használatával:
echo '
<div class="margo">
<table>
<tr>
<td class="num">'.$lines.'</td>
<td>'.$content.'</td>
</tr>
</table>
</div>';Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4911 üzenetére
Bár nem igazán értem az értelmét a kódodnak, reguláris kifejezéssel ilyen lenne:
elseif ( isset($_GET['sorszam']) and (!preg_match('[\/admin\/.*]', $oldal) ) ){
...
}Remélem stimmel, nem teszteltem túl hosszan, de 3 dologra jól működött.
Sk8erPeter
-
Sk8erPeter
nagyúr
"Én úgy szoktam csinálni, hogy nem használok echo-t, hanem egy $html vátozóba írom a html outputot."
Én is így csinálom két oldalnál is, de pont azt mondta pár hónappal ezelőtt Tele von Zsinór, hogy PHP-ban a stringműveletek relatíve lassúak.Sk8erPeter
-
Sk8erPeter
nagyúr
Győződj meg róla Notepad++-ban, hogy biztosan UTF-8 kódolásúak-e a fájljaid, és mielőtt adatbázis-műveleteket hajtasz végre, a MySQL-csatlakozás után küldj ki egy ilyet:
mysql_query('SET NAMES utf8');Az oldal legelejére, minden output előtt pedig állítsd be a fejlécet UTF-8-ra:
header('Content-Type: text/html; charset=utf-8');Sk8erPeter
-
Sk8erPeter
nagyúr
Na de lehet, hogy a korábban feltöltött adatok nem UTF-8 kódolással kerültek az adatbázisba, így utólag kellene javítani őket. De ezt könnyen ki tudod deríteni, hogy az volt-e a gond, ha ugyanazzal a módszerrel, amivel a korábbi adatok bekerültek, feltöltesz valami új bejegyzést az adatbázisba, csak annyi különbséggel, hogy az általam előbb írtakat is beleteszed, majd azt is lekérdezed, megnézve, hogy javult-e. Ha igen, akkor ki kell javítani a korábbi bejegyzéseket.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4958 üzenetére
Kipróbáltam, tökéletesen működik localhoston.
Egy 1300 soros kóddal próbáltam ki...Szerk.: a contrib/example.php segítségével próbáltam ki.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4960 üzenetére
nálam most localhoston:
PHP 5.2.6
Apache 2.2.8Kipróbáltam a Te kódodat is (kiszedve az adatbázis-műveleteket), az is jól működik nálam.
Konkrétan nálad mi a hibajelenség?Szerk.: amúgy a kódodban tök feleslegesen használod az ob_start(); függvényt, nyugodtan pakolhatnád még az output elé az átirányítást, megfelelően átírva a kódot.
Amúgy is értelmetlen az egész HTML-részt echo-val kiíratni, mivel annak többsége mindig statikus. Válaszd szét jobban a kódodat (pl. a MySQL-csatlakozást is tedd még az output elé), mert így nehezen átlátható, ráadásul nem túl elegáns.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #4962 üzenetére
"Azért van ott az ob_start() mert már megszoktam a használatát, akár milyen kicsi is a program használom."
Csak akkor használd, ha nagyon muszáj, mert egyébként nagyon rossz programozási gyakorlathoz vezethet, és más számára is kevésbé áttekinthető a program.
Ezenkívül tök felesleges ott alkalmazni, ahol egyáltalán nincs rá szükség (pl. nem akarsz az output után még átirányítani header()-rel), na meg ellenkezik az MVC-szemlélettel.
(Egy szóval: gányolás! )"Miért baj echo-zni a statikus dolgokat?"
Felesleges lassítani a megjelenítést, ha gyorsabb is lehet. És megint csak az átláthatóság..."így olvastam a leírásokat a neten"
A net tele van szeméttel...--
Geshi-vel kapcsolatban: már eleve az example.php sem megy? Nem néztem bele a kódjába, de elvileg nem kéne, hogy baja legyen magasabb számú PHP-verziókkal, de esetleg adhatnál neki egy próbát, hogy kipróbáld korábbival, mint az 5.3.0. Bár szerintem valahol máshol lesz a hiba.
A MySQL-rész NÉLKÜL is kipróbáltad már a kódodat? Ha anélkül sem megy, akkor nem az adatbázissal hozható kapcsolatba, legalább akkor ezt ki lehet zárni.Szerk.: ja, amúgy a kódodban az hibás, hogy a megjelenítés során is escape-elve jelennek meg az idézőjelek, aposztrófok és egyéb speciális karakterek (pl. echo \"valami\". Ettől függetlenül működik, csak rosszul jelenik meg a kód.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #5021 üzenetére
Akkor magyarul ilyen esetben csak az a megoldás, hogy ha automatikusan escape-elődik pl. az összes $_POST érték, és ezzel tisztában vagyunk, akkor először alkalmazzuk a stripslashes() fv.-t, majd a mysql_real_escape_string() fv.-t az adatbázisba való feltöltéshez (amit amúgy is kellene, csak a stripslashes() nélkül már duplán lenne escape-elve)?
Csak mert nálam is van egy hasonló probléma, de a mysql_real_escape_string() fv.-t nem szeretném elhagyni, mert ki tudja, később nem lesz-e PHP-verzió-váltás vagy egyéb módosítás (pl. az általad említett opció kikapcsolása).
Így elsőre gánynak hangzik, de nem jut eszembe jobb megoldás.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #5026 üzenetére
Már PHP 5.3.0-tól is deprecated, a történelmi előzmény érthető is, meg nem is, de ez nem változtat az eredeti kérdésen. Továbbra sem jut eszembe más, mint bent hagyni a mysql_real_escape_string() fv.-t, mert én adatbázisba töltök fel, de mivel a magic_quotes_gpc beállítás továbbra is úgy marad, először el kellene tüntetni belőle az escape-elt karaktereket, hogy ne legyen duplán escape-elve... Később egyszerűbb lenne a stripslashes()-t eltávolítani, mint most kihagyni valamelyik lépést (pl. a mysql_real_escape_string()-et), ami amúgy sem lenne praktikus szerintem. Nem?
Szerk.: látom miközben írtam a hsz.-t, szerkesztetted a sajátodat.
"a stripslashes-t kell feltételes módban és tömbre rekurzívan meghívni"
Hogy érted, hogy "feltételes módban"? Mit kellene vizsgálni?Amúgy lehet, hogy késő van, de most az sem esik le, hogy tömbre miért rekurzívan? Pl. sima foreach-csel bejárom. Vagy lehet, hogy félreértelek.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz Speeedfire #5251 üzenetére
Ez aztán jó ronda megoldás... ($_GET változónak értéket adni? Hmm... )
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #5313 üzenetére
a rengeteg elseif helyett megoldhattad volna switch-csel, így nagyon átláthatatlan
szerk.: amúgy bocs a kötekedésért, csak rég voltam a topicban, kicsit visszaolvastam, és szemet szúrt ez meg az előző[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Az a "bajom", hogy ez a "nyomorult" változótípus olyan változótípus, aminek a $_POST, $_SERVER, $_REQUEST, stb. változókhoz hasonlóan nem illik értéket adni, mivel ez a szkript bemeneti adata, és ha hozzányúlkálsz, akkor adott esetben előfordulhat, hogy saját magaddal szúrsz ki. Akkor már érdemes ezeket a bemeneti adatokat átadni egy másik változónak, és azt már tetszőlegesen módosíthatod. Persze megteheted, hogy ezeket a bemenetként kapott adatokat is módosítod, de azt úgy nevezik, hogy gányolás.
Ez hasonló ahhoz, mintha mondjuk C-ben az argc, argv változókat módosítanád. Az is gányolás.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #5336 üzenetére
Az nem baj, ha dolgozol vele, felhasználod az értékeit (nem muszáj átadni másik változónak, sőt, sokszor felesleges - pl. végigrohangászhatsz egy foreach ciklussal a $_POST értékeken, átadni az értékeket másik változónak meg csak felesleges időveszteség (már amennyiben ez egyáltalán érzékelhető ideig tart)) csak az a furcsa, ha módosítod. Én nem tenném, persze mindenki azt csinál ezekkel a változókkal, amit csak akar.
Most megtaláltam cucka egy régi hsz.-ét, amire emlékeztem, ahol ő is pontosan ugyanerről ír, csak jóval több hozzáértéssel, mint ahogy én vakerászok: [link]A switch nagyon egyszerű, és megkímél a sok-sok if-elseif-else ág írogatásától, pl. a Te kódod esetén jelenleg így néz ki:
if-elseif-else megoldással:
if ($_POST['tipus'] == 'navigacio') {
// ...
}
elseif ($_POST['tipus'] == 'tartalom') {
// ...
}
elseif ($_POST['tipus'] == 'felhasznalo') {
// ...
}
// ...
else{ //ha egyik sem a fentiek közül
// ...
}ugyanez switch-case megoldással:
switch($_POST['tipus']){
case 'navigacio':
//...
break;
case 'tartalom':
//...
break;
case 'felhasznalo':
//...
break;
//...
default: //ha a fentiek közül egyikkel sem egyezik meg (ez az if-elseif-else ágból az utolsó, az else ág)
//...
break;
}(amúgy most nézem, nálad nincs az if-elseif után egy végső else, ami arra vonatkozik, ami egyik korábbi feltételre sem igaz, persze nem kötelező, de nem árt)
Szerintem legalábbis utóbbi átláthatóbb, jobban egységbe foglalja a feltételvizsgálatot.
Ezek tényleg csak tanácsok, nem kötekedés.
------
(#5324) nuendo: tényleg egész szépen elrendezi a kódot ez a PHP Formatter.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Bírom, hogy mindig az ilyen rendkívül fontos dolgokba kötsz bele... (de ha a belekötésre reagálok is, az már nem érdekel) Miért nem érdemben szólsz hozzá?
Most speciel arra gondoltam, hogy ha mondjuk egy foreach-csel végigmászkál, és bizonyos dolgokat ellenőriz a $_POST tömbön (csak példa, ne keress ebben is hibát, ha kérhetem), akkor végül is tök felesleges másik változónak átadni, de a lényeg az volt, hogy az ilyen bemeneti értékeket lehetőleg ne módosítsa...erről is sikerült elterelned a figyelmet. Csak nem nagyon értem, mi a célod a kötekedéssel.Sk8erPeter
-
Sk8erPeter
nagyúr
Hali!
Kicsit OFF, de biztos tudtok segíteni.
Adatbázisból kérek le olyan adatot, amit egy HTML-elemnél az adott elem (div, p, stb., ez mellékes) azonosítójába szeretnék tenni. Ez oké, de lehet olyan adat, amiben szóköz szerepel, ami miatt az id-ben is szóköz van, ami XHTML Strict 1.0 szerint nem valid. Akkor sem, ha a szóközöket -re cseréltem, és még átnyomok rajta egy htmlentities()-t az egyéb karakterek miatt.
Tehát pl. <div id="akarmi 2_stb.">...</div> már nem valid az XTHML Strict szerint.
Van valami megoldási javaslatotok?Thx.
----------------------------------Szerk.:
Ja még egy: az XHTML Strict oldal esetén a w3c validitás-ellenőrzője nagyon sokszor pampog az elnevezési konvenciók miatt, tehát pl. az id-ben nem lehet tilde (~), vagy-jel (|) és ehhez hasonlók, van erről valami lista, hogy mik a megengedett karakterek? Így nem egyszerű valid oldalt készíteni, ha ennyi tiltott karakter van, és még a HTML-entitás (hogy mondjam ezt szebben ) kódja szerint sem fogadja el.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #5414 üzenetére
Hali!
Sajnos az nem jó megoldás, mert az eredeti névre van szükségem. De az furcsa, hogy a HTML-kódra lecserélve sem fogadja el a w3c validitás-ellenőrzője.
Na, de jobb, ha elmondom, mire kell:
a Jeditable nevű jQuery-plugint használom egy admin-oldalon, ahol módosításokat lehet elvégezni egy adott névnél és egyéb adatbázisban szereplő elemeknél, de úgy, hogy a felhasználó csak kétszer ráklattyog a névre, és máris módosítható az elem, a módosítást pedig elküldi a feldolgozó PHP-fájlnak. Kényelmes, olyan jellegű, mint pl. Facebook-on a módosítható mezők (pl. a Magamról résznél, stb.), helyben módosítasz, nincs szükség az egész lap újratöltésére, stb.A HTML-elem (div, stb.) azonosító (id) attribútuma segítségével (többek közt ezt alakítja a Jeditable $_POST adattá, úgy, hogy a div-et formmá alakítja a ráklattyogáskor! Meg elküldi az input mezőbe beírt adatot) elküldöm az adott elem azonosítóját, ami alapján lecsekkolom az adatbázisban, tényleg van-e ilyen elem, valamint egy alsóvonással elküldöm az eredeti nevet is (ez viszont egyelőre hibaforrás lehet, ha a felhasználó alsóvonás-jelet ad meg a névben, mert explode()-dal bontom szét az elemeket, de ezt majd megoldom), hogy amennyiben megegyezik a módosított névvel, akkor egyszerűen visszaküldöm az eredeti nevet, és nem dolgozgatok fel, így gyorsabb.
Természetesen minden oldal elején ellenőrzöm, a felhasználó belépett-e (a módosító oldalon és a feldolgozó fájlban is), tehát valamelyest biztonságosnak mondható, még ha egyelőre vannak is lyukak benne...Ezért szeretném elküldeni az eredeti azonosítót és magát a mezőnevet is.
Többnyire nincsenek brutálhosszú dolgok, ami ne férne bele egy id-be, ezért gondoltam ehhez a módszerhez folyamodni...
Kerülő megoldás lehetne az, hogy csak az id-et küldöm el, de akkor minden alkalommal tényleg szükség van adatbázis-lekérésre, eddig ezt kerültem el azzal, hogy csekkoltam, megegyezik-e az eredetileg a mezőben szereplő értékkel, vagy sem, ha igen, akkor nem dolgozgattam fel, egyszerűen visszaadtam a júzernek ugyanazt a nevet (amit nem is módosított).Nem tudom, érthetően írtam-e le...
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #5416 üzenetére
Hülyeségnek tűnhet, hogy admin-oldalt szeretnék validálni, de mégis. Operából Direct Inputtal el lehet küldeni validálásra az oldalt (vagy más böngészőben beépülővel), szóval ez nem kérdés, tudom ellenőrizni a validitást.
A szóköz azért fordulhat elő az id-ben, mert lehet olyan név, amit lekérek adatbázisból, amiben előfordul szóköz (nem tudhatom, hogy a júzer milyen nevet tölt fel, de simán lehet, hogy olyat, amiben van szóköz).
Mondom, az eredeti nevet csak azért pakolom bele az id-be, hogy gyorsabb legyen ellenőrizni, nem úgy küldte-e el a júzer a "módosított" adatot, hogy valójában nem módosított semmit - ha nem módosított, megegyezik az eredetileg látott értékkel, minek nyúlkáljak adatbázishoz, úgysincs változtatás.Ja igen, ami fontos a megértéshez: a Jeditable úgy működik, hogy mondjuk megadsz egy CSS-osztályt (pl. "edit") egy HTML-elemnek (pl. egy div-nek), és onnan fogja tudni, hogy kétszeri ráklattyogásnál (lehet akár egyszeri is egyébként, több lehetőség van) módosítható legyen a mező, átalakítja form-má, azonbelül létrehoz egy input mezőt, majd egy Enter leütésével ezt a form-ot tudod elküldeni a feldolgozó fájlnak, majd az abból visszakapott adatot kiíratni - ha sikerült a módosítás, nyilván már a módosított adatot írod ki.
Maga a HTML-elem azonosítója (id) a $_POST['id'] változóval érhető el, a módosított érték pedig a $_POST['value'] segítségével (ez az input mezőből jön).Példa:
<div class="edit" id="nev_68_eredetinév">eredetinév</div>A példában szereplő "eredetinev" adatbázisból jön (ebben lehet szóköz is! Pl. "eredeti név"); a "nev" jelzi, hogy most mondjuk az adatbázisba feltöltött cuccnak a nevét szeretném módosítani, a "68" pedig az adott elem azonosítója.
Eszerint pedig szétrobbanthatom a $_POST['id'] változót mondjuk alsóvonás szerint (erre mondtam, hogy esetleg hibaforrás lehet, ha a júzer alsóvonás-karaktert ad meg, ez most átmeneti próbálkozás egyelőre), az új név pedig a $_POST['value'] változóban van:list($object_to_mod, $dog_id, $original)=explode("_", $_POST['id']);
$new=$_POST['value'];Ha a $new megegyezik az $original változóval, akkor visszatérek az eredeti névvel, és kész, nem vizsgálgatok tovább, így gyorsabb.
Remélem nem voltam túl zavaros.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #5418 üzenetére
Basszus, jobb lett volna, ha előbb jobban körbenézek.
Most találtam meg a Jeditable oldalán, hogy el lehet küldeni extra paramétereket is a köv. módon:
$(".editable").editable("http://www.example.com/save.php";, {
submitdata : {foo: "bar"};
});Így pedig a $_POST tömbbe új elemeket pakolhatok, vagyis a gond megoldva: ilyen módon elküldöm az eredeti nevet, id-t, és akármit, amit csak szeretnék...
Ráadásul biztonságosabb megoldás.
Szóval a gond megoldódott.Az admin oldalt nem véletlenül validálom: az eddigi részek mind validak, így ez már egyrészt szinte presztízskérdés , na de ami sokkal fontosabb, hogy a validálással rengeteg hibát is fel lehet fedezni, pl. sokszor előfordult, hogy a PHP által generált kódba sikerült belekutyulni olyan módon a HTML-kódot, hogy maga az oldal elcsúszott - a validálással viszont többnyire igen gyorsan rájöttem, hogy hol is lehet a hiba; ezenfelül nem véletlenül találták ki a valid kódot, mert így csökkentem annak az esélyét, hogy különböző böngészőkben különböző módon jelenjenek meg a dolgok, persze nyilván már amennyire szabványkövetők (ha nem is szabvány, csak ajánlás) a böngészők... (lásd IE, stb.)
De mondok még egy érvet: kis gyakorlattal és odafigyeléssel nagyon egyszerű valid kódot írni... Hidd el, nem haszontalan.------------
A Te kérdésedre:
nálad az "ajaxload' osztállyal ellátott HTML-elemeknek van href-attribútumuk?
mutass rá példát, pl. így van, ahogy itt?
<a href="akarmi.html" class="ajaxload">...</a>A load() függvénynél felesleges a második paraméter, ha azt nem használod semmire.
Mutass konkrét példát, és akkor sztem tudok segíteni.Sk8erPeter
-
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...
[ Szerkesztve ]
Sk8erPeter
-
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.Sk8erPeter
-
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();
});[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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?
Sk8erPeter
-
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.Sk8erPeter
-
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]Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #5463 üzenetére
A Newhosting-os szervernél ugyanez tapasztalható! Azt Te is ki tudod próbálni.
Sk8erPeter
-
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.Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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".
-----
(#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.Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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.[ Szerkesztve ]
Sk8erPeter
-
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?Sk8erPeter
-
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.
[ Szerkesztve ]
Sk8erPeter
-
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...Sk8erPeter
-
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.
Sk8erPeter
-
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.
Sk8erPeter
-
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...[ Szerkesztve ]
Sk8erPeter
-
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.
Sk8erPeter
-
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.
Sk8erPeter
-
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.Sk8erPeter
Új hozzászólás Aktív témák
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- Parci: Milyen mosógépet vegyek?
- Senua’s Saga: Hellblade II teszt
- Vezetékes FÜLhallgatók
- Kés topik
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Galax GeForce RTX kártyák jönnek a szűkösebb házakba
- Kínai, és egyéb olcsó órák topikja
- Xiaomi Mi 9 SE - csúcsimitátor
- További aktív témák...
- Üzletből, garanciával, Macbook Air Retina 13" 2020, 8GBRAM 256GB SSD magyar bill
- Lenovo ThinkStation P330 Workstation: 3D tervezésre (CAD), videó vágásra, animációk készítésére(DCC)
- ASUS ROG STRIX RTX 3070 8GB
- Eladó ASUS ROG STRIX SCAR II GL704G kishibás gamer notebook
- ÚJ! // ÁR ALATT! // Edifier S3000 MK II // Muziker garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest