- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- Nvidia GPU-k jövője - amit tudni vélünk
- 3D nyomtatás
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- AMD Navi Radeon™ RX 5xxx sorozat
- Kormányok / autós szimulátorok topikja
- Apple MacBook
- Steam Deck
Új hozzászólás Aktív témák
-
#10200
Sk8erPeter
nagyúr
j0k3r!
#10191
Sk8erPeter
nagyúr
válasz
j0k3r!
#10191
üzenetére
"ja meg ugye erdemes lenne a camelCase nevkonvenciot kovetni"
Na, jó is, hogy nyitottad a témát, már akartam ebben a témában veletek eszmecserét folytatni.
A PHP beépített függvényei sem mindig konzekvensek, sokszor kevertek a névkonvenciók, de azért a legtöbb "globális" függvény neve következetesen underscore-ral ellátott, míg az objektumorientált kód (lásd PDO, DateTime class, stb.) metódusai a camelCase-konvenciót követik. Aztán a .NET-es konvenciókhoz hasonlóan lehet látni egy-két kódban Pascal case-t is, de ez a ritkább eset, már amennyire legalábbis én eddig észrevettem.Én általában inkább követem az eredeti szokásokat, tehát osztályon belüli metódusoknak én is camelCase-neveket adok, globális függvényeknek pedig underscore-ral ellátottat, de néha a mai napig belekavarodom, és van, hogy keverem a kettőt, aztán utólag persze javíthatom következetes névre. Bár általában törekszem az objektum-orientált kódra, van, amikor ezt mellőznöm kell, pl. a Drupal használatánál, ami egyelőre erősen procedurális (okok itt olvashatók, amúgy is érdekes cikk), és itt is az underscore használata a jellemző a függvényeknél.
Nálatok mi a bevett szokás?
Maradtok annál, hogy OOP-s jellegű kódolásnál camelCase, procedurális kódolásnál underscore, vagy következetesen ragaszkodtok az egyik konvencióhoz? -
#10198
Sk8erPeter
nagyúr
mobal
#10190
Sk8erPeter
nagyúr
Akkor is harmadik opció
: IIS+kattintgatós Web Platform Installer+MySQL+FastCGI PHP.
Totál felesleges Windows-ra rákényszeríteni az Apache-ot: lassabb, mint az IIS (ezen a platformon).===
(#10196) ArchElf :
"Ez a vállalatvezetők hitkérdése."
Meg gondolom anyagi kérdés is - ha valahol nincs pénz Windows-os liszenszekre, vagy másra szánják azt a pénzt inkább, akkor maradnak a Linuxnál.===
(#10193) Siriusb : a Windows-fika témája lejárt lemez.
-
#10189
Sk8erPeter
nagyúr
trisztan94
#10186
Sk8erPeter
nagyúr
válasz
trisztan94
#10186
üzenetére
Ha a PHP telepítve van, és működik, akkor ahhoz tartozik egy konfigurációs fájl is (php.ini), ott pedig be lehet állítani, csak meg kell keresni azt az adott fájlt.
Ha nagyon nincs kedved vele tökölni, akkor a fájlod elejére beteheted ezt:ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL | E_STRICT);=======
(#10188) mobal: neszóljábe!
-
#10183
Sk8erPeter
nagyúr
mobal
#10180
Sk8erPeter
nagyúr
Olvass vissza, #9911 környékén kezdődött a vita a Singletonokról.
Linkek esetén meg legfeljebb akkor szóltam be, ha a linken található tutorial gány megoldásokat mutatott be, nem szoktam ok nélkül pampogni, mindig megmagyarázom, ha valami baj van a linkelt cuccal. Legközelebb az indoklást is olvasd el, hátha átjön.
-
#10179
Sk8erPeter
nagyúr
mobal
#10177
Sk8erPeter
nagyúr
-
#10168
Sk8erPeter
nagyúr
trisztan94
#10167
Sk8erPeter
nagyúr
válasz
trisztan94
#10167
üzenetére
Beállítod valahol egyáltalán a $_COOKIE['user']-t?
Egyébként értelmesebb lenne akkor már $_SESSION-t használni (session_start()-tal). -
#10166
Sk8erPeter
nagyúr
papa019
#10161
Sk8erPeter
nagyúr
válasz
papa019
#10161
üzenetére
Bár asszem már ezt priviben megbeszéltük (már keverem a dolgokat, de mintha épp veled beszéltem volna erről), de az ilyen tákolt wrapperosztályok adatbázis-kapcsolódáshoz, query-khez már csak azért is feleslegesek, mert lényegében indokolatlanul felfedezed a spanyolviaszt, becsomagolod az alapvető műveleteket egy saját osztályba, de úgy, hogy pl. a MySQLi vagy PDO neked már eleve objektumorientált kezelhetőséget kínál, plusz kezeli azt az elképesztő sok hibalehetőséget (vagy legalább azok nagy részét), amikre Te csak hosszú évek kínszenvedései alapján jönnél rá (nem kevés ideje javítják ezeket az osztályokat is a PHP-ben).
Ahogy már javasolta fordfairlane is, én is azt tanácsolnám, hogy egyszerűen dobd ki ezt az osztályt, és térj át a PDO-ra vagy akár egy komoly ORM-re, és következetesen használd. -
#10155
Sk8erPeter
nagyúr
ArchElf
#10154
Sk8erPeter
nagyúr
válasz
ArchElf
#10154
üzenetére
Hatásos hivatkozási alap lesz a későbbiekre.
Amúgy szerkesztettem a hsz.-t az aposztrófról, lásd a hsz. végét.
"Egyébként a MySQL-nek semmi problémája nincs egy idézőjelbe rakott inttel INSERT-nél, lazán elfogadja, tehát nem az lesz a baj."
De még kiegészíteném:
nemcsak az idézőjelbe, de az aposztrófba rakott INT-tel sincs semmi baja. -
#10153
Sk8erPeter
nagyúr
papa019
#10149
Sk8erPeter
nagyúr
válasz
papa019
#10149
üzenetére
$result = mysql_query("SELECT id FROM categories WHERE name='$name'");
$DB->Query("INSERT INTO category_parent(did,parent) VALUES('$result','$category')");mysql_query() :
"For SELECT, SHOW, DESCRIBE, EXPLAIN and other statements returning resultset, mysql_query() returns a (I)resource(/I) on success, or FALSE on error."Te ezt az erőforrásazonosítót adod át közvetlenül.
Próbáld így:$result = mysql_query("SELECT id FROM categories WHERE name='$name'");
$row = mysql_fetch_object($result);
$DB->Query('INSERT INTO category_parent(did,parent) VALUES('.$row->id.',"'.$category.'")');Bár eleve a mysql_query()-jellegű függvényhívások meg a query-konkatenálások kerülendőek. Szerencsére már a hivatalos honlapon is írják.
========
(#10152) ArchElf :
ez jó, még nem láttam, qrva beteg. Egyébként a MySQL-nek semmi problémája nincs egy idézőjelbe rakott inttel INSERT-nél, lazán elfogadja, tehát nem az lesz a baj.
-
#10145
Sk8erPeter
nagyúr
Soak
#10144
Sk8erPeter
nagyúr
Szerintem senki nem fog tudni itt konkrét határokat húzni neked, a legjobb válasz erre megint az "attól függ".
Attól is függ, hogy elbírsz-e az 50000+ felhasználóddal, hogy milyen szerverek vannak a háttérben, mennyire erőforrás-kímélő a kód, stb.
Ettől függetlenül nyilván nem véletlen, hogy nagyobb projektekhez már azért a PHP-t legfeljebb vegyítve használják (lásd Facebook), a Stack Exchange családhoz tartozó oldalak (Stack Overflow, Super User, stb.) már ASP.NET-ben készülnek, stb.A Symfony meg azért jó, amiért jó általában egy keretrendszer, hogy egységesebbé teszi, szigorúbb szabályok közé szorítja, de egyben elősegíti és gyorsítja a kódolást.
"a php mellett nagy érv, hogy könnyű és gyors eredményt produkál, olcsón"
Ez igaz.
Ezzel együtt ez sajnos sokszor a minőség rovására is megy. (Lásd nagyszámú olcsó, csakis PHP-n nevelkedett, szűkebb látókörű, és/vagy fejlődni nem akaró munkaerő.) -
#10142
Sk8erPeter
nagyúr
lakisoft
#10140
Sk8erPeter
nagyúr
válasz
lakisoft
#10140
üzenetére
"Biztonsági kérdésekben mennyire jó a php?"
Szerintem nem túl jó a kérdés, a biztonsági tényezők számtalan dologtól függnek. A rendszered nagyjából annyira lesz biztonságos, amennyire azzá teszed, amennyire szűröd a rosszindulatú támadásokat (amennyire paranoiás vagy); de hiába tekinthető biztonsági szempontból viszonylag jónak az alkalmazásod, ha pl. a webszerver beállításai ilyen tekintetben rosszak.Ugyanígy a PHP-t sem biztos, hogy jó összehasonlítani a Java-val; ha igazán komoly rendszert akarsz, akkor mondjuk én személy szerint nem a PHP-hoz fordulnék.
De minden attól függ, hogy neked mik az igényeid, adottságaid, mit tudsz megfizetni, stb.
Teljesen biztonságos nyilván soha nem lesz egy rendszer, mert maga a biztonság csak egy cél, amit sosem lehet elérni, mégis törekedni kell rá.Egy PHP-alapú webshopot is lehet jó esetben viszonylag biztonságosan üzemeltetni, ha folyamatosan felrakod a biztonsági foltozásokat (amint kiderül, hogy van), stb., de ha open source webshopról van szó, akkor nyilván ismertek lehetnek a bugok, biztonsági lyukak is...
Nem egyszerű a kérdés, de az tény, hogy a Java (vagy C#, stb.) nem ad lehetőséget olyan szintű tákolásra és gányolásra, mint a PHP.
Ha van lehetőséged Java- vagy C#- vagy ehhez hasonló alapokon működtetni az oldaladat (tehát PHP-nál jóval komolyabb nyelveket tudsz alapul venni), akkor én inkább ezt az utat választanám a PHP helyett.
-
#10136
Sk8erPeter
nagyúr
cucka
#10135
Sk8erPeter
nagyúr
Ja igen, az ékezetes domainnevek jogos, azt tényleg nem szűri ki, ilyenre is lehet találni különböző megoldásféleségeket a kommentek közt php.neten: [link], mondjuk érdemes tudni, hogy ilyeneket is validnak tekinti: [link]. Szóval tényleg egy elég gyenge szűrő, esetleg még vegyíteni lehetne a parse_url() függvénnyel is, meg némi egyedi megoldással, és akkor talán már egy egész korrekt függvényt lehetne összehozni vele az ellenőrzésre. Mondjuk meglep, hogy nincs még erre beépített PHP-s függvény.
"Teljesen véletlenül alakult így, php fejlesztőnek vettek fel, első héten derült ki, hogy a szoftver, amin dolgozni kell, az bizony python-ban van írva, nem php-ban."
Érdekes kis tévedés a munkáltató részéről.
Na, a Pythonról speciel semmi véleményem és tapasztalatom sincs, milyennek találod így 1 év távlatából a PHP-val összehasonlítva (már ha van értelme ilyen jellegű összehasonlítást végezni)?====
"Fejlesztés során rengeteg potenciális hibát lehet kiszűrni, ha teljesen be van kapcsolva a hibák kijelzése - érdemes a szkript elején E_ALL-ra állítani."
Inkább E_ALL | E_STRICT-re PHP 5.4.0 alatt. Ezzel kiszűrhetők a deprecated függvényhasználatok is, stb. -
#10133
Sk8erPeter
nagyúr
fordfairlane
#10131
Sk8erPeter
nagyúr
válasz
fordfairlane
#10131
üzenetére
+1, akár tömbszerűen megadhatod az elvárt paramétereket, ha több is van.
-
#10130
Sk8erPeter
nagyúr
Soak
#10129
Sk8erPeter
nagyúr
Van. Például ha nem szoksz rá, hogy csekkold, akkor lehet, hogy olyan esetekben is elvárod egy adott tömbindex létezését, amikor tuti, hogy nem fog létezni, megpróbálod felhasználni az értékét, aztán nézel, hogy most mi a szarért nem működik a kódod. Aztán debuggolsz, rájössz, hogy ja, hát persze, mivel ott az az index nincs beállítva. És végül eljutsz oda, hogy csak kéne oda egy ellenőrzés.
Normális nyelvek esetén eleve sikítozik a fordító, nem is lehet ilyen gányolásokat csinálni, vagy kapsz egy buzinagy runtime exceptiont, stb., de a PHP az más. Az megengedi neked, hogy tákolgass.
Persze választhatod azt az utat is, amit sajnos sokan mások még javasolnak is, hogy elkezdesz gányolni: elrejted a hibákat, mintha egy strucc lennél, ami a homokba dugja a fejét, ha para van, aztán csodálkozol, ha közben elmar egy raptor. -
#10124
Sk8erPeter
nagyúr
cucka
#10122
Sk8erPeter
nagyúr
Ja igen, a relatív URL-ekben teljesen igazad van, az tényleg külön kezelést igényelne, most ezzel nem foglalkoztam.
De a nemzetközi domainekre miért ne menne?
Konkrétan mikre gondolsz?Azóta milyen nyelven fejlesztgetsz?
===
(#10123) RootRulez : már a kérdésedet sem értem. Miért vinne át másik oldalra? Ez a függvény csak vár egy paramétert, amiről eldönti, hogy valid URL vagy sem. (De mint cucka írta, egyébként relatív URL-eket nem kezel.) Szóval olyan, mintha valakinek feltennél egy eldöntendő kérdést, igennel vagy nemmel válaszol (jobb esetben nem kussol, és nem is beszél mellé
). -
#10112
Sk8erPeter
nagyúr
riska1982
#10108
Sk8erPeter
nagyúr
válasz
riska1982
#10108
üzenetére
"ehhez google api key kellene, amit már a földön nem lehet szerezni."
Ezt fejtsd már ki egy kicsit bővebben plíz, mert próbáltam rájönni, hogy mi az oka, hogy ezt írod, de nem sikerült.(#10106) cucka:
"A tippem, hogy a képernyőmentésed a B betűs nagy magyar torrentszájtról van"
Itt írta is, nem rejtegette: "Ilyen van a google keresőben is és a bithumen oldalon."
Amúgy miért szar?(#10105) mobal : cucka egy az egyben elmondta, amit gondolok, nehogy belekezdj egy WYSIWYG-editor írásába, totál haszontalan időtöltés, amikor ennyire jók vannak a piacon, mint pl. a CKEditor és a TinyMCE.
(#10110) Soak : ha rákeresel, tuti találsz egy fél órán belül ilyen plugint ingyé'.
-
#10101
Sk8erPeter
nagyúr
riska1982
#10100
Sk8erPeter
nagyúr
válasz
riska1982
#10100
üzenetére
Mindkettő adatbázisban keresgél, ennek a PHP-hoz nem sok köze van. A PHP-vel legfeljebb egy függvényt/metódust hívsz meg, ami ezt a keresgélést az adatbázisban elintézi (pl. MySQL LIKE). Összeveti a megadott keresési stringet az adatbázisban lévő tartalommal. Ha talált valami hasonló szót a megfelelő táblák adott mezőiben, kiadja.
-
#10092
Sk8erPeter
nagyúr
Soak
#10091
Sk8erPeter
nagyúr
Akkor megnyugodtam, azt hittem, csak nekem tűnik értelmetlennek.
Egy tanács: inkább add át az ilyen értékeket egy változónak, mielőtt komplexebb vizsgálatokat végeznél rajtuk, mert akkor nem kell állandóan lecsekkolni, hogy létezik-e a megadott indexen bármi.
Tehát így:
$id = isset($_GET['id']) ? $_GET['id'] : NULL;
VAGY
$id = isset($_GET['id']) ? $_GET['id'] : '';... és így tovább.
Utána mehet a vizsgálat:
switch($id){
case 'tökömtudja':
// ...
break;
case 'mittudomén':
// ...
break;
default:
break;
} -
#10089
Sk8erPeter
nagyúr
Sebaj Fóbiás
#10084
Sk8erPeter
nagyúr
válasz
Sebaj Fóbiás
#10084
üzenetére
Hát jó, és akkor a problémát megoldani nem akarod? Csak mert kódot nem mellékeltél végül
-
#10073
Sk8erPeter
nagyúr
CSorBA
#10072
Sk8erPeter
nagyúr
válasz
CSorBA
#10072
üzenetére
Na igen, többek közt ezért kell prepared statementeket használni, pl. PDO-val: [link]. Nagyon sok szempontból hasznos.
(pl. ronda query-összefűzögetések, SQL Injection-veszélyek kiszűrése szintén ronda mysql_real_escape_string() hívások helyett; plusz más adatbázisok támogatása, és így tovább) -
#10071
Sk8erPeter
nagyúr
CSorBA
#10068
Sk8erPeter
nagyúr
válasz
CSorBA
#10068
üzenetére
echo "<li id=\"blabla\">kiscica</li>";
escape-elgetések helyett inkább így:
echo '<li id="blabla">kiscica</li>';
Nem tom, hogy vagy vele, de számomra legalábbis az utóbbi áttekinthetőbb, plusz a PHP nem próbál keresgélni benne behelyettesítendő változókat (nem macskaköröm, hanem aposztróf). Nagyobb kódnál ennek lehet pozitív teljesítménybeli vonzata, még ha nem is olyan nagy a különbség. -
#10069
Sk8erPeter
nagyúr
Sebaj Fóbiás
#10064
Sk8erPeter
nagyúr
válasz
Sebaj Fóbiás
#10064
üzenetére
Nem csak úgy céltalan beszólásból és heccből írtam.
Ha komolyabb fejlesztési igényed lesz, akkor majd rájössz, hogy ez tényleg nagyon nem egy könnyen kezelhető és szép megoldás, mert nagyon sok macerával jár, nem lehet vele szépen felépíteni galériákat (vagy csak nagyon barmolósan), stb. Ráadásul adott esetben még egy adatbázis-kapcsolódással, adatlekéréssel járó kód is kevésbé erőforrás-igényes, mint komplett könyvtárak beolvastatása.
Ha a képek sorrendjét szeretnéd megváltoztatni, akkor ahhoz be kell olvasnod az egész könyvtár tartalmát, majd egy összehasonlító függvényt ráereszteni, és bizonyos szempontok szerint átrendezni egy tömböt, vagy pedig magában a fájlnevekben leszel kénytelen explicite megadni a sorrendet, nem nevezheted át tetszőlegesen a fájlt, sőt, ha mondjuk a fájlnévben szerepelteted a kategóriát, akkor azt minden egyes fájlnál meg kell tenni, ami adott kategóriába tartozik, és ha a kategóriád át szeretnéd utólag nevezni, akkor ügyelni kell rá, hogy minden egyes fájlt helyesen átnevezz; aztán hosszabb neveknél már probléma lehet maga a fájlhossz; nem tudsz tetszőleges hosszú, esetleg HTML markuppal kiegészített leírást mellékelni a fájlhoz; sőt, ami még rosszabb, állandóan figyelned kell rá, hogy ne kerülhessen rosszindulatú, vagy a programod/felületed megborítását eredményező karaktersorozat a fájlnevekbe. Ezek csak azok a szempontok, amik elsőre eszembe jutottak, de szerintem ezt a listát a végtelenségig lehetne bővíteni.
Hidd el, nem hülyeségből használ minden normális képmegjelenítő webalkalmazás adatbázist.No, de ha ragaszkodsz ehhez a megoldáshoz, akkor (máris találkoztál az első problémával
) a másik topicban is említettem, hogy szerintem nem jó, hogy kutyulod a karakterkódolásokat: egyszer ISO-8859-1, majd ISO-8859-2, majd UTF-8, én őszintén szólva nem tudom követni.
Válassz ki egy karakterkódolást, és ahhoz ragaszkodj konzekvensen, hogy ne legyen szükség konvertálgatásokra.
De az a baj, hogy nem látjuk a teljes kódodat, így nehéz megmondani, konkrétan hol a para.
Ha bemásolod, akkor tudunk érdemben is segíteni. -
#10061
Sk8erPeter
nagyúr
Sebaj Fóbiás
#10060
Sk8erPeter
nagyúr
válasz
Sebaj Fóbiás
#10060
üzenetére
"Remélem valaki felnyitja a szememet, baromi kényelmes lenne file-névbe rakni az infókat."
OK, te akartad.
1.) Ne használj ékezeteket fájlnévben, csak az angol ábécének megfelelő karaktereket használj (mint most saját bőrödön tapasztalod, problémáid lehetnek vele; de a példád csak egy a sok közül);
2.) ne tárolj infókat fájlnévben. Nem kényelmes megoldás, hanem ronda megoldás. A kényelmes az, ha rugalmasan és gyorsan, könyvtárak listázása, fájlok felolvasása nélkül fel tudod használni az adatokat.
Használj adatbázist ilyen célra.Ha htmlentities()-t használsz az ékezetes karakterekre is, akkor HTML-kódokká alakítja azokat, ami nem ugyanaz, mint maga az eredeti karakter, ergo problémáid lesznek az elérési utakkal.
-
#10059
Sk8erPeter
nagyúr
Siriusb
#10058
Sk8erPeter
nagyúr
válasz
Siriusb
#10058
üzenetére
Ajjaj, előre félek...
Akkor majd várlak a Drupal topicban, ahol jelenleg úgyis temetőhangulat van. -
#10057
Sk8erPeter
nagyúr
orkester
#10054
-
#10049
Sk8erPeter
nagyúr
orkester
#10048
Sk8erPeter
nagyúr
válasz
orkester
#10048
üzenetére
Pedig azzal kezdtem a hozzászólásomat, hogy leírtam, melyik foreach blokkon belülre kellene tenned.
Mutatok inkább komplett kódot a tiéd alapján, amiben definiálok egy my_var_export() függvényt, ami tesztelésre kiváló, hogy megnézd, mi az adott változó tartalma, és az adott változó milyen típusú. Nálam most az RSS feedet tartalmazó XML-fájl neve test.xml lesz.
A teszt kedvéért az XML-fájlt kiegészítettem a tiéden felül egy saját <item>-mel is.index.php:
<?php
header('Content-Type: text/html; charset=utf-8');
function my_var_export($variable, $text = '...') {
return '<p>' . $text . ' (type: "' . (gettype($variable)) . '"):</p><pre>' . var_export($variable, TRUE) . '</pre>';
}
$feed_url = 'test.xml';
libxml_use_internal_errors(true);
$RSS_DOC = simpleXML_load_file($feed_url);
if (!$RSS_DOC) {
echo "Failed loading XML\n";
foreach (libxml_get_errors() as $error) {
echo "\t", $error->message;
}
}
foreach ($RSS_DOC->channel->item as $RSSitem) {
$categories = array();
foreach ($RSSitem->category as $category_index => $category) {
$categories[] = $category;
}
$categories_string = implode(',', $categories);
echo my_var_export($categories_string, '$categories_string');
}test.xml:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title>Test RSS feed</title>
<link>http://example.com</link>
<description>Read RSS feed</description>
<item>
<link>
http://www.pafi.hu/_pafi/palyazat.nsf/ervdocidweburlap/490FAC2B35FC9E0EC1257A0F0038DC43
</link>
<title>
<![CDATA[
Milyen kérdést intéznék a miniszterekhez, ha képviselő lennék?
]]>
</title>
<description>
<![CDATA[
A kíirók pályázatot hirdetnek gyermekintézmények számára a Gyermekek Világnapja alkalmából.
]]>
</description>
<category>gyermek, ifjúság</category>
<category>közművelődés</category>
<category>művészet</category>
<category>szociális</category>
<pubDate>Sun, 03 Jun 2012 23:51:34</pubDate>
</item>
<item>
<link>
http://prohardver.hu/tema/php_kerdesek_2/friss.html
</link>
<title>
<![CDATA[
PHP kérdések
]]>
</title>
<description>
<![CDATA[
A Prohardver! lapcsalád PHP-kérdésekkel foglalkozó fóruma.
]]>
</description>
<category>webfejlesztés</category>
<category>programozás</category>
<category>PHP</category>
<category>Prohardver!</category>
<pubDate>Thu, 07 Jun 2012 13:05:05</pubDate>
</item>
</channel>
</rss>==============================================
KIMENET:
$categories_string (type: "string"):
'gyermek, ifjúság,közművelődés,művészet,szociális'
$categories_string (type: "string"):
'webfejlesztés,programozás,PHP,Prohardver!'==============================================
Ebből jól látszik, hogy vesszővel elválasztva bekerült egy változóba az összes kategória.
Természetesen a sima vesszős megoldás nem feltétlenül jó, ha a fent látható módon a "gyermek, ifjúság" egyetlen kategóriának minősül, mert egy vessző mentén történő "szétrobbantásnál" külön kategóriába kerülhet.
Ezért a legjobb lenne szépen szétválasztani, many-to-many relation alkalmazásával az adatbázisban. -
#10046
Sk8erPeter
nagyúr
sonar
#10045
Sk8erPeter
nagyúr
A karakterkódolásaid mindenhol stimmeljenek, legyen a karakterkódolás konzekvens - tehát ha az a fájl, ahonnan meghívod, UTF-8 kódolású, akkor a forrásfájl is legyen az. Notepad++-szal meg tudod nézni, most ANSI-ban vagy UTF-8 kódolásúban van-e. Valamelyik legyen a kettő közül, vagy konvertáld.
Esetleg megpróbálkozhatnál az mb_strlen, mb_substr és társaival.Egyébként a content-type-nál a text/plain helyett nem text/html kéne neked? Csak hogy ne plain textként írja ki pl. a <br />-t.
-
#10044
Sk8erPeter
nagyúr
Siriusb
#10043
Sk8erPeter
nagyúr
válasz
Siriusb
#10043
üzenetére
kutyuli
Na, ennek a pluginnek nem akart most egyszerűen beugrani a neve, kösz(#10042) riska1982 :
Ennek nem sok köze van a PHP-hoz.
Az a plugin tényleg jó, amit Siriusb linkelt.
De ami neked ebből konkrétan kell, az inkább ez:
jQuery Waypoints - Scroll Analytics -
#10041
Sk8erPeter
nagyúr
orkester
#10040
Sk8erPeter
nagyúr
válasz
orkester
#10040
üzenetére
A foreach($RSS_DOC->channel->item as $RSSitem) blokkon belülre.
Így lehet vesszővel elválasztott stringet kapni a kategóriákból:
$categories = array();
foreach ($rss_category as $category_index => $category) {
$categories[] = $category;
}
$categories_string = implode(',', $categories);Ha így vesszővel elválasztva jó lesz, akkor az INSERT résznél ezt a $categories_string változó tartalmát pakolhatod bele az adatbázisba az $item_category helyett mysql_real_escape_string()-gel, hogy escape-elve is legyen.
-
#10039
Sk8erPeter
nagyúr
orkester
#10038
Sk8erPeter
nagyúr
válasz
orkester
#10038
üzenetére
Ciklussal kell végigmenni az $rss_category tartalmán.
A feltöltés attól függ, hogy néz ki az adatbázis-szerkezeted, hogyan szeretnéd megoldani.
Több sort szeretnél feltölteni, kategóriánként? Vagy vesszővel elválasztva, azonos sorba (nagyon gagyi megoldás)?Egyszerű kiírós foreach:
foreach ($rss_category as $category_index => $category) {
echo $category, '<br />';
} -
#10036
Sk8erPeter
nagyúr
orkester
#10031
Sk8erPeter
nagyúr
válasz
orkester
#10031
üzenetére
Nem nagyon értem a kódodat.
if(mysql_num_rows($item_exists)<1)
Nyomatsz egy ilyet, de én nem látok előtte semmiféle adatbázis-lekérést (vagy nem másoltad be azt a kódrészletet, vagy eleve rossz az elgondolás).Amúgy mivel inicializálod az $RSS_DOC objektumot?
A korábbi kódokat sem látjuk (legalább csak részleteket).Ha már feltetted a kérdést: a <font> tagek használata 2012-ben már nagyon gáz, elavult dolog. Meg a mysql_query is
mondjuk a PDO helyette sokkal jobb választás lenne (lásd Tele von Zsinór korábbi rövid írását erről: [link]).
De ha már mysql_query, mindenképp használnod kellene a query előtt a mysql_real_escape_string() függvényt, hogy escape-elve legyenek a változótartalmak, mielőtt berakod adatbázisba őket. -
#10033
Sk8erPeter
nagyúr
RootRulez
#10028
Sk8erPeter
nagyúr
válasz
RootRulez
#10028
üzenetére
mobalnak teljesen igaza van, a Newhosting is egy rakás szar, de főleg az úgynevezett "supportjuk" botrány, meg az, hogy néha a szerver gyors, néha meg iszonyatosan lassú, vagy egyszerűen nem elérhető az oldal (pedig az állítólagos rendelkezésre állási idő náluk valami 98%, plusz ezt írják: "Kizárólag kiváló minőségű IBM eszközökkel biztosítjuk a szinte állandónak mondható rendelkezésre állást, valamint folyamatos felügyelettel csökkentjük az esetleges meghibásodások számát." - hahaha
Amikor jeleztem a problémákat, akkor a supportos csávó kijelentette, hogy ha nem tetszik, akkor válasszak más szolgáltatót. Ezt nevezem jó hozzáállásnak!
Drupal futtatására is valóban alkalmatlan (próbáltam).Egy nagy előnye van, hogy a 3 GB-os tárhelyméret ellenére ingyenes.
Úgy emlékeztem, hogy át lehetett irányítani más domainről is a névszervert, igazából csak emiatt javasoltam kezdetnek, átmeneti megoldásnak, de ezek szerint tévedtem, ahogy írod, csak náluk regelt domainhez lehet tárhelyet rendelni (mondjuk ez végül is érthető a tárhelyért cserébe).
Szóval akkor a Newhosting nem téma.Abban is egyetértek moballal, hogy a Tárhelypark viszont már egészen más kategória, pozitív értelemben. Jó a support (csetelni is lehet velük, és tök normálisan és gyorsan reagálnak a problémákra), az oldal rendelkezésre állása kifogástalan eddigi tapasztalataim alapján, meg a sebességgel sincs probléma, korrekt cpaneles admin-felület van, plusz nem drágák.
Ha úgyis magyar a célközönséged, akkor őket mindenképp tudom ajánlani.Ha 200 MB felett vagy, akkor sajnos tényleg csak a 3900 Ft-os, 1 GB-os csomag marad, és akkor már (3900 Ft [tárhely]+1200 Ft [domain] =) 5100 Ft-nál vagy, az havonta 425 Ft.
Szerintem az sem vészes.De persze nem akarlak rábeszélni, csak én már annyira megcsömörlöttem az ilyen UW-s, ATW-s, FW-s tárhelyektől, annyi korlátot állítanak, meg extra szívást, hogy inkább másnak is mást ajánlok (minőséget).
-
#10024
Sk8erPeter
nagyúr
RootRulez
#10023
-
#10019
Sk8erPeter
nagyúr
RootRulez
#10016
-
#10014
Sk8erPeter
nagyúr
Sk8erPeter
#10013
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#10013
üzenetére
Inkább nézd meg ezt: [link]
már az elején:
Warning: session_start() [function.session-start]: open(/tmp/sess_4f0a512a7d873a41414b7f0fc8f3e5d5, O_RDWR) failed: No such file or directory (2) in /guestbook/captcha.php on line 2Fasza.
Nyomatsz egy
session_start();-ot, és ezt kapod a pofádba.ATW-specifikus megoldás:
hozz létre a főkönyvtáradban egy "tmp" könyvtárat, és máris menni fog....Most már vágod, milyen idióta f@szságokról beszéltem az ilyen ratyi uw-, atw-jellegű szarkupacoknál?
Ja, egyébként még egy: az a korábbi baromi hosszú "/mnt/ultraweb/h/hu/hunapk/khand.ttf" teljes fájlrendszerbeli elérési útvonal sajnos UW-nél valóban indokolt volt, mert ettől az elérési úttól totálisan eltér pl. a $_SERVER['DOCUMENT_ROOT'], tök máshova mutat, szóval gány az egész úgy, ahogy van... kár, hogy úgy tűnik, ezeket a hülyeségeiket azóta sem sikerült javítaniuk.
Nem értem, ezek a cégek hogy létezhetnek még egyáltalán. Jó, mondjuk értem, a sok arcba pakolt reklámmal. -
#10013
Sk8erPeter
nagyúr
RootRulez
#10011
Sk8erPeter
nagyúr
válasz
RootRulez
#10011
üzenetére
Nem mondod komolyan, hogy exportáltad az adatbázisod tartalmát valami Excel-kompatibilis fájlba, aztán abból a fájlból importáltad azt az uw-re...
Egy mezei phpMyAdmin miért nem volt jó?Kódodból:
imagettftext($im,20,0,12,32,$szurke,"/mnt/ultraweb/h/hu/hunapk/khand.ttf",$str);"/mnt/ultraweb/h/hu/hunapk/khand.ttf"
helyett próbáld ezt:
$_SERVER['DOCUMENT_ROOT'] . '/khand.ttf'
is. -
#10008
Sk8erPeter
nagyúr
RootRulez
#10006
Sk8erPeter
nagyúr
válasz
RootRulez
#10006
üzenetére
Csak most látom, amit a szerkesztés után írtál.
Annak a hozzáadós függvénynek is működnie kell, csak vigyázz arra, hogy ne írass ki SEMMIT az outputra a header előtt.
Akár egy szóköz is boríthatja az egészet, ami miatt azt a hibát kapod, amit bemásoltál korábban.
Egyébként pontosan ezért van az, hogy a csakis PHP-kódokat tartalmazó fájlba soha nem szabad záró PHP-taget rakni, mert elég egy kiírt karakter, és máris ilyen hülye hibák fordulhatnak elő.Lásd hivatalos oldal vonatkozó részét:
"If a file is pure PHP code, it is preferable omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines after PHP closing tag which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script."==
Ezek alapján működnie kéne (most pszeudokód az a hozzáadós függvény):<?php
function add_visitor($xyz){
// logging stuff, do this, do that, etc....
}
$xyz = 'blablabla';
add_visitor($xyz);
$new_location = 'http://example.com'; // cseréld le
// 301 Moved Permanently
header('Location: ' . $new_location, TRUE, 301);
exit();// ...
-
#10007
Sk8erPeter
nagyúr
RootRulez
#10004
Sk8erPeter
nagyúr
válasz
RootRulez
#10004
üzenetére
FÁJL LEGELEJÉRE:
<?php
$new_location = 'http://example.com'; // cseréld le
// 301 Moved Permanently
header('Location: ' . $new_location, TRUE, 301);Nyilván cseréld ki az example.com-ot sajátra...
===
Szerk.:
ha valami nem megy, ne azt írd, hogy "nekem nem megy", hanem írd le, hogy milyen hibát tapasztaltál....... -
#10005
Sk8erPeter
nagyúr
RootRulez
#10003
Sk8erPeter
nagyúr
válasz
RootRulez
#10003
üzenetére
Hát akkor meg is van a baj forrása.
Régen amúgy amikor kezdtem, én sem nem akartam lét szánni domainre meg tárhelyre, de aztán rájöttem, hogy már annyira olcsón vesztegetik ezeket a nagy verseny miatt, hogy már annyiért meg lehet kapni, amennyiért veszel egy kocsmában egy sört havonta.
Sörre meg kinek nincs pénze??Kezdetnek, egy domain birtokában (kb. 1200/évért már megkapsz egy .hu-st!!!) használhatod a Newhostingot, aztán a nagyon olcsó, de minőségi Tárhelyparkot, külföldiek közül meg sokan dicsérték a másik topicban a hostgatort.
Az UW-nél, ATW-nél annyi korlátba és hülyeségbe lehet ütközni (pl. htaccess tiltása és hasonlók), meg annyira zavaró a reklámframe, hogy bőven megéri váltani.
Persze nem akarlak rábeszélni, de gondold meg, hogy havi egy sör áráért legalább minőséget kapsz. -
#10002
Sk8erPeter
nagyúr
RootRulez
#10001
Sk8erPeter
nagyúr
válasz
RootRulez
#10001
üzenetére
"Átpakolnám az oldlaam UW-ről ATW-re"
Az igen. Egyik jobb, mint a másik. Kipróbáltam egy ATW-s oldalon, teljesen jól működik a header-es átirányítás, amennyiben nincs más output előtte...
Amúgy az a gáz, hogy hiába irányítod át headerrel, az a fosadék reklám-frame ott marad.Mi van a 6. sorban?
Egyébként ha teljesen át akarod irányítani, akkor miért nem teljes címet használsz, és miért nem kapásból a legelején?
<?php
$new_location = 'http://example.com';
header('Location: '.$new_location);
die();Meg mondjuk illene kiküldeni egy 301-es headert is, azt most kihagytam.
(.htaccess-megoldást direkt nem mondtam, mert a szaros ATW nem engedélyezi a használatát, ahelyett, hogy korlátozná a módosítható opciókat)==
(#10000) mobal :
nincs mit.
Tiéd a 10000. hsz.? Nem rossz. -
#9998
Sk8erPeter
nagyúr
PazsitZ
#9994
Sk8erPeter
nagyúr
válasz
PazsitZ
#9994
üzenetére
Aztán lehet ezt még kombinálni
SELECT *
FROM test_time
WHERE myunixtime
BETWEEN UNIX_TIMESTAMP( '2012-06-03 00:00:00' )
AND UNIX_TIMESTAMP( '2012-06-03 23:59:59' )Mondjuk ezt csak lehetőségként írtam, gondolom a tiéd gyorsabb.
(#9995) mobal :
PazsitZ a megoldásában átalakítja úgy, ahogy kell.
De legegyszerűbb, ha kipróbálod.===
Szerk.: egyébként kérdéses, hogy vajon ez a tárolás a jobb/hatékonyabb, vagy a MySQL saját timestampje, esetleg szétbombázva. -
#9989
Sk8erPeter
nagyúr
CSorBA
#9988
Sk8erPeter
nagyúr
Nincs mit!
Szerk.:
"Nem, ebből 2 2 3 lesz"
De nem$egyezoek = array_intersect($tomb2, $tomb1);
Ez lesz (most próbáltam):
array (
0 => '2',
1 => '3',
)Szerk2.:
ÁÁá, bocs, én felcseréltem, mert azt hittem, neked az kő, sorry, nem szóltam.
Szóval ha így nyomatod:$egyezoek = array_intersect($tomb1, $tomb2);
Akkor az van, amit írtál.
-
#9987
Sk8erPeter
nagyúr
CSorBA
#9983
Sk8erPeter
nagyúr
$tomb1 = array('1', '1', '1', '1', '2', '2', '3', '5', '6', '7');
$tomb2 = array('1', '2', '3', '4', '5');
$egyezoek = array_intersect($tomb2, $tomb1);
var_export($egyezoek);Az output:
array (
0 => '1',
1 => '2',
2 => '3',
4 => '5',
)Szerk.:
"Magyarán ezt várnám:
$eredmeny_tomb = array('2', '2', '3');"
Ebből csak array('2', '3') lesz array_intersecttel. Nem arra vagy kíváncsi? -
#9984
Sk8erPeter
nagyúr
PazsitZ
#9982
Sk8erPeter
nagyúr
válasz
PazsitZ
#9982
üzenetére
+1 : Jaja, az ilyenek rontják a PHP megítélését.
"Ez mondjuk 1 hónap után nem gáz, de több év alatt, igazi teljesítmény, hogy semmi nem ragadt rá."
Ez tényleg elég durva...
Amúgy szerintem az sem jó, ha valaki nem kóstol bele más nyelvbe, ahol szigorúbb megkötések vannak, mert akkor megszokja, hogy simán lehet gányolni, mert a PHP nem pampog érte, főleg, ha jól kikapcsolja még fejlesztés idejére is a hibajelzést, mert "zavaró". -
#9981
Sk8erPeter
nagyúr
biker
#9979
Sk8erPeter
nagyúr
"Mit adnátok annak, aki egyszerre használ magyar és angol neveket pl táblázatai fejlécében? é emiatt írja el a dolgokat?"
Ha már így kérdezted: sallert.
Amúgy a többivel is teljesen egyetértek, a változóneves problémát soha nem értettem, szerintem is sokkal jobb egy jó hosszú, de beszédes és félreérthetetlen változónév plusz karakterekkel, mint egy lerövidített szarság, amiből semmire nem tudsz következtetni, csak egy dolgot tudsz tenni, hogy visszamész a legelejére, ahol inicializálja vagy épp megváltoztatja a változó értékét, és megpróbálod kinyomozni, hogy mi a franc az, esetleg még debuggolást sem úszod meg. Aztán egy replace all valami értelmes változónévre.
Nem tudom, egyes önjelölt programozózsenik miért gondolják úgy, hogy pozitívan hat a teljesítményre vagy a munkatempóra, ha $a, $b jellegű változóneveket használnak.
Ez az initscreen/endscreen meg úgy gány, ahogy van. Nem véletlenül találták ki a template-ezést.
Sajnos vannak menthetetlen esetek, én is találkoztam már ilyennel (kedvelt kolléga volt), akinek hiába adsz elő normális érveket (lásd amiket mondtál is), ő akkor is jobban tudja (a legerőszakosabb, legokoskodóbb fajta). -
#9977
Sk8erPeter
nagyúr
bazsi44
#9976
Sk8erPeter
nagyúr
válasz
bazsi44
#9976
üzenetére
Igazából annyi a lényeg, hogy ne add fel, ha elsőre nem sikerül valami, olvass utána, gyakorolj sokat (fontos, hogy amit olvastál, próbálgasd is ki, mert szerintem csak akkor lehet jól megérteni a működését), stb. Szóval kitartás, ugyanez vonatkozik a többi nyelvre is.
Ha a tanárod meg utálja az egészet, akkor lehet, hogy jobb is, hogy nem tőle tanulsz.
Egyébként becsülendő, hogy már középiskolában ennyire ráfeküdtél a témára, csak így tovább!
-
#9965
Sk8erPeter
nagyúr
bazsi44
#9962
Sk8erPeter
nagyúr
válasz
bazsi44
#9962
üzenetére
Én egy szóval sem mondtam, hogy ne kérdezgess.
Csak kértem, hogy használd a válasz linket, azt' annyi.Nem választottál ki adatbázist.
Egyébként normális esetben így kéne kinéznie, ahogy itt a példakódban látható: [link]
hosttal, felhasználónévvel, jelszóval...aztán kiválasztva a megfelelő adatbázist. -
#9955
Sk8erPeter
nagyúr
bazsi44
#9954
Sk8erPeter
nagyúr
válasz
bazsi44
#9954
üzenetére
Igazából nem értem a kérdést. Van már egy nike menüpontod, az megnyit egy oldalt, azon az oldalon kell megjeleníteni ezt az adatbázisból lekért tartalmat.
Amúgy ez most csak egy ujjgyakorlat? Csak próbálgatod? Ha éles webshopot szeretnél, akkor azt ne Te írd meg, használj kész alkalmazásokat (lásd biztonság és egyebek). Ha csak gyakorolsz és tesztelsz, akkor nem szóltam egy szót sem, bár én a helyedben nem pont webshoppal kezdeném a gyakorlást, mert az túl komplex lehet, hanem mondjuk formok feldolgozásával, adatbázisba feltöltésével, az oda felvitt adatok megjelenítésével, sessionökkel, biztonsági kérdésekkel, stb.
Persze ez csak magánvélemény. -
#9953
Sk8erPeter
nagyúr
bazsi44
#9952
Sk8erPeter
nagyúr
válasz
bazsi44
#9952
üzenetére
Végig is kell rohangászni a lekért eredményeken.
A php.net-es oldalon is van példa: [link].Valahogy így:
$nike_result = mysql_query("SELECT * FROM table WHERE name='nike'");
while ($row = mysql_fetch_assoc($nike_result)) {
echo '<div>'. $row['description'] . '</div>';
}Itt persze a $row['description'] csak egy példa, attól függ, mik a mezőnevek a tábládban.
-
#9951
Sk8erPeter
nagyúr
modder
#9950
Sk8erPeter
nagyúr
httpd.conf
Mondjuk tesztelésig érdemes lehet létrehozni csak erre egy VirtualHostot, és azonbelül alkalmazni, a httpd-vhosts.conf-ba betéve.====
Egyébként most nálam sem működik IIS+FastCGI PHP+XDebug+NetBeans kombóval a debuggolás, nem vágom, miért.
A breakpointnál megáll, de b@szik kiírni bármit is, az említett beállítások ellenére is. Na majd ha lesz időm, megkukkantom, mi a sz@r baja van. -
#9937
Sk8erPeter
nagyúr
Sk8erPeter
#9936
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#9936
üzenetére
Érdekes, hogy MySQL-ben ezt meg tudták oldani rendesen...
SELECT NOW( )
2012-05-31 17:51:15SELECT DATE_ADD(NOW(), INTERVAL 1 MONTH)
2012-06-30 17:51:15Ahogy ez is jó:
SELECT DATE_ADD( '2013-01-30 17:51:15', INTERVAL 1 MONTH )
2013-02-28 17:51:15 -
#9936
Sk8erPeter
nagyúr
Sk8erPeter
#9935
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#9935
üzenetére
Mondjuk igazából a saját témaköröm inkább arról szól a Stack Overflow-n, hogy a plusz egy hónap miért viselkedik ilyen érdekesen, nem is annyira fókuszál konkrétan a hónap utsó napjára, csak hogy miért b@szódik el, ha 31-én hozzáadok egy hónapot, most jövök rá.
De ez mindenképp nagyon hasznos segítség volt.Az is igaz, hogy azt mondjuk lehetne csekkolni, hogy amennyiben ez a hónap 31 napból áll, és épp 31-e van, akkor másképp viselkedjen, konkrétan így, ahogy mutattad, és akkor ezt a kódot már fel lehetne rakni SO-ra.
-
#9934
Sk8erPeter
nagyúr
Sk8erPeter
#9932
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#9932
üzenetére
Na várjunk, most fogom fel a tweet lényegét:
első:
http://twitter.com/rasmus/status/208157669452816384
második:
http://twitter.com/rasmus/status/208160760302538752Ezek szerint a PHP a GNU date-et használja, tehát igazából nem a PHP sara ez, hanem a GNU date függvényé?
-
#9932
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Úgy tűnik, sikerült felfedezni egy érdekes hibát a PHP beépített dátumkezelő függvényeivel kapcsolatban: [link]
A lényeg: ma ugye május 31 van, lekértem a köv. hónap napjainak számát, 31-et ír, miközben június hónap 30 napból áll csupán. A másik: a mostanihoz képest plusz egy hónapra július 1-jét írja (07-01), pedig annak június 30-ának kéne lennie (06-30).
Úgy tűnik, már Rasmus is írt a problémáról, trükközni kell azzal, hogy adott hónapban 15-e utáni dátum legyen, ahhoz képest legyen számolva.Hát ez elég gáz, nem értem, eddig hogy nem sikerült ezt kijavítani. Én most konkrétan PHP 5.3.8-at használok.
-
#9931
Sk8erPeter
nagyúr
CSorBA
#9930
Sk8erPeter
nagyúr
-
#9929
Sk8erPeter
nagyúr
Tele von Zsinór
#9923
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#9923
üzenetére
"Feltételezem, a kód C#-ból van"
Igen, rögtön gondoltam, de nem igazán volt világos, hogy ez most hogy jön ide, PHP-s témához, amikor kizárólag a PHP-re jól alkalmazható, itt érvényes mintákról beszéltünk korábban.
Éppen ezért mondtam, hogy most fel lehetne ilyen alapon hozni Singletonra az ablakkezelő objektumokat is, de mivel ilyen PHP-nél nincs, tök felesleges ilyenről beszélni.Lambda: jahh, oké, closure néven oké, most már ezen a néven is.
Ja, eddig is világos volt, hogy miről beszél, hogy nehéz hozzá unit testet írni. Én viszont azt mondtam, hogy vannak esetek, amikor erről felesleges beszélni, pl. most egy naplózó osztály esetén nem biztos, hogy valaki hatalmas bűnt követ el, ha nem passzolgatja inkább a controllereknek a már létrehozott példányt, hanem használ egy nyamvadt singleton-példányt, azt' kész.
Van, amikor úgy logikus, hogy 1 példány legyen valamiből, és azt csak macerás passzolgatni össze-vissza, ezért jól jön néha a Singleton minta, ennyit állítok. Aztán ha már unit testekről van szó, nyilván át kell gondolni, hogyan lehet ezt átvariálni.Egyébként az adatbázis-kapcsolódáshoz nem biztos, hogy egy request során csak egyet akarunk, ezért nem is biztos, hogy olyan jó "klasszikus" példának a Singleton alkalmazására, mert elképzelhető, hogy valaki egy request során több adatbázishoz is szeretne csatlakozni.
===================
(#9924) Athlon64+ :
ezek szerint elbeszélünk egymás mellett, nem értetted meg, miről magyaráztam. Most itt fentebb leírtam még egyszer. PHP-ről beszélünk, könyörgöm, ne keverjük már ide a C#-ot, meg a többi nyelvet, mert nyilván nagy különbségek lehetnek."A tervezési minták átívelnek a nyelveken."
Nem mondod komolyan, TÉÉÉNYLEEG??
Azért ne nézd már hülyének az embert. Inkább próbáld megérteni, miről beszél. Pl. arról, hogy attól még, mert mondjuk van értelme ablakkezelő objektumról beszélni egy másik nyelv, más jellegű felhasználása során, attól még nem biztos, hogy hasonló minta alkalmazható egy nyomorék PHP-s webalkalmazás esetén. -
#9922
Sk8erPeter
nagyúr
Peter Kiss
#9921
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9921
üzenetére
Várj, most PHP esetén milyen dll-ekről beszélünk?
"Lambdákkal"? Lehet, hogy sok volt a mai utazás, és fáradt vagyok, de most nem esik le.
Service locatorről fogalmam sincs, nem használtam még, de erről ezt találtam (nem javasolja).
Mivel már idekevertük a szezont is a fazonnal (dll-ek?), nem vágom, egyáltalán PHP keretein belül beszélünk-e a Singleton osztályok létjogosultságáról.Én szimplán azt állítottam, hogy pl. egy Logger osztálynál teljesen megfelelő megoldás egy Singleton használata, statikus metódusokkal, hogy mindenki hozzáférjen, tök felesleges bonyolítani egy ilyen osztályt. Mindent lehet még nyakatekertebben is megoldani, hogy aztán arra recskázhasson a fejlesztő, hogy ő milyen ügyes volt, de vannak esetek, amikor tökéletes időpocsékolás ilyennel rajoskodni.
-
#9920
Sk8erPeter
nagyúr
Peter Kiss
#9919
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9919
üzenetére
Találtam egy jó összefoglalót arról, hogy miért is NEM feltétlenül indokolt a Singletonok használata (amiről tulajdonképpen Te is beszélsz):
http://gooh.posterous.com/singletons-in-php
"Singletons are not unique snowflakes
In languages where objects live in an application server, Singletons can be used to keep memory usage low. Instead of creating two objects, you reference an existing instance from the globally shared application memory. In PHP there is no such application memory. A Singleton created in one Request lives for exactly that request. A Singleton created in another Request done at the same time will still be a completely different instance. And it will occupy it's own memory. Those instances are not linked to each other. They are completely isolated, because PHP is a Shared-Nothing architecture. You do not have one single unique instance, but many similar instances in parallel processes. Thus, one of the two main purposes of a Singleton is not applicable.Don't construct twice, it's all right
Advocates of the Singleton in PHP often argue it's still useful to be able to limit an instance within a single request. The aforementioned database classes being the most prominent example. But the much easier solution would be simply not to instantiate a second instance. If anyone can make sure there is just one instance, it's the developer. If you need to have the same instance in many classes, use Dependency Injection. Just create one, inject everywhere. That will also save you the hassle of deconstructing your Singleton once you notice you need a second instance of it all of a sudden.
Another example where Singletons are often applied but don't make sense is classes like FrontControllers. While conceptually it makes sense to say "There may be only one FrontController", it is superfluous to ensure it from an architectural viewpoint. A FrontController is usually instantiated only once in your application's control flow anyway. If you don't write a new Foo; anywhere else, you already made sure there is just one instance. So you ain't gonna need the Singleton here. Don't express concepts in your code that are never used.Don't shoot yourself in the foot
The Singleton's other purpose (to have a global access point to the instance) is undesirable in PHP. The desire for that usually stems from having an architecture where objects pull in their dependencies. Like any globals and statics, the Singleton's getInstance() method creates coupling to the global scope. This makes Unit-Testing harder. There is ways to mitigate this, but in general, the cost to mitigate is higher than to simply avoid the Singleton in favor of Dependency Injection. This is especially true in those situations, where the Singleton is applied but never instantiated twice anyway."Itt van egy hosszabb témázás magyarul erről:
http://weblabor.hu/blog/20100727/php-egyke-ososztaly============
Hadd mondjak ellenérvet is (már úgyis megszokhattátok, hogy ez a rész is mindig jön a hsz.-eimben
):
[link]
Pont ez jutott nekem is eszembe elsőként, amit itt írnak az elfogadott válaszban, hogy pl. egy Logging class esetén tipikusan jól használható egy Singleton osztály, mert ott felesleges tesztelésekről beszélni (valszeg nem a naplózásért felelős osztály a legfontosabb, amit tesztelni kellene), plusz teljesen elfogadható lehet ennek a mintának az alkalmazása, mert más módon szépen összehozni a rendszerrel feleslegesen macerás lehet.Saját példa az, hogy bizonyos esetekben csak nagyon macerás módon, adott esetben a teljes rendszer újratervezésével lehetne normálisan beépíteni a rendszerbe egy több helyen szükséges változó Singleton nélküli használatát - tipikusan olyan rendszerekre gondolok, ahol jelenleg még nem elsősorban az OOP-szemléletet követik, hanem egyelőre inkább globális függvényekét (bár van elmozdulás az OOP irányába): mint a Drupal.
Más megoldás nyilván a globális változók használata, ami tulajdonképpen hasonló lehet a Singletonokhoz, de kicsit mégis más. Pl. Drupalnál szükségem volt már ilyenre: [link].A másik: csak hogy egy kicsit pontosítsunk, a Singleton-osztályok használata elsősorban PHP-nél felesleges. Aztán más nyelveknél vannak bőven kivételek, mint pl. egy ablakkezelő objektum használata.
Ettől függetlenül tényleg fennáll, hogy a lehető legritkább esetekben szabad használni, alapvetően a már említett szempontok miatt kerülendő. Főleg PHP-nél (lásd az idézett cikket).
===
DE további ajánlott linkek:
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons -
#9914
Sk8erPeter
nagyúr
Peter Kiss
#9911
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9911
üzenetére
"Yii::app()->user->admin; és nincs ez a static borzalom benne a rendszerben."
De még mindig ott a public static function app(). -
#9913
Sk8erPeter
nagyúr
papa019
#9868
Sk8erPeter
nagyúr
válasz
papa019
#9868
üzenetére
Hátha másnak is hasznos lesz, közben privátban megoldottuk a dolgot, olykor a MultiViews letiltása csodákat tesz.
Példa, ami itt többek közt a problémákat okozta: megnyitottuk az example.com/xyz címet, de közben aktív RewriteRule is volt, plusz MultiViews bekapcsolva, de eközben - mint kiderült - volt a gyökérkönyvtárban egy xyz.php fájlunk is, így az example.com/xyz betöltésére egyből 500 Internal Server Errort kaptunk. A MultiViews bekapcsolt állapota esetén egyébként elkezd az Apache kutakodni a megfelelő kiterjesztésű fájlok után: [link]..htaccess-ben:
Options +FollowSymLinks
HELYETT:
Options +FollowSymLinks -MultiViews... és máris nem volt 500-as error.
-
#9908
Sk8erPeter
nagyúr
Speeedfire
#9907
Sk8erPeter
nagyúr
válasz
Speeedfire
#9907
üzenetére
Na jó, befejeztem, amúgy nincs mit, és én is köszi.
-
#9906
Sk8erPeter
nagyúr
Speeedfire
#9905
Sk8erPeter
nagyúr
válasz
Speeedfire
#9905
üzenetére
http://the-echoplex.net/log/php-case-sensitivity
class constructors - ez is case insensitive. Régebben meg ugye az volt a módi, hogy a konstruktor neve egyezik az adott osztály nevével. Most már a "mágikus" __construct()-ot érdemes ugye használni. Na de ettől függetlenül működik a régi módszer is.
Röviden: konstruktornak minősül, mert azonos a neve az osztályéval (case insensitivity), konstruktor meg nem lehet statikus (ahogy a hibaüzenet is elmondja).
Megoldás: adj más nevet a metódusnak, és annyi.Szerk.: jé, most lettem "PH! nagyúr".
Ezt is megértem. Mindenki vendégem egy virtuális sörre. -
#9902
Sk8erPeter
nagyúr
Peter Kiss
#9899
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9899
üzenetére
"Királyság", de nem abban a formában, ahogy írták abban a kódban, amit Speeedfire itt "idézett".
-
#9896
Sk8erPeter
nagyúr
Speeedfire
#9894
Sk8erPeter
nagyúr
válasz
Speeedfire
#9894
üzenetére
Ez olyan fejlesztőnek az idióta agyalmánya, aki azt hiszi, az a jó programozó, aki minél tömörebben, helyspórolósabban ír minél átláthatatlanabb és követhetetlenebb kódot.
Orbitális nagy sallert érdemel. -
#9891
Sk8erPeter
nagyúr
Peter Kiss
#9890
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9890
üzenetére
Ja, végül is az igaz.
-
#9888
Sk8erPeter
nagyúr
Peter Kiss
#9886
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9886
üzenetére
Ahogy Korcsii mondja.
Igazából egyébként nagyon nem passzol ide a filozófiai felvetésed, mert ez egy szakmai fórum, itt létezik pontos megfogalmazás, pl. ha azt mondod, hogy UTF-8 BOM nélkül, akkor az eléggé kifejezi a lényeget. -
#9885
Sk8erPeter
nagyúr
Speeedfire
#9884
Sk8erPeter
nagyúr
válasz
Speeedfire
#9884
üzenetére
Nem, nem akartam belekötni, de annak semmi értelme nincs, hogy "BOM-olva", mivel pont, hogy a BOM nélküli változat a megfelelő webes használatra...
-
#9883
Sk8erPeter
nagyúr
Korcsii
#9882
Sk8erPeter
nagyúr
válasz
Korcsii
#9882
üzenetére
Ja, valszeg tök feleslegesen zabál úgy, mert gondolom a file_get_contents() is a háttérben valójában a fentihez hasonló módszerrel megy végig a fájlon (kb. C-s szintaktika), ez csak egy "wrapper" ahhoz, hogy még kényelmesebb legyen ilyen ismétlődő feladatok elvégzése (ne kelljen szarakodni a fájllezárással, stb.), meg hogy némileg beszédesebb legyen a függvény neve.
Ráadásul az nem feltétlenül egyértelmű, hogy milyen sortörés van a fájlban (Windows-os CRLF, vagy Linux-ra jellemző sortörés, stb.), így azzal is szarakodnod kéne, hogy azt megoldd.
Tehát ha kifejezetten a fájl soraira vagy kíváncsi, akkor nem érdemes ezt a függvényt használni, akkor a sonar által mutatotthoz hasonlót érdemes inkább alkalmazni, már csak erőforráskímélés érdekében is. -
#9881
Sk8erPeter
nagyúr
sonar
#9880
Sk8erPeter
nagyúr
Nem egy tömbbe "szippantja", hanem sima stringbe.
Az a különbség, amit írtál, meg hogy könnyebben áttekinthető és kezelhető, plusz hogy nem soronként olvas be, hanem egyszerűen mindent berak egy stringbe, ömlesztve, azt' kész.
DE természetesen ha neked kifejezetten arra kell az fgets függvény, hogy soronként olvasd be a fájlt, akkor NEM felejtős a dolog, csak ha egyszerű fájlbeolvasás/kiíratás kell, akkor jóval könnyebb használni a file_get_contents()-t. -
#9879
Sk8erPeter
nagyúr
sonar
#9875
Sk8erPeter
nagyúr
PazsitZ már leírta az esélyes megoldást.
Szerintem ezt a fájlbeolvasási módszert nyugodtan elfelejtheted (hacsak nincs valami különleges okod rá, hogy így használd), nyugodtan használhatod a file_get_contents()-et.
Akkor az ennyi:
$filename = 'e.txt';
$filecontent = file_get_contents($filename);
echo $filecontent;======
(#9876) Speeedfire:
"BOM-olva"
az meg milyen? -
#9872
Sk8erPeter
nagyúr
mobal
#9871
Sk8erPeter
nagyúr
...és akkor jól átirányítja egy általa megadott oldalra, annak megmutatja a tartalmát, és csak a lényeg nem történik meg, amit szeretett volna: "egy konkrét általam létrehozott weboldalra rakja ki azt aki elküldi ezt a form-ot".
Akkor már átirányítás előtt nem ártana legalább session változóba lementeni a küldő nevét vagy egyéb adatát, és azon az oldalon kiírni ennek a session változónak a tartalmát, ahova átirányítottad.Szerk.: (#9873) alapján ezek szerint mégsem olyan fontos neki a küldő neve...
-
#9865
Sk8erPeter
nagyúr
papa019
#9864
Sk8erPeter
nagyúr
válasz
papa019
#9864
üzenetére
Uhh, hát az nem egyszerű... ezzel együtt törölték is az összes fájlt? Mondjuk valszeg igen, de azért kérdezz rá. Esélyes, hogy nem lesz egyszerű újraírni a .htaccess fájlt. Mondjuk az is lehet, hogy csak simán ráfuttatja az index.php-re az összes elérési utat, és átadja egy $_GET változónak, és akkor már meg is oldódott, de a mintát akkor is ki kell deríteni a meglévő fájlokból, meg elképzelhető az is, hogy bonyolult regexpeket használt.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Konkrétan mikre gondolsz?
Új hozzászólás Aktív témák
Hirdetés
- Hálózati / IP kamera
- Óvodások homokozója
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- World of Tanks - MMO
- Formula-1
- Konteó topic
- Nvidia GPU-k jövője - amit tudni vélünk
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- 3D nyomtatás
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest