- Samsung Galaxy A52s 5G - jó S-tehetség
- Android alkalmazások - szoftver kibeszélő topik
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- Samsung Galaxy A34 - plus size modell
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Samsung Galaxy Watch7 - kötelező kör
- Extra erő egy gombnyomásra - Engwe EP-2 Boost
- Mobilinternet EU-n kívül, eSIM adatcsomagok használata
- Érintésnélküli fizetési megoldások - PayPass via NFC
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
Új hozzászólás Aktív témák
-
-
#68216320
törölt tag
válasz
Joci93 #19508 üzenetére
Nem kell ezert composer rogton. Mint kiderult a macOS-en, amin a PHP 5.6 van, nem volt a mysql.default_socket beallitva a php.ini-ben. Kellet egy link a mysql.socket-hez es be kellett allitani a php konfigban. Azaz nem programkod volt a problema, hanem a dev. env. volt elszurva.
-
PumpkinSeed
addikt
válasz
Joci93 #18516 üzenetére
Az ilyenek amúgy például pont mehetnének egy model-be aminek pl lenne a neve imageHandlerModel vagy valami ilyesmi. Nem tudom mik a lehetőségek erre Laravel-ben de mivel alapból asszem az is MVC framework ezért biztos van rá lehetőség. Amiért én ezt a model-be tenném, mert pl. lehet, hogy más controllerek is használni akarják majd a kép átméretezést és a model-t bármilyen conrollerben meghívhatod.
-
fordfairlane
veterán
válasz
Joci93 #18516 üzenetére
... a harmadik megoldást megnézem a doksiban.
A harmadik módszer az, amit manapság javasolni szoktak. Dependency Injection, DI container, Service container, hasonló kulcsszavak mögött találod meg a témakört.
Egyébként szerintetek sem jó, ha egy metódusban 2 vagy több dolog történik? Például kép feltöltés --> méretezés --> mentés. Hanem, ezeket a lépéseket célszerűbb külön - külön metódusba szervezni?
Az attól függ, mennyire komplex egy-egy eljárás. Ha egyberakod, később nehezebb lesz a részeit újra felhasználni egy másik pontján a kódban, mivel így nem eléggé moduláris. Persze meglévő kódot később is át lehet írni, tagoltabbá tenni.
Ezen kívül azt is érdemes szem előtt tartani, hogy a kód olvasásával és értelmezésével általában nagyságrendileg több idő szokott elmenni, mint a leírásával, függetlenül attól, hogy a saját-vagy más által írt programot kell tudnod értelmezni. Egy év múlva ránézel egy metódusra, és hiába te írtad, egyáltalán nem biztos, hogy érteni fogod, mi micsoda. Ha a kódod tagolt, és egyértelmű, hogy mi miért van benne, az sokat számít.
-
fordfairlane
veterán
válasz
Joci93 #18513 üzenetére
1. Lehet úgy csinálni, hogy egyetlen kontrollerobjektumot használsz több metódussal. A közös kódrész, a "getItemDetails" külön metódusba kerül, amit a többi metódus meghívhat.
2. Lehet csinálni a két kontrollerosztálynak közös szülőosztályt, ami tartalmazza a közös kódrészt.
class IndexController extends MyController
class SubmitController extends MyController
class MyController extends Controller3. Lehet csinálni egy service objektumot, amit aztán bármelyik kontroller használhat. Ebben az esetben a service objektumot példányosítani kell az adott Kontroller konstruktorában, vagy valami service manager komponens segítségével. Laravelben is van ilyen, csak én speciel nem ismerem a Laravelt, így ebben konkrét tanácsot vagy kódrészletet nem tudok produkálni.
A framework saját controller osztályát módosítani valóban nem tanácsos.
-
PumpkinSeed
addikt
válasz
Joci93 #18513 üzenetére
Igazából elvben nem szabadna két kontrollernek kommunikálni egymással vagy nem tudom. De szerintem jobb lenne ezt a
Details()
metódust beletenni a Controller-be. Viszont mivel gondolom a Controller a Core-ban van benne ezért ezt nem kellene csinálni a későbbi frissítések miatt. Esetleg azt lehetne csinálni, hogy betenni egy Controller-t ValamiController néven (Nem tudom mi az Index és Submit ebben az esetben) és aSubmitController
meg azIndexController
nemextends Controller
-el lenne ellátva hanemextends ValamiController
, míg aValamiController
megkapná azextends Controller
-t és benne lenne aDetails()
metódus. -
DNReNTi
őstag
válasz
Joci93 #18467 üzenetére
Ha egy kép csak egy gallériában szerepelhet akkor jó ez a megoldás, ez az 1:n (egy a többhöz) kapcsolat. Ha ugyan azon kép több galériában is benne lehet, akkor kell az n:m, abban az esetben külön egy tábla van csak a kapcsolatoknak fenntartva, tehát három táblára van szükség. Egy a gallériák, egy a képek, illetve egy a kapcsolat tábla, amely összeköti PK alapján a képeket és gallériákat, így lehetővé téve az n:m (több a többhöz) kapcsolatot.
Ha jók az indexek biztos nem lesz lassú, sőt, a string parse-olástól tuti lényegesen gyorsabb. Kell rá írni egy fasza SP-t, ami mondjuk galéria ID alapján visszaadja az össze képet, és akkor már adatbázis szinten le van kezelve.
-
supercow
őstag
válasz
Joci93 #17837 üzenetére
kimazsoláztam, asszem jó lett. Érdekes módon az echo használatával hibákat adott, print-tel viszont nem..
$param = (object)array('name' => 'test');
isset($param->name) ? ( $param->name=='test' ? print 'test' : ( $param->name=='test2' ? print 'test2' : print 'not_test2' ) ) : print "not_set"; -
PumpkinSeed
addikt
válasz
Joci93 #17791 üzenetére
Gondolom a jquery .value értéket írna felül amit amúgy az etdate2-nél nem lehet.
document.getElementById('stdate2').value = "valami";
/*Sikeresen felülírta*/
document.getElementById('etdate2').value = "valami";
/*Nem írta felül*/Mert az első form-ban is etdate2-nek nevezted el és ezért nem látja a hivatkozásnál a másikat.
-
DNReNTi
őstag
válasz
Joci93 #17296 üzenetére
Kíváncsi lennék mivel magyarázza meg, hogy ott lehet biztonsági rés. Arra is kíváncsi lennék mégis mit javasol akkor helyette, ami biztonságosabb. Abban meg egészen biztos vagyok, hogy biztonsági rés sokkal hamarabb keletkezik kliens oldalon, vagy akár szerver oldalon - lásd nem régiben a YouTube fatális béna hibája. Na mindegy, szerintem ne foglalkozz vele, de asszem ezt már a többiek is javasolták.
-
Sk8erPeter
nagyúr
válasz
Joci93 #17285 üzenetére
cidalainnal értek egyet, van olyan feladat, ami eleve értelmetlen, így nem biztos, hogy megéri elvállalni, szépen türelmesen el kell magyarázni a megrendelőnek, hogy baromságot akar. Aztán hátha meggondolja magát, vagy tovább kell állni (már ha van választási lehetőség). Nem akar adatbázist valami degenerált indokból, de azért valahol mégis, meg szeretne query-ket is írni kézzel, amit ja, akár phpMyAdminban is megtehetne, ha ez a kattanása, de nem, ő a spanyolviaszt akarja felfedezni.
De ha már muszáj elvállalnod, és valahova menteni kell, illetve fel is kell tudni dolgozni a tárolt adatot, akkor a txt-t vagy bármi behányt szöveget azonnal felejtsd el, valami normálisan és hatékonyan feldolgozható formátumban mentsd el, legyen az JSON, XML, stb. Ha már az SQLite is szóba kerülhet, mint lokális, fájlba írós adatbázis, akkor már nem igazán értem, miért ne lehetne egy tisztességes adatbázis (nem lebecsülve az SQLite-ot, de nagyobb adatmennyiség esetén már nyilván nem ez a hatékony megoldás), onnantól már csak egy lépés.
Mi is pontosan az indoka a megrendelőnek arra, hogy nem lehet adatbázist használni?Amúgy ha már SQL parsert kell használnod, akkor nehogy elkezdd kézzel összetákolni, mert rohadt nagy szopás tud lenni egy parser, inkább használj fel egy kész könyvtárat:
https://code.google.com/p/php-sql-parser/
http://stackoverflow.com/questions/283087/php-mysql-sql-parser-insert-and-update/283115#283115Szerk.:
(#17290) PumpkinSeed: pont megelőztél.Amúgy egyetértek.
-
PumpkinSeed
addikt
válasz
Joci93 #17285 üzenetére
"Ahogy mondod. Meg kéne írni, hogy a SELECT,FROM, WHERE mit csináljon
"
Elnézést kedves Edgar F. Codd elsőre nem ismertem meg önt, az a helyzet, hogy nem 1970-ben vagyunk, rossz időben tetszik lenni. Már létezik az SQL, nem most kell kitalálni.
Na de most komolyan, miért kér egy megrendelő ilyen ostobaságot? Látszólag azt se tudja miről beszél, te meg hagyod, hogy ilyen hülyeségeket kérjen tőled. Az más lenne, ha komolyan megmondaná mit használj mondjuk NoSQL-t vagy valami de így, hogy ne használj adatbázist ez csak értelmetlen szavakkal való dobálózás. Fel kell világosítani, hogy kell ha adatokat akar tárolni és reális időn belül akarja visszakeresni. Használhattok .txt-t is, de ha az adatbázist a biztonságtalansága miatt nem kedvelte akkor ez azonnal meg is bukott, sőt még lassú is.
-
-
cidalain
veterán
válasz
Joci93 #17285 üzenetére
űrlap lehet a sima text beviteli mező is, az meg nem kötött. azt ír be amit akar.
az a baj hogy adott a tárhely, és nincs rajta adatbázis?
ha igen, én nem szarakodnék fájl alapú tárolással, elő kell fizetni egy normális adatbázisos tárhelyre. 10/év alatt már vannak. nem éri meg a vesződséget, amit nyerne a vámon a megrendelő elbukná a réven... -
PumpkinSeed
addikt
válasz
Joci93 #17276 üzenetére
Szögezzük le: Nem akarsz DB-t! De...
- "kiadja a lekérdezés eredményét"
Milyen lekérdezés eredményét? Nincs adatbázis amiből adatokat kérdezzen le.- "SELECT name FROM Test WHERE id = 1"
Hogy kerül ide SQL, mikor nincs adatbázis kezelő program se ami feldolgozza... vagy van adatbázis kezelő programod adatbázis nélkül?- "hogy a szintaxisa hasonló"
Esetleg te írod meg az adatbázis kezelőt és a hozzá tartozó strukturált lekérdező nyelvet illetve az adatok tárolására szolgáló állományokat is te generálod? Vagy hogy van ez? -
cidalain
veterán
-
PumpkinSeed
addikt
válasz
Joci93 #17223 üzenetére
Erre szerintem nincs beépített függvény de ha azt csinálod, hogy a egy for-al végigjárod a tömböd tartalmát majd az str_split() beépített függvénnyel azt egy karaktertömbbé alakítod és úgy vizsgálod meg akkor valószínűleg menni fog. pl.:
for($i = 0; $i<valamennyi;$i++){
$charArray = str_split($array);
for($j = 0; $j<count($sharArray);$j++){
if("}" == $charArray[j]){
echo "valami";
}
}
}(#17224) Sk8erPeter
Nem tudtam, hogy van erre függvény,
meg lehet kérdezni, hogy mi az?Gondolom az strpos(), most találtam meg.
-
Sk8erPeter
nagyúr
válasz
Joci93 #15894 üzenetére
"Részletes keresést $_GET[""]-el vagy $_POST[""]-al érdemes csinálni?"
A kérdés így kicsit furán hangzik. Most az a kérdésed, hogy GET-metódussal vagy POST-metódussal érdemes-e egy keresésre szolgáló űrlapot megadni (method-attribútumban)? Mert ha igen, akkor a GET-metódust szokás általános keresésekre használni, így a keresések könyvjelzőzhetők, elküldhetők másnak, stb., de ha elég összetett az űrlap, akkor nyilván az sem jó, ha minden be van hányva az URL-be, így ez esetben POST-metódus használható.
DE ami fontos, és ami miatt a kérdésed nem helyes, hogy a HTML-oldalnak semmi köze a PHP szuperglobális változóihoz, a GET és POST csupán HTTP-metódusok (amiket jelen esetben a form tag method-attribútumában adsz meg), a szerveroldal pedig az űrlap adatait fogadhatja bármi más szerveroldali nyelvvel, nem csak a PHP létezik; csak a PHP az ilyen nevű szuperglobális változókon keresztül teszi elérhetővé az ilyen metódussal - kliensoldalról - kapott adatokat. Ergo a kérdésed inkább úgy hangzana jól, hogy az ilyen-olyan keresőűrlapok adatait GET- vagy inkább POST-metódussal érdemes-e elküldeni szerveroldalra. -
fordfairlane
veterán
válasz
Joci93 #15897 üzenetére
25 checkbox esetén célszerű egy listát csinálni, és azon iterálva ellenőrizni, hogy melyik szerepel a bemenőparaméterek közt. A listában lehet egyéb opciókat is tárolni, ha bizonyos checkboxokat egyedileg kell kezelni, validálni, satöbbi.
Mivel nem írtál konkrétumot, így nehéz konkrétumot válaszolni, mindenesetre a 25 már akkora mennyiség, aminél valószínűleg érdemes generalizálni mind a checkboxok html renderelését, mind a submit feldolgozását, és az adattárolás részét. Kérdés, hogy technikailag felkészült-e vagy ilyenre vagy sem.
Alternatívaként érdemes szétnézni a PHP-s web frameworkök (Symfony, Laravel, Zend) form moduljai körül, amik pont ennek az automatizálására vannak kitalálva.
-
Sk8erPeter
nagyúr
válasz
Joci93 #15871 üzenetére
Szívesen.
"Jelenleg Eclipse-t használok."
Az is teljesen jó.Még szerkesztettem az előző hsz.-t, beleírtam, hogy tudod normálisabban kezelni a hibákat, még azt azért nézd meg.
Mondjuk én a mysqli-ről a helyedben inkább áttérnék PDO-ra, mint előbb látható volt, szebb tud lenni.A PDO-nál az előbb írt felparaméterezéssel ráadásul hibák esetén exceptionök dobódnak, az ilyen jellegű hibákat meg egy try {...} catch(...) {...} blokkban tök szépen le lehet kezelni.
(Amúgy a fentebbi kódot kézzel pötyögtem be, nem próbáltam ki, de remélhetőleg működik egyből.) -
Sk8erPeter
nagyúr
válasz
Joci93 #15869 üzenetére
Akkor már csináld objektumorientáltan, ha a lényege szintén az (és amúgy is sokkal szebb):
$mysqli = new mysqli('localhost', '*****', '******', 'test');
A hibaellenőrzés mondjuk nem objektumorientált, de még mindig jobb, mint az "or die(...)":
// check connection
if (mysqli_connect_errno()) {
$errorMsg = mysqli_connect_error();
// hiba volt, csinálj valamit a hibával ($errorMsg-ben lévő hibaüzenetet naplózd, írj ki felhasználóbarát üzenetet, ne hagyd folytatni a script vonatkozó részének végrehajtását, stb.)
}"Az "egyedi" változónevekről én tudom, hogy micsoda és az szerintem bőven elég"
Hát ez egy nagyon rossz hozzáállás. Nem elég! A kódod legyen később általad és akár más által is olvasható. Amúgy meg semmivel nem kerül több időbe normális változóneveket adni (jó, néha nem jut eszébe azonnal a legfrappánsabb név az embernek, akkor lehet, hogy 1-2 másodperccel több).
És ne Notepad++-t vagy valami hasonlót használj, hanem olyan fejlesztőkörnyezetet (IDE), ami normális támogatást ad a kódolásodhoz, és pl. Ctrl+Space-re kiegészíti a kódodat. -
Sk8erPeter
nagyúr
válasz
Joci93 #15866 üzenetére
A $bd->prepare előtti részt is oszd meg légyszi, hogy hogyan csatlakozol az adatbázishoz (nyilván a felhasználónév-jelszó infót csillagozd ki, vagy valami), és hogyan inicializálod a $bd változót. Egyébként ne használj ilyen változóneveket, mint a $bd, mert nem lehet belőle tudni, hogy az micsoda. Egy változónév legyen beszédes. Olyanokat se használj, hogy $res3, $uzenet2, $uzenet3, mert ez így katyvasz (miért pont 2? Miért pont 3?). Bár remélem csak a demókódodban vannak ilyenek. Illetve elírások: reciever --> receiver, RECIEVED --> RECEIVED.
Amúgy annyira gusztustalan ez a mysqli-s szintaktika (ezzel az $uzenet->bind_param('si', $uzenetszam, $zero); résszel), ha már ilyesmi, akkor PDO-val ezt sokkal szebben meg lehetne oldani, valami ilyesmi lenne ($idOfReceiver változó megfelelője a te kódodban az $uzenetszam):$idOfReceiver = 123123;
$hasReceivedMessage = 0;
$db = new PDO(
"mysql:host=localhost;dbname=test",
"root",
"root",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);
$stmt = $db->prepare("SELECT COUNT(reciever) AS uzenet FROM uzenet WHERE reciever =:receiver AND RECIEVED =:received");
$stmt->bindValue(':receiver', $idOfReceiver); // vagy bindParam
$stmt->bindValue(':received', $hasReceivedMessage); // vagy bindParam
$stmt->execute();
/*
// vagy egyben:
$stmt->execute(array(
":receiver" => $idOfReceiver,
":received" => $hasReceivedMessage,
));
*/
$numberOfMessages = $stmt->fetchColumn();
echo 'Number of messages: ', $numberOfMessages; -
PumpkinSeed
addikt
válasz
Joci93 #15817 üzenetére
Milyen hibát dob?
Ez így szerintem azért nem jó, mert gondolom azért használtál függvényt, hogy többször felhasználd a kódot, na így most minden függvényhívásnál "feleslegesen" includeolod a config.php-t. Ez olyan mintha minden mondatod előtt bevennél egy újabb Orbitot és a mondandód végére tele lenne rágóval a szád.
-
fordfairlane
veterán
válasz
Joci93 #14697 üzenetére
Akkor valószínűleg az átirányítás nem működik. A header csak akkor működik, ha előtte nem történt írás a kimenetre, a böngésző felé (akárcsak egy szóköz vagy sortörés, vagy hibaüzenet, bármi). Ha az output buffering localhoston be van kapcsolva, akkor ezt észre sem veszed, mert ilyen esetben késlelteti a kiíratást a PHP.
-
DeltaPower
addikt
válasz
Joci93 #14684 üzenetére
1. Nyisd meg inkognitó ablakban, ha úgy is egyből beenged akkor a kódban rossz valami.
2. Ennek miért kellene leszedni a .php végződést a linkekből? Ez azt csinálja, hogy minden nem létező fájlra mutató kérést átirányít az azonos nevű php-ra. Nyilvános tárhelyre így fel ne tedd az oldalt.
Új hozzászólás Aktív témák
Hirdetés
- OLED monitor topik
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Autós topik látogatók beszélgetős, offolós topikja
- Filmvilág
- Vegyszerek, permetezés, Élettani hatások
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- DUNE médialejátszók topicja
- További aktív témák...
- UF Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1360P 16/1TB Iris Xe 2,8K OLED 90Hz
- Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1260P 16/512 Iris Xe 2,8K OLED 90Hz
- Új DELL Inspiron 16 Fémházas Multimédiás Laptop 16" -40% Ryzen 7 8840U 8mag 16/1TB FHD+ IPS
- Új DELL Inspiron 16 Fémházas Multimédiás Laptop 16" -40% Ryzen 7 8840U 8mag 16/1TB FHD+ IPS
- Sony FE 28-70 mm F3.5-5.6 OSS
- BESZÁMÍTÁS! Apple MacBook Air 15 M3 8GB 256GB SSD garanciával hibátlan működéssel
- Eladó szép állapotban levő Huawei P30 Pro kék 6/128GB 12 hónap jótállással!
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- Telefon felvásárlás!! Xiaomi Redmi Note 10, Xiaomi Redmi Note 10s, Xiaomi Redmi Note 10 Pro
- Bomba ár! Dell Inspiron 15 3511 - i5-11GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Gari
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged