- Bluetooth hangszórók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Gaming notebook topik
- Azonnali notebookos kérdések órája
- ZIDOO médialejátszók
- LCD, plazma és projektoros TV-k hibái
- OLED monitor topik
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
DeltaPower #10757 üzenetére
Én sem értem, minek az oda.
De szerintem elég jól körbejártuk a témát itt és a másik topicban is, hogy hogyan lehet értelmesen kialakítani a struktúrát.
Az utóbbi mondattal is egyetértek, alapvetően adatbázis-tervezési feladatot nem tudom, minek kell a PHP topicban megbeszélni (miközben abszolúte semmi köze a PHP-hoz). -
Sk8erPeter
nagyúr
válasz
Lacces #10753 üzenetére
Jójó, értjük, ne magyarázd agyon.
Tehát a lényeg röviden: minden hirdető júzer, de nem minden júzer hirdető.
Ezért a hirdetőhöz kapcsolódó extra adatokat külön táblában szeretnéd tárolni, hogy ne legyen csupa NULL annál a júzernél, amelyik nem kíván hirdetni. Ez így teljesen érthető és jogos szempont.
De az SQL-topicban elsőre úgy tűnt, mintha a hirdetőt külön állatfajnak tekintenéd a júzertől.De akkor tisztáztuk.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10745 üzenetére
Szívesen, örülök, hogy így már világosabb.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10739 üzenetére
"Lehet Url-be (hogy később $_GET-tel visszakérhető legyen) mást írni, mint ?p=változó?"
Azt írhatsz a címbe, amit csak szeretnél. A $_GET tömbben meg fogod kapni, ha helyesen használod, tehát ?kulcs=érték&másikkulcs=másikérték&harmadikkulcs=harmadikérték formában.
Ha ez a cím:
http://example.com/index.php?kutyafule=123&gyumolcs=alma&azonosito=543&tokmindegy=blablaakkor a $_GET tömb így fog kinézni:
array (
'kutyafule' => '123',
'gyumolcs' => 'alma',
'azonosito' => '543',
'tokmindegy' => 'blabla',
);Tehát a $_GET['kutyafule'] értéke '123' lesz, a $_GET['gyumolcs'] értéke 'alma', és így tovább. Az &-jellel addig bővítheted ezt a címet, amíg a böngésződ vagy a szerver kezelni tudja.
(Arra figyelj, hogy az &-jel HTML-beli megfelelője az & --> ezt kell írni tehát a HTML-kódokba, ha azt szeretnéd, hogy valid legyen validator.w3.org szerint (ez ilyen esetekben érdekes pl.: <a href="/alkonyvtar/index.php?kutyafule=98324&tokmindegy=blabla</a>, így lesz valid); de ha mondjuk PHP-vel átirányítasz egy címre, amiben használod az &-jelet, akkor a simát használd.)
Tehát az általad használt 'p' nem egy mágikus valami, az annyit jelent, hogy valszeg így hívtad meg a címet: http://example.com/index.php?p=ASD, de ez nyugodtan lehetne http://example.com/index.php?page=ASD, és így tovább.Az általad mutatott kódrészletben a feladatokat viszont lehetőleg teljesen válaszd szét, mert tök más a teendő, mégis azonos nevű változókat használsz logikátlanul - pl. a "SELECT `admin` FROM `members` WHERE username='$torolid'", query-ben a $torolid változónévnek semmi értelme, mert ezzel nem törölsz semmit, aztán az ezután lévő UPDATE-ben sem törölsz semmit, tehát a $torolid változónév megint indokolatlan.
Remélem a fenti példa érthető.
====
Biztonság: ahogy Soak is mondta, semmi értelme először rosszul megírni a query-ket, és aztán a kész változatot majd javítgatni, mert csak szopatod magad vele. Tényleg olyan helyeken is bent maradhat, amit már totál elfelejtettél, és akkor majd a felhasználód fogja szidni a zzzanyádat.
Másik, fontosabb szempont: biztonság. Harmadik: ha eleve jól kódolsz, akkor azt is szokod meg. Ha rosszul kódolsz, akkor meg azt. -
Sk8erPeter
nagyúr
válasz
trisztan94 #10724 üzenetére
Ja hogy gyakorlás céljára lenne, akkor az más.
Chat kialakítása előtt érdemes rendesen megtanulni a formkezelést, validálást, adatok adatbázisba való feltöltését - tehát eddig csak PHP-ról, MySQL-ről beszéltünk, ezek elengedhetetlen alapok. Tudd, hogyan kell megjeleníteni az adatbázisba feltöltött tartalmakat (ne használj mysql_*-jellegű függvényeket, hanem PDO-t; erről Tele von Zsinór kolléga belinkelte korábban az elég tömör, de érthető és hasznos cikkét: [link]), kombináld a lekéréseket, kapcsolj össze táblákat (egyáltalán tudd, mi értelme van a táblakapcsolásoknak), stb.
Aztán kezdd el a JavaScript-alapokat, változtatgasd az oldalon megjelenő tartalmakat, színüket, betűtípusokat, stb., validálj formokat kliensoldalon, és hasonlók; majd jöhet egy hasznos JavaScript-library, mint a jQuery és társai, sajátítsd el ennek a szintaktikáját, és ha ez is megvan, akkor próbáld ki az AJAX-függvényeket (pl. kezdésnek elég jó példa lehet, hogy .load()-dal milyen egyszerű külső fájlokat betölteni, jó a leírás is hozzá), majd ezen keresztül próbálj meg adatbázisba feltölteni, adatbázisból lekérni, stb.Szerintem csak mindezen alapok elsajátítása után van értelme egyáltalán nekikezdeni egy PHP+MySQL+AJAX-alapú csetalkalmazás elkészítésének.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10720 üzenetére
Ha ezt nem gyakorlásnak szánod, hanem éles oldalra kéne, akkor semmiképp ne próbálkozz saját megoldásokkal, a chat kialakítása nagyon nem kezdőfeladat. Rengeteg PHP+MySQL+AJAX-alapú, kész megoldás van ilyenre.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #10703 üzenetére
Ennél még egy fokkal szebben kellene (de ez még így is egy egyszerű megoldás):
lehetne egy tag tábla, egy képeket nyilvántartó tábla, plusz egy összekapcsoló tábla;
tag táblában: tag id, tag neve
kép táblában: kép id, kép elérési útja, stb.
összekapcsoló táblában: tag id, kép id
Ahhoz meg persze megint külön összekapcsoló táblák kellenek, hogy jelezzük, hogy milyen cikkekhez kapcsolódnak a tagek. Hasonló módon mondjuk cikk id, tag id.
Inkább érdemes több táblát létrehozni, hogy szét legyen választva az, ami logika szerint nem feltétlenül kapcsolódik egymáshoz szorosan.Ennek megvan az az előnye, hogy akár több kép is tartozhat egy taghez. Meg így lazább kapcsolatot teremt a kettő között.
Ezenkívül olyan elképzelés is szóba jöhet, hogy minden tagnek van egy "szülője", ami azt jelzi, hogy milyen kategórián belüli tagekről van szó. Ilyenkor a hierarchia nyilvántartásához össze kell kapcsolni az id-kat egy külön táblában (tag id, parent tag id).
Többnyelvűségnél kicsit tovább is érdemes bonyolítani, hogy magát a fordításokat ismét külön táblában tároljuk, és a taghez legfeljebb fordítási "csomópontot" tárolunk (pl. Drupal is így csinálja).=============
(#10702) Soak :
soha ne tárolj vesszővel elválasztott módon különálló kifejezéseket, mert iszonyatosan kényelmetlen lesz módosítani, törölni is, a query-k is lassúak lesznek, plusz nagyon nehéz a táblákban így keresni. Inkább a fentiekhez hasonló megoldást alkalmazz.
A query-k megírásában meg segítünk, ha elakadtál! -
Sk8erPeter
nagyúr
válasz
trisztan94 #10697 üzenetére
Hát akkor legalább neked jó.
De az elég elkeserítő, hogy valaki úgy szerez OKJ-s képesítést, hogy konkrétan SEMMIT nem tud az egészről, és ezek szerint még az érdeklődés sem volt meg benne, hogy elsajátítsa a dolgokat (legalább magától, ha egy raklap szar a tanári kar). Mondjuk én megértem, ha már 500k-t kiszórt az ablakon, legalább legyen meg a végtermék. De igazából tök felesleges, mert a piacon sajnos nem fog tudni melót találni 0 tudással.
Ha "géphasználat" címén elkértek tőle pénzt, úgy, hogy ő konkrétan a saját laptopját használta, és ő még hajlandó is volt odaadni ezt a pénzt, hát...kicsit jobban a sarkára kellett volna állnia, pl. rájuk kellett volna borítani ilyenért az asztalt
(nehogy azt mondd, hogy a nők nem tudnak kibalhézni maguknak dolgokat...
).
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10695 üzenetére
Ez egy webfejlesztéssel kapcsolatos OKJ-s tanfolyam? Tehát konkrétan webfejlesztésről szól, 500k-ba került, és nem sikerült elsajátítania az ismerősödnek semmit?
-
Sk8erPeter
nagyúr
válasz
Speeedfire #10693 üzenetére
Szívesen!
-
Sk8erPeter
nagyúr
válasz
Speeedfire #10689 üzenetére
Pakold zárójelbe a kivonásokat:
$kor18 = Hirdetes::model()->count('szul_nap >= '.($date-18).'-'.date('m-d').' and szul_nap <= '.($date-24).'-'.date('m-d'));
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10686 üzenetére
Nincs mit!
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10684 üzenetére
Nincs baj ezzel a megoldással, amit alkalmazol, mármint azzal, hogy az URL-ben átpasszolod a teendőt. Soak arra hívta fel a figyelmedet, hogy a felhasználótól jövő adatot minden esetben ellenőrizd, tehát pl. KÖZVETLENÜL SOHA ne töltsd fel adatbázisba az adatot, előtte mindig validáld.
Számolni kell azzal, hogy a felhasználó nem biztos, hogy ember, és hogy a felhasználó nem biztos, hogy jóindulatú. Sőt, eleve feltételezni kell a rosszindulatot, és annak megfelelően kódolni. -
Sk8erPeter
nagyúr
válasz
trisztan94 #10680 üzenetére
Szívesen!
-
Sk8erPeter
nagyúr
válasz
CSorBA #10675 üzenetére
A country-t minek átvinni, ha ott az id, ami hozzá tartozik?
Egyébként országválasztó listáknál a legtöbb esetben kétkarakteres country code-okkal szokták megoldani, mutatok egy példát a Drupal egyik moduljának legenerált listájáról (Location modul):
http://i.imgur.com/0DMbt.png
Bőven elég tehát csak valami egyedi azonosító vagy kód (itt országkód).
A selecthez tartozó name-et meg úgyis eléred, és az ország és a város meg úgyis teljesen különálló selectbe tartozik. -
Sk8erPeter
nagyúr
válasz
trisztan94 #10677 üzenetére
"ha index.php?p_kosar akkor valamit adjon ki."
Ha értéket is adsz neki, úgy van értelme, pl. index.php?p_kosar=543:
$cart_item_id = isset($_GET['p_kosar']) ? $_GET['p_kosar'] : NULL;Így a $cart_item_id változó tartalma 543 lesz.
-
Sk8erPeter
nagyúr
válasz
CSorBA #10669 üzenetére
Ja, értem, hát az előbbi megfogalmazás ezek szerint kissé félrevitt, azt hittem, neked pont az kell, hogy egyszerűen egy stringből tömb legyen, azt' kész, de ezek szerint bonyolultabb.
Akkor az a jó, amit PazsitZ javasolt (vagy ahhoz hasonló, amit csináltál), jobbat nem tudok.Egyébként meg szabad kérdezni, hogy mihez kell ez? Hátha találunk egyszerűbb megoldást.
-
Sk8erPeter
nagyúr
válasz
Brown ügynök #10640 üzenetére
"Visszavonva. A duma nem kell."
Nem azt mondtam, hogy te általában szarul kódolsz, hanem ha már rákérdeztél, gondolom valahonnan szedted ezt a kiíratási módot, és előre felhívtam a figyelmedet, hogy ez egy rossz szokás.
De látom itt egy-két ember úgy érzi, porcelánból van, még szólni sem lehet, hogy valamit nem érdemes alkalmazni, minden nyersen fogalmazott tanácson meg kell ám sértődni és duzzogni, mint egy óvodás. -
Sk8erPeter
nagyúr
válasz
Brown ügynök #10636 üzenetére
Legegyszerűbb gyorspélda:
$obj = new stdClass();
$obj->values = array();
for($i=0;$i<4;$i++){
$obj->values[$i] = new stdClass();
$obj->values[$i]->name = 'Józsi';
}
echo "{$obj->values[3]->name}";Kimenete: "Józsi".
Szerk.: egyébként sosem láttam értelmét az ilyen nyakatekert kiíratásnak.
Minek idézőjelbe rakni ilyen esetben? Minek szívatnia magát az embernek azzal, hogy csak nehezebb kivenni a kódban, hogy ott mi is van, plusz figyelni kell a string miatt arra is, hogy a kapcsos zárójelek megfelelő helyeken legyenek?
Akkor már egyszerűbb konkatenálni, sprintf()-et használni, vagy bármi hasonlót, ami kissé jobban átlátható, könnyebben módosítható.
Példa konkatenálásra:echo 'Name: '.$obj->values[3]->name;
Szerintem jobb, hogy itt nincs kapcsos zárójel meg körbeölelő idézőjel. A stringet látványban folytonosabbá tenni azzal, hogy beleerőltet az ember ilyen változókat az általad mutatott módon, szerintem önszopatás. -
Sk8erPeter
nagyúr
Nem azt mondtam, hogy a PDO "szép", ahogy te értelmezted. Hadd idézzem magam még egyszer: "Ezerszer szebb, mint a régi mysql_query()-s bohóckodások..."
"Pontosan azért, mert igazából nem szebb."
De, szebb. Nem is értem, hogy állíthatod ezt. Hol volt bindolás a sima mysql_query()-s szarakodásnál? Mennyire okádék volt, hogy mindenhol mysql_real_escape_string() hívások voltak, és az objektumorientáltsághoz, kivételek dobálásához köze nem volt? Most hadd ne soroljam fel az érdemi különbségeket a PDO és a sima mysql_* szarokhoz képest, össze sem hasonlítható.
Azért a "pár cuccnál" szerintem kicsit jobban érzékelhető különbség van a mysql_* függvényekhez képest.Gondolom azért mondod mindezt, mert hosszabb távon nem is használtad, így távolról ítéled meg.
De senki nem mondta, hogy összevethető egy ORM-mel... Azt írod, az ORM bonyolultabb... nem mondod, tényleg?!
Szándékosan magyarázod félre, amiket írok? Arról magyaráztam, hogy az ORM-ben szereplő query-k működhetnek a háttérben a PDO-val, és a kettő egy kicsit sem zárja ki egymást, sőt.
"A pdo az egy wrapper a mysql* függvényekhez"
Ha ez ilyen egyszerű lenne, akkor a PDO nem működne más adatbázisokkal is.Egyébként biztos vagy benne, hogy csak a mysql_* függvények köré írtak wrappert? Úgy emlékszem, hogy a php_mysql.dll NEM kell, hogy engedélyezve legyen ahhoz, hogy a PDO-t zavartalanul lehessen használni a php_pdo_mysql.dll engedélyezésével. De cáfolj meg, ha tévedek. Furcsa lenne, ha szimpla "duplikáció" lenne ilyen tekintetben.
-
Sk8erPeter
nagyúr
"Egyébként olvasgatom az utóbbi hozzászólásokat, ti tényleg ezt a PDO-t használjátok? Olyan ocsmány az egész, szívem szerint bottal sem piszkálnám. "
Miért olyan botrányos? Ezerszer szebb, mint a régi mysql_query()-s bohóckodások...
Lehet használni ORM-et is, de ez is jól használható.
Kíváncsi lennék egyébként, hogy ha egy adott ORM lényegében egy "wrapper" a PDO-hoz, akkor az milyen overheadet jelent a gyakorlatban. (Már maga a plusz függvényhívások sokasága is overhead.)A Drupal is a PDO-t használja egyébként a háttérben, de ott is van hozzá egy elég jól használható "wrapper", ami szebbé és egyértelműbbé teszi a használatát.
Meg gondolom az általad használt megoldások is a "natív" PDO-t használják a háttérben. (Vagy legfeljebb a mysqli-t, de az mennyivel jobb? Semmivel, sőt.) -
Sk8erPeter
nagyúr
Hogy érted azt, hogy "aloldalt"? Ez egy alias, tehát nem fizikailag különálló könyvtár, vagy hasonló... egyszerűen egy leképezés.
Mondjuk van a
http://example.com/users/kisjozsi
ez egy alias erre:
http://example.com/user/231Utóbbira meg van egy .htaccess-szabály, vagy akár másik megoldással ez is egy alias pl. erre:
http://example.com/index.php?user_id=231
Ez csak egy példa a végtelen lehetőség közül.Igen, 10000 felhasználónál ugyanennyi alias lesz. (De nem "aloldal".)
Szerk.: most jövök rá, hogy szerintem félreérted az "alias" szót ebben az esetben. Ennek totál semmi köze a webszerver aliashoz (pl. Apache-ban van Alias kulcsszó). Ez egy URL alias, ami az alkalmazásodhoz kötődik.
Ilyet alkalmaznak a CMS-ek is (pl. Drupal), meg frameworköknél is lehet használni.Szerk. 2.: na várj, akkor most userhez tartozó könyvtárakról beszélünk? Mert akkor meg én is félreértettelek. Attól még, mert a userhez tartoznak könyvtárak, ahova mondjuk gyűjtögeti a fájljait (pl. a profiljához tartozó kép, vagy hasonló, ha nincs ömlesztve), attól még nem kell "aloldal", miért kellene? Egyszerűen a hozzá tartozó könyvtárba pakolod a hozzá tartozó fájlokat, és onnan húzod elő, ha szükséged van rá, azt' kész.
De ahogy már sztanozs is említette, léteznek alternatív megoldások, pl. a fájlokat gyűjtheted dátum szerint rendezve is, ez már kb. tök mindegy, csak tartsd nyilván, hol van. -
Sk8erPeter
nagyúr
"Neked nem mindig könnyen emészthető a stílusod viszont a kritikák egyértelműek és építőek."
Akkor ezt bóknak veszem, kösz!">>sztanozs korábban linkelt neked egy stackoverflow-s topicot, annak az alkalmazásával mi a helyzet? Nem látom a kódodban.<<
Ha erre gondoltál akkor nem értem hogy hogy nem látod mert benne van :
$db->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );"Én erre gondoltam.
-
Sk8erPeter
nagyúr
válasz
burgatshow #10588 üzenetére
"Ha a :változókat lecseréled kérdőjelre"
... akkor elveszíted a prepared statement BESZÉDESségének előnyeit.=======
(#10593) Soak :
"Amugy $sql-t szoktam használni, ez a testpagen volt"
Hogy mi?Nálad az $sql az egy módszer?
=======
(#10594) Lacces :
"csinálj egy die($query)"
Ilyet soha ne csináljon... or die('You shouldn\'t have done that!')!
=======
(#10602) sztanozs :
ez volt az ő kódjában:
$result_set = $query->execute(array($id,$per_page,$pagination));
Az execute() pedig boolt ad vissza.
Ott jól csinálta, bár a $query változónév itt nem túl találó, inkább félrevezető, a php.net-es példában látott $stmt változónév ennél jobban illik ide.=======
(#10600) Soak :
sztanozs korábban linkelt neked egy stackoverflow-s topicot, annak az alkalmazásával mi a helyzet? Nem látom a kódodban.
Egyébként Lacces itt jó példát mutatott, leszámítva az intek stringesítését, bár kicsit ellenségesen reagáltál a tanácsára.Amúgy az instantiate() metódusod elég nyakatekert. Szerintem tipikusan olyan megoldás, amit szebben és egyszerűbben is megoldhatnál, de gyorsmegoldásnak annak idején megtette.
Tulajdonképpen akkor még mindig ugyanarról a query-ről van szó, amire sztanozs küldte a linket? Annak az összes értéke NULL? -
Sk8erPeter
nagyúr
válasz
Lacces #10574 üzenetére
A reguláris kifejezésedben látsz számokat?
/^http:\/\/[A-Za-z0-9\.:]+/
Így stimmelne, de ez a kifejezés sem jó még önmagában semmire, csak arra, hogy valamennyire korlátoztad, hogy ezek a karakterek lehetnek benne, tehát ezen a teszten még egy http://9: is átmenne.Amúgy itt van egy online tester, ha érdekel.
-
Sk8erPeter
nagyúr
Én PHPMailert szoktam használni.
Ha meghatározod a karakterkódolást, ahogy itt látható, akkor is probléma van az ékezetekkel?// Approach 1: Change the global setting (suggested)
Swift_Preferences::getInstance()->setCharset('iso-8859-2');
..........(lásd még a többi approach-ot is)
Ez a "leáll a futás" tényleg elég megfoghatatlan, így nyugodtan elképzelhető, hogy más levelezőosztály használhatával is le fog állni...
-
Sk8erPeter
nagyúr
válasz
Lacces #10564 üzenetére
Röviden: felejtsd el a fostalicska ingyenes szervereket. Ma már olyan olcsón lehet kapni tárhelyeket, meg domaint, hogy felesleges szopatnod magad ezekkel.
Szerintem a user agent tök mindegy az URL tartalmának lekérésekor ebben az esetben.
De ha hibába fut valamiért az állítgatás, akkor lehet parád az ingyenes szerókon."Ezzel meg pont az a bajom, hogy mindenképp kinyomja a curl_exec() a tartalmat."
Nem értem, most miért nem volt jó az a függvény, amit éppen Te másoltál be az előbb, és amihez még hozzáfűztem plusz két sort.
Itt volt benne erre a megoldás:// Should cURL return or print out the data? (true = return, false = print)
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); -
Sk8erPeter
nagyúr
válasz
Lacces #10556 üzenetére
Ha egy fájlban csak és kizárólag PHP-kód van, akkor sose zárd le ezzel a résszel: ?>. Lásd ezt.
"The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include or require, so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files."
Ez persze az érdemi kérdésen nem változtat, csak jótanács.ini_set('user_agent', 'Mozilla');
Nincs olyan valid user agent, ami csak úgy simán azzal egyenlő, hogy "Mozilla"!Az érdemi részre meg már látom, PazsitZ leírta a választ, allow_url_fopen nincs engedélyezve a szerveren, amivel próbálkozol, anélkül meg nem megy.
-
Sk8erPeter
nagyúr
válasz
Lacces #10560 üzenetére
Azért nem működik, mert be kell tenned még ezt:
// This will make cURL follow the redirects (@see http://stackoverflow.com/questions/6028050/curl-returntransfer-is-empty-curl-getinfo-error-1)
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);Tehát a teljes függvény:
/**
* Download a website or any other file using cURL
*
* @see http://www.jonasjohn.de/snippets/php/curl-example.htm
* @see http://stackoverflow.com/questions/6028050/curl-returntransfer-is-empty-curl-getinfo-error-1
*
* @param string $Url
* @return string
*/
function curl_download($Url){
// is cURL installed yet?
if (!function_exists('curl_init')){
die('Sorry cURL is not installed!');
}
// OK cool - then let's create a new cURL resource handle
$ch = curl_init();
// Now set some options (most are optional)
// Set URL to download
curl_setopt($ch, CURLOPT_URL, $Url);
// This will make cURL follow the redirects (@see http://stackoverflow.com/questions/6028050/curl-returntransfer-is-empty-curl-getinfo-error-1)
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
// Set a referer
curl_setopt($ch, CURLOPT_REFERER, "http://www.example.org/yay.htm");
// User agent
curl_setopt($ch, CURLOPT_USERAGENT, "MozillaXYZ/1.0");
// Include header in result? (0 = yes, 1 = no)
curl_setopt($ch, CURLOPT_HEADER, 0);
// Should cURL return or print out the data? (true = return, false = print)
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
// Timeout in seconds
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
// Download the given URL, and return output
$output = curl_exec($ch);
// Close the cURL resource, and free system resources
curl_close($ch);
return $output;
}Teszt:
$curl_download = curl_download('http://www.example.org/');
echo $curl_download; -
Sk8erPeter
nagyúr
válasz
Lacces #10540 üzenetére
Háde félreértettél, nem a Te hibád az, ha a nagy guru fejlesztő saját keretrendszerrel állt elő, amit nehéz használni.
Hát, segítenék szívesen, de ha nem mondasz konkrétabb példát, akkor nem tudom kitalálni, mi a helyzet.
Pedig az előbb épp hozzá akartam tenni, hogy sokat vakerászom itt a topicban is - mások nagy bánatára.
-
Sk8erPeter
nagyúr
válasz
Lacces #10538 üzenetére
"ő találta ki a keretrendszert"
Ezt úgy bírom, amikor valaki felfedezi a spanyolviaszt."Az egyszerű polimorfizmus nem működik benne... sem konstruktorral, igaz nem is jön létre objektum, hanem osztályok közötti öröklődés van csak... és hiába próbálom a gyermekben felülírni az ősosztályból származó adattagot, nem megy."
Konkrétum nélkül nehéz erre mit mondani, nem látjuk, mit csinálsz rosszul vagy értelmezel félre.Ja, hát igen, múlik az idő, és sokat vakerászom.
-
Sk8erPeter
nagyúr
válasz
DeltaPower #10532 üzenetére
12 ezred.
-
Sk8erPeter
nagyúr
Szerintem a 6 számjegy kicsit kevés.
(#10520) Soak : "A VirtualHost-hoz nem nyúltam abszolut."
Most hogy van beállítva?
pl. localhost/phpmyadmin, vagy hogyan használod?
Azt még mindig nem írtad, próbáltad-e már másik verzióval.
Ha nem, tedd meg.
Esetleg rakd fel a php.ini-det is valahova, vagy a my.cnf-et, esetleg az Apache megfelelő konfigfájljait. -
Sk8erPeter
nagyúr
válasz
Lacces #10518 üzenetére
Ja, de most végül is mi a kérdés?
Pont meg volt nyitva a NetBeans, úgyhogy bepötyögtem neked egy rövid példát a kódjaid alapján, abból hátha megérted, próbáld ki, kiírat minden szirszart:
<?php
class Admin {
public $valami = 0;
public function ez() {
return __METHOD__;
}
}
class Child extends Admin {
public function __construct() {
$this->valami = 1;
}
public function ez() {
return __METHOD__;
}
public function az() {
$parentMethodReturnValue = parent::ez();
return 'child: "'. __METHOD__.'", parent: "'.$parentMethodReturnValue.'"';
}
}
function my_var_export($var, $text = '...', $output_type = TRUE) {
if (gettype($var) === 'string') {
$var = htmlentities($var);
}
return '<p>' . $text . ($output_type ? ' (' . gettype($var) . ')' : '') . ':</p><pre>' . var_export($var, TRUE) . '</pre>';
}
$admin = new Admin();
$child = new Child();
echo my_var_export($admin, '$child');
echo my_var_export($admin->valami, '$child->valami');
echo my_var_export($child, '$child');
echo my_var_export($child->valami, '$child->valami');
echo my_var_export($child->ez(), '$child->ez()');
echo my_var_export($child->az(), '$child->az()');=================
KIMENET:
$child (object):
Admin::__set_state(array(
'valami' => 0,
))
$child->valami (integer):
0
$child (object):
Child::__set_state(array(
'valami' => 1,
))
$child->valami (integer):
1
$child->ez() (string):
'Child::ez'
$child->az() (string):
'child: "Child::az", parent: "Admin::ez"' -
Sk8erPeter
nagyúr
Lehet, hogy korábban már volt szó róla, de már nem tudom követni, szóval milyen szerver?
Milyen szerverbeállításaid vannak?
Ha Apache, akkor az adott VirtualHost beállítása hogyan néz ki?
Újabb verzióval próbáltad már?
Nem tudom, miket kérdezzek még.(#10499) randras : hát jó.
-
Sk8erPeter
nagyúr
válasz
Cathfaern #10486 üzenetére
Na, most felraktam ide, hogy normálisan nézzen ki, így már legalább látható is, mi van a kódban...
Csak most látom át, így, hogy ki is lehet valamit belőle venni, hogy csak az else ágban van a másik kettő foreach...A $senders-re vonatkozó részt tényleg félreértettem... hát igen, nem árt, ha normálisan van indentálva a kód....
$senders = array();
foreach ($messages as $message) {
if (array_key_exists($message->sender_username, $senders)) {
$senders[$message->sender_username]++;
} else {
$senders[$message->sender_username] = 1;
}
}Tehát magyarul akkor ad hozzá a $senders adott kulcsánál lévő számhoz plusz egyet, ha már létezik az adott kulcs a felhasználó nevével, egyébként eggyel egyenlő...
Igazad van, ezt sem láttam át a korábbi ocsmány kód miatt (az is igaz, hogy eléggé átrohantam rajta).
Ettől függetlenül továbbra is fenntartom, hogy ezt nem így kéne, nemsokára írom, miért. Áll a többi dolog is, azzal a módosítással, hogy ezek szerint nem fut le mindhárom ciklus, mert külön vannak. A statikus függvényhívásokra, változókra, egyebekre (pl. truncate() külön függvény/metódus, stb.) vonatkozó dolgok is állnak."Amennyiben az első foreachen belül megváltoztatsz valamit a tömbön, akkor lehet értelme mégegyszer bejárni (elvileg ugyanazt a tömböt, gyakorlatilag nyilván akkor már nem ugyanazon mész végig). És ahogy láttam, itt pontosan erről van szó."
Nézd meg még egyszer, a $messages tömbön nem változtat semmit az első ciklusban. Csak kigyűjti a $senders tömbbe a megfelelő neveket, a hozzájuk tartozó üzenetek számát. Aztán ezt használja fel a második foreach-nél, és ennyi.
Az a baj, hogy feltételezem, a find_messages_by_users_id() metódusában eleve van már egy ciklus, ami bejárja az adatbázisból lekért eredményeket. Így tehát összesen 3 darab (!) ciklus lesz mégis, mert még ezt is be kell járni még egyszer. Úgy lehetne ezt redukálni mondjuk max. 2-re, hogy eleve egy normális query-t ír, ami felhasználók szerint csoportosítva kéri le az üzeneteket, aztán amikor ezt az eredményhalmazt bejárja PHP-vel, akkor eleve felhasználónként gyűjti egy tömbbe az üzeneteket. Akkor meg már lehetne használni ezeken a gyorsabb count() függvényt is, amivel egyből megkapná, hány darab üzenet tartozik a felhasználóhoz, meg csak a kiíratáshoz kellene bejárni.
Úgy már nem lenne gány. -
Sk8erPeter
nagyúr
"Az előző hsz.-edben az volt a problémád"
Ácsi, kicsit rosszul közelíted meg a kérdést. Nekem aztán nem probléma, ha gányolsz, de tanácsot kértél.$_GET: Akkor totál félreértetted, amit mondtam. Annyit javasoltam, hogy a $_GET, $_POST és hasonló tömbökhöz közvetlenül már ne nyúlj az objektumodban, hanem add át paraméterként a tartalmukat a metódusnak, állítsd be a konstruktorban, vagy fogalmam sincs, hogyan oldd meg, de a metóduson belül ne közvetlenül használd már ezeket a tömböket, mert szerintem nem szép. Komolyabb rendszerekben sem nagyon szoktam látni, hogy közvetlenül nyúlkálnak hozzá az osztályon belül. De ahogy érzed.
A foreach egy egyszerű bejáró algoritmus, semmi extra mutatvány nincs a dologban. De ha háromszor használsz foreach-et, akkor háromszor járod be. Ez felesleges.
Ez most a kosaras példánál maradva olyan, mintha lenne egy kosarad, ami tele van kék, fekete, piros golyókkal, és neked az lenne a feladatod, hogy ezeket külön kosarakba gyűjtsd színek szerint; te pedig úgy oldanád meg, hogy először átnéznéd a kosarat, és kiszednéd a pirosakat a saját kosarába, majd ha ezzel végeztél, akkor megint átnéznéd a kosarat, csak a kék golyókra koncentrálva, aztán harmadik alkalommal is átnéznéd, akkor már csak a fekete golyókat keresgélve, miközben ezt megoldhattad volna úgy is, hogy az épp kezed ügyébe kerülő golyót a megfelelő kosárba pakolod, szín szerint.$senders tömböd:
itt már részletesen leírtam, mi a probléma vele. Nem igazán vágom, mit nem értesz belőle, de megpróbálom még egyszer elmagyarázni, kiemelve a lényegi részt:$senders = array();
if(array_key_exists($message->sender_username,$senders))Elmagyarázva szavakkal, a kosaras példával:
$kosár = tök üres
ha a $kosárban van piros színű golyó, akkor csináld ezt:
Vágod? -
Sk8erPeter
nagyúr
"Te hogy oldanád meg?"
Egyetlen ciklussal.
De őszintén szólva már a kérdést sem értem. Egymás alatt, azonos metódusban szerepel háromszor ez:
foreach($messages as $message)
Akkor ebből nyilvánvaló, hogy pontosan ugyanazt csinálják, tehát nem értem, miért nem pakolod egyszerűen egybe azt, amit számomra érthetetlen okból különválasztottál, és vizsgálgatod a feltételeket a cikluson belül.Leegyszerűsítem olyan példára, aminél egyszerűbbet már nem tudnék mondani az adott helyzetre:
foreach($messages as $message){
echo 'ELSŐ blablabla';
}
if($tokmindegy){
foreach($messages as $message){
echo 'MÁSODIK blablabla';
}
}
if($ezismindegy){
foreach($messages as $message){
echo 'HARMADIK blablabla';
}
}ehelyett miért ne lehetne így:
foreach($messages as $message){
echo 'ELSŐ blablabla';
if($tokmindegy){
echo 'MÁSODIK blablabla';
}
if($ezismindegy){
echo 'HARMADIK blablabla';
}
}Capisce?
"Az lett volna az értelme, hogy elösször biztosan le kell futnia, mivel az első vizsgálatnál még nem volt üzenet és fogalmam sincs ki a feladója az első üzenetnek. Ezért az elsőt beleírja és ha tőle jött még 3 akkor azokat már ignorálja és csak a következő legfrissebbet rakja ki, másik usertől."
Miért találna bármit is egy üres tömbben?
Most gondolj már bele, ez olyan, mintha lenne egy tök üres kosárkád, és elkezdenél keresgélni benne izomból egy piros színű labdát, amikor tudod jól, hogy az a kosár tök üres. -
Sk8erPeter
nagyúr
"A 3 foreach azért van, mert legrosszabb esetben 2 fut le, de nem tudtam jobban megoldani, hogy ki tudjam jelezni egy usertől hány üzenet van."
Akkor sem értem a logikát, hogy miért kell különbontani, és három különálló, de teljes mértékben egyező ciklusban megoldani, amit meg szeretnél, ezzel háromszorosára növelve a ciklus futási idejét..."Azért egyenlő egy üres tömbbel, mert különben hibaüzenetet dobál, hogy nincs definiálva..."
Még mindig nem érthető, mit is akarsz üres tömbbel... array_key_exists-szel vizsgálgatsz egy nyilvánvalóan nem létező kulcsot, mivel üres a tömb? Mi értelme? -
Sk8erPeter
nagyúr
Használd ezt a formázót, ha nem sikerül másként...:
http://beta.phpformatter.com/Szétb@szhatja azért is a formázást, mert public functionnel kezded kapásból, és nem adsz nevet az osztálynak. Nyilván most csak kivágtad a megfelelő részt, de akkor ne az ideone.com-ra rakd, hanem a pastebinre, ha előbbire, akkor legalább adj egy nevet az osztálynak, és tedd oda kommentbe a három pontot, ami jelöli, hogy ott amúgy van más is. (Hogy ne legyen itt ezen az oldalon syntax error.)
if(isset($_GET['i']))
Már eleve rossz kezdés szerintem. Itt már szerintem nem kellene $_GET, $_POST és hasonlókhoz nyúlni, hanem a megfelelő helyen be kellene ezeket állítani, legalábbis ez ebben a formában csúnya osztályon belül.
Ezenkívül mi az az "i"? Miért szopatod magad ilyen kulcsokkal? Miért nem használsz beszédesebb neveket, teljes szavakat?
Én kimegyek a fazonomból az ilyenektől, elég utálatos feladat, amikor más kódját kell kotorásznod, és ilyeneket látsz, egyből letépnéd a fejét annak, aki írta ezt a kódot, és még egy nyomorék kommentet sem rakott oda. Ha már agilis szoftverfejlesztés, akkor már a kód legyen beszédes.$messages = self::find_messages_by_sender_id($_GET['i']);
Miért static függvényhívás? Miért kevered a szezont a fazonnal? Egyáltalán minek ide static függvény?
Erről már korábban is volt szó, cucka is említette neked.foreach($messages as $message)
Összesen háromszor??Mi a francnak mész végig rajta külön-külön?!
Ugye tudod, hogy ez így háromszor annyi időbe is kerül (és egyébként totál értelmetlen)?if(strlen($message->body) > 140){$dots = "...";} else {$dots = "";}
Ez is több helyen szerepel, az már eleve gáz, de amúgy is: mi értelme van? Ennyiből kb. semmi.
Ha le kell vágni a törzsből valamennyit, mert adott karaktermennyiséget túllép, akkor azt egy tök különálló truncate() metódusban végezd el, ne ugyanebben a függvényben. A default karakterlimit pedig a függvény egyik paramétere lehet, default értékkel. Vagy tárold pl. osztályváltozóként a limitet, de inkább előbbi.Aztán egyszer a $message_username változót használod, egyszer a $message->sender_username-et. Abszolút semmi értelme. Egyébként sincs értelme itt átadni másik változónak.
$senders = array();
foreach($messages as $message){
if(array_key_exists($message->sender_username,$senders)){
$senders[$message->sender_username]++;
}
else{
$senders[$message->sender_username] = 1;
}
}Ennek magyarázd már el légyszi, mi értelme, mert szerintem kb. semmi.
Miért kotorászol a $senders-ben, amikor egy üres tömbbel tetted előtte egyenlővé?Tovább nem volt kedvem keresgélni a hibákat, ezek csak első blikkre tűntek fel, némi fájdalmat okozva.
Bocs, de ez így iszonyatosan gány. A kritikákon ne sértődj meg, mert Te kérted.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #10468 üzenetére
"feltölti a képet csak az src-be nem tudom berakni"
A $stringData változód már a cikluson kívül van... magát a kiíratásra vonatkozó, konkatenált stringet is a cikluson belül kellene összeállítani (a foreach-en belül). Úgyis ott rakod össze a végleges elérési utat, ahova át kellene mozgatni, tehát akkor lehet az az src attribútum értéke.=======
(#10465) wolandino : ahogy elnézem, közben megtaláltad a megoldást.
-
Sk8erPeter
nagyúr
válasz
Fecogame #10467 üzenetére
Már magát az elgondolást sem értem, miért jó azonos domain alatt két különböző fórummotort működtetni... Nem tudod összeolvasztani?
Megoldhatod aldomainekkel és alkönyvtárakkal is: pl. a főoldalon van két választási lehetőség, Fórum 1 és Fórum 2 linkekkel, ha valaki ráklattyol egyikre, akkor átirányít a http://example.com/forum1 VAGY http://example.com/forum2 címre, ahol teljesen függetlenül működik a két motor. Az adatbázis lehet közös, prefixek alkalmazásával. -
Sk8erPeter
nagyúr
válasz
CSorBA #10466 üzenetére
Akkor már pakold fel phpclasses.org-ra vagy ehhez hasonló helyre, ha már ópenszósz lesz a kód.
-
Sk8erPeter
nagyúr
foreach($previous as $previous){
foreach($current as $current){
foreach($next as $next){
A lényeget cucka már leírta, de nekem a fentiektől nyílt ki legjobban az agyam.Nem is tudom, ez működik-e így egyáltalán, bár valószínűnek tartom, hogy inkább nem, és felmerül, hogy felül is írja a változót...
De ezek szerint a foreach használatának logikája sem jött át, vagy nem vágom, ilyet miért toltál be a kódodba.Példa jó használatra:
foreach($ezatömböd as $ezazaktuáliskulcs => $ezazaktuálisérték){
}
vagy csak
foreach($ezatömböd as $ezazaktuálisérték){
}
De ne legyen már ugyanaz a neve a tömbnek és az aktuális értéknek...(#10461) Soak : annyira rondán van indentálva a kódod, hogy őszintén szólva nem sok kedvem van a végignézésére.
Mit használsz PHP-fejlesztésre? Csomó IDE-ben van automatikus formázás, pl. NetBeans-ben Alt+Shift+F.
DW: [link].=========
(#10458) cucka :
"Az empty() nyelvi elemet (figyelem, ez nem függvény) érdemes elkerülni"
Szerintem nem kell kerülni, tudni kell, hol indokolt a használata.
Akár debuggolásra is jól jöhet.
És/vagy ha az ember számíthat NULL, 0 vagy false értékekre is valamilyen oknál fogva.
Persze mielőtt mondanád, azzal egyetértek, hogy jobb szigorú szabályokhoz kötni, adott függvények/metódusok mivel térhetnek vissza, de előfordulhat olyan eset, hogy nem vagy biztos benne, milyen jellegű típus várható az empty()-nek megfelelőek közül, és nincs kedved típusonként ellenőrizni.
Persze a konkrét esetben valóban nem indokolt, de általános értelemben szerintem nem feltétlenül igaz, hogy kerülni kell. -
Sk8erPeter
nagyúr
válasz
trisztan94 #10454 üzenetére
Ha jól értettem, az eredeti problémád az volt, hogy a képeket NEM TÖLTI FEL, nem a kiíratással volt a para.
Tehát a move_uploaded_file() is valami ciklusban kéne, hogy lefusson. -
Sk8erPeter
nagyúr
válasz
trisztan94 #10441 üzenetére
Nem látom, hogy itt lenne bármilyen ciklus is a több fájlmezőn való bejárásra, szóval az lesz a gond így első ránézésre.
-
Sk8erPeter
nagyúr
"JS jobb klikk védelmet"
Na ezt inkább ne. Legalábbis ne globálisan (úgy értem, max. csak akkor legyen érvényes, ha ténylegesen a képre kattintasz jobb gombbal). Vagy akkor már valahogy flash-sel jelenítsd meg a képet, az is nehezíti a dolgot (ehhez képest a jobbklikkes tiltás tényleg nem sokat ér). De ez a jobbklikk-tiltás engem legalábbis megőrjít, utálom, hogy egy oldal még a böngészőmnél is okosabb akar lenni, a felhasználók nagy része számára szintén rendkívül frusztráló lehet. Meg a JS-t akkor kapcsolod ki, amikor akarod."Ez lenne a cél végsősoron amit mondasz, csak egy léptethető, értelmes galériában. Olyan linkel ami nem évül el (kivéve nyilván ha törölve lett a fotó)."
Én is erről írtam korábban, hogy a photo_id-s $_GET-paraméter sem évül el... Hacsak nem törölték a képet, ekkor pedig megjeleníted a komplett galériát, és kész. De őszintén szólva még mindig nem világos számomra, ez miért is nem jó neked. Ha oldalakat akarsz megjeleníteni a képekből dátumra szűrve, az megint más. Ettől még én azt mondanám, inkább többféle megjelenítési módra is kellene gondolni: ahol összegyűjtve, galériaszerűen, albumba rendezve akarod megjeleníteni a képet, ahol dátum szerint rendezel (és nem feltétlenül albumba rendezve, hanem mindent megjelenítesz, ami adott időperiódusban készült), ahol user szerint rendezel, aztán tagek szerint, stb., és van egy, ahol csak egy képet jelenítesz meg nagyban, meg thumbnaileket (kisképeket) a nagyobb kép alatt, amire kattintva tovább tudsz menni a többi képre, meg van előző-következő nyíl.Ha az a gond, hogy több query kellene a lekérdezéshez, meg lehet oldani egy query-vel is, biztos van egyszerűbb is, de most hirtelen ez jutott eszembe, egész gyorsan lefut:
SELECT *, 'previous' FROM `photographs`
WHERE fid < 34
LIMIT 2
UNION
(SELECT *, 'current' FROM `photographs`
WHERE fid = 34)
UNION
(SELECT *, 'next' FROM `photographs`
WHERE fid > 34
LIMIT 2)Így összesen 5 kép jelenik meg, a "középső" az aktuális kép. (Persze nem "középső" lesz a 'current', ha az adott id előtt vagy után nincsenek képek.)
Most ezt csak példaként írtam, ahogy hirtelen eszembe jutott, nem feltétlenül ez az optimális megoldás.Egyébként lehet, hogy érdemes lenne keresni egy open source galériamodult PHP-hoz, és azt felhasználni, ahol már a legtöbb ilyen problémát kezelték.
-
Sk8erPeter
nagyúr
Nem értem, a direkt link miért generálna felesleges forgalmat, ezt még nem fejtetted ki. A hotlinkelés generálhat felesleges forgalmat, ezt esetleg lehet szűrni .htaccess-szel.
Meg lehet írni úgy is a query-t, hogy az előző és utána lévő pár képet is behozza.
Viszont a wis által javasolt dátum szerinti rendezés tényleg jó ötlet, egy áthidaló megoldás a problémádra. A query-nél egyszerűen dátum szerint rendezve kéred le a képeket, az adott dátumnál kisebb vagy épp nagyobb sorrendbe rendezve; így az sem gond, ha közben törölték a képet, mert akkor egyszerűen nem fog szerepelni a találatok között, és kész.
A (#10437)-ben írt kérdésed viszont megint nem világos, hogy miért ne lehetne ugyanezt a címsorból linkelni. Egy újabb $_GET paraméterként a dátumot is megadhatod, aminél előbb vagy később feltöltött képeket szeretnél megjeleníteni.(#10437) szerk. utáni rész:
Itt a "direkt link" alatt nem azt értettem korábban, hogy megnyitod a képet külön fülön mondjuk (bár jogos, tulajdonképpen általában erre vonatkozik), hanem arra, hogy közvetlenül a kép id-ja szerint tudod belinkelni, és ezt a felhasználó is el tudja menteni kedvencek közé, elküldheti, stb... Míg ha ilyen nincs, akkor konkrét képre nem tud hivatkozni, csak dátumokra, az meg gáz. Engem legalábbis idegesítene.
Egyébként ha meg szerzői jogokra hivatkozva nem akarod, hogy megjeleníthető legyen külön, akkor már eleve buktad a dolgot, ami az internetre felkerül, az már csak úgy védhető le, ha föléraksz egy vízjelet, vagy legalább nehezíted a dolgát a júzernek. Viszont az nem megoldás, hogy ne tudjon közvetlenül hivatkozni egy képre, ha az mondjuk tetszett neki, és később is meg akarja nézni, az oldalad keretével együtt; mert ahogy most szeretnéd, úgy első ránézésre nem fogja tudni csak azt a képet megnézni.Remélem azért már kezdünk kevésbé elbeszélni egymás mellett.
-
Sk8erPeter
nagyúr
"Na most, ha valaki nézi ezt a nagy képet akkor szeretném ha tudná linkelni is, nem direkt linkként - fehér háttéren a kép-, hanem a konkrét oldalt amin van, mindenestől."
Hát ez azért necces, mert ha bekerülnek újabb képek az adatbázisba, vagy törölsz párat a régiek közül, akkor teljesen megváltozik a sorrend, tehát mondjuk ami addig az 1. oldalon volt, pl. 20 újabb kép után a 2. oldalra tolódik.
Az még esetleg kerülő megoldás lehet, hogy $_GET paraméterként megadod a photo_id-t és még egy egyéb paramétert is, ami jelzi, hogy galériaszerűen akarod megjeleníteni, tehát legyen előtte és utána is kép, vagy csak utána, stb... ekkor adatbázisból ennek megfelelően kérdezed le az eredményeket, hogy mindenképp köztük legyen a megadott photo_id-val jelölt kép is.
Az előző-következő nyilak kezelése meg nem olyan nehéz, de ahogy elnéztem, ez nálad kezelve is van valahogy a $pagination->has_previous_page() és $pagination->has_next_page() metódusokkal.
De egyébként ha az adott képet nagyban meg lehet nézni, tehát az van a "középpontban" akkor most hirtelen nem világos számomra, miért nem jó az, hogy a photo_id szerint direkt linkeled be, és akkor attól még felajánlhatod az előző-következő képeket, és lekezeled azt az esetet is, ha azóta a képet törölték: ha ez a helyzet, akkor pl. megjeleníted a teljes galériát (esetleg jelezheted azt is, hogy azóta az adott képet törölték), vagy hasonló. -
Sk8erPeter
nagyúr
Hát meg kellene különböztetni a kép id-ját és a page-et: a page-dzsel csak megadod, hogy az adatbázisból lekért, korlátozott mennyiségből hanyadik oldalt szeretnéd megjeleníteni.
De elvileg hasonlót csinál a kódod is, tehát csak limitálja a lekért mennyiséget, és megad egy bizonyos offsetet is, ahányadik rekordtól meg akarod mutatni az eredményhalmazt.
Szóval itt még egyáltalán nem jön képbe a képnek a konkrét id-ja...Vegyük azt, hogy pl. van 200 képed. Egy oldalon 20 képet jelenítesz meg, tehát az 1. oldal lekérése így néz ki:
SELECT * FROM photographs LIMIT 0, 20
aztán a 2. oldal megmutatása:
SELECT * FROM photographs LIMIT 20, 20
a 3. oldalé:
SELECT * FROM photographs LIMIT 40, 20
a 4. oldalé:
SELECT * FROM photographs LIMIT 60, 20
és így tovább...(Utóbbi egyébként ekvivalens ezzel:
SELECT * FROM photographs LIMIT 20 OFFSET 60
)A képekhez tartozó linkekbe meg belegenerálhatod a photo_id-t...
Remélem szép lassan közelebb kerülünk a megoldáshoz. Kérdezz, ha valami még nem érthető. -
Sk8erPeter
nagyúr
Pedig "elég magától értetődő mi történik", épp Te írtad.
"csak hogyan linkelen egy olyan id-t amit elvileg adott környezetben nem látok, mivel minden esetben csak 1 képet kapok"
Mi az, hogy "adott környezetben nem látod"?
Normális esetben egy képhez egyetlen id tartozik, tehát egyértelműen azonosítja.
Az offsetnek pedig a címben is megadhatod a kezdetét és végét, vagy ahogy most is csinálod, egyszerűen megadod a page számát, és akkor nyilván nem kell id a címbe.Szerk.: egyébként most látom, hogy itt az id-vel user id-t azonosítasz... nem tudom, milyen rendszert használsz, miért így van megoldva, és ennek mi értelme. Meg van egy ilyen:
if(!isset($_GET['id']) AND !isset($_GET['user']))
{
$id = $_SESSION['user_id'];
}A $_SESSION['user_id'] biztos, hogy be lesz ezelőtt állítva?
Egyébként minél többet nézem, annál kevésbé világos a megvalósítás miértje.
-
Sk8erPeter
nagyúr
A linkbe tedd bele a fotónak mondjuk az id-ját, és aszerint szűrj.
Pl. /photos.php?id=123123Így már lesz $_GET['id']-d.
De felhasználótól érkező adatot soha ne hagyj ellenőrizetlenül!
Mielőtt adatbázis-query-t futtatnál, escape-eld - de inkább jobbat javaslok, használj prepared statementeket!
Ezt muszáj belinkelnem: [link].Szerk.:
echo " <a href=\"photos.php?page={$i}\">{$i}</a> ";
HELYETT pedig lehetne
echo ' <a href="photos.php?page='.$i.'">'.$i.'</a> '; -
Sk8erPeter
nagyúr
Itt külön-külön tesztelve mindig ad match-et.
(#10409) CSorBA : sajnos ez csak első szűrőnek jó, mert amúgy jó címekre nem lesz jó a teszt, pl. pont korábban volt szó róla, hogy az ékezetes neveket tartalmazó domainekre sem jó. (mondjuk akkor FILTER_VALIDATE_URL-ről volt szó, de gondolom egy része közös a függvényeknek)
Mondjuk ahogy nézem, a biker által mutatott regexp sem lesz jó ilyenekre. -
Sk8erPeter
nagyúr
Hát akkor kicsit túlérzékeny vagy.
Ott volt direkt a "vagy én értem félre a kérdést", mert kicsit túl szarul tetted fel a kérdést, már bocs.
Szerk.: zacskó.
Komolyra fordítva:
fordfairlane előttem elég jól megfogalmazta, hogy ha a kérdésedet nem tudod megfogalmazni úgy, hogy mi is értsük, akkor ne várj jobb választ. Hülye kérdésre hülye válasz. És akkor cserébe nem kell visszavágni azzal, hogy "mindenkit kioktatsz", mert akkor ott tartunk, mint az óvodában. Mellesleg ha visszanézel a topicban vagy a többiben, akkor a sok "kioktatás" azért nem egy ember számára segítséget jelentett, szóval lehet, hogy valakik számára hasznosat is írtam, miután megköszönték a kőkemény kioktatást, amit én szoktam tolni.
A másik meg az, hogy nem vagyunk porcelánbabák, ne kelljen már szofisztikáltan fogalmazni, hogy ne sértődj meg apróságokon. -
Sk8erPeter
nagyúr
JavaScript nélkül a szokásos formokkal, bár őszintén szólva már az is meglep, hogy ezt a kérdést felteszed, vagy én értem félre a kérdést... Ha küldtél már el formot valaha, akkor tudnod kéne, hogy küldesz szerveroldalra formadatot. Azonosítót lehet akár hidden mezőként is meg sok egyéb ötlet is lehet rá, de egy ideje PHP-zol, hogy merül fel a kérdés? Vagy esti összezavarodás?
JavaScripttel meg pl. a jQuery akármelyik AJAX-os függvényével összepakolhatsz adatokat, formból pl. a .serialize() függvényt használhatod... -
Sk8erPeter
nagyúr
Ja hogy így flat tárolás, így már minden világos, elsőre másra gondoltam.
Az utána következő "programozás alapjai órát" nem tudom, nem inkább mobalnak szántad-e...
Én annyira kérdeztem rá fordfairlane-től, hogy magával az elképzeléssel mi a baj, hogy a nézetben kapsz egy egymásba ágyazott listát, nem arra, hogy az mire jó és hogyan kell bejárni.(Mondjuk én is értékelem a lelkesedést.
)
(#10363) fordfairlane :
ja OK, szóval ezek szerint az a probléma vele, hogy nem feltétlenül tudod, milyen komplexitású mondjuk egy egymásba ágyazott lista, és bizonyos feltételek döntik el, mi szerint kellene bejárni, milyen mélységig, stb., és ezek a komplex döntések meg pont, hogy nem a view-ban kellene, hogy megszülessenek. Így már teljesen világos. -
Sk8erPeter
nagyúr
válasz
fordfairlane #10361 üzenetére
És mit tárolsz "flat" módon relációs táblában? Még nem jön át.
Mi a baj azzal, ha egymásba ágyazott listát kapsz a nézetben? -
Sk8erPeter
nagyúr
válasz
fordfairlane #10359 üzenetére
"flat módon tárolva, flat módon átadva a nézetnek"
Mit értesz "flat" mód alatt? -
Sk8erPeter
nagyúr
Előttem cucka leírta a megoldást, de tovább fejtegetve a dolog egymásba ágyazott ciklusokkal könnyen megoldható. Gondolj bele, hogy van egy tömböd, amikor azon végigmész egy foreach-csel, ekkor ennek a tömbnek az elemei szintén tömbök lesznek, amin szintén végigmehetsz egy foreach-csel. Most ez kétdimenziós tömb volt, de a komplexitás tetszőlegesen fokozható.
Teccikéjteni? -
Sk8erPeter
nagyúr
Tulajdonképpen megközelítés kérdése, hogy belefér-e, lehet, hogy szebb lenne úgy, hogy a View-ban ténylegesen mindent csak szimplán kiíratsz, amilyen adatot kapsz, szóval lehet, hogy ez most kényszermegoldás.
De melyik rész nem sikerült, hogy a korábbi állapotába kotorj bele, ne a megjelenítésben kelljen machinálni? -
Sk8erPeter
nagyúr
Ez speciel szerintem még beleférne, hogy a nézetnél konvertáld, mert végül is csak azt határozod meg, hogy más formátumban szeretnéd megjeleníteni. Gondolom a megjelenítéshez amúgy is végigmész a tömbön, és amikor kiíratod, oda pakolhatnád ezt. De ha már korábban szeretnéd konvertálni, akkor már eleve a query-t úgy kéne megírni, vagy rögtön a lekérés után konvertálni, amikor végigszaladsz az eredményhalmazon, és berakod mondjuk egy tömbbe őket (ha végigszaladsz). Nem ismerem a rendszeredet, úgyhogy ennyi infóból nehéz lesz megmondani, hogy hol csináld mindezt.
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #10350 üzenetére
Ez így jónak meg elegánsnak tűnik. Került bele egy typo: $val után $var (csak ha valaki elsőre nem venné észre, azért jelzem).
-
Sk8erPeter
nagyúr
Szerintem ennél nagyon nem fogsz találni "elegánsabbat", legalábbis nem tudok ilyen optimalizált, beépített függvényről.
Itt is van még egy megoldás regexpekkel, de ez sem elegánsabb semmivel. -
Sk8erPeter
nagyúr
Nem kell túlbonyolítani, de ha már tanítasz, ne hülyeségeket verj a diákod fejébe...
Ezt írtad:
"Ezzel eléred azt, hogy ugymond a te gépeden egy könyvtár ki lesz nevezve servernek"
ez nem igaz, és félre is vezeti, ezért ezt is írhattad volna:
"A WAMP telepítése után lesz egy c:\wamp\www könyvtárad, amibe pakolhatod a http://localhost címen elérhető weboldalad tartalmát, és már tesztelheted is."
Nincs túlbonyolítva. -
Sk8erPeter
nagyúr
Bocs, de muszáj megint pontosítanom, nem kötekedésből, csak hogy ne vezessen félre senkit. Ne vedd rossz néven, én sem szoktam, ha korrigálnak, sőt, ha jó a korrekció, annak örülök is.
"Magyarul, ha te a böngésző elött ülsz és megnézed a forráskódot akkor csak html lesz
benne."
Nem feltétlenül HTML, ha más content type-ra vonatkozó headert küldött ki a szerver, és nem HTML-tartalmat rakott össze."Ezzel eléred azt, hogy ugymond a te gépeden egy könyvtár ki lesz nevezve servernek"
Könyvtár nem lehet kinevezve szervernek.
A WAMP mozaikszóban benne van az Apache is, na az a szerver (webszerver). Az Apache-hoz tartozó különböző hostokhoz pedig különböző gyökérkönyvtárak tartozhatnak, mindez csupán beállítás kérdése. Az alapértelmezett, localhosthoz tartozó gyökérkönyvtárat is könnyen át lehet állítani az Apache megfelelő konfigurációs fájljában. De ugyanezt a gyökérkönyvtárat tetszőleges számú másik (virtual)hosthoz beállíthatod. -
Sk8erPeter
nagyúr
"az action="" azt jelenti, hogy a form hol keresi a függvényt"
Nem, az azt jelenti, hogy megadod, HOVA, melyik feldolgozó fájlba küldöd el a form adatait. Nem keres semmilyen függvényt, és ennek önmagában még a PHP-hoz sincs köze. A megadott metódusoknak a HTTP-protokollhoz van köze, meg a böngészők működési mechanizmusához. Az action attribútumban megadott feldolgozó fájl akár nyugodtan lehetne ASP.NET fájl is."valamint fontos a name is mert a $_POST onnan tudja, hogy most ő van porondon."
A $_POST nem tud semmit. Az csak egy tömb, a kapott adatokkal. A name attribútum valóban kell, mert szerveroldalon csak így kapod meg a bevitt adatokat. -
Sk8erPeter
nagyúr
válasz
papa019 #10297 üzenetére
Dehogynem, teljesen jó az elképzelésed. Alapvetően ez az általános (jó) megoldás, meg esetleg egy felirat, hogy az adatfeldolgozás folyamatban van, várjon a júzer.
===
(#10293) Soak : nem tudom, ez a qTip2 hogy van megoldva, még nem használtam, de jQuery UI Dialognál nem okoz semmilyen gondot, ha a jQuery UI Dialognak átadott DOM-elem display:none-ra van állítva. Megoldja magának az átalakítást dialógusformára (nyilván a qTip is, csak az nem tudom, hogy), és a display tulajdonság váltogatását is kezeli, alapvetően pont inline-elemeket tudsz megjeleníteni a dialógusablakban, ettől is kényelmes az egész.
-
Sk8erPeter
nagyúr
Gondolom ezekre a függvényekre gondolsz: imagepng és társai, mutat is példát, hogyan tudsz PHP segítségével képeket kiíratni a böngészőbe:
<?php
$im = imagecreatefrompng("test.png");
header('Content-Type: image/png');
imagepng($im);
imagedestroy($im);Esetleg megoldás lehet, hogy mindenféle kép megjelenítését átirányítod .htaccess-szel egy PHP-fájlba, amiben elvégzed a nézettség naplózását, megnézed, milyen kiterjesztésű a kép, és aszerint használod a headert, majd használsz imagepng-t, imagejpeg-et vagy a többit.
-
Sk8erPeter
nagyúr
Most tényleg ezen témázunk?
Nagyon kevesek vagytok Ti ahhoz, hogy magamra vegyem.
Amúgy pont az volt a mondandó lényege, hogy ezek a megjegyzések túl gyerekesek és gyengék ahhoz, hogy üljön a poén.
Na meg ez egy szakmai topic, minden hsz. végén ezeket olvasni kicsit uncsi.
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
Siriusb #10262 üzenetére
"3. Drupla-féle poormanscron jellegű megoldás, de ezt inkább nem fejtem ki.
"
De itt úgyis leírják.
Amúgy ötletes megoldás.
Na jó, mégis leírom, nagyjából ennyivel összefoglalható: ha nincs crontab-beállítási lehetőséged, akkor jön jól ez a megoldás: elhelyez egy JavaScript-kódot az oldalon, ami AJAX-szal a betöltés után kérést intéz a szerver felé, és ha már szükséges, elvégzi az ütemezett feladatokat. Ehhez persze az kell, hogy látogassák is az oldaladat.
-
Sk8erPeter
nagyúr
Nem értem, miért ragaszkodsz ehhez a
function isUrl($val){ return $val != ''; }
függvényhez...Nem kicsit megtévesztő a függvény neve, mert az ember azt gondolná, itt valós ellenőrzés történik arra, hogy URL-ről van-e szó, miközben csak azt ellenőrzöd, empty stringről van-e szó... akkor már inkább legyen isEmptyString a függvény neve, vagy készítsd el rendesen a függvényt.
Most csak azért köcsögösködöm, mert épp tanítasz valakit a helyes kódolásra, akkor mutass neki jó példát, meg tőled nem ilyen béna függvényeket vár az ember. -
Sk8erPeter
nagyúr
válasz
PazsitZ #10233 üzenetére
Bocs, nem figyeltem oda rendesen, f@szságot írtam, igazad van!
Nem teszteltem, csak ránézésre mondtam, mert a \w szóra illeszkedik, és nem figyeltem oda, hogy ott van a "^" karakter, és szögletes zárójelek közé van téve, magyarul csak azt szeded ki, ami nem szó. Sorry. -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Te tettél fel kérdést felhasználó által megadott fájlnevekről, és én erre reagáltam... Arra mondtam, hogy whitelisteket érdemes alkalmazni.
Egyébként szerintem értelmesebb egy beszédes képnév, mint egy névben lévő id, ami totál semmitmondó, ha ránéz az ember. Azt nem tudom, SEO-szempontból mennyit nyom a latba, de elvileg ennek is lehet szerepe, hogy maga a fájlnév is legyen beszédes. Ettől még olyan id-t generálsz bele PLUSZBAN, amilyet akarsz.
A képeket normális esetben így is-úgy is id szerint tárolod az adatbázisban, amihez - mint említettem - tárolod az egyéb adatait is, ezek közül a fájlnév is csak egy a sok közül, vagyis nem a kép egyértelmű azonosítására szolgál, az "csak" egy fizikai elérhetőség, de jó esetben úgy tárolod, hogy tök mindegy, mikor, mire változtatod a fájlnevet, attól még beazonosítható marad a kép.=======
(#10228) ArchElf : OK.
Én egyébként olykor ciklusoknál is az $i és $j és $k és egyebek helyett beszédesebb indexneveket használok, de persze csak akkor, ha ennek a kódban van az olvashatóságot javító szerepe (sokszor van).
A lokális változónevek tekintetében én egyelőre a kódjaimban az underscore-t használom túlsúlyban, mostanában vettem fel a camelCase-zel kódolás szokását PHP-nél is. -
Sk8erPeter
nagyúr
Itt már leírtam a fájlnevekre vonatkozó dolgot, arra semmit nem reagáltál. (whitelist)
A leírás mezőt meg általában a képtől/bármi egyéb fájltól külön szokták kezelni, nem is minden képformátum támogatja a leírás "beleégetését" (vagy nem tudom, erre gondoltál-e), adatbázisban a file-hoz tartozó id-val rendeled össze a kiegészítő mezőket (maga a fájlnév, leírás, szerző, stb.).
A leírásban lévő karaktereket meg a szokásos módon szűröd (pl. legegyszerűbb példaként htmlentities()-t is használva, stb.), adatbázisban tárolod, és nem fájlban. -
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #10220 üzenetére
Ja, ez tény.
Amúgy elfelejtettem hozzátenni, hogy természetesen az osztálynevek esetében én is a PascalCase-t használom. -
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #10214 üzenetére
OK, tehát hogy a lényeget kiemeljük, ha már linkelted (bár ehhez bele is kellett olvasni a linkelt cuccokba, és ez melós volt
):
Symfony2:
"Naming Conventions¶
» Use camelCase, not underscores, for variable, function and method names, arguments;
» Use underscores for option, parameter names;
» Use namespaces for all classes;
» Suffix interfaces with Interface;
» Use alphanumeric characters and underscores for file names;
» Don't forget to look at the more verbose Conventions document for more subjective naming considerations."A PSR-1-ből:
"[...]
» Namespaces and classes MUST follow PSR-0.
» Class names MUST be declared in StudlyCaps.
» Class constants MUST be declared in all upper case with underscore separators.
» Method names MUST be declared in camelCase.
"Tulajdonképpen utóbbi nagyjából csak OOP-kódolásról beszél. Ezt a StudlyCaps-et még most hallom először, gondolom ez a PascalCase-zel ekvivalens, nem? (legalábbis az írási módjából következtetve)
Előbbi viszont egyértelműen camelCase-t ajánl függvényekre és metódusokra egyaránt, ezeknél az underscore-t kerüli.Az itt leírtak nagyjából egyeznek az én szokásaimmal, azzal az egy nagy eltéréssel, hogy a procedurális kódolásnál, globális függvényeknél én még többnyire underscore-t használok. Igaz, néha keveredést okoz az agyamban, főleg amikor mondjuk C#-kódról térek át PHP-ra, akkor először nagyon katyvasz van a fejemben, hogy na most akkor hogyan is deklaráljam a függvénynevet, mert a PascalCase használata viszont PHP-ben nem szokásom.
Amúgy köszi a tapasztalat-megosztást.
==========
(#10202) j0k3r! :
neked is kösz!
"- osztalynevek, nevterek: nagybetuvel kezdodik es camelCase (ClassTwo)"
>>> Tehát akkor gondolom a PascalCase-re gondolsz."az alahuzasos dolgot kerulom (kiveve konstansok), igy legalabb ha ranezek a kodra, akkor egybol latom, hogy az valoszinuleg valami beepitett php-s dolog lesz"
Hmm, végül is ez is egy elfogadható szempont.
Engem alapvetően a Drupal szoktatott rá arra, hogy a procedurális kódolásnál következetesen az aláhúzásokat használjam a szavak elválasztására függvényneveknél (persze a következetes szó akkor igaz, amikor épp nem vagyok kicsit megzavarodva más nyelv használata miatt).==========
(#10203) ArchElf :
OK, köszi, ezek szerint alapvetően kerülöd az underscore használatát. -
Sk8erPeter
nagyúr
válasz
fordfairlane #10212 üzenetére
#9911 környékén én is érveltem a Singleton mellett, igazából csak annyit, hogy azért annyira nem ördögtől való szerintem a használata, de olvass csak vissza, a véremet akarták.
========
(#10207) Soak :
fájlnevekre is alapvetően a whitelisteket érdemes alkalmazni: tehát azt mondod meg, milyen karaktereket engedsz, nem azt, hogy mit nem szabad használni, minden neked nem tetsző karaktert egyszerűen kivágsz a fájlnévből, vagy behelyettesíted egy általános helyettesítő karakterrel, ami neked tetszik, lehet ez egy aláhúzás (_), kötőjel, vagy egyéb, olyan karakter, ami nem okozhat problémát egyik platformon sem (pl. ne akarj egy » jelet tenni a fájlnévbe).
Új hozzászólás Aktív témák
Hirdetés
- Gurulunk, WAZE?!
- Bluetooth hangszórók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen légkondit a lakásba?
- sziku69: Fűzzük össze a szavakat :)
- exHWSW - Értünk mindenhez IS
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Xbox Series X|S
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- További aktív témák...
- Nvidia Quadro M2000/ M4000/ P2000/ P2200/ P4000/ P5000/ RTX 4000/ RTX A2000 / RTX A4000
- Apple iPhone 12 Pro Max 128GB Kártyafüggetlen 1Év Garanciával
- BESZÁMÍTÁS! Apple MacBook Pro 16 M4 Pro 24GB RAM 512GB SSD - garanciával hibátlan működéssel
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Apple iPhone 14 Plus 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest