- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Forrmell.enn
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- AMD Navi Radeon™ RX 5xxx sorozat
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- HiFi műszaki szemmel - sztereó hangrendszerek
- Hobby elektronika
- Milyen joysticket vegyek?
- 3D nyomtatás
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
oleslie #12380 üzenetére
"PDO vs MySQL hitvita"
Valamit nagyon rosszul tudsz, mivel itt PDO-val is a MySQL-hez csatlakoztam, ahogy a mysql_connect() is MySQL-hez csatlakozik... a PDO egy PHP-s osztály. A MySQL pedig egy adatbázis-kezelő szerver.http://php.net/manual/en/book.pdo.php
Itt utána tudsz olvasni, mi is ez.
Lényeg nagyon röviden:
- OOP
- adatbázis eléréséhez absztrakciós réteget nyújt, így könnyebbé teszi más adatbázisra való átállást (pl. SQLite-ról MySQL-re vagy fordítva, de ez most csak egy példa a sokból), nem kell mindenhol lecserélni a mysql_* előtagokat (persze nem úszod meg bizonyos query-k átírását az átálláskor, ha azt nem támogatja a másik adatbázis)
- prepared statementek, macerás mysql_real_escape_string() és ehhez hasonló ocsmány hívások elkerülése
- szebb kód (ez az előző pontból is következik)
- itt Tele von Zsinór még leírt pár dolgot
- kényelmesebb kód (mint például az előbbi pontban látható foreach-es bejárás, ami gyorsan átlátható kódot eredményez)
- ez a jelen/jövő, a régi mysql extension a múlt és deprecated: http://news.php.net/php.internals/53799Ha még magasabb szintű absztrakció kell, akkor persze egy komplett ORM-et kell használni.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #12378 üzenetére
Ne má', legalább Te ne mutass őskövület kódokat kezdőknek...
Egyébként a query-d első ránézésre hibás.
Átalakítom, szerencse, hogy Tele von Zsinór példájából lehet gyorsan ollózni.// ........ MIUTÁN ELLENŐRIZTÜK a $_POST-tömböt
// persze a csatlakozás lehet máshol is, most tök mindegy
$db = new PDO(
"mysql:host=localhost;dbname=etterem", // adatbázis neve 'etterem'
"USERNAME", // cserélendő
"PASSWORD", // cserélendő
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);
$stmt = $db->prepare(
"INSERT INTO tablanev (mezonev1, mezonev2, mezonev3, mezonev4)
VALUES(:mezonev1, :mezonev2, :mezonev3, :mezonev4)");
$stmt->execute(array(
':mezonev1' => $_POST['piritos'],
':mezonev2' => $_POST['palacsinta'],
':mezonev3' => $_POST['kakao'],
':mezonev4' => $_POST['tea'],
));Szerk.: persze ez sem biztos, hogy hibátlan, nem teszteltem, nem raktam code syntax highlightot mutató editorba.
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #12374 üzenetére
Ez így van, de mondjuk ez már a kötekedés része, és akkor még fel lehetne pár ilyet sorolni, echo, print, unset, satöbbi.
-
Sk8erPeter
nagyúr
válasz
vgyuri #12361 üzenetére
IsSet --> isset
"datumtol, datumig - árváltozásnál a régi árakat is meg lehetne nézni, ebben akár nettó ár is szerepelhetne, ha változna az áfa"
Ezt a termék általános adataitól teljesen elkülönítve kellene tárolni, másik táblában. Az árat is.
A termék adatait tartalmazó táblába mindenképp kerüljön bele egy INT típusú, auto_increment termékazonosító (pl. product_id) is.A vásárlások táblázatában product_id szerint kellene hivatkozni a termékre, nem stringgel.
Aztán persze ezen a táblaszerkezeten még lehetne javítani, de az inkább az SQL kérdések vagy MySQL topic témája.
(#12371) vgyuri :
"függvényekbe szoktam nagybetűt is rakni, így számomra olvashatóbb a kód, pl. StrToLower, HtmlSpecialChars, Str_Replace..."
Ez egy rossz ötlet, ne akard saját szád íze szerint megváltoztatni egy nyelv beépített függvényeinek nevét, mert rossz szokást nevelsz saját magadba, valamint ha külső szemlélő meglátja a kódodat, akkor nagyon anyázni fog. Egy normális nyelvnél nincs ilyen szintű szabadságod amúgy sem. -
Sk8erPeter
nagyúr
válasz
lazlora #12349 üzenetére
Escape-elni kell a karaktereket. A video.php után szerintem elfelejtettél egy kérdőjelet a query string elkezdéséhez.
Valahogy így próbáld meg:
print '<div onclick="ajax(\'belso\',\'xml/video.php?id='.$id['video_id'].'&title='.$video['title'].'&description='.$video['description'].'\')">';
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12350 üzenetére
Dehogy oldja meg.
Nézd meg jobban, az attribútumnak adott értéket lezárod lényegében már az első onclick-ben lévő idézőjellel, tehát a "belso" stringgel már el is van cseszve. -
Sk8erPeter
nagyúr
A Drupal is egy PHP-fájlban, konkrétan egy tömbben tárolja az adatbázis-kapcsolódáshoz szükséges felhasználónevet, jelszót, az adatbázis nevét, host címét, portszámot, esetleges prefixet, a használt karakterkódolást, meg drivert (ha nem MySQL lenne, hanem egyéb), mégsem ez a legfőbb oka a feltöréseknek. Valahol muszáj tárolni hozzáférési adatokat, különben a PHP script sem fogja tudni, honnan szedje őket.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12343 üzenetére
Ennek örülök, szívesen!
(#12344) kahva :
rengeteg változás történt, meg sajnos a PHP4 még tele volt gányolásokkal, így a hozzá tartozó könyvek, tutorialok is, úgyhogy ezekből tényleg nem érdemes tanulni.
Remélem, beválik a másik könyv, sok sikert hozzá! -
Sk8erPeter
nagyúr
Na, ezt a könyvet dobd ki. Vagy nyomtasd ki, alázd meg, aztán égesd el máglyán, az látványosabb.
"Tanuljuk meg a PHP4 használatát 24 óra alatt"
2004. július 13-án bocsátották ki a PHP 5-ös verzióját, tehát a PHP4-est felejtsd el.
Akkor már ugyanebből a kötetből legalább a PHP5-öshöz tartozót használd...
Persze vannak ennél sokkal jobb könyvek is, reméljük, hogy valaki ajánl egy jót.Például esetleg ezzel próbálkozhatnál:
http://nagygusztav.hu/web-programozas
Van lecke az OOP-ről, PDO-ról is benne. -
Sk8erPeter
nagyúr
válasz
Speeedfire #12338 üzenetére
"PHPMail-ert használok"
Akkor miért nem azt mutattad (vagy inkább azt IS), hogy a PHPMailert hogyan inicializálod, és milyen kóddal küldöd a levelet...?"From: =?UTF-8?Q?T=C3=B3th_Szabi_-_Linux=2C_openwrt=2C_tplink_-_1043?= <>"
Itt valami nagyon nem kerek......! -
Sk8erPeter
nagyúr
Szívesen!
Ja, OK, akkor bocsánat, összekevertelek valakivel, aki még jóval korábban beküldött hasonlót, hibaüzenet nélkül.
Miben programozgatsz? Egy Notepad++ is a segítségedre lehet, egész jó benne a syntax highlighting, tehát könnyebben megtalálod a hibákat a különböző színek miatt (pl. lezáratlan tagek, lezáratlan zárójelek, blokkok, stb.):
http://notepad-plus-plus.org/
Melyik könyv az, amelyik ezt a kódot mutatta? Tényleg kidobandó.
Egyébként nehogy bármilyen PHP4-es írást elővegyél, mert az nagyon rossz dolgokat fog mutatni Neked.
Amúgy az 500-as HTTP code elég furcsa, sima PHP-s syntax error miatt elvileg nem kellene előfordulnia. -
Sk8erPeter
nagyúr
"ismét a keresd a hibát játékkal jelentkezek."
Nem lett volna egyszerűbb, ha megosztod a hibaüzenetet/hibajelenséget, amit kapsz?Egyébként a kódod elképesztően gány, a form taged nincs lezárva, a $PHP_SELF változó NINCS, mivel alapból a register globals off-ra van állítva szerencsére ($_SERVER['PHP_SELF']), de egyébként totál felesleges is használni (az action attribútumot egyszerűen üresen kellene hagyni, két idézőjel egymás mellett, azt' kész), ráadásul nincs is utána pontosvessző, a $fajl változó szintén nem lesz beállítva a register_globals kikapcsolt állapota miatt (még jó), a $fajl_name, $fajl_size, $fajl_type teljesen ismeretlen, honnan kéne, hogy beállítva legyenek, a második if-ednél hiányzik a zárójel zárórésze, és a submit típusú inputod sincs lezárva rendesen...
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12319 üzenetére
Dehogy sértődtem.
Inkább meglepődtem.
Amúgy hátha segít, nem olvastam el:
http://erickennedy.org/blog/Drupal-to-Yii-Migration-TipsVisszatérve az eredetire: még nem vágom, hogy mit viszel át, és mindezt miért PHP-ben csinálod, miért nem közvetlenül MySQL-ben mondjuk. Engem például érdekelne, hogyan migrálod az adataidat.
A tömbben előforduló értékek mire kellenek? -
Sk8erPeter
nagyúr
válasz
Speeedfire #12316 üzenetére
Nem gondoltam volna, hogy meg fogja zavarni a nyugalmadat, hogy a te problémádon "lovagolnak".........
Hát bocs már, hogy témázunk azon, hogyan néz ki normálisan a függvény, amiről beszélsz.
"hogy a drupal adatbázist át tudjam rakni a sajátomba"
Ehhez miért kell, hogy csinálod? Csak kíváncsiságból. -
Sk8erPeter
nagyúr
válasz
Sk8erPeter #12307 üzenetére
Ja, a kulcsot az előbb nem tudom, miért mondtam, hogy csekkolni kell, mivel itt értéket nézünk.
Na jó, akkor már legyen meg teljesen:function count_repeat_values($needle, $haystack){
if(!is_array($haystack)){
trigger_error('Invalid 2nd parameter passed to count_repeat_values().', E_USER_WARNING);
return FALSE;
}
$number_of_instances = 0;
foreach($haystack as $value){
if($value === $needle){
$number_of_instances++;
}
}
return $number_of_instances;
} -
Sk8erPeter
nagyúr
válasz
Speeedfire #12299 üzenetére
Hát ez nem egy túl bonyolult függvény.
Nem ártana bele valami hibaellenőrzés, hogy a kulcs int vagy string, a második meg egyáltalán tömb-e.
Meg azt sem értem, minek ezt tömbbe pakolni, aztán nyomatni rá egy count()-ot...El lehetne intézni ennyivel, felesleges tömbbe gyűjtés helyett:
function count_repeat_values($needle, $haystack){
$x = count($haystack);
$number_of_instances = 0;
for($i = 0; $i < $x; $i++){
if($haystack[$i] == $needle){
$number_of_instances++;
}
}
return $number_of_instances;
}beépített függvény ilyen van:
array_count_values()$array = array('valami', 'valami', 'valami', 'ketto', 'harom', 'ketto');
$array_count_values = array_count_values($array);
var_export($array_count_values['valami']); // output: 3
var_export($array_count_values['ketto']); // output: 2Szerk.: megelőztek, Soak is ezt a függvényt linkelte pont.
-
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12290 üzenetére
Jaja.
OK, akkor sorry a félreértésért.
===================================
(#12287) Kommy :
de végül hogy oldottad meg? -
Sk8erPeter
nagyúr
válasz
Speeedfire #12281 üzenetére
Nekem abszolúte nem para
Amiatt szóltam amúgy, mert úgy tűnt, a Drupalt okolod (valszeg csak félreérthető volt), hogy spammelték az oldaladat, amiről azóta úgy néz ki, kiderült, hogy nem, csak nehogy valakit ez elijesszen esetleg a Drupaltól, hogy töredékinfóból azt hiszik, hogy rossz választás lehet, pedig nem.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12278 üzenetére
Hát, kár, hogy egy modul telepítésére nem voltál hajlandó klikk-klikk-kész módszerrel, amivel egész hatékonyan szűrhetők lettek volna, pedig ajánlottam az előbb linkelt topicban is, plusz még privátban is elküldtem neked, dehát nyilván sokkal egyszerűbb a Drupalra fogni az egészet, és nyilván egyszerűbb egy totál új oldalt fejleszteni emiatt.
Dehát a Te dolgod, sok sikert hozzá.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12268 üzenetére
Azt hiszed, attól a kici kínai jómunkászemberek munkája meg fog szűnni, hogy átköltözteted másik oldalra?
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12249 üzenetére
És Notepad++ milyen karakterkódolást mutat a dokumentumra?
-
Sk8erPeter
nagyúr
válasz
Dave-11 #12247 üzenetére
Általában nem szoktam közvetlenül adatbázisban kotorászni, egy működő webalkalmazásnál nem is túl egészséges, csak NAGYON kényszermegoldás, végső esetben, egyébként elvileg tilos. Egyébként ha tudod, hogy mit csinálsz, és jól is csinálod, nem történik tragédia, de inkább írd meg úgy (vagy használd úgy) a webalkalmazásodat, hogy ne kelljen belekotorni közvetlenül az adatbázisba.
A tábla karakterkódolásánál én utf8_hungarian_ci-t szoktam asszem választani. -
Sk8erPeter
nagyúr
válasz
Dave-11 #12245 üzenetére
A leírásodból nem épp az derül ki, hogy nem volt gond a karakterkódolással.
Ha választasz egy karakterkódolást, akkor MINDENHOL azt használd. Tehát mindenhol UTF-8-at használj, a fájljaid is UTF-8-kódolásúak legyenek, az adatbázis-kapcsolat is, header()-rel is küldj ki UTF-8-at, és a meta tagek közt is ezt a karakterkódolást add meg. -
Sk8erPeter
nagyúr
válasz
Dave-11 #12239 üzenetére
"Megpróbáltam a dolgot ismét, és oda jutottam, hogy nem kellenek ezek az átalakítások meg kapcsolódáskor a SET NAMES dolog."
Miből jutottál erre a konklúzióra?
Ha nem vágod a dolgot, akkor szerintem ne kérdőjelezd meg a hasznosságát.
Biztos nem annyira nagy baromság, ha nagy CMS-ek is (mint pl. a Drupal), meg frameworkok is használják. -
Sk8erPeter
nagyúr
válasz
kkdesign #12238 üzenetére
Már írták korábban, de még mindig nem szedted ki a mysqli_close($dbc) sort.
Nem érdemes lezárni, mert mint látható, úgyis használni fogod az oldal betöltése során az adatbázis-kapcsolatot, és a betöltés végén úgyis záródni fog a kapcsolat magától. Vagy ha nagyon ragaszkodsz a kapcsolat lezárásához, akkor legalább az összes adatbázis-kapcsolódás UTÁN zárd csak le...a session_start()-ot pedig szintén írták már, hogy hova tedd, de úgy tűnik, nem igazán vetted figyelembe.
Csak szemléltetésként, van a kimenetedben ez a rész:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">mindenképpen még ennek a kiíratása előtt legyen a session_start(), csak egy példa:
<?php
session_start();
// ITT JÖN MINDENFÉLE EGYÉB KÓD!!!!!!!!!!!!
// ..............
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
.....mint látható, a legelején van a session indítása.
A lényeg, hogy először szedd ki a mysqli_close()-t, és mindenféle ilyen bezárási kísérletet, és majd csak utána próbálkozz.
Meg a session_start()-ot tedd a legeslegelejére, és ne akard újból meghívni a session_start()-ot, ha már egyszer megtetted. -
Sk8erPeter
nagyúr
válasz
lezso6 #12206 üzenetére
12342468
nem ez? tegnap, 11-e délelőtt 10 óra óta nem aludtam egy percet sem, szóval lehet, hogy hülyeség
De a referencia miatt ez ugrana be elsőre. Nem futtattam le, ahhoz már nincs energiám, inkább eltakarodok lassan aludni.
szerk.: na jó, nem bírtam a véremmel, lefuttattam, mert rájöttem, hogy ahhoz nem kell sok energia.
Majd kommentálom, ha páran még megnézték. -
Sk8erPeter
nagyúr
És ennek mi lenne a lényege?
itt van egy példa, itt tesztelheted:
http://preg_replace.onlinephpfunctions.com/minta:
/data:image\/(jpeg|jpg|png|gif|bmp);base64,/kód:
$pattern = '/data:image\\/(jpeg|jpg|png|gif|bmp);base64,/';
$replacement = '';
$subject = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAUUAAAEyCAYAAABtU8IkAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9kLDAkfAXFvbGkAACAASURBVHja7L1pjLRdeh50nXOepaq73+/7Zsafx7GCnR9ICJIIsciISBECQZzEa2awx4sAy2Ds8Sz2OPxACigRP5ATLE88tuPxgmI7Nt7HIzKOAQsF4gghEIsIiCUoDrHjxJOZb3nf7q56lnMOP6ru+q666zzVVd1P11tVfW6p1d21PMt5zrnOvV43kCVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsjwF+QoAvw7gcwA8gBsA/yeAH89Dk+XIJKqfLFlGl29PTDT5+V/z8GTJoJjlqcn/tQUUfyoPT5YMilmemrRqkv1JACWA1wC8Nw9PlgyKWU5FzIiT7DGOmyXLY4Finq9ZkmJH2nG37cRaXgPw7wH4GwDeANAvf/8mgO8B8GyPHf49AD4D4BaLAM+PJr7zVVgEgORc/xDArwD4lxOf/Tp1/J8YuI6fUJ/7ugee9yH395TlnwTwYwD+9nKMegCfB/DfA/gzd8ylXWTMuQoAXwbglwB8dmld/R0A3wfg3Xdcx33mUpYjMUPiHabJVy4nxLbP/y6Af2nH8/1V9f//RJ91AH7yjnN9XB3/AsA1vf+/D1zH/0GfuVl+7yHnvc/9PXX5agDzO8b5bwP4ffc0n8eeq9+NRVbG0HWmgPEhcynLCYDin1jucrt8Zz4w2bZ95wWA/4g++xd2PNe/r87x8/ReAPBqQnsI9JlfVO/f97z73t9Tli8G8PaO4/zj9wDFx56rqZ/vTRzjIXMpy5GBo5ZXlio/f+bXAPxhAPXy968nduFnd5xnDuDrAUzU5/4JBVy/B+BfBVAB+KMAfofeu8V6MOh96hx/TB37y7eYzg857z73d3x+GGt3WvzOudXfy+/cR76Xjvk/A/insQjsfQmAX0hoYfvM18eaqx2A7wRwCeAfB/A/qPf/1ohzOMsJgOLH1Pu/uTQNWAoA/5363J++4zxDpsP3qc99o3r/a9T730PvTQA8p/f+rPrun9tiOj/kvPvc38HBriiKJLANAd5dP8aYh0SA/1/63j+r3vsSddybPefrY81VreX/0YQlgBHnUpYjB8W/qd7/ioHjfJX63N+84zz/ysBx/kf1Oe1XukpoAiw/S+/9F+q9/5Le+6WRz7vr/R30eQogMpAJWMprCZC7ExAT2uUoOK6OGfacr481V/+gev9d6n0/8lzKcuSgqP0/7xk4zheoz715x3m+dOA4b+zpz/mtLbvwm3gnZcMAeIve+/qRz7vr/Y0uZVluAFZd14NAxiC4DyBqMJTvkpZ5H/l9WARevhfA/7bDfNz2/mPN1VcS2ua263joXMpy5KCondZu4Dh6ovR7TjSRbs8Jdau+X6vF8YeXr/9B9Z3Lkc+76/2NZhqzWTwEevKZlCmt39tFQggxhJAE3OXfu8h7APzHAP4f7JcBcdd8fay56va8jofOpSxHDoqf33H3fV197vN3nKcYOM7zPSdUysT66YQ/6KP02i8/wnl3vb8HPysCoA1NTwDOObd6L4QQY4xrn3XOxa7rYowx9n2/FyDK3ylTegdg/FIAfx/rQYxfwyLt5Z96ICg+1lzdd92MMYeznKFP8b+5x0RDwoS6j8b1FfT9v7M0nf9beu0Dj3Dex/CxDZq3AkQMSPyaAJcW+ax+z3sfd5UUyAKIBpPF33br/X9a3cu/Ru9VDwTFQ87VbZ8ZYw5nOWJQ/A9wd0TPYTOi95F7gsYPq8990z3uqVr6ieQYH7rDdB7jvGOA4oZJnNIAMRBM0QDHGiD/rQFwH01Rf4dNaaCMQBELN43ANJbutf8FwJ8L8R/9C/P4t15b3uMLdf1XdP9f9kBQPORc3faZMeZwliMGxfcmzIHPAPhDS/D5QwD+mnr/72E93WUf0Pjn1OfeAPB+LNJt3g3gPwTwd7GoFvgWAH9g4Dh/WZlo8vevPNJ5HwKKg/5A1v60Zuaci977NYDSAMYA6L1fez2EsHo/pVUOAWNKq1xcm42uWGiKtliCuaneBOxfNwY/+W0WF1ik2fB9/IXlGP/zSDM2TfYY50PO1W2fGWsOZzlSUMRypwt7OI3/xQdqUv/pHv6YTw8c448PfP4bHum8e4HitrxAY0zSLJb3tDBI9X2/8hUyAA5pjftoiho8GWT7vl8AdYEIg1iUcj9FLIpqaV6XvwHgN/b0t33JnuN8qLl612fGmMNZjhgUgUX1x+fueLi/DeCPjGBeTpbBkLsm03+NzVI+kSLheJ8pc23M8269vyIBcBoINVCKdjikqXVdN6jh8edSpjMHTfb1KXrvY9u2ie/6pTldRIMqAuUCEA2iWYIl7OTDWK9R16kpf/YO03OXeXSIuXrXZ8aYw1mOHBSxfHjfDeCvLwHHY5H795vL169G9rl9FYBfxaIUqwfQAPj/libw+3A3bdSPq3N+6hHPu3l/5ioWJaJDEY3ZDJpIfqEGRw1AGtwYwBj8+LcGPfmu1gr3AcMhgHznHG2MsYsxtrHrb6OxiICNQBkNLhaaJKbRAd+6BIx/tBzf3wLw57GoTf8Dakz+xj3n0WPP1V2v46FzOEuW45Aalwbl9M4JG/7vHzZ/BLiAm/wzBvYzr37Zn3nL1RceKCOKOjoglkBEwmeo/YgxxpUGJqCW8hemAEn+ns/nG6axHIu1RG367gOA8r3ZbJbURPs+rDRHa+U+bZzAREwQK1xFmOKvoMAFUGRQyDKa5Ml0RFIAsQJwezHF5HaGYCZoyzmq1iIioHNXgL9ePDizeHQxRsQY4b2Hcw4xRhhjVv+LeO9hrV19x1qLEMLqtRVA02sxRoQQ4Jxbe12OZYzBIkPnneu506RYXl8Ii7Q6a+3qWteuOS5mZwg9jDGwtlicMzj4IgDewwHwMc/hLBkUz9L9IKAgIqAlIu8bY9D3Pay16PseRVGsgc0YooFxNVkIbOW3BksG4nsPBt2L3GMIAUVRbFzP8v88j7NkUDwXMGTwE0BhcGSgYMDi36ypPRQYhzRF1ggZqOSzKa3zvoDIv/W9OudQliW6rtMbR57LWUYRm4fg5YAhFn7A1aKuqgre+zVALIoCXdetaUfa7LXWjqolynH7fmG2ilbIZq9op3xOMYNH2amXGiDfo9xzjBFd1620VAAoy1LGNEuWDIqnBIRVVa3AUPvj2rZd+s4WABBjRNM0G9qXmM7yN5vWo11ojCiKAk3TrGmwDFAhhDW/pmhxYwib4XKP4i4AgK7rVq4EY8wKJLNkyebzCQChLFz2D7IwoGkTmaVpGtR1vfG+vD6WtqgBjv2WAkpiOpdluQLwMbVVOVbqnvneB86X53SWrCkeMyAKyAiYyGKWBS2mqQCjRHb5tb7vUdf1mjYof9d1vTJ1xxIGarlmMZuLokDf92uAKFrjmOaz3DPfK5v3Xdclv5clS9YUj3GnsTayv6vrupW5zGYzm4BD5mNKixIA4NSYIQ3zPloa/04FOqy1aNt2MAr9ENkl0MNSluVKg83zOksGxWMbzCUPoAYU1nI4aMEgMASEHGBgH57WjsYCJTZf2XzmlBg+P4PVWCb0tpQgDvjIhiDjnFN0smTz+YikLMsoC1anxwiQiEajo7Zisgog8O8hcODzMHDuImyqa/NUwIXPL1FoMZf5+vh+xo6Ap+5Vn0OuSYFyjkRnyaD4ss1lnSYiYCP/i6m8CyBIOkpKI2TzVqLArCntAojOubWIrXNuLcrL2iDnIWpNjs85tl9ziza+dp0aMMcM+GTJoJjlntYmm8ZiYpZluUqzEeDZJRDBgJT6fMqE3EdLEyDk6hAdYRbNUMBZAF2ujfMHu65DURQoy3I0831fgGzbdm0T2VVjzpIlOa/yENxfiqKIrGGJNqVTVPYtf9OmswAPa4sMgrrueRdNUWt9fFxOyRkCmLZtUVXV2r2PVeZ3h5tipdVyzbd2SSzHMM/vLFlTPKSGyOYjm8n8f4xxwx93FyBqsoWyLFfRZj6G1iR3Ob6AZ9/3cM6tro19idbaNVcAm+p8TaKt6TLFx5T5fL7SdFmjlYDLPq6ELFmypjiCOOci5x6yZqIX430rPcSclZSbrutWWhkvfk5F0ZHuu4CRE8ZTkeuu61CWZTIVhn15rBUfQlPUpnNRFGjbdq38UF7v+z7P7ywZFB95IcZUAEKDIfvoUubwTmqoMoXbtsV0Ol0Blvj2dOrMLseV5Gt9HgY4Pq4kjutrYm1WQPSxhYFXtHApfZTxyOk5WTIoHhgQWdOSQMRdVFr7REV1SVsq8iyv3ReMBDiG8hwFdDXRg9YStwH5oYAxla6jxizP8ywZFEeWmDJRRSt5LDDYxxe5C8gymCSJXRXoMXjq13UwKZXwzefWY6RN7rFMb52ek+d5ln0lB1p2AMShXD2JuKYqTe59MkqOZkDc9djs75Tvc4meaH0CuBoQOcjD0WjWDrXmyGAkgJjyVer74fNzKd9Dx4/TjZbnzzk6WTIojjI4i054q8XNgMH5h2Nqi1zTnNJKd7zuVe6eviZO1OZgizFmBSa60kXuXd7j3Eh9XRoQeWzkOFVVwTmHuq5XxxjLHyk+U67CEfdHntFZsvn8QEDUlRucyqITmcc0ocWU5Ci0MWZFRLurtql9kKncRjm+pi1jINNgyP5TAc1UPbcO/sjx5vN5MrI9Zv02V75kdu4sGRRHUDhYCxKmmxTfoZTLPQYZgz7XLqAhIMdaozadNVhos5U1YwFk7ZccCiileA8FNHVep0SPxwZEHaCq63pFmLu8tjzvs2RQ3AeXGDAEEHXazZiLOCUcVeacwbu0UR2NZU5HHSTh6xfw07XX/L';
echo preg_replace($pattern, $replacement, $subject, -1 ); -
Sk8erPeter
nagyúr
Igen, nekem is ez rémlik, de hogy konkretizáljuk, itt mondtad egész pontosan ezt:
http://prohardver.hu/tema/php_kerdesek_2/hsz_12087-12087.html
most meg újdonságként állítja be -
Sk8erPeter
nagyúr
válasz
Speeedfire #12162 üzenetére
Csak olyan van, hogy array_merge().
-
Sk8erPeter
nagyúr
"A dinamikusan típusosság miatt nehéz használni a NuSoap-ot?"
Ezek szerint mégis elbeszélünk egymás mellett. Ki a francot érdekel a NuSOAP? Engem nem, mert nem erről beszéltem, nem a NuSOAP library fikázása volt a cél, már megint terelődik a téma egy halott irányba. Most tényleg el kell, hogy magyarázzam még többféleképpen is, hogy nem a library-vel magával van bajom, hanem azzal, hogy a típusosság hiánya miatt nem lehet egy ilyen tök felesleges időelb@szó munkát automatizálni ÚGY ÁLTALÁBAN PHP-ben, hogy pár klikkel ezt a részét megoldjam, és az ÉRDEMI programozási feladatokkal foglalkozzak?
"Azt is állítom, hogy a programozás leginkább feladatok, problémák megoldásáról szól, tehát elméleti viták helyett gyakorlati alkamazásokra kéne inkább fókuszálni, itt dől el, hogy mi jó és mi nem."
Ebben eddig is egyetértettünk, ennek kapcsán eddig is egy nyelvet beszéltünk. Igen, így van, de ez megint csak egy magasztos, tök általános jellegű állítás, a téma kapcsán nem visz sehova, ez már kezd szinte marketingszagú lenni.
IGEN, meg kell oldani egy feladatot. Szeretnél SOAP-ban kommunikálni? Kell hozzá egy WSDL. Nézzük meg ezt mondjuk C#-ban: Visual Studio megnyit, ide-oda klikk-klakk, és kész van a kódból a WSDL-generálás. Na, akkor most csináljuk meg ezt PHP-ben. Előveszünk egy library-t (hangsúlyozom, teljesen mindegy, melyiket), és elkezdjük tanulmányozni a doksiját, hogy vajon hogyan kell legeneráltatni vele egy WSDL-t úgy, hogy az működjön is; tanulmányozhatjuk ismét ennek megfelelően a saját kódunkat is, hogy megnézzük, hogy melyik metódus mit is ad vissza (ahelyett, hogy kódírás közben mondjuk a már legenerált WSDL-ből kapnánk hintet). Akkor most a doksiban olvasottak alapján kipróbáljuk, hogy vajon működik-e az, ahogy értelmeztük a dolog működését. Ób@sszameg, nem működik, akkor most mi a szar van? Debuggoljunk, vagy kezdjünk el korábbi kérdések után kutakodni a neten. Tök jó, máris egy csomó idő elment egy ilyen baromsággal.
Miből következik ez? A típustalanságból. Hiába kántálunk arról, hogy mi lehet a választás alapja igények szerint, mi mire jó, és hogyan is kell szépen kódolni. Tök mindegy a téma szempontjából. Kár, hogy nem lehet automatizálni ilyen jellegű feladatokat például PHP-ben.
Jó lenne azt érezni, hogy érted, miről beszélek.A magic methoddal kapcsolatos dolgokról meggyőztél, elfogadom az érveidet.
-
Sk8erPeter
nagyúr
"Csak ugye még mindig ott tartunk, hogy elméletileg mi mindent lehet megcsinálni egy nyelvvel/technológiával, nem pedig ott, hogy a gyakorlatban mire van szükség."
Egyáltalán nem értem, ez hogy jön az említett SOAP-os példához, ahol számít a típusosság, és számít olyan szempontból is, hogy mennyire lehet automatizálni az ebből történő WSDL-készítést, vagy mennyire nem."..akkor az azt jelenti, hogy belefutottál egy nem túl jó 3rd party lib-be. Gondolod, hogy más nyelveknél ez nem fordul elő?"
Már megint leegyszerűsíted a kérdést, és mintha szándékosan vezetnéd vakvágányra a témát. Nem sikerült megismernem a NuSOAP-nál sokkal értelmesebben megírt 3rd party library-t, a konkrét probléma megoldására. Igen, az mondjuk igaz, hogy komplex példákat nem nagyon említenek a hivatalos doksiban, ami mondjuk az ő f@szságuk. Egy library-hez mellékelt dokumentáció sokszor minősíti magát az egész library-t is. Ha szar a dokumentáció, lehet akármilyen faszán megírva a lib, nehéz vele mit kezdeni, és gáz, ha órák mennek el a source-ban lévő kommentek olvasgatásával. Mindegy, ez most csak a téma elterelődése megint, szóval ne erről beszéljünk. A NuSOAP-os parát így sikerült magamnak megoldani: http://stackoverflow.com/questions/6986350/generating-wsdl-with-nusoap-return-struct-with-various-types-int-string-arr
Nem értem, melyik részt nem érted abból, hogy ezzel tök felesleges munkaidő ment el, mert lehetetlen ilyesmi kódot legeneráltatni egy IDE-vel PHP-t használva, mert nem lehet felismerni a típusokat. Tehát típustalanság = a példában szar.
Már elég sokadszor tereled a témát magasztos elvekre, hogy legyen átlátható a kód, és akkor király minden, de ez egyszerűen nem kapcsolódik a konkrét témához, amivel próbálom veled érzékeltetni, miért is tud problémás lenni a típustalanság. Tehát amiről beszélünk már jópár hsz. óta.
Mint látható, igény van rá, és hogy reagáljak arra, amit mondtál, igen, a gyakorlatban is van rá szükség. Vagy szerinted ha nem lett volna rá a gyakorlatban szükség, akkor töltök vele egy percet is, hogy ilyesmivel szopassam magam PHP-ben?
Kezd így kicsit fárasztó lenni a beszélgetés, hogy elbeszélünk egymás mellett.----
magic metódusok részre:
"Megint itt tartunk, hogy valaki Java-ban akar programozni PHP-ben"
Úgy tűnik, itt én értettem félre az eredeti témát, én a magic methods-ról beszéltem, ami szerintem igen csúnya:
http://php.net/manual/en/language.oop5.magic.php
bár tény, hogy végül is félreérthetetlenné teszi a dolgot, de nekem ennek kapcsán kicsit olyan érzésem van, mintha ez is egyfajta erőltetett megoldás lenne, mint sok másik.A függvény overloading (típusok szerint) mondjuk PHP-ben valóban értelmetlen, ezt el kell fogadni, ezzel egyetértek. Ebben az esetben mondjuk kerülő megoldásként például különböző nevű függvényt lehet definiálni, és a nevével egyértelművé tenni, hogy mi is a helyzet.
-
Sk8erPeter
nagyúr
Én nem gondolom úgy, hogy a típusosság kérdése irreleváns, rossz kérdés. Nagyon nem mindegy, hogy adott fejlesztőkörnyezettel, kiegészítő eszközökkel milyen szinten tudsz akár automatizáltan is együttműködni a kódoddal. Tudom, hogy már sokat szoptam a SOAP-os, WSDL-generálós példámat, de megint elő kell hoznom, mint egy kritikus példát, ahol a típusosság kérdése nagyon nem irreleváns, hanem épp, hogy kritikus jelentőségű. Amikor olyan dolgokkal kell órákat elcseszned a drága idődből, hogy kitaláld, hogy vajon a PHP-alapú NuSOAP-library mit nem szeret a kódodból ahhoz, hogy mondjuk legeneráljon neked egy nyomorult WSDL-t, amivel már meg lehet kezdeni egy SOAP-alapú kommunikációt, és objektumok tömbjét és egyéb komplexebb típusú elemeket tudj vele előre deklarálni, akkor azokat rendkívül elvesztegetett fejlesztői munkaóráknak találom, nem hiszem, hogy normális fejlesztőnek WSDL-kódok debuggolásával kellene tökölnie. Mint említettem korábban, mindez például C#-ban (de akár Java-ban is) pár klikk egy megfelelő IDE-ben (Visual Studio, NetBeans, Eclipse, vagy egyéb), nagyjából 10 perc alatt meg is vagy vele, normális teszteléssel együtt fél óra. Mindez részben annak köszönhető, hogy a típusok szigorúbb szabályokat adnak a kódnak, és a kiegészítő eszköz is képes ezek felismerésére (meg annak köszönhető, hogy mindezt már valakik elkészítették).
Mondom, ez csak egyetlen kiragadott példa a rengeteg lehetőség közül.
De az is sokat segíthet a debuggolásban, ha a figyelmetlen típuskutyulásokkal kapcsolatos hibák miatt a fejlesztőkörnyezet vagy a compiler még időben ugat, hogy valamit rosszul csináltál."Ez a fícsör a php-ban igazi kókányolás. Működik objektumokra és tömbökre, de nem működik primitív típusokra. (Így mi értelme az egésznek?)"
Jaja, ez teljesen igaz, hogy ez ilyen módon csak félmegoldás, annyit ér, mint halottnak a csók, ettől függetlenül legalább valami minimális megszorítást adhat a függvény várt argumentumaira. Sajnos sok ilyen következetlenség van a PHP-ban (ezért tákolmány).
===========
(#12141) modder :
"Vagy olvassak inkább arról, hogy milyen király php-ban a "magic metódusokkal" megoldott függvény túlterhelés, és egy 20 éves nyelvnél még mindig ilyen tákolmány megoldásokat kell alkalmazni?"
Brrr, ne is mondd, hányadék.
Amikor C++ után először kezdtem PHP-ben OOP-zni, először nem is értettem, hogy ez most csak ilyen vicces trükkös megoldás, amit kényszermegoldásként be lehet vetni, ha nagyon muszáj, nagyon őrülteknek, vagy pedig egy bevett szokás. Sajnos kiderült, hogy utóbbi.Amúgy már alig várom, hogy jöjjön egy troll megjegyzés valamelyikünknek címezve, hogy "hádefigyeljé' má, akkó anyádé' használsz PHP-t, köccccsööög??!"
-
Sk8erPeter
nagyúr
"Jelenleg pedig nem tetszik az a hozzáállása, hogy a visszafele kompatibilitást meg kell őrizni bármi áron. Szerintem a PHP6 egy reboot kellett volna legyen, ahol végre felülvizsgálják a korábbi tévedéseket, nem ez történt."
Na ezzel teljesen egyetértek.Amúgy nekem most nehéz eldöntenem az írásaid kapcsán, hogy a típusosság kérdésében melyik "oldalra" állsz, mintha a kettő között lennél, hogy jó is, meg nem is.
Mondjuk erre lehet mondani egy klisészerű mondatot, hogy "igénytől függ".
Sztem a korábban említettek miatt nem jó, hogy nem kell megadni a típust. Habár függvénydefinícióknál szerencsére PHP-kódokban is látni már olyat, hogy mondjuk
function tokmindegy(array $tomb){
...
}
tehát deklarálja, hogy itt tömböt fogunk várni. -
Sk8erPeter
nagyúr
válasz
Forza_JUVE #12136 üzenetére
Na, akkor örülök, szívesen!
(#12135) Sk8erPeter :
ehhez még annyit hozzátennék, hogy abban viszont igazad van, hogy jó nagy multidimenziós tömböket passzolgat sokszor a függvényeknek.Ennek mondjuk előnye, hogy csomó minden elérhető ezekből a fv.-ekből.
-
Sk8erPeter
nagyúr
válasz
modder #12132 üzenetére
Azért nehogy valakit ez elriasszon a Drupaltól, még ha vissza is vontad
:
"egy drupal oldalletöltés több száz megabyte memóriát igényel"
Ez nagyon nem igaz.Csak akkor, ha egy vagy több Drupal-modul kegyetlenül el van kúrva, mert rengeteg erőforrást igényel. Múltkor itt a topicban írogattam Drupallal kapcsolatban ilyen memóriazabálós problémáról, hogy állandóan kifogy belőle, és azóta kiderült, hogy konkrétan melyik modul hibáztatható érte (egy modul!), létre is hoztam róla a hivatalos oldalon egy issue-t, és mellékeltem egy félmegoldást:
http://drupal.org/node/1836264
Egyébként az a része igaz, hogy általában a CMS-ek nem éppen az erőforrás-spórolásról híresek, de ez az ára a nagyon nagy rugalmasságnak. Ettől függetlenül egyébként normális esetben maximum 10-20 MB-ot fogyaszt egy átlagos Drupal-oldal (szerk.: ha csak egy-két statikus oldal van az oldalon, akkor lószart sem fogyaszt, magyarul nincs 10 MB sem, itt most némi dinamizmusról beszélek, adatbázis-lekérésekről, stb.). Ami nagyon komplex, az persze simán felmehet 60 MB-ig is, de általában ez úgy igaz, ha sok-sok egymásba ágyazott táblázat van, vagy számtalan kitöltendő űrlapmező, admin-oldalon mindenféle kliensoldali szkript betöltődik, és sok egyéb legenerálandó elem van az oldalon. -
Sk8erPeter
nagyúr
válasz
Forza_JUVE #12131 üzenetére
Szívesen, igen, jól értetted.
Majd jelezz vissza, sikerült-e.
-
Sk8erPeter
nagyúr
válasz
Forza_JUVE #12129 üzenetére
"A flash önmagától is megteszi ezt, vagyis ha lefut, automatikusan ugrik az action scriptbe beírt html oldalra.
Viszont nem szeretném csak ezt a flasht tenni az index.html-re, és a korábbi index.html-t átnevezni/helyezni, mert akkor borul minden hivatkozás, menü, minden."
Szerintem ehhez nem kell PHP, ha a szervereden engedélyezve van a .htaccess használata, akkor legegyszerűbb lenne, ha bemásolnál a gyökérkönyvtárba egy .htaccess fájlt ezzel a tartalommal:# Set the default handler.
DirectoryIndex ezlegyenakezdolapom.html index.html index.phpés akkor innentől kezdve az ezlegyenakezdolapom.html lesz a kezdőlapod, ide berakhatod azt a bizonyos flash-es lejátszást, és az action scriptbe továbbra is beírhatod az index.html-t.
Szerk.: persze az ezlegyenakezdolapom.html-t arra nevezed át, amire csak szeretnéd, de akkor mindkét helyen.
-
Sk8erPeter
nagyúr
Használtam a 4-es PHP-t annak idején, amikor elkezdtem tanulni, sőt, első könyvem a hogyan tanuljunk blabla sorozatból erre a verzióra vonatkozott. De ez miért számít?
"ha egy átlagos típusos nyelv lett volna a kezdetektől akkor lehet nem jut el idáig"
De mi számít "átlagos típusos nyelvnek"?"Amugy mióta fejleszti közösség a PHP-t? Ez azért nem Drupal."
Nem azt írtam, hogy Drupal-szerűen fejlesztik, de egyébként a Drupalnál sem úgy működik, hogy valaki fogja, és csak úgy felülír egy modult...az elég gáz lenne. Egy modulfejlesztésbe is be kell kapcsolódni, felvesznek maintainerek közé, stb. Persze saját tákolt modulokat büntetlenül lehet publikálni, sajnos futottam már bele olyan modulba, aminek a kódjától majdnem elhánytam magam.
Azt írtam, hogy a PHP mögött óriási közösség áll, így sok helyről érkezhetnek bug reportok, javaslatok a megoldásra, stb.
Egyébként a PHP open source, azért azt vágod, remélem.Az tény, hogy a PHP 5 számtalan újítást hozott, de ebben szerintem mindannyian egyetértünk, ez nem is volt vitatéma.
Amúgy lehet, hogy a típustalanság volt valóban az oka, amiért elkezdett rohamosan terjedni, de sztem ez önmagában kevés lett volna.==============
(#12123) Speeedfire :
"Az hogy valaki nem írja a funkció elé, hogy miket vár és mi a visszatérési érték a későbbi kód újrahasznosítás miatt megértem. Én is ki szoktam kommentezni előtte és leírom szépen. De ez ettől még nem gányolás."
Nem tom, most lehet, hogy itt elbeszélünk egymás mellett.
Amit én mondtam, hogy a típustalanság az egyszerűségével együtt nagyon káros lehet, jó kis teret ad a wanna-be-developereknek a gányolásokra, meg ezerszer nehezebb a kódokat debuggolni is, ráadásul a kódból nehéz automatizáltan kihozni valamit, erre még párszáz hsz.-szel korábban említettem a SOAP-os szívást, ahol számítanak a típusok, és milyen jó lenne, ha WSDL-t egy kattintással lehetne gyártani egy PHP-kódból is, ahogy akár C#-nál. -
Sk8erPeter
nagyúr
"Attól népszerű, mert egy könnyen tanulható, nagyon megengedő szabályokkal ellátott szkriptnyelv."
Lényegében én is ezt írtam, csak kicsit hosszabban kifejtve. De gondolom továbbolvastad.
Igen, végül is ennek része lehet az is, hogy nem kap az arcába a gányoló fejlesztő mindenféle hibákat, ha olyasmiket követ el, amikről eddig szó volt (ez a hátránya is a nyelvnek, ahogy arról már korábban beszéltünk)."egy részük annak köszönhető, hogy Rasmus Lerdorf nem értett a programozási nyelvek fejlesztéséhez, a másik részük meg annak, hogy a mai napig nem ért"
Korábban is írtad, hogy kvázi egy dilettáns majom, de miből gondolod ezt amúgy? (Csak kérdezem, nem tisztem megvédeni.)A phpsadness-t nem ismertem, de jónak tűnik.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12121 üzenetére
Nem, én nem hiszem, hogy csak a típustalanság miatt népszerű ennyire, én nem tudom, ezt honnan szeded.
Szerintem azért ilyen népszerű, mert gyorsan lehet benne fejleszteni, viszonylag egyszerű, óriási közösség áll mögötte, mérhetetlen mennyiségű tutorial, segédanyag, erre épülő fórum, sok-sok tapasztalat áll rendelkezésre (ergo könnyű segítséget találni hozzá), sok platformon nagyon gyorsan működésre lehet bírni, széleskörű a támogatottsága (keretrendszerek, library-k, CMS-ek, IDE-k, más nyelvekkel történő kommunikáció), és nem mellesleg ingyenes. Most még ráadásul nem is soroltam fel mindenféle érvet mellette, ami miatt népszerű lehet, ez csak az, ami hirtelen beugrik. Az előzőek miatt nagy a kereslet az ebben programozni tudó fejlesztőkre (magyarul munkát is kínál), és weboldalra mindig szükség van és lesz, viszont a megítélése éppen a könnyű gányolási lehetőségek miatt nem is túl jó általában, és ez némileg árnyalja a dolgot."De ha van pl egy function akkor miért baj az, ha nem mondom meg előre, hogy mit kell várni?
Nonszensz számomra."
Nem tudom, ezt hányféleképpen lehetne még elmagyarázni azontúl, amiket leírtam, és amiket modder előttem nagyon jól összefoglalt. Próbáld meg végiggondolni ezeket az érveket még egyszer. Ahogy Coyotnak is érdemes lenne. -
Sk8erPeter
nagyúr
Na nehogy már az jöjjön ki az egészből, hogy ti csináljátok jól, mert szétszarjátok a kódotokat, nekem meg túl nagy elvárásom van, hogy egy tömb az maradjon tömb, és ne legyen már hirtelen belőle integer...
"Tudom és értem miért kell okosan kódolni, de azért a php legnagyobb előnyéből ne csináljunk már hátrányt."
Szerinted komolyan az a legnagyobb előnye a PHP-nek, hogy egyetlen változóba beletömködhetsz BÁRMILYEN típusú elemet? Hát ez elég sajnálatos, ha így látod."nem szoktam gányolni"
Hát az előbb mondtad, hogy szoktál, sőt, kifejezetten szereted ugyanazt a változót felhasználni tömbre, objektumra, stringre, jó az vidékre!"engem nem zavar ha egy tömbbe stringet teszel"
Egy tömbbe nyugodtan kerülhet string, azzal nincs is baj, például
$en_tombom = array('valami');
tessék, van benne egy string, és ebben még semmi gányolás nincs.Mutatok példát, ami már a gányolás netovábbja:
$en_tombom = array('valami');
fuggvenyhivas_tombot_varok($en_tombom);
$en_tombom = 123;
fuggvenyhivas_integert_varok($en_tombom);
Valóban gyönyörű. -
Sk8erPeter
nagyúr
válasz
Speeedfire #12113 üzenetére
Dehogynem. PHP-ben egy változóba azt tolsz bele, amit akarsz, ami korábban egy integer volt, abba lazán belepakolhatsz egy objektumot, aztán felülbírálhatod stringgé, kreálhatsz belőle tömböt, tákolhatsz-gányolhatsz büntetés nélkül. Na, ilyet egy normális, típusos nyelvben nem tudsz megtenni.
De a validálós példád még mindig nem értem, hogy jött ide.
Szerk.: az első bekezdésben említett példával kapcsolatban a legnagyobb baj az, hogy sokan a PHP-fejlesztők közül ezt szégyentelenül meg is teszik.
És ezzel még pénzt is keresnek.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12111 üzenetére
Nem értem, mit akartál ezzel mondani. Hogy egy adott formelemre milyen validálási szabály vonatkozik, annak köze sincs ahhoz, hogy mindezt ne lehetne tökéletesen jól megcsinálni egy típusos nyelvben. Emiatt nem kell PHP-t használni (vagyis megfordítom: nem emiatt kell PHP-t használni).
Nem vágom, mire akartál kilyukadni.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #12109 üzenetére
"Nekem pl meg kifejezetten bejön, hogy nem kell megmondani, milyen adat megy be. Majd én azt a kódban eldöntöm, hogy jó vagy sem."
Az igen!.... jó programozási szokásaid vannak...
-
Sk8erPeter
nagyúr
válasz
Lacces #12106 üzenetére
Azt senki nem mondta, hogy ne lehetne attól még érdekes megoldásokkal találkozni ASP.NET-ben is...
(#12107) Speeedfire :
ha nem lenne használható, akkor ez a topic már rég döglött lenne, vagy meg sem született volna.
Használható, viszont sajnos megengedi a gányolást, és ez alapvetően káros, én jobban örülnék neki, ha sokkal szigorúbb és főleg típusos lenne. Tudom, akkor térjek át az ASP.NET-re. -
Sk8erPeter
nagyúr
válasz
Speeedfire #12096 üzenetére
Tudod, de mégis következetesen ASP-t írtál.
Na, majd tőle megtudjuk, miért vált. -
Sk8erPeter
nagyúr
válasz
Speeedfire #12091 üzenetére
Az ASP és az ASP.NET NEM ugyanaz. Itt bővebben: http://programmers.stackexchange.com/questions/44810/relationship-between-c-net-asp-asp-net-etc/44828#44828
(egyébként ezt írta Athlon64+ is, hogy "ASP-ről nem is volt szó")Én sem értem a váltás okát, egyetlen elfogadható magyarázat az lehet, hogy ingyenes környezetre akar váltani, mert egyébként teljesen értelmetlen.
-
Sk8erPeter
nagyúr
válasz
trisztan94 #12081 üzenetére
Csatlakoznék Athlon64+ kérdéséhez, ez engem is nagyon érdekelne.
A másik, ami foglalkoztat, hogy azt hogyan csináltad, hogy "nem találtam meg ezt a hivatalos dokumentációt" - most komolyan, a Google-ben milyen keresőszavakkal próbálkoztál, amikor a Yii framework kezelésével kapcsolatban kerestél? Beírtad, hogy kiskutya, és nem adta ki, hogy yiiframework.com? -
Sk8erPeter
nagyúr
Hát nem a "hol" a lényeg, hanem a "mit".
Arra gondoltam, hogy azért felelősséggel bíró melót (szenzitív adatok védelme) bevállalni elsőre, ujjgyakorlatnak szerintem kissé túlzás.
Kezdésnek jó, ha az ember megtanul egy formot validálni, feldolgozni, adatokat bevinni az adatbázisba, stb. Aztán jöhet képfeltöltés, stb. Mondjuk első lépés eleve az, hogy az ember megtanulja dinamikusan kiíratni az adatokat, külső tényezőktől (pl. aktuális oldal lekérése) függően...A CMS-ek sem betörhetetlenek, sőt, de azért a piszkos meló nagy részét elintézik helyetted, kattintgatós módszerrel (is).
-
Sk8erPeter
nagyúr
Nem tudom, a "theme szinten átalakítani" alatt mire gondoltál, mindenesetre nem szabad belehekkelni a core-ba, létre kell hoznod egy saját "alsminket" pl. a Zenből, aztán úgy szépítgeted, ahogy akarod. Vagy vannak jó kész sminkek is, hogy még egyszerűbb legyen.
Jaja, pár modul telepítésével, meg hosszú beletanulási idővel megoldható.
Ne arra számíts, hogy 2 perc alatt megoldod, de ilyesmire szerintem kezdőként nem érdemes elölről belevágni (pontosabban NEM ilyesmivel kell kezdeni, ahol szenzitív adatok múlhatnak a programozási tudásodon).
Van Drupal topic, ajánlom még a drupal.hu-t, meg a Drupal Answers-t.Már ha ez lesz a szíved választottja.
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
sztanozs #12043 üzenetére
Na, itt említették, eddig ezt nem is ismertem:
http://www.iis-aid.com/
IIS+PHP gyors összehozásához ez elég jó lehet.
Bár a Web Platform Installeren keresztül sem túl nehéz. -
Sk8erPeter
nagyúr
válasz
SektorFlop #12036 üzenetére
$row_count['count(date)']
Uhh, hát ilyen helyett inkább adj egy aliast a meződnek:
SELECT COUNT(date) AS date_count FROM....
vagy ilyesmi. -
Sk8erPeter
nagyúr
válasz
Peter Kiss #11865 üzenetére
Nekem még nem volt időm meghallgatni vagy egyáltalán huzamosabban belehallgatni, de hátha elhangzanak érdekes információk ebben a beszélgetésben a korábbi téma kapcsán, amikor arról beszéltünk, hogy mennyire jó vagy mennyire nem PHP-ben is erőltetni a Java-szerű vonalat:
Ha valaki esetleg meghallgatja, nagyon röviden leírhatná a konzekvenciákat, hogy mit hoznak ki a dologból.
-
Sk8erPeter
nagyúr
dehogyis
Ennél jóval egyszerűbb, egyszerűen elosztod a darabszámot a csomagegységgel, aztán ceil()-lel felkerekíted, majd beszorzod a csomagegységgel ezt a számot, az lesz a korrigált darabszám.Például én 34-et tettem be a kosárba, a csomagegység nálatok meg 12, tehát akkor a legközelebbi felfelé kerekített, csomagegységnek megfelelő darabszám a 36 lenne. Ez így ki is jön:
$package_unit = 12;
$pieces_in_cart = 34;
$pieces_corrected = $package_unit * ceil($pieces_in_cart/$package_unit);A $pieces_corrected értéke tehát 36 lesz.
-
Sk8erPeter
nagyúr
válasz
Brown ügynök #12024 üzenetére
Na, hát az is valami.
-
-
Sk8erPeter
nagyúr
válasz
Brown ügynök #12015 üzenetére
pedig ez a "másodjára azonban már nem tudok behúzni semmilyen fájlt ugyanabból a könyvtárból" nem túl beszédes, mert most nem tudjuk, hogy a require_once-nál mi a baj, az elérési út a gáz vagy jogosultságok vagy egyéb... localhostra nem tudod ugyanezt tükrözni?
az éles szerveren egyébként nincs semmi logolás a hibáknak?
-
Sk8erPeter
nagyúr
válasz
Vision #12006 üzenetére
Nem ártana, ha az UFT-8 helyett UTF-8 lenne használva.
Mondjuk ettől még gondolom nem ez a para. Az a baj, hogy eléggé általánosságokat írsz, szóval nehéz kitalálni, most mi a pálya. Végül is most akkor a $result objektumodban mi van? Azt írtad, valamiért htmlentities-zel nálad üres string jön vissza, pedig az nem túl normális, de lehet, hogy korábban rossz sorrendet mutattam, már nem emlékszem
szóval próbáld meg megint kiíratni (vagy fájlba, mindegy):echo ' <pre>', htmlentities(var_export($result, TRUE)), '</pre>';
erre mit kapsz eredményül?
-
Sk8erPeter
nagyúr
válasz
Vision #12000 üzenetére
(#11999) Tapsi :
ha már rákérdezel fórumon, segítséget is kapsz, akkor illik azt is megírni, hogy végül mivel oldottad meg.Amúgy igazából nem értem, miért jó ez így neked, hogy XML-ben adod vissza a választ, ha már meglenne a módszer arra is, hogy szépen objektumokban és/vagy tömbökben kapd meg a választ, ami könnyen kezelhető...
így csak raksz egy tök felesleges overheadet az egészre. Mármint a kliensoldalra, a szerveroldalon nálad nem tudom, mi a helyzet (pl. miért így XML-ben kell visszaadnod). -
Sk8erPeter
nagyúr
válasz
Vision #11991 üzenetére
Lehet, hogy félreértelek: most az a kérdés, hogy a $result object elemeit hogyan tudod kiíratni/felhasználni fájlbaírásra?
Ha a $result->GetCikkekKeszletenResult->any-t kiíratod, akkor nem a várt eredményeket kapod? Mondjuk ahogy elnézem, XML-formában kéne várnod, azt meg parse-olni kell.
De amit írtál, tehát ez.
[any] => 3Túl sok kérés )
azért van ilyen formában, mert gondolom böngészővel kiírattad, az meg nem mutatta a <valasz>, <hiba>, <kod>, <leiras> tageket, mert megpróbálta parse-olni, tehát mindezt htmlentities()-zel és <pre> taggel írasd ki, ha meg akarod nézni, ténylegesen mi van benne.
Sőt, inkább var_export()-tal, az értelmesebb kimenetet ad, mint a print_r().Valahogy így:
echo ' <pre>', var_export(htmlentities($result), TRUE), '</pre>';
(a vessző itt most szándékos, felesleges konkatenálni)
-
Sk8erPeter
nagyúr
válasz
bobace #11976 üzenetére
Hát szerintem a "check_mysql" mindent kifejez, csak azt nem, hogy egy lekérdezés eredményét fogjuk megvizsgálni, és mindezt logolni vagy kivágni a képernyőre, ha mondjuk a fejlesztői módon engedélyezve van.
Ilyen névnél egy jó hosszú függvénynév is szerencsésebb, még a check_result_of_query_and_log is jobb.(vagy mindez camelCase-ben; persze lehet simán checkQueryResult is, vagy mittomén, ízlés dolga, de legyen beszédes)
Egyébként a PDO-t már csak ezért is érdemes használni, mert para esetén képes kivételdobálásra, a kivételeket meg a megfelelő helyeken el lehet kapni, és logolni mindenféle hibát. Plusz saját exception osztályokat is lehet definiálni, amiben alapból benne van a logolás, és még lehetne sorolni.cucka leírta az alapvető problémát.
De a #11977-ben írt okfejtésedben nem látom azt az esetet, ha épp csak másfél kifizetetlen számlányi összeg érkezik be. Ha nem akarsz nagyon átalakítgatni, akkor ezt valahol jelezned kéne, hogy egy adott számla végösszegének hányad része érkezett be eddig, azt' csókolom (mondjuk ezt írtam már korábban is). De tényleg a megrendelőnek kéne felvetned ezt a problémát, hogy na most akkor hogy legyen az elszámolás, nehogy aztán az legyen, hogy dehát ez nem is úgy működik, ahogy én gondoltam (tipikus ilyen rejtett elgondolás a megrendelő részéről, amikor azt hiszi, hogy amit ő gondol, az triviális másnak is, és nyilván ő is úgy gondolta, nincs is más lehetőség).
-
Sk8erPeter
nagyúr
válasz
bobace #11974 üzenetére
Hát reméltem, hogy ez okozza a legkisebb problémát, amikor pluszban van. De attól még a korábban felvetett probléma létezik, szóval a tartozásából kéne levonni annyit, amennyit kiegyenlített, vagy az az arányos megoldás, amit írtam, ha nem szeretnéd nagyon átvariálni, na az úgy pl. nem túl nehéz.
Ha nem megy a dolog végiggondolása kódolás során, akkor az egészet írd le egy papírra, hogy számolnád ki (ez attól még nem lesz amatőr, sőt, segít a gondolkodásban), gondold át úgy, hogy jó lesz-e, a gondolatmenetből kódot csinálni már talán a kisebb probléma, először jól kell megtervezni.
Egyébként ha már valami "rendszer" van az egész körül, akkor nem ártana azzal együttműködve megírni a kódot, gondolom akkor van valami objektumorientált módja az adatbázis-kezelésnek is (ha már ez a check_mysql() nevű, látszólag nem túl értelmes metódus is van [legalábbis a neve semmiképp sem értelmes, mert nem lehet belőle kitalálni, mit csekkol]).van ez:
while ($row = mysql_fetch_assoc($res2))
szóval a $row['id'] nyilván itt a ciklus következő lépésében fog változni.
Nálad ezen a cikluson belül van még egy másik ciklus, amivel megint egy másik query-t akarsz lefuttatni, de valamit nagyon rosszul csinálsz. -
Sk8erPeter
nagyúr
válasz
bobace #11967 üzenetére
Hogy ellenőrzi a szintaktikát, miután már rég lefutott?
Egyáltalán mivel ellenőrzöd? És mi ez a mágikus $system osztály?
A #11965-ben küldött kód attól még ugyanaz, és továbbra is áll, amiket mondtam, hogy a $row['id'] nem változik, satöbbi.
Meg cucka felvetése is jogos, hogy így még mindig nem oldottad meg a feladatot. Legfeljebb a beérkező összegtől függően valamiféle arányt tudnál a kifizetetlen összegekre beállítani, hogy mondjuk a következő kifizetetlen számlának csak a 25%-a van rendezve, a maradék még hátravan, vagy ilyesmi. Mármint a jelenlegi rendszerhez igazodva, ha csak plusz egy mezővel kell kiegészíteni - vagy a paid mezőt átalakítani úgy, hogy csak akkor 1.00, ha teljesen ki van fizetve, addig meg mondjuk decimal number, például 0.25. -
Sk8erPeter
nagyúr
válasz
bobace #11963 üzenetére
Egyrészt nem is futtatod a query-t a while-on belül, másrészt mivel itt nem változik a $row['id'], ezért lényegében többször csinálod pontosan ugyanazt, ugyanannál a sornál, vagyis állítod 1-re a paidet, egészen addig, amíg nagyobb az $avabal, mint a $row['amount']. Szóval ez még erősen átgondolásra szorul.
-
Sk8erPeter
nagyúr
Na, csak most volt lelkierőm elolvasni.
Szerintem ezek a problémák amúgy érdekesek, és egyáltalán nem OFF, szorosan kötődik a PHP-fejlesztéshez, még ha a másik oldalon nem is PHP-t használsz. Mondjuk engem akkor is érdekelne, ha köze nem lenne a PHP-hez, csak valami érdekes probléma.
Még arra kíváncsi lettem volna, a fejlesztéshez miért épp ezeket az eszközöket használtad, és igazából mi a végcélja a kliensednek, milyen jellegű kommunikációt szeretnél folytatni, miért oly fontos neked pont a session_id().
Szóval ezeket még le tudnád írni a kedvemért?
Sikerült megoldani azóta a problémákat? -
Sk8erPeter
nagyúr
válasz
Brown ügynök #11958 üzenetére
Arra pedig a DirectoryIndex-et nézd meg, milyen sorrend van beállítva a .htaccess-ben, vagy azon a szerveren mi a default.
Saját direktívával felülbírálhatod. -
Sk8erPeter
nagyúr
válasz
Speeedfire #11949 üzenetére
Én is tudok ilyen fejet küldeni, tessék:
.
Amúgy nagyon ügyes vagy, hogy te ilyeneket is tudsz. -
Sk8erPeter
nagyúr
válasz
Sk8erPeter #11946 üzenetére
*otthon : nem biztos, hogy otthon, mindenesetre saját gépen.
Szerk.: bocs a szemetelésért. -
Sk8erPeter
nagyúr
válasz
SektorFlop #11945 üzenetére
-
Sk8erPeter
nagyúr
Őőőő, itt most szerintem egy kicsit továbbmentél az elképzelésekben, mint kellett volna. Sima, otthoni felhasználású webszerverekről beszéltünk csupán, arról, hogy nem biztos, hogy Windows-on érdemes az Apache-ot erőltetni, amikor ott van a beépített IIS is, aminek ráadásul teljesen jól kezelhető grafikus felülete van, és tök felesleges az embernek szopatnia magát az Apache konfigbuzerálásával, ha nem muszáj.
Én legalábbis jobban szeretem az érdemi fejlesztésre fordítani az időmet, mint a szerverrel való szarakodásra.Tehát itt nem arról beszéltünk, hogy nagyvállalati környezetbe mi a jó, és úgy általában Windows vagy Linux, hanem hogy Windows-ra kinek min jó fejleszteni otthon.
-
Sk8erPeter
nagyúr
Mondd már meg, hogy a klienssel hogyan próbálod mindezt lekérni, mert ilyen titokzatos információkból nem lehet kitalálni... én sem értem, miért a szervert hibáztatod, miért nem előbb a saját alkalmazásodat, mielőtt megnéznéd valami normális programmal, hogy valóban nem érkezik-e meg az említett header...
Javaslom a böngésződ fejlesztőpanelének (F12, Ctrl+Shift+I) Network fülét.
Szóval milyen kóddal csekkolod mindezt?(#11923) mobal :
hát az osztott tárhely olyan, mint amikor regisztrálsz egy tárhelyet mondjuk a Tárhelyparknál, a Hostgatornál, GoDaddy-nél, és így tovább, és lesz egy saját tárhelyed, még sok-sok másik előfizető tárhelye mellett. Osztott a tárhely, tehát másokkal is kell osztozni az erőforrásokon, emiatt vezetnek be memória- és egyéb korlátokat.
Ha a saját szerveredet üzemelteted, akkor az nem osztott tárhely.
Gondolom annyira nem mondok vele meglepő dolgot, hogy a Facebook a saját szerverét használja, és nem regisztrált egy osztott tárhelyet.......(#11922) Speeedfire :
hát én szándékosan nem vittem el hitkérdés irányába, hogy márpedig fúj, Apache, mert attól még az Apache egy jó szerver, hogy kényelmetlen a konfigolása az IIS-hez képest...
Új hozzászólás Aktív témák
Hirdetés
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Motoros topic
- Luck Dragon: Asszociációs játék. :)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Viccrovat
- One otthoni szolgáltatások (TV, internet, telefon)
- Anime filmek és sorozatok
- The Crew sorozat
- Forrmell.enn
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
- SZÉP Lenovo ThinkPad P15 G2 Tervező Laptop -75% 15,6" i9-11950H 64/2TB RTX A4000 8GB UHD OLED
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 16GB/512GB FHD IPS
- Eladó Apple MacBook Pro 13" A1706 (Late 2017, Silver - EMC 3163)
- Amazfit GTR 2 Classic okosóra dobozában töltőkábellel
- Mac mini M1 chip 8 magos CPU-val, 8 magos GPU-val
- LG 65C2 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- 121 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Bomba ár! Lenovo ThinkBook 14s Yoga - i5-1135G7 I 16GB I 256SSD I 14" FHD Touch I Cam I W11 I Gari
- AKCIÓ! MSI B550 R7 5700X 32GB DDR4 512GB SSD RTX 3060Ti 8GB Rampage SHIVA MSI 650W
- BESZÁMÍTÁS! MSI B550 7 5800X 16GB DDR4 512GB SSD RTX 3070 8GB Rampage SHIVA Enermax 750W
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest