- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy A55 - új év, régi stratégia
- Vodafone mobilszolgáltatások
- Samsung Galaxy S23 Ultra - non plus ultra
- iPhone topik
- Okosóra és okoskiegészítő topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen okostelefont vegyek?
- Az Apple is mesterséges intelligenciával turbózza fel a teljes kínálatot
- Honor Magic V2 - origami
Hirdetés
-
Musk betiltja az iPhone-okat a Teslánál és az X-nél, ha ezt meglépi az Apple
it Elon Musk azt mondja, hogy betiltja a Teslánál és az X-nél is az iPhone-okat, ha az Apple operációs rendszer szintjén integrálja az OpenAI-t – szerinte ez elfogadhatatlan biztonsági kockázat.
-
Ilyen lesz a Metal Slug Tactics
gp A friss gameplay anyag mellé sajnos továbbra sem kaptuk meg, hogy a játék mikor érkezik az ősz folyamán.
-
Ilyen lesz a CMF Phone 1
ma Intenzív narancs színben és extra lehetőségeket kínáló hátlappal várható a Nothing almárkájának első modellje.
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #3962 üzenetére
Tényleg? Ez eléggé meglepett. Köszi, hogy szóltál.
Azt hittem, épp az a gyorsabb, ha minden megjelenítendő elemet összegyűjtök egy változóba, és aztán csak echo-val kiíratom a HTML-elemek végleges kiíratásakor, így nincs szükség a megjelenítés közbeni esetleges feltételvizsgálatokra, stb.
Ezek alapján viszont alaposan át kell gondolnom, hogy jó-e, hogy egy csomó helyen éppen úgy változtattam meg a kódot, hogy ahelyett, hogy a HTML-elemek között lenne több helyen echo-zás, és esetleg feltételvizsgálat, inkább összegyűjtöttem egyetlen $main_content változóba az egész tartalmat...
Áttekinthetőség szempontjából jó, de ezek szerint éppen, hogy lassabb... Akkor csinálhatom vissza csomó helyen.Sk8erPeter
-
Sk8erPeter
nagyúr
Ismét köszönöm az alapos választ.
A DBDesigner-t majd kipróbálom.
Jaaaa, akkor már sejtem a parent_id szerepét. Vagyis ez akkor arra való, hogy adott menüpontnak tetszőleges számú almenüpontja legyen?Na, ez az MVC-szerkezet egyelőre kicsit magas, de remélhetőleg előbb-utóbb csak utána tudok már olvasni, ha lesz rá időm... Amúgy most olvasgatom a PHP fejlesztés felsőfokon c. könyvet, eddig nagyon alapos és hasznos olvasmánynak találom.
"(Tehát a struktúrád működjön tetszőleges számú nyelv esetén)"
Így lesz, mindenképp ki fogom javítani.A menu_content táblában úgy látom, hogy a táblázat mezői közé tartozik a language_id és a menu_id is. De ettől függetlenül valószínűleg mindenképp joinolni kell a language és menu táblát is, hogy ezek azonosíthatók legyenek.
Akkor már nem lenne esetleg jobb/szebb megoldás egy külön összekapcsoló táblát létrehozni erre a célra? Ezt most nem kötekedésként kérdezem, hanem mert érdekelne."Nagyjából ugyanolyan gyors lesz."
Tényleg? Mert ez esetben viszont egyértelmű, hogy az adatbázisban való tárolásnál maradnék, az legalább könnyen és rugalmasan kezelhető, módosítható, különböző szempontok szerint egészíthető ki, nem macerás a jogosultságok beállítása sem, míg mindez a fájlkezelésről azért nem mondható el! Tehát ha azt mondod, hogy nem lesz gyorsabb attól, hogy fájlból olvasom ki, akkor mindenképp maradok az adatbázisnál.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz raczger #3976 üzenetére
Uhh, az egyenként való kikeresés helyett nem lett volna egyszerűbb itt megnézni szépen áttekinthetően?
Sk8erPeter
-
Sk8erPeter
nagyúr
"Az iskolában nem tanították, hogy hogyan kell gráfokat és azon belül fákat reprezentálni?"
Most mit kötekszel? Nem arról volt szó, hogy fingom sincs, mi az a gráf vagy fa, hanem arról, hogy jelen esetben Te hogy oldottad meg a gyakorlatban. Nyilván az egyetemen vagy máshol tanított elméletet csak akkor tudod összekapcsolni a gyakorlattal, ha erre szolgáló feladatot minimum egyszer megoldottál. Az meg még akkor sem biztos, hogy elsőre eszedbe jut, amikor az triviális. Jó, most mondhatod, hogy de neked igenis elsőre eszedbe jutott, de talán ne hasonlítsuk össze a Te webfejlesztésben és programozásban szerzett tapasztalatodat az enyémmel, ahhoz képest én valszeg csúfosan le vagyok maradva...
Szóval érted, ha már akár egyszer láttam olyan megoldást, ahol végre azt érezhetem, hogy az egyetemen vagy akárhol oktatott elméleti dolgok közül tudom hasznosítani a tudást, akkor a homlokomra csapva mondhatom azt, hogy "nahát, akkor ezt az elméleti hátteret erre a feladatra is le lehet képezni!" És onnantól könnyebben megy."Pedig eddig is erről volt szó."
Valóban..."A menü és a menü tartalom táblák között 1:n típusú reláció van. Ha n:m reláció lenne, akkor lenne szükség kapcsolótáblára. Ezt sem tanították az iskolában?"
Ismét kötekedés...de inkább elengedem a fülem/szemem mellett...
A kérdés oka az volt, hogy először úgy képzeltem, hogy a language táblát is azért kell joinolni, mert mondjuk úgy kérdezel le, hogy "... WHERE language.name='en';", és akkor tényleg kellett volna joinolni, mivel akkor különben honnan szeded a nevet? De persze rájöttem, hogy csak simán azonosítószám alapján kérdezel, én meg úgy gondoltam, hogy név (hu, en, de, es, stb.) alapján kissé könnyebb beazonosítani adott nyelvet..."A file-os megoldás azért jó, mert tudsz olyan oldalt készíteni, amelynél a megrendelő saját maga szerkeszthetik a menüt és a menüpontok tartalmát, mégsincs hozzá szükség adatbázisra."
Igen, viszont így megnő az esélye annak, hogy elcseszi a fájlt, és ha nem ért a HTML-hez, akkor néz, hogy miért nem működik. Mondjuk ha úgy van megoldva a dolog, hogy ne legyen benne HTML, hanem mondjuk csak soronként elválasztva a menüpontok, behúzással az almenüpontok, a menüpontokhoz tartozó tartalom meg különálló fájlokban, csupán a fő szövege, vagy valami más megoldással kerülik el a gányolás lehetőségét, akkor ilyen para nincs, de akkor meg már iszonyat macerásnak látszik az egész.
Akkor meg már mondjuk az a kérdés is felmerül, hogy miért is ne használjunk adatbázist a saját életünk megkönnyítésére, és alakítunk ki egy jó admin felületet a megrendelőnek, ahol sokkal szebb felületen tudja szerkesztgetni a menüpontokat és a belső tartalmat. Persze azt is alá lehet támasztani, hogy miért ne, ha akarjuk, de minek.Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
"A nyelvek kezelését egy nyelvkezelő osztállyal oldom meg, amely a konstruktorában betölti a rendszerben található összes nyelvet."
És ez hogyan történik? Nem úgyszintén adatbázisból való lekérdezés segítségével? Mivel most nem arról az esetről beszélünk, hogy fájlban tárolod ezeket az elemeket, ezért máshogy nem tudom elképzelni ennek a megvalósítását, mint ugyanúgy adatbázisból való lekéréssel - de szólj, ha valami más módszer van rá... -, ebben az esetben meg nem nagyon értem, miért lenne "rosszabb" egy joinolás.
Mondjuk C-ben esetleg valami struktúrában tárolnám el pointerekkel és egyéb mókák segítségével az egyszer már megkapott adatokat, rendezve, és ahhoz nyúlkálnék, de itt egyelőre nem tudom elképzelni a megfelelő megoldást, ha az nem lekérdezés.
Ismét csak azért kérdezem, mert ennek a gyakorlati megvalósítására még elég kevés példát láttam osztályokkal (mondom, az OOP-t még csak most fogom tanulni), nem azért, mert "nem tanították az iskolában"...Amiket még írtál, nagyon jó és megfontolandó. Már ebből is látszik, mire jó az OOP-szemlélet.
Köszi.
Sk8erPeter
-
Sk8erPeter
nagyúr
Köszi a példát, még mindenképp tanulmányozni fogom, ha kicsit kiismertem az OOP-t. Egyébként egész érthetőnek tűnik.
De azért még megkérdezem:
$lang_object->add_language(1,'en');
$lang_object->add_language(2,'hu');
Ez most ilyen default értéket ad, mert a hu és en nyelvekhez nyúlkálsz a legtöbbször, és ha mégis másik nyelvre van szükséged, akkor lekérdezed adatbázisból, de egyébként nincs rá szükség?Sk8erPeter
-
Sk8erPeter
nagyúr
Mondjuk ha valaki ilyen gyökérségeket csinál, hogy kétbetűs változóneveket ad meg, és még csak nem is kommentezi, vagyis később már ő maga sem fogja érteni a saját kódját, akkor ilyen merényleteket akár más nyelveken is elkövethet.
Amúgy tényleg meglepő, mennyire egyszerűen össze lehet hozni PHP-vel "működő" kódokat, és most, hogy kicsit már talán jobban megy a PHP-zás, mint az elején, rossz visszanézni, miket műveltem eleinte, amikor elkezdtem tanulni a nyelvet, és még mindig nem tudok az egészről semmit.
Mondjuk sokan vannak, akik már egy for ciklustól profinak érzik magukat. Ezzel szemben viszont: "An expert is someone who knows more and more about less and less, until eventually he knows everything about nothing."Sk8erPeter
-
Sk8erPeter
nagyúr
Áháá, már kezdem kapiskálni.
"Nyilván ekkor kézzel kell hozzáadni a lehetséges nyelveket"
Ez volt a kulcsmondat... Eddig nem igazán értettem, hogy ha nem adatbázisból szeded, akkor mégis honnan, ha csak egy osztályod van... Rögtön gondoltam, hogy valami ilyesmi megoldás, de az elmondásodból először úgy tűnt, hogy mégsem.
Így viszont pont a rugalmasságát veszti el a dolog, ha kézzel kell hozzáadni, nem?
És a gyakorlatban ezt a kézzel való hozzáadást hogy kell elképzelni?Sk8erPeter
-
Sk8erPeter
nagyúr
Értem én, csak szerintem hülyén tettem fel a kérdéseket. Úgy tanul a gyerek, ha kérdez. Egyébként minden témával kapcsolatos hozzászólásoddal inspirációt adtál a saját megoldásomhoz, ezért is kérdezősködtem. Köszönöm a példát és a válaszaidat, azt hiszem, menni fog.
Persze lehet, hogy még felteszek majd pár kérdést, ha időközben felmerül.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DerStauner #4037 üzenetére
Használd a WAMP-ot, ezt a lehető legegyszerűbb telepíteni, next-next-finish módszerrel rakhatod fel, és a konfigurálása is könnyű (magához a működéshez viszont nem is szükséges átállítgatni semmit). Aztán a cuccaidat bepakolod a www könyvtárba, és kész vagy, a böngészőben a http://localhost/ cím beírásával már el is éred az oldaladat.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
"(Már végigzongoráztam párszor az apache-php-mysql telepítést külön-külön, mindent beállítva, nekem ennyi elég is volt belőle, ezért kerestem olyan csomagot, ami megcsinálja helyettem)"
Én is ugyanezen okból kezdtem el használni a WAMP-ot... Franc fog szarakodni minden újratelepítésnél.A "WAMP saját szemete" nem hinném, hogy túl sok kárt okozna a gépben, nem fosta tele a registry-t sem, azért szerintem ezt nem kell ennyire túlparázni, ráadásul azért is előnyös a WAMP egy kezdő számára (is), mert nem szöveges fájlokban kell kutakodni a megfelelő beállítások után, hanem van egy kellemes grafikus felület a Tálcán, ahol eléred az Apache, a MySQL és a PHP beállításait is.
Az Appserv-et még nem próbáltam, de az alapján, amit elmondtál, meg az alapján, amit a honlapján látok, ehhez nincs ilyen könnyen elérhető és kezelhető grafikus felület.
Nem értem, a WAMP miért lenne rosszabb az Appserv-nél, a WAMP is ugyanúgy az éles környezetet pakolja fel, csak biztosít hozzá még egy plusz felületet, amin a beállítások elérhetők.Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz DerStauner #4048 üzenetére
Notepad++-t rakd fel, aztán egy új doksiba pötyögd be, hogy
<?php
echo 'Hello World!';
?>
majd mentsd el mondjuk hello.php néven, a telepített WAMP-alapkönyvtár www könyvtárába elhelyezve. (Pl. ha a WAMP-ot a C:\wamp könyvtárba telepítetted, akkor C:\wamp\www könyvtárba pakold.)
Aztán böngésző megnyit, és írd be a címsorba:
http://localhost/hello.php
És látnod kell a szöveget, ha minden jól lett beállítva.Szerk.: csak a félreértések elkerülése érdekében: ez nyilván nem nevezhető még "weblapnak" (csak egy sort írunk ki), a sima HTML-részeket már neked kell hozzáillesztened...
Pl. ha már weblapszerű struktúrát szeretnél, akkor így is megírhatod a hello.php tartalmát (legegyszerűbb példával élve):<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Dokumentumod címe</title>
</head>
<body>
<div style="font-weight:bold;color:red;"><?php echo 'Hello World!'; ?></div>
</body>
</html>[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Sziasztok!
Egy kis ötletet szeretnék kérni.
Van egy honlap, amin amin egy fotósnak a képei jelennek meg. A képek különböző kategóriákba tartoznak, egy kép akár több kategóriába is tartozhat. Az admin felületen ez mind szépen, grafikus felületen működik (lehet kategóriákat létrehozni, új képet feltölteni, azt akár több kategóriához rendelni, címet megadni hozzá, kategóriát vagy képet törölni, módosítani).
Az adatbázis úgy néz ki, hogy van egy tábla, ahova a kép elérési útja és egyéb adatai (szélesség, magasság, stb.) kerülnek, van egy tábla a kategórianeveknek, és van egy összerendelő tábla, ahova a kép azonosítószáma és a kategória azonosítószáma kerülnek, jelezve, hogy mik tartoznak össze.Egy ponton viszont most elakadtam, lehet, hogy a fáradtság az oka, de most nem jut eszembe, mi lenne a legjobb megoldás:
az admin felületen a kép tulajdonságainak módosításánál az eddig bejelölt kategóriákat checkboxok formájában jelenítem meg, amelyik kategóriához a kép már hozzá van rendelve, oda kerül egy pipa, amelyik kategóriához NEM tartozik a kép, ott nincs pipa.
Azt szeretném megoldani, hogy a felhasználó viszont újabb pipák behelyezésével (más kategóriákhoz), vagy korábbi pipák kivételével tudja módosítani, melyik kategóriákba tartozzon egy adott kép.
Ezt hogy kellene megoldani az űrlap ellenőrzésekor, hogy azokat a rekordokat töröljem az összerendelő táblából, amelyeknél a checkboxoknál korábban volt pipa, de a felhasználó kiszedte (jelezve ezzel, hogy nem szeretné, ha abba a kategóriába is tartozna), viszont azok a rekordok kerüljenek be az összerendelő táblába, ahol korábban nem volt pipa?
A problémám az, hogy milyen módszerrel hasonlítsam össze, hogy hol volt és hol nem volt korábban pipa, mi az, amit törölni kell, mi az, ami új elem.Lehetne
-hidden elemekkel betenni valami inputba azoknak a kategóriáknak az azonosítószámát, amikbe a kép már tartozik, így POST-tal elküldöm, de az gány megoldásnak tűnik
-valami session változóban (tömbben) ugyanezt eltárolni, de ott meg az új checkbox-os POST tömbbel (egy tömbben tárolódnak a kipipált checkboxok) kell mindig összehasonlítgatni, és azt sem tudom, hogy lehetne a legkisebb lépésszámmal megoldani
-meg még azt is lehetne, hogy a kép összes addigi kategória-hozzárendelését törlöm az összerendelő táblából, és az újonnan bepipált értékeknek megfelelően adogatom hozzá az új összerendelést, de az meg már megint nagyon gáz: tegyük fel, hogy mondjuk csak egyetlen helyről kiszedem a pipát, akkor az összes hozzárendelést törli, és adhatja hozzá újra az összeset, ez felesleges munka; ráadásul mi van, ha megszakad valamiért a folyamat, akkor elvesztek az addigi hozzárendelésekTehát egyelőre tanácstalan vagyok, az összehasonlítgatásokra mi lenne a jó módszer.
Nagyon megköszönném, ha bármi jó ötlettel tudnátok segíteni!
Sk8erPeter
-
Sk8erPeter
nagyúr
Tényleg, köszi. Nem tudom, miért nem jutott eszembe, hogy azt is meg lehetne oldani, hogy még egyszer lekérdezem a feldolgozó fájlban az adatbázist, és összepakolom a lekérdező parancsot sima for ciklussal aszerint, hogy ha mondjuk nem adott azonosítószámú annak a bizonyos post tömbnek az aktuális értéke, akkor insert...
De mondjuk abban is igazad van, hogy talán adatbázisban átláthatóbb lenne, ha minden egy helyen lenne, bár nem mintha túl sűrűn nézegetné bárki is az adatbázist, de esetleg a kódban is jobban lehetne követni az eseményeket, kevesebb parancs lenne, ha adott azonosítójú elemet törölnék az összerendelő táblából, aztán a kiválasztott kategóriáknak megfelelően ismét feltölteném.
Na de ez nem lenne sokkal erőforrás-igényesebb művelet? Valóban nem lenne túl sokszor kategória-átrendezgetés, de azért gondolkodom hosszú távon is.
Mondjuk most jobban belegondolva ha azt csinálnám, hogy a feldolgozó fájlban ismét lekérném adatbázisból a kategória-összerendeléseket, és összehasonlítanám a post tömbbel, amiben a bejelölt kategóriák azonosítói vannak, akkor a for ciklusban is lennének if(in_array(...)) és ehhez hasonló ellenőrzések, ráadásul akkor külön kellene figyelni, hogy viszont mi az, ami NINCS benne a korábbi hozzárendelésekhez képest az új kategória-kiválasztásokban, amit meg törölni kell, és akkor lehet, hogy ott vagyok, ahol a part szakad. Vagyis így a hozzászólás végére eljutottam arra a következtetésre, hogy lehet, hogy semmivel nem lenne erőforrás-igényesebb az, ha mindent törölnék, és mindent újra hozzáadnék - itt már az a kérdés, hogy vajon melyik működik gyorsabban, a MySQL törlő és hozzáadó műveletei, vagy a PHP összehasonlítgatásai, majd egy MySQL-törlés illetve -hozzáadás...
Hmm, na ezekkel a különbségekkel mondjuk nem vagyok tisztában, ezt azért nem lenne egyszerű tényleges összehasonlításnak alávetni. De inkább az első megoldás tűnik hasznavehetőbbnek.Azt hiszem, igazad van abban, hogy ezerszer átláthatóbb és követhetőbb lenne, ha inkább mindent törölnék, majd mindent hozzáadnék a kiválasztottaknak megfelelően.
Ha esetleg valami kommentár eszedbe jutott még a leírtakkal kapcsolatban, akkor örömmel várom. Köszi.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Még egy kérdés: amikor get methoddal küldök el egy formot, akkor hogyan tudom elérni, hogy az url-be NE pakolja bele a submit gombnak az értékét is?
(Elég hülyén néz ki, amikor a submit gomb neve mondjuk mod_submit, és akkor lesz az url-ben egy mod_submit=Elküldés vagy valami ehhez hasonló...)Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #4083 üzenetére
Na ja, de előfordul, hogy az alapérték (pl. pont az Elküldés, ezért rossz példa volt, amit írtam) nem megfelelő, hanem a value-ba valami egyedi szöveg kellene (pl. Kiskutyafüle), hogy kerüljön. Mintha egyszer láttam volna már megoldást ilyenre, de nem tudom, hol, és lehet, hogy az valahogyan manipulálva volt, mert nem tudok róla, hogy alapból meg lehetne oldani. De szóljatok, ha mégis (azonkívül, hogy nem adok nevet).
Sk8erPeter
-
Sk8erPeter
nagyúr
Köszönöm a válaszokat, akkor tényleg maradok a lehető legegyszerűbb megoldásnál. Ami talán mellesleg ugyanolyan gyors is, vagy gyorsabb, mint ha minden egyes feltételt vizsgálgatnék, annak megfelelően törölnék, stb. Azért jó ebbe a topicba írni, mert végül a segítségetekkel valahogy mindig eljutok a közel legegyszerűbb megoldáshoz.
"Általában egy nagy terhelésű rendszeren az adatbázis i/o a szűk keresztmetszet, nem pedig a processzor sebessége."
Mondjuk gondolom ilyen esetben érdemes lenne megfontolni, hogy inkább PHP-vel vizsgálgatom a különböző tömböket kicsit komplikáltabb módon, mint hogy több adatot töröljek, majd vigyek be újra az adatbázisba.Még egy eszembe jutott, amire kíváncsi lennék:
-csak érdekességképpen: van olyan módszer, amivel figyelni lehet a felhasznált erőforrások váltakozását? Csak azért, mert érdekelne, az egyes módszerek, függvények felhasználástól függően vajon nagyjából mennyi erőforrást (memóriahasználat, prociigény) igényelnek. Legalább itthoni gépen próbálgatnám, ha a szolgáltató szerverén nem is lehet - van olyan külső progi, amit rá lehet állítani a PHP-s folyamatokra? Vagy akár beépített függvény? A microtime()-mal ugye elvileg jól lehet figyelgetni a lekérdezések idejét, ezzel csak az a probléma, hogy nyilván a saját procim is mindig más folyamatokkal foglalkozik, mást helyez előtérbe (prioritás, megszakítások), ezért akárhányszor frissítek a böngészőben, a microtime() függvény mindig más eredményt ad... így sokszor még ez sem olyan jó összehasonlítási alap.
Pl. azt akartam tesztelni legutóbb, hogy a többszörös mysql_query($query) utasításnál mennyivel gyorsabb a MySQLi osztály használata, és a $mysqli->multi_query($query) utasítás egy do{...}while($mysqli->next_result()); paranccsal.
De akárhányszor frissítettem, mindig más eredmény jött ki, egyszer az egyik javára, máskor a másik javára - de összességében a MySQLi osztály használata a multi_query()-vel jött ki győztesen, legalábbis ott szerepeltek a rövidebb értékek a legtöbbször.(#4086) cucka: igazad van, a JavaScriptes megoldás a legegyszerűbb, amennyiben szükség van a gomb value mezőjére (már amennyiben egy felhasználónál nincs kikapcsolva a JavaScript, de ez az esetek döntő többségében nem áll fenn).
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sickboy25 #4087 üzenetére
Az első hsz.-ben látható könyvek közül én kivettem könyvtárból a Bevezetés a PHP5 programozásába c. könyvet, és nekem eddig pozitívak a tapasztalataim, ezerszer értelmesebb könyvnek látszik, mint pl. a "Tanuljuk meg a PHP5 használatát 24 óra alatt" c. könyv... Előbbi igen vaskos, több mint 1000 oldalas könyv. Én ezt ajánlanám kezdetnek, meg persze a php.net-et.
Aztán amikor elkezd jobban menni, és a dolgok hátterére is kíváncsi vagy, akkor érdemes lehet olvasgatni a PHP fejlesztés felsőfokon c. könyvet, nagyon érdekes dolgok vannak benne, és jó az író (a fordító?) stílusa is.Sk8erPeter
-
Sk8erPeter
nagyúr
Na várj, a glob függvény fejléce így néz ki:
array glob ( string $pattern [, int $flags = 0 ] )
Akkor a $pattern-be megadott sztringbe kerül bele egy szögletes zárójel? Hogy adod meg?
Ha perjellel escape-eled?
/[ kjkj /]
Persze jó lenne többet tudni a problémáról.Sk8erPeter
-
Sk8erPeter
nagyúr
Na basszus, most látom, hogy pont a backslash-t akartam írni, erre csak elcsesztem... Úgy látszik, már késő volt.
Na várj, ezt írd már körül kicsit, mert nem értem. Tulajdonképpen mit szeretnél elérni? Hogy a szögletes zárójeleket tartalmazó elérési útvonalakat találja meg? Ezek szerint a backslash nem volt jó ( \[ kjkj \] )
A [ és ] HTML-kódjával is próbálkoztál?
[ : [
] : ][ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
"Microtime-al tudsz időt mérni, memory_get_usage-el tudsz memóriahasználatot mérni. Esetleg felrakhatod a zend szervert, ott kapsz pl. profile-ozási lehetőséget."
Köszönöm az ötleteket, erre voltam kíváncsi."Tehát ha lassú egy rendszer, akkor nem attól lassú, mert mysql helyett mysqli-t használsz, vagy fordítva."
Ebben igazad van, de most épp azért kellett a mysql_query-s lekérés helyett a mysqli osztály függvényeit használnom, mert még korábban elég csúnya módszerrel úgy oldottam meg a többszörös lekérdezést (pl. több elem törlésekor más táblákból, vagy több sima SELECT-es lekérdezés egymás után, majd az eredmények tárolása, kiíratása - persze itt is elválasztva az alkalmazáslogikát a megjelenítéstől, ahogy illik), hogy egymás utáni mysql_query-ket hajtottam végre, az a kódban meg elég csúful mutat, sokkal szebb, ha konkatenálom egy sztringbe a lekérdezéseket, majd egymás után végrehajtom MySQLi-függvényekkel, ahogy írtam. Pl. van olyan eset, amikor a júzer törölni szeretne az admin felületen egy képet az összes kategóriából, és ilyenkor magából a képtáblából is törölni kell, meg a kategória-kép-összerendelő táblából is, és ilyenkor jó rondán néz ki a kódban az egymás után mysql_query.Aztán ha már próbálgattam, kíváncsi voltam arra is, hogy vajon a két lekérdezés (sima mysql_query-vel vagy mysqli-s függvényekkel) között milyen időbeli különbségek vannak. A memóriahasználatbeli különbségekre is kíváncsi vagyok.
Meg egyébként még nem dolgozom komoly cégnél, mint honlapszerkesztő, most egyelőre szeretném magam minél jobban kiképezni, és megtanulni, hogy mik azok a megoldások, amik a lehető legkisebb erőforrást igénylik, és a leggyorsabb megjelenítést eredményezik.
Ezért foglalkozom esetleg apróságoknak tűnő kérdésekkel is.Sk8erPeter
-
Sk8erPeter
nagyúr
"Nem tudom, mitől szebb. Ha arra van szükséged, hogy 2 query-t lefuttass egymás után, akkor azt le kell futtatni egymás után, miért csúnya ez?"
Hát nem tom, szerintem jobban mutat. Pl. adott a következő:
$query = "DELETE FROM `adatb`.`tbl_egyik` WHERE `tbl_egyik`.`id` = 1 LIMIT 1;\n";
$query = @mysql_query($query)
or die ("Nem lehet lekérni az adatot a MySQL-táblából.<br />Hiba: ". mysql_errno() . ": ". mysql_error() ."<br />");
$query = "DELETE FROM `adatb`.`tbl_masik` WHERE `tbl_masik`.`id` = 1 LIMIT 1;";
$query = @mysql_query($query)
or die ("Nem lehet lekérni az adatot a MySQL-táblából.<br />Hiba: ". mysql_errno() . ": ". mysql_error() ."<br />");
$query = ""DELETE FROM `adatb`.`tbl_harmadik` WHERE `tbl_harmadik`.`id` = 1 LIMIT 1;";
$query = @mysql_query($query)
or die ("Nem lehet lekérni az adatot a MySQL-táblából.<br />Hiba: ". mysql_errno() . ": ". mysql_error() ."<br />");Ehelyett lehet így is:
$query = "DELETE FROM `adatb`.`tbl_egyik` WHERE `tbl_egyik`.`id` = 1 LIMIT 1;\n"
. "DELETE FROM `adatb`.`tbl_masik` WHERE `tbl_masik`.`id` = 1 LIMIT 1;\n"
. "DELETE FROM `adatb`.`tbl_harmadik` WHERE `tbl_harmadik`.`id` = 1 LIMIT 1;";
if ($mysqli->multi_query($query)) {
do { /* ... */ }while ($mysqli->next_result());Számomra utóbbi áttekinthetőbb... Szerinted?
"Annak idején az első munkámat úgy kaptam meg, hogy lóf*szt se értettem az egészhez. Konkrétan javascript-et az első, beugró feladatomnál írtam először ."
Én is az első munkámnál tanultam meg a(z) (X)HTML, CSS, JavaScript, PHP, MySQL alapjait, haverom faterjának csináltam egy honlapot baráti alapon (nem fizetős), kutyatenyészetről volt szó, és meg kellett csinálni hozzá a szép, felhasználóbarát (és egyben foolproof) admin felületet is, hogy tudjanak képet hozzáadni, a kutyához törzskönyvet kitölteni, meg minden egyéb adatot, törlés, módosítás, a honlap szerkesztése és minden egyéb finomság belekerült, szoptam vele elég sokat. Szerencsére nem tűztek ki szoros határidőt (főleg mivel tisztában voltak vele, hogy ingyé' csinálom, meg csak most tanulom az egészet), szóval eltökölhettem vele egy pár hónapot, mire nagyjából fullos lett. A dizájnon mondjuk lenne mit csiszolni, de valahogy a dizájn egyáltalán nem érdekel. De majd ráérő időben ráfekszem arra is. Egyedül azért mindent megcsinálni kicsit sokáig tartott...
Most utólag javítgatom a kódot, és röhögök a saját hibáimon. És még mindig érzem, hogy az igazán komoly webfejlesztéstől elég messze vagyok, de folyamatosan tanulok."Senki sem fog fizetni azért, mert megspóroltál 0.3% processzoridőt, vagy hogy 0.2 másodperc helyett 0.13 alatt jön be a weboldal."
Ez igaz, de saját kíváncsiságom kielégítésére jó móka ilyenekkel szórakozni. Persze ha már komoly munkánál szoros határidő lesz, akkor valszeg nem apróságokkal fogok tökölni.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Inv1sus #4134 üzenetére
ha sikeres volt a feltöltés, mondjuk csinálsz egy ilyet:
session_start(); //még a fájl elején!!!
// ...
$_SESSION['success']='Fasza, sikerült feltöltened.'; //lehet felőlem $_SESSION['sikerhurra']='blabla'; is, tehát a név tök mindegy, beállítod asszociatív tömbindexeléssel a tömb egyik elemét egy bizonyos értékre
// blabla, header-rel visszairányításItt pedig abban a fájlban, ahova visszairányítod a feldolgozó oldalt, kiíratod a session változót, ha az létezik (ami nyilván akkor lehet, ha a feldolgozó fájlban beállítottad), aztán megszünteted (hogy ne írja ki minden alkalommal, mindössze egyszer írja ki):
if( isset( $_SESSION['success'] ) ){
echo $_SESSION['success'];
unset( $_SESSION['success'] );
}Ennek analógiájára lehet kiíratni a hibaüzeneteket is, elég rugalmas a dolog, és a session erejéig bárhonnan elérhető, hacsak meg nem szünteted (unsettel).
Sk8erPeter
-
Sk8erPeter
nagyúr
Mondjuk az or die... rész jól jön teszteléshez, legalább jelzi, ha valamit elcsesztem. Persze ez már működő rendszernél nyugodtan elhagyható, de ha mondjuk saját gépen tesztelem, és elfelejtem módosítani az eredeti adatbázisneveket, akkor ez legalább jelzi, hogy valamit még kéne csinálni. Nem nézek, mint Jani a moziban, hogy most akkor mi van.
Mondjuk nagyon összetett lekérdezéseknél épp az eredeti mysql_query()-s megoldás tényleg jobb lehet.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #4137 üzenetére
Köszönöm, szerintem megpróbálom, így elsőre elég könnyen kezelhetőnek és áttekinthetőnek tűnik.
(#4144) Inv1sus: nincs mit, tényleg egyszerű. A sessionnel való babrálás sokszor hasznos. Pl. látogatók számlálására is, ahogy cucka írta korábban: [link].
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
De ha valaki mégis szeretne órát a honlapjára, akkor az az ő dolga...
PHP-vel ezt megoldani azért hatalmas baromság lenne. (még ha csak a perceket íratná ki, akkor is kellene egy visszaszámláló, ami mondjuk 60 mp-enként frissíti magát, vagy valami hasonló, meg AJAX, meg anyámkínja, ki lehet hozzá találni okosságokat, de minek )Sk8erPeter
-
Sk8erPeter
nagyúr
válasz egyjotakaro2 #4165 üzenetére
Talán ha tudnánk, hogy egyáltalán milyen programot használsz (itt azt írtad, találtál másikat, de hogy melyiket, az rejtély számunkra), akkor lehet, hogy könnyebb lenne segíteni. Mondjuk csak úgy szórakozásból felrakni az általad használt chatprogramot szerintem senki nem fogja, legfeljebb tudunk segíteni tutorial keresésében... Bár lehet, hogy a program dokumentációjában leírják, hol lehet naplózni a beszélgetéseket, csak keresni kell.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz vancha2 #4172 üzenetére
Ha jól látom, az $uj változót csak arra használod, hogy amikor elmented adatbázisba a látogató adatait, akkor az adatbázisban az "egyedi" mezőben 1 vagy 0 lesz, attól függően, hogy a $_COOKIE["latogato"] be van-e állítva. Ennek szerintem semmi értelme. Akkor már miért nem teszed az egészet a cookie létének ellenőrzése alá? Ha még nincs beállítva a cookie változó, akkor tárolja el az adatbázisba: if(!isset($_COOKIE["latogato"]))...
Meg a feltételvizsgálatot is lehetne egyszerűsíteni. Az $uj szerintem felesleges. A setcookie("wait", time(), time()+60); pluszban történő beállításával mit szerettél volna?
Valahogy így képzeltem el egyszerűsítve (az $uj változó felesleges, az eregi-vel ellenőrzést korábbra is be lehet rakni, a második setcookie most így elsőre nem világos, miért szükséges):if(!isset($_COOKIE["latogato"]) && !eregi('(nuhk)|(Googlebot)|(Yammybot)|(Openbot)|(Slurp/cat)|(msnbot)|(ia_archiver)', $useragent) )
{
$uj = 0; //??? felesleges...
$ip = $_SERVER["REMOTE_ADDR"];
$host = gethostbyaddr($ip);
$referer = $_SERVER["HTTP_REFERER"];
$useragent = $_SERVER["HTTP_USER_AGENT"];
$nap = date('d', time())+1;
$ho = date('m', time());
$ev = date('Y', time());
$meddig = strtotime($ev.'-'.$ho.'-'.$nap)-(60*60);
setcookie("latogato", time(), $meddig);
mysql_query("INSERT INTO stat(pozicio, datum, ip, host, referer, useragent, egyedi) VALUES ('$ad_pozicio', '$time', '$ip', '$host', '$referer', '$useragent', '$uj')");
//itt az $uj változót valami célszerűbbre lehetne lecserélni...
setcookie("wait", time(), time()+60); //???
}Ezt az egész látogatószámlálást mondjuk sessionnel is el lehetne intézni, és akkor nem lenne olyan gond, hogy ha valaki tiltja a cookie-kat a böngészőjében, akkor nem tárolja el a látogatását. >> [link] Persze akkor a visszatérő vendégeket is újraszámolja (bár az nem hiszem, hogy probléma lenne, hiszen gondolom arra is kíváncsi vagy, hogy visszajönnek-e; meg egyébként is újraszámolná cookie-k törlése után).
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Inv1sus #4173 üzenetére
És ez most miért lenne hiba? Sehol nem kötötted ki, hogy hány ilyen karaktert szeretnél engedélyezni, csupán escape-elve töltötted fel az adatbázisba. Pont azt csinálja, amit mondasz neki.
Mellesleg helytelen így használni a $_POST-ot: $_POST[ki],
helyesen $_POST['ki'] vagy $_POST["ki"]
Fontos, hogy használd az aposztrófot ( ' ) vagy az idézőjelet ( " ).
Ugyan az általad használt módon is működik, de bizonyos esetekben gond lehet belőle.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz vancha2 #4177 üzenetére
Te egyetlen dologtól teszed függővé azt, hogy el kell-e tárolni, vagy sem:
if(eregi('(nuhk)|(Googlebot)|(Yammybot)|(Openbot)|(Slurp/cat)|(msnbot)|(ia_archiver)', $useragent)) { }
else {
mysql_query("INSERT INTO stat(pozicio, datum, ip, host, referer, useragent, egyedi) VALUES ('$ad_pozicio', '$time', '$ip', '$host', '$referer', '$useragent', '$uj')");
setcookie("wait", time(), time()+60);
}
Gondolom az $uj változót ezek alapján arra használod fel, hogy egy reklámot már megnéztek-e vagy sem, és minden egyes megnézést tárolni szeretnél, hogy tudj készíteni egy összesítést arról, hogy összesen hányszor ugrott az arcába a látogatóknak a reklám.
Az a probléma, hogy van, hogy pontosan ugyanabban az időpontban menti el azonos látogatást duplikálva, úgy, hogy az $uj változó 1 értékű? Mert ezt a duplikálást nem fejtetted ki bővebben.
Igen, az eregi() már deprecated lesz 5.3.0-tól.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz vancha2 #4179 üzenetére
Nem tudom, minek magyaráztad meg a teljesen egyértelmű részt, mivel elég könnyű volt felfogni, hogy az mire jó, nem is azt kérdeztem. Az előző hsz.-ben csak összegeztem, hogy ezek szerint minden egyes oldallátogatást el szeretnél menteni, nem elég az új látogatók lekérdezése, arra is kíváncsi vagy, hogy az egyedi látogató hányszor kattintgatott az oldalon belül, ill. hányszor frissített. Ugyanezt írtam az előző hsz.-emben, csak másképp. Egyébként így már teljesen érthető, miért van szükség az $uj változóra, csak a legelső hsz.-ednél még nem volt világos, hogy minden "látogatást" tárolni szeretnél.
A duplikált bejegyzés elég furcsa, most így hirtelen nincs rá ötletem.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz egyjotakaro2 #4188 üzenetére
Hogy jön ez a PHP topicba?
Egyébként ha van egy ilyen sorod:
<link href="/img/favicon.ico" type="image/x-icon" rel="shortcut icon" />
akkor a href-ben szereplő elérési út stimmel, azt megváltoztattad a megfelelőre? Egyébként meg töröld a böngésző gyorsítótárát.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Robb202 #4193 üzenetére
Egyébként itt is van egy jó leírás:
Apache és PHP telepítése kezdőknek Windows rendszereken (Weblabor)Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Inv1sus #4206 üzenetére
Azért azt se ártana ellenőrizni előtte, hogy létezik-e egyáltalán a $_SESSION['loggedname']:
if( isset($_SESSION['loggedname']) )
esetleg még kiegészítheted azzal is, hogy nem üres-e
if( isset($_SESSION['loggedname']) && !empty($_SESSION['loggedname']) )
Utóbbi mondjuk nem kötelező - de előbbiért, ha a display_errors be van kapcsolva, akkor amennyiben nem létezik az adott változó, dob egy hibanotice-t.
Egyébként így elsőre nem világos, hogy most itt miért hasonlítgatsz össze - az nagyon nem biztonságos, ha session változóban tárolod a jelszavadat. De ha pl. adatbázisból szeded, akkor oké.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PazsitZ #4223 üzenetére
Na basszus, teljesen igazad van.
(Ezt az error_reporting = E_ALL beállítással lehet a legjobban tesztelni (persze csak teszteléshez szabad ezt így engedélyezni, különben nem biztonságos). Meg itt is szerepel, hogy lefedi az isset() esetet: empty(). )
Köszi, hogy szóltál![ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz egyjotakaro2 #4229 üzenetére
Nem az egyenlőségjel okoz problémát, hanem az idézőjel helytelen használata.
2 megoldás van:
1.) escape-eled az idézőjelet:
echo "<b>Nev:</b> <a href=\"viewprofile.php?viewprofile=$username\" target=\"_parent\">$username</a>" ;2.) Sima aposztrófot használsz az idézőjel helyett a sztring egységbe foglalására, csak ilyenkor arra kell figyelni, hogy a $username nem helyettesítődik be, de erre nagyon egyszerű megoldás a hozzáfűzés:
echo '<b>Nev:</b> <a href="viewprofile.php?viewprofile=$username" target="_parent">'.$username.'</a>' ;
Szerintem az utóbbi átláthatóbb. De egyéni ízlés kérdése.
Kezdetben sokáig használtam az első módszert, aztán rájöttem, hogy az utóbbi számomra sokkal kényelmesebb és átláthatóbb megoldás.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz egyjotakaro2 #4233 üzenetére
Jahh, arra az előbb nem is figyeltem, hogy ott is van egy $username, bocsi. Igazából az alapján a gondolatmenet alapján kellett volna megcsinálnod a másik $username-et is. Azóta 1ed megírta a jó választ.
(#4232) RoyalFlush: hajrá, hajrá! Csak gyakorolj sokat. Eleinte valszeg szívni fogsz vele, készülj fel rá (szívás nélkül nem lehet igazán megtanulni semmit sem ), aztán megkedveled.
Sk8erPeter
Új hozzászólás Aktív témák
- Lenovo Thinkpad P70 " szép állapot "
- MacBook Pro (15", 2019 Mid)
- Lenovo ThinkPad T470s, I7-6600U, 8GB RAM, FHD, 2 év garancia, áfás számla! (41)
- DELL 7070 SFF Core i7 8700 vagy i7 9700 8/16GB DDR4 250GB M.2 SSD számla + gari - több db
- Lenovo ThinkPad T470s, I5-7300U, 16GB RAM, FHD, 2 év garancia, áfás számla! (39)
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen