Új hozzászólás Aktív témák
-
tbs
addikt
Sztem cuckának nagyon igaza van. Élmény korrekt php kóddal találkozni. Az esetek 90%-ában php elsőnyelves szkriptkiddie az alkotó, nemkicsit zavaros kód.
Mondjuk programozást tanulni erősen típusos nyelvvel érdemes. Nem vagyok c fan (mer' nem típusos a szentem), ezért pascal és java. Pascal sohasem lesz igazán jó produkcióra, de tanulni jó vele. Java meg visz mindent. Ezek után ujjgyakorlat a c és a c++ (akárcsak fordítva), és rémüldözöl a php ''zagyvaságaitól''...
Ennél már csak a ''rendszergazda php''-zik műsor viccesebb... -
tbs
addikt
-
tbs
addikt
válasz Tippcsi10 #337 üzenetére
Hát az, amíről itt beszéltünk az előbb... A php megengedi a slendrián fogalmazást, így előfordulhat, hogy egy olyan rejtett hibahelyzetet fejleszt be az egyszeri programozó, ami akár évek múlva is okozhat fejfájást...
Tehát:
A $helyes változónak nincs alapértéke, tehát ha a foreach belsejében lévő feltétel sohasem teljesül, akkor nincs érteke, amit később le lehetne vizsgálni... Ha a foreach elé okosan beleapplikálod az inicializálását, megszűnik a hiba. ($helyes = false;)
A példa alkotója a balfax volt, mert hibahelyzetre nem tesztelt, csak jó futásra... -
tbs
addikt
-
tbs
addikt
válasz Protezis #355 üzenetére
''...hiaba hoz letre egy objektumot, a kovetkezo http keresnel az mar nem letezik...'' Jajajajajajj..! Pláne szervletekkel..! Mondd hogy vicceltél..!
''Web-re nem MVC-t...'' Tehát, a web, illetve a hosszú userwaitekkel tarkított állapotmentes felület/logika kapcsolat elfogadhatóan MVC struktúrával kezelhető. Ettől el lehet térni, de nem érdemes. Erre van rengeteg dekompozíciós tapasztalat. Persze ez egy vanmensónál mellékes... -
tbs
addikt
válasz Protezis #358 üzenetére
Hihi... Pedig értelmes mondat. Hangsúlyozd a NEM szócskát. Persze szívesen központoznám, de nem tudom hogy...
Semmiféle erőszakbűvészkedésre nem kell gondolni, de ha más java és szervletek, akkor 2 pillanat egy alkalmazásszervert összeütni a logikának, az pedig nagyon nem állapotmentes... Persistant objectek tömegével lehet variálni...
A http/web protokollra úgy kell gondolni, mint I/O szeközre: monitorra és billentyűzetre. Pici trükk, hogy rengeteg monitor és bill lehet egyidőben, de azért ez nem igazán nagy probléma: a legelső tömegszámítógépek is időosztásosak voltak már, könnyedén azonosították a különböző termináljaikat... -
tbs
addikt
Hmmm... A php 1-1 letöltés (függvényhívás) után, ha nem gondoskodsz róla, mindent ''elfelejt''. Amit szeretnél megoldható, de nem úgy, ahogy írtad.
Tehát: klikkelni kell a képekre és más-más változóértéket kell beállítani, majd egy egyéb klikkolásra a változó állapotától függően kell cselekedni..?
Ha a fenti a feladat, akkor 2 fő megoldási lehetőseg van.
1. Némi intelligenciát tuszkolunk a kliensoldalra. Keveset (ajax), vagy sokat (custom scriptek).
1a. Ajax: copy-paste tutorial megoldás, ügyes sessionkezeléssel a szerveroldalon. Ebben a megoldásban értelemszerűen erős szerveroldali támogatásra van szükség, viszont jól kézbentartható a működés, mert nem válik szét a működtető intelligencia.
1b. Custom szkriptek: pl. képklikkelésre input hidden value-k változnak, a főklikk pedig submit. Stb. Egyszerű megoldás, szétforgácsolt intelligencia (bár ebben az esetben ez mellékes).
2. Minden klikkelés megy egy kört a szerver felé. Ua. mint az ajax-os megoldás, csak új oldal lekérések lesznek. Lassú, atombiztos, 100% böngészőfüggetlen. Primitív, de jó működik, ha kézben tartható a frissülő oldal letöltési mérete. -
tbs
addikt
Mktime az unixtime. 197x-ben indul, 2037-ben átpördül. A 2000-es évmizéria kutyafüle volt ahhoz képest, ami akkor lesz; bár aki ezt használja, az megérdemli, hogy szívjon. Fájlrendszerek maximum. Komoly DB-k már régóta nem.
Próbáld kézzel számolni. Dátummanipulációt mindig illik rendszerfüggetlen műveletekkel végezni és a végén konvertálni, ha lehet és kell. -
tbs
addikt
válasz vakondka #410 üzenetére
Hmmm... A php-é meg nem..? Semmi veszélyes nincs benne, elhiheted. Php szemszögből hamar átlátható, könnyen lehet oop-s logikára ráépíteni, kiváló debug outputja van, stb. Arra viszont vigyázni kell, hogy a templatek-be ne sok logikát tegyen az ember: a smarty ''túl'' okos...
-
tbs
addikt
válasz vakondka #412 üzenetére
Hmmm... Párat kipróbáltam, szerintem smarty, de másnak biztos más tetszik. 90%-ban tetszés kérdése.
Jórészt smartyval dolgozom, ha php-s munka van. A felületeket egy grafikus lány szokta összerakni, én csak átalakítom smartyra. Azaz belerakom a ciklusokat a megfelelő helyre, meg kicserélem a konstans szövegeket változóra... Minden templétrendszer így működik. A smarty kielégíti a perverz programozó énemet.
Mindent meg lehet csinálni a templétrendszerekkel. Csak türelem kérdése... -
tbs
addikt
válasz Thunder78 #443 üzenetére
MD5, SHA1 -> hash, az input elvileg egyedi lenyomata. Ugyanarra az inputra ad csak ugyaolyan outputot. Ellenőrzésekre jó, pl. ahol direkt nem akarod tudni, hogy mi az eredeti szöveg. Vagy a szöveg vátozatlanságának ellenőrzésére.
Base64 -> röviden ''bitszámcsökkentő''. Benne van az adat, 0 titkossággal. Mintha nem is kódolnád.
A feladatra hash függvényt használnék. Ha tényleg lehet. Az jól mutat GET kérésben is.
Pdf-et generálnék az FPDF nevű cuccal. -
tbs
addikt
Hmmmm... select LAST_INSERT_ID() (sql) és mysql_insert_id() (php)
Ha ennél korrektebb meghatározás kell, akkor javaslom a 2fázisú insert-et: első körben egy dummy, de jól kereshető adattal insertálsz, amire select id from akarmi where data='dummyhash', és megvan az utolsó insert id. Aztán mehet az update a valódi adatokkal az id-re...
Amúgy ilyesmi technikával lehet kézihajtány tranzakciókat gyártani, ami nemritkán gyorsabb, mint a valódi...
Csak úgy, önmagában, az autoincrement állapotát nem tudod egyszerűen lekérdezni.
-
tbs
addikt
válasz Tele von Zsinór #610 üzenetére
Jó pap holtig...
-
-
tbs
addikt
mysql_query ( "SET NAMES 'utf8'", $this->resConn );
mysql_query ( "SET collation_connection='utf8_general_ci'", $this->resConn );
mysql_query ( "SET collation_server='utf8_general_ci'", $this->resConn );
mysql_query ( "SET character_set_client='utf8'", $this->resConn );
mysql_query ( "SET character_set_connection='utf8'", $this->resConn );
mysql_query ( "SET character_set_results='utf8'", $this->resConn );
mysql_query ( "SET character_set_server='utf8'", $this->resConn );A weboldal és a db kódolásának is érdemes azonos "nyelven" beszélnie.
-
tbs
addikt
Hát azt, hogy az előző sorok átlökik az akárhogyan beállított mysqld-t utf-8-ba, és ekkor ha a html head-ben szerepel a <meta http-equiv="content-type" content="text/html; charset=utf-8" />, akkor nincs kódkonverziós probléma.
Szóval a mysql konnekt után át kell lökni a db-t, a táblát, meg amit még tudsz a kívánt karakterkészletre, ami lehetőleg ugyanaz, mint a html I/O oldalé.
-
tbs
addikt
Mi a cél..? Én speciál egy trükkös, requestenként egyedi sztringet használok a kép azonosítására, aminek segítségével nyomonkövethető, hogy milyen ipről, milyen böngészőről, mikor, stb. linkelték tovább.
Egyszerű onclick vagy egyszerű anchor. Nálam semmi trükk.
(Nem vagyok híve a nem szerverkört befutó klikkeknek... )
[ Szerkesztve ]
Új hozzászólás Aktív témák
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Tőzsde és gazdaság
- Crypto Trade
- Mibe tegyem a megtakarításaimat?
- Samsung Galaxy A54 - türelemjáték
- Melyik tápegységet vegyem?
- Android játékok topikja
- Kertészet, mezőgazdaság topik
- Brawl Stars
- Azonnali informatikai kérdések órája
- További aktív témák...