- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- erkxt: A Roidmi becsődölt – és senki nem szól egy szót sem?
- Magga: PLEX: multimédia az egész lakásban
- droidic: Így beszélhetsz élő emberrel EA supportban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Elektromos rásegítésű kerékpárok
- sziku69: Szólánc.
- MasterDeeJay: Noname 1TB-os SATA SSD teszt
- hcl: MS Office365 Linuxon
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
ezt, amit az előbb írtam, nem olvastad?
Nem kell külön installer meg bohóckodások, egyszerűen rákeresel a WPI-ben, hogy MySQL, rákattintasz, hogy "Add" (vagy install, most nem emlékszem hirtelen, szóval ilyesmi), aztán rákeresel, hogy PHP, a megfelelőre szintén rákattintasz, aztán elindítod a telepítőjét, és ez minden szükséges függőséget behúz, ami kell. -
coco2
őstag
válasz
Peter Kiss #11897 üzenetére
Hát ha elég gyakorlott vagy benne, biztos csak két perc. Esetleg megemlíthetnéd a lényegesebb dolgokat, te mit szoktál abba a két percbe belesűríteni.
Találtam egy ilyen linket:
http://www.php.net/manual/en/install.windows.iis7.php-Bepippantottam windows összetevőknél azt a CGI pöttyöt.
-Leszedtem egy php 5.3 non thread safe msi installert, és telepítettem iis fast cgi-vel.SQL kapcsolatra jelenleg nem tartok igényt. Most csak a session id van nagyító alatt. Ezt az index.php-t:
<?php
session_start();
if (!isset($_SESSION["counter"])) $_SESSION["counter"]= 0;
$_SESSION["counter"]++;
echo "*".$_SESSION["counter"]."*".session_id()."*";
?>szeretném elérni http://127.0.0.1/index.php -val. Kell még nekem valami arról a fentebb linkelt cefet hosszú leporellóról, vagy a fenti két lépés már elég lesz? Apropó, merre találom a php root dir-t jelen esetben?
(Több alkalommal szerkesztve, bocsi, valami mindig kimaradt.)
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #11897 üzenetére
+1, de annyival korrigálnám, hogy telepítse nyugodtan a MySQL-t, összekattintgatós módszerrel, a Microsoft Web Platform Installer segítségével, összesen kb. 10 másodperc, megkérdezi azt is, hogy milyen root-jelszót szeretnél.
-
Peter Kiss
őstag
Mi lenne, ha nem a WAMP-ot használnád? IIS + PHP 2 perc alatt telepíthető (Windows XP és régebbiről nem nyilatkozom), adatbázist meg telepíteni se kell, ha pl. MySQL-ed van, akkor abból van "portable". Esetleg, ha ez nem fekszik, XAMPP vagy kézzel összelegózod az összetevőket.
-
coco2
őstag
válasz
Sk8erPeter #11894 üzenetére
Enyhén mókás, hogy a wamp apache-ban alapból nem volt beélasítve sem a session modul, sem a session cookie modul. Bekapcsoltam, restart. Sajnos a helyzet ugyan az. Nincs a headerben Set-cookie.
-
coco2
őstag
válasz
Sk8erPeter #11887 üzenetére
Header egy wamp apache szervertől:
{
"Cache-Control" =
"no-store, no-cache, must-revalidate, post-check=0, pre-check=0";
"Content-Length" = 53;
"Content-Type" = "text/html";
Date = "Fri, 16 Nov 2012 13:15:47 GMT";
Expires = "Thu, 19 Nov 1981 08:52:00 GMT";
Pragma = "no-cache";
Server = "Apache/2.4.2 (Win64) PHP/5.4.3";
"X-Powered-By" = "PHP/5.4.3";
}Header a google.com címről:
{
"Cache-Control" = "private, max-age=0";
"Content-Type" = "text/html; charset=ISO-8859-2";
Date = "Fri, 16 Nov 2012 14:29:25 GMT";
Expires = "-1";
P3P = "CP=\"This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.\"";
Server = gws;
"Set-Cookie" = "NID=66=BPhukWJ9yxeHm7WjfVG8yN-N1CfFQpaKj5iYDBFCBtkgb8_ApFpOV3mx0EP_j_lllCxf8K82hQ5LiyQigChGhiD_rmeCeRbgbBahrhWHiq9Okq9d-2bCLze0OxmCvDwu; expires=Sat, 18-May-2013 14:29:25 GMT; path=/; domain=.google.hu; HttpOnly";
"Transfer-Encoding" = chunked;
"X-Frame-Options" = SAMEORIGIN;
"X-XSS-Protection" = "1; mode=block";
}Az a bizonyos Set-Cookie az, amit hiányolok. Ha nem php szinten van a bűnös, akkor kotrok mélyebbre.
-
Lacces
őstag
válasz
Peter Kiss #11891 üzenetére
-
Peter Kiss
őstag
válasz
Lacces #11890 üzenetére
A PHP ad rá "keretet" (http://php.net/manual/en/session.customhandler.php), több gyakorlatilag nem is kell, mert onnantól egyértelmű, mikor mit kell csinálni, a megvalósítás pedig már nagyban függ attól, mi van a rendszer körül.
-
Lacces
őstag
válasz
Peter Kiss #11889 üzenetére
Aha, köszi.
Van erre ajánlott általános séma, hogy hogyan kell egy ilyen session osztályt implementálni, vagy kezelni a session-t, ha adatbázisban akarom tárolni őket? Valami példaprogram / kód, amit ajánlasz tanulmányozásra?
Ahogy szétnéztem a neten, többféle is van, de hogy melyiket használjam azt még nem tudom. -
Peter Kiss
őstag
válasz
Lacces #11888 üzenetére
Bármikor célszerű lehet, ha nagyobb kontrollt szeretnél a session-ök fölött (néha a biztonságot is említik itt), de számolni kell a remote call költségeivel, viszont, ha több alkalmazás függ elvileg azonos session-öktől, akkor kötelező adatbázisba (vagy más tárolóba) központosítani mindent (ugyanez ll arra is, ha az alkalmazást elosztott környezetben szolgálod ki több webszerverről).
-
Lacces
őstag
Sziasztok!
Mi a véleményetek arról, hogy mikor érdemes / célszerű a Session-öket adatbázisban tárolni?
-
Sk8erPeter
nagyúr
Hát onnan tudja, hogy alapértelmezettként a böngésző bezárásáig "él" egy munkamenet. Tehát egy bejelentkezős rendszernél ez azt jelenti, hogy amennyiben alapértelmezetten van minden, a böngésző újraindítása esetén kijelentkeztet.
session_name()-mel egyébként megadhatsz egyedi session nevet (és lekérheted a korábbit) a PHPSESSID helyett, session_id()-vel lekérheted/beállíthatod az aktuálisat (session_start() előtt), ezekkel is kísérletezgethetnél, miket ad, ha használod őket. -
coco2
őstag
válasz
sztanozs #11885 üzenetére
Ahogy nézem default-on van minden. Leginkább a session.auto_start volt gyanús, de amikor átállítom 0 -> 1, azonnal pampogni kezd a php, hogy a session már el van indítva, ergo session_start() tilos. Szóval az sem az, amire gondoltam.
Jelenleg olybá tűnik nekem a webszerver viselkedése, mint ami beazonosítja, hogy milyen ip:port van a küldő mögött, és amíg azt látja a küldőtől, addig egy saját jogon eldöntött session id-t rendel hozzá, amit egyáltalán nem szándékozik a kliens orrára kötni. Ez nekem valamiféle agyonóvatoskodott hekkelés védelemnek tűnik, de nem találtam olyan beállítást, ami konkrétan erről szólna, ergo nem tudom kikapcsolni.
Kicsit filozom még a session.cookie_lifetime-on is, hogy át kell-e állítanom nulláról (default), merthogy talán azért adja nekem mindig ugyan azt. Php-ban kiírom echo-val a session id-t, és látom, hogy mindig ugyan az, bármit is csinálok. Böngésző restartig nem változik meg. Tudnám, honnét a fenéből ismeri fel, hogy böngésző restart volt..
-
coco2
őstag
Sziasztok,
Kicsi segítség kellene nekem session kezelés ügyben. Windows alatt az újabb wamp csomag van fent, és index.php-ra betettem egy ilyet:
<?php
session_start();
echo "X";
?>Írtam külön natív nyelvben egy kicsi http lekérdezőt, amiben a session id-t szeretném megkapni, és kiírni. A talált doksik szerint a session id-nek a fejlécben kellene lennie set-cookie alatt, de én olyat nem találtam. A szervertől első kapcsolat felvételre visszajött a body-ban az X, és a fejlécben ez (szétszedtem sorokra a könnyebb olvashatóság kedvéért):
{
"Cache-Control" =
"no-store, no-cache, must-revalidate, post-check=0, pre-check=0";
"Content-Length" = 53;
"Content-Type" = "text/html";
Date = "Fri, 16 Nov 2012 13:15:47 GMT";
Expires = "Thu, 19 Nov 1981 08:52:00 GMT";
Pragma = "no-cache";
Server = "Apache/2.4.2 (Win64) PHP/5.4.3";
"X-Powered-By" = "PHP/5.4.3";
}Namost ebben nagyon nincsen session id. Nyálazom a doksikat órák óta, és arra jutottam, hogy az apache lehet a hunyó. Lehet valamit trükközni a wamp apache-al, ugyan ugyan szíveskedjék már.. ? Vagy valami egyéb okosságot kell kitalálni?
Minden tippet előre is köszi.
-
cucka
addikt
válasz
Peter Kiss #11879 üzenetére
Jaja, az fopen végére kell egy "or return array()". (Vagy lehet dobni kivételt is, ízlés szerint)
Plusz a html összerakó rész megcsinálható 2 sorban, kell hozzá 1 darab array_map meg 2 darab implode és megspórolható a dupla ciklus. Ha valakinek van kedve, elszórakozhat ezzel.
-
dodopek
addikt
találtam megfelelőbb topicot...
-
Speeedfire
félisten
Egyre menőbb ez a topic.
-
Peter Kiss
őstag
válasz
Swifty #11878 üzenetére
Sebesség: talán az enyém gyorsabb.
Ez a premature optimization. Nem tudom megmondani, igaz lehet-e, szerintem nem/mérhetetlen különbség.Memória használat: biztos, hogy kevesebb memória kell az enyémnek.
Téves, alapból nem lehet biztos.
- felolvasod az egész fájlt egyszerre, bent is tartod a parse végéig a memóriában
- parsolt adatokat értelem szerűen szintén bent tartod ($tables, második foreach-ben már talán a GC kitakarította a felolvasott cuccokat), emellett az első megoldásodban háromszor használtál ternary operátort egymás után, ami pontosan 2 db teljes tömbmásolást jelent. Ehhez jön, hogy ez borzasztó drótozott megoldás volt.
A kódod fut 5.3-as PHP verzióbál régebbin is, ott nem volt még normális szemétgyűjtés, szóval veszélyes lehet.Hossz: az enyém rövidebb.
Csak nem lehet elolvasni.Átláthatóság: egyén függő. Ki mit ismer jobban.
Jó OO kódot mindenki elolvas, mert értelmes, egyszerű elemekből áll.Bővíthetőség/kiterjeszthetőség: Athlon64+ kódja könnyebben származtatható. Az enyém "direkt" kód erre a problémára.
Az enyémben a parser szar, legalább egy absztrakció hiányzik.Hibakeresés: egyén függő. Talán a kód hossza miatt mondanám, hogy az enyémben könnyebb.
@ operátort használsz, szerinted azzal mennyire egyszerű a hibakeresés?---
@cucka: Ez már legalább olvasható, könnyen szétszedhető az említett két darabra. A resource létrejöttének az ellenőrzése tényleg kellene.
---
Érdekes, hogy csak én olvastam fel CSV-ként.
-
Swifty
csendes tag
Hibajavítás... Mert persze volt benne, és mert tanultam egy új függvényt
-
cucka
addikt
válasz
Swifty #11870 üzenetére
Benevezek én is a versenyre, várom a zsűri véleményét
Ez egy függvény, ami egy tömböt ad vissza, elemei html táblázatok (ugye gondolunk arra, hogy talán el szeretné őket helyezni az oldalon). További előnyei, hogy nem csak 3 oszlopra működik, mellékhatásmentes és el lehet olvasni (azt az egész képernyőt betöltő sorodat hamarabb újraírom, mint hogy értelmezzem, mit csinál).
[link]
Ja, és normál esetben elég nagy fasság ilyen függvényeket írni, legalábbis mvc-ben a függvény első fele az m vagy a c dolga (ízlés dolga), a második fele pedig a v-é. -
Swifty
csendes tag
válasz
Sk8erPeter #11873 üzenetére
Nem akartam én megaszondani senkinek...
A nyelv rejtelmeit megosztani én is szeretem, hiszen mindennap tanulhatsz valami újat, érdekeset, mást...
Csak tudod... Egy kb. 20 (érdemi) soros megoldásra ráeröltetni mindenáron OOP-t... Háááát... Nekem nem jön be... Amit Athlon64+ tűzzel-vassal véd, az nálam kiverte a biztosítékot... Sorry...Lehet rosszul fogalmaztam, de nekem az jön le, hogy főleg olyanok jönnek ide segítséget kérni, akik elég "kezdők"... És ha így nézem, akkor nem is az hogy nekik szól, vagy nekik lett nyitva, de az ő problémájukkal foglalkozik leginkább a topik... Vagy rosszul érzem?
És ehhez mérten nehezen veszi be a gyomrom, hogy mindenképp OO kell, meg hogy a szkriptnyelvek mennyire nem alkalmasak semmire... Ezzel azt hiszem, el is tántoríthatunk kezdőket a PHP használatától. Pedig pont hogy segíteni kellene mindenkit aki ide jön a problémájával.
Igaz, a kódomat nem lehet paraméterezni, de nem is volt szándékomban.
Ciklussal azért nem tenném meg, mert akkor igaz, hogy a 3 isset-es részt megsprórolnám, viszont nevesítenem/példányosítanom kellene egy tömböt, amibe tenném a sorok elemeit, és a végén ezt a tömböt kellene felfűzni az "anyatömbre". Persze ha mondjuk 20 db elem lenne, akkor a ciklus befigyel.
Nézzük pro és kontra a két verziót:
Sebesség: talán az enyém gyorsabb.
Memória használat: biztos, hogy kevesebb memória kell az enyémnek.
Hossz: az enyém rövidebb.
Átláthatóság: egyén függő. Ki mit ismer jobban.
Bővíthetőség/kiterjeszthetőség: Athlon64+ kódja könnyebben származtatható. Az enyém "direkt" kód erre a problémára.
Hibakeresés: egyén függő. Talán a kód hossza miatt mondanám, hogy az enyémben könnyebb. -
Sk8erPeter
nagyúr
válasz
Swifty #11870 üzenetére
Jobb lett volna, ha korábban jössz konkrét ellenvéleménnyel a problémával kapcsolatban, és nem csak annyi látszik az egészből, hogy Te most jól "megaszontad".
A hsz.-ek száma max. annyiból számít, hogy utal arra, mennyire látsz bele mondjuk a fórum működésébe, mennyire vetted fel a fórum ritmusát. Ha egyből azzal kezded a tevékenységedet, hogy beoltasz embereket, hogy most már aztán hallgassanak el, milyen alapon merészelnek itt túl magasszintű társalgást folytatni a nyelv rejtelmeiről, akkor az úgy elég érdekesen veszi ki magát. De ha egy kicsit jobban belegondolsz, nem értesz ezzel egyet?
Nem tudhatom, neked túl magas-e a dolog, vagy nem, mert fogalmam sem lehet a tudásodról, eddig csak annyit láttam belőled, hogy beszóltál, hogy legyen vége a témának, mert ez a topic elsősorban szerinted a kezdőknek szól (pedig sehol nincs ilyen szabály, legfeljebb Te így képzeled el, pedig nagyon gáz lenne), ebből a szemrehányásból pedig nehéz arra következtetni, hogy vágod a témát (de ettől még penge is lehetsz benne).Kódból most csak egy sort emelnék ki:
if(($split=explode(';',$line))!==FALSE)$tables[$split[0]][]=array((isset($split[1])?$split[1]:''),(isset($split[2])?$split[2]:''),(isset($split[3])?$split[3]:''));Szerintem az ilyen szinten bedrótozott megoldások nem túl jók, nem lehet megváltoztatni, hány elem érdekes, és akkor már ilyen ismétlődő dolgok helyett (végül is 3-szor írod le ugyanazt) ciklusban kellene feldolgozni az adatokat.
-
Swifty
csendes tag
válasz
PazsitZ #11871 üzenetére
Jajj wazzz...
Nem akarok én itt senkit sem oltani... TÉGED sem... Én csak értetlenkedtem, hogy miért szólítasz meg...
Asszem én is csak félig olvastam el a válaszod...Kérdésedre válaszolva: Nincs megtiltva, (én sem tilthatom meg - szerencsére
) hogy miről csevegünk itt..
Csak felvetettem, hogy az ADOTT kérdésre Athlon64+ megoldása (szerintem) túl "elrugaszkodott"...A válaszaim valószínű túl erősek voltak, és erre most páran felkapták a vizet. Ezért újból elnézést kérek.
Remélem kielégítő választ adtam...
-
PazsitZ
addikt
válasz
Swifty #11870 üzenetére
Valóban, nem szólítottál meg.
Elnézést kérek, nem gondoltam át ezt a dolgot, csak sebtiben belevágtam a válasz linkbe. Így történhetett az meg, hogy reagáltam a hozzászólásodra.
Becsszó, ígérem vigyázok, többet iylen ne történjen.U.i.: Semmit nem vettem magamra csak kifejtettem, hogy nem értek egyet és kérdést fogalmaztam meg, amire látom nem megy a válasz. Jah, de persze, hát nem szólítottál meg.
-
Swifty
csendes tag
válasz
Sk8erPeter #11861 üzenetére
@cucka:
Válaszod első részével egyetértek. A második résznél: én sem azért írtam, hogy panaszkodjak.
Véleményt formáltam, amit itt nem lehet.@Sk8erPeter:
Nagyon sajnálom, hogy elhalt a vita... Nem beledumálni szerettem volna, hanem csak hangot adni annak a véleményemnek, amit már párszor kifejtettem, mégpedig az "ágyú - veréb" esetet az ADOTT feladathoz mérten.Hogy lehessen erről is csámcsogni beillesztem az én verzióm:
<html>
<head>
<title>teszt</title>
</head>
<body>
<?php
if(($data=@file_get_contents('test.txt'))!==FALSE){
foreach(explode(PHP_EOL,$data) as $line)if($line!=''){
unset($split);
if(($split=explode(';',$line))!==FALSE)$tables[$split[0]][]=array((isset($split[1])?$split[1]:''),(isset($split[2])?$split[2]:''),(isset($split[3])?$split[3]:''));
}
if(isset($tables))foreach($tables as $id => $table){
?>
<table>
<thead>
<tr>
<?php echo ' <th colspan="3">Tábla '.$id.'</th>'.PHP_EOL; ?>
</tr>
</thead>
<tbody>
<?php
foreach($table as $line){
?>
<tr>
<?php
foreach($line as $value)echo ' <td>'.$value.'</td>'.PHP_EOL;
?>
</tr>
<?php
}
?>
</tbody>
</table>
<br />
<?php
}
}
?>
</body>
</html>@Soak és Sk8erPeter:
Akkor kérésetekre abbahagyom az off-ot...Nem mondtam, hogy prioritást élveznek a kezdők... Azt mondtam, hogy sok olyan kezdő jön ide, (a lama kérdések nagy részét ők teszik fel) akik a PHP-s problémájukra keresnek megoldást.
Miből gondolod, hogy nekem túl magas a dolog?
@Athlon64+:
Bocsánat, hogy ilyen szürke lett... Nem ezt akartam és téged sem megbántani... Nekem is elgurult a gyógyszerem...De azért nem is olyan rossz szín ez a szürke...
@PazsitZ:
Bocs a hülye kérdésért, de melyik hozzászólásomban szólítottalak meg? Mit vettél magadra?@Sk8erPeter:
Most komolyan a hozzászólások száma számít? -
Peter Kiss
őstag
válasz
Sk8erPeter #11868 üzenetére
Ki tudják törölni a felesleget.
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #11867 üzenetére
Nem, szerintem ezt meg tudjuk oldani mi is, moderátorok nélkül...
Remélhetőleg eléggé rászálltunk ahhoz, hogy megértse a lényeget (hogy menjen innen, ha nem tetszik a rendszer
).
Miért szereted te ennyire a modikat?Tök felesleges bevonni őket, most mondják ugyanazt neki, mint mi? Semmi értelme, ez csak ilyen nevetséges erőfitogtatás lenne (korábban is ugyanezt magyaráztam neked, amikor ezt velem szemben játszottad el, vagy mással, azóta sem változott a véleményem erről
).
(#11866) PazsitZ :
"Én lassan emiatt a hozzáállás miatt fogom törölni már az értesítést erről a topikról"
Na igen. Örültem, hogy végre érdekes témáról van szó, erre valaki ebbe is beleugat, hogy ne. (ráadásul újonc, 25 szakmai topicban tett hozzászólással, 6 ebből itt született, és csupán 1 db (!!) vágott ténylegesen a témába)Amúgy bocsi, itt a felsorolásban véletlenül fordfairlane-t írtam PazsitZ helyett.
(pedig az említett illető nem járt errefelé régóta)
-
Peter Kiss
őstag
válasz
Sk8erPeter #11863 üzenetére
És akkor most menjek a modkerbe? Menjen már most valaki más, mindig én vagyok a hunyó.
Vagy előtte még megvitatjuk, mit szabad és mit nem kérdezni? Ezt meg szabad egyáltalán kérdeznem? Mit tettem?! -
PazsitZ
addikt
válasz
Swifty #11852 üzenetére
Nem értem miért ne lenne helye elméleti tervezési kérdéseknek is akár?
Vagy csak az szabad kérdezni, hogy ez az error message, melyik sorban miért van szintaktikai hibám?
Nem szabad osztályokkal megoldani egy problémát, tervezési minta alapján levezetett megoldást adni, mert az már nem ez a topik?
Akkor melyik is az a topik?Már felvetődött párszor és talán tényleg idegesítőbb azt beírni minden héten, hogy a 3 mezős formot, hogy kell letárolni.
És légy oly szíves nem kiforgatni a szavaimat. Én is voltam kezdő, amit most megfogalmazok egyáltalán nem erről szól. De kérdései -remélem belátható- nem csak a kezdőknek vannak és talán nem mindenki a feladatot éppen ellátó legprimitívebb megoldást várja.Én lassan emiatt a hozzáállás miatt fogom törölni már az értesítést erről a topikról, bár már eddig is egyre-egyre hanyagoltam az olvasását...
-
cucka
addikt
válasz
Peter Kiss #11862 üzenetére
"~2 éve nem is fejlesztek php-ban" - így egy kicsit világosabb, miért írtad azokat, amiket.
Márhogy pontosan mi lett világosabb ettől az információtól?
(Amúgy igen, maradtam a szkriptnyelv vonalon, de lehet, hogy 1 éven belül már java fejlesztő leszek, legalábbis ez a valószínű forgatókönyv) -
Sk8erPeter
nagyúr
válasz
Peter Kiss #11862 üzenetére
Hát ja, mióta belépett, kábé a topic fele szürkebetűs lett...
-
Peter Kiss
őstag
@cucka
"~2 éve nem is fejlesztek php-ban" - így egy kicsit világosabb, miért írtad azokat, amiket.
"Na, hát csak kibújt a szög a zsákból."
---
@Swifty
Az valóban nem érdekes, hogy újoncként vagy itt, vagy nem, az annál inkább, ahogyan bevágódtál a beszélgetésbe.Sokkal jobb így, rengeteg off-fal ez a topik, nem? Igazán barátságos lett!
-
Sk8erPeter
nagyúr
válasz
Swifty #11859 üzenetére
Csatlakoznék Soakhoz a kérdéssel: áruld el, honnan szedted, hogy prioritást élveznének a kezdőbbek?
Ebből látszik, hogy újonc vagy, mégis meg akarod mondani a frankót. SzéjjelOFFolod a topicot, miközben pont ezért oltottál mást; plusz túl terjengősen fogalmazol. Nem "savazta" a két oldal a másikat, hanem a topichoz kapcsolódó szakmai vitát folytattak, és ez teljesen helyénvaló. Az, hogy mindezt valaki le akarja állítani, mert neki túl magas a dolog, az már nem az. Remélem, végre megérted, miről vakerászunk, és abbahagyod az OFF-ot, köszi!
-
Swifty
csendes tag
válasz
Sk8erPeter #11855 üzenetére
Na most azt ne firtassuk, hogy mitől átlag az átlagközönség... Szerintem igenis nekik van a topik első nekifutásra... És persze más is jön ide...
Ha valakinek azt mondod, hogy a warp-hajtómű azért jó, mert a hipertér görbületét jobban lovagolja meg a tér görbületét, miközben ő csak el akart jutni A-ból B-be, akkor azt hiszem nem igazán segítettél...
Nincs megszabva a mérce... Nem is lehet... De ha van egy "egyszerű" kérdés, amire "egyszerű" válasz van, akkor nehogymá csak a hiper szuper .NET, satöbbi legyen a megoldás... Főleg, ha PHP-ről beszélünk...
Nem akarom megmondani miről szóljon a topik... Csináljátok, ahogy nektek tetszik... Csak azt látom, hogy mindkét oldal elkezdte savazni a másikat...
Mellesleg megjegyzem, hogy nekem meg ez a véleményem... Nekem túl sok volt az "ágyúval - verébre"...
(Ne vedd sértésnek, de az hogy itt újonc vagyok, az semmit nem jelent.)
-
Sk8erPeter
nagyúr
válasz
Swifty #11857 üzenetére
Erről ment éppen a vita, és a vita szerintem teljesen konstruktív volt (épp több helyről is elhangzott az ellen is érv, hogy csak az OOP lenne az egyetlen jó megoldás), egészen addig, amíg el nem kezdtetek beledumálni, hogy ugyan ne legyen már itt vita, mert micsoda dolog, hogy nem a gyökér kérdések vannak a fókuszban. De legalább elintéztétek, hogy ez a vita is elhaljon. Ha nem értesz vele egyet, hogy csak az OOP lenne a jó megoldás, akkor szólj hozzá a vitához ÉRDEMBEN, és ne csak pattogj, hogy neked nem tetszik, amiről itt szó van.
-
Swifty
csendes tag
Megkövetlek benneteket, tényleg nincs leírva, hogy ez egy kezdő/haladó/expert topik...
Amint írtam, beszélgessünk... Akár a TDD-ről...Nekem arra sült el az agyam, hogy a probléma megoldása lassan már abba az irányba mutatott, hogy csak egyfajta (értsd: OOP és társai) megoldás létezik...
Sorry, ha túl agresszív vagy érthetetlen voltam...
-
cucka
addikt
válasz
Swifty #11852 üzenetére
Ebben a topikba járnak kezdők, haladók és profik is. Na a kontent is pont ezt fogja tükrözni.
Ha kizárólag banális, 3 perc gúglizással megoldható, középiskolai házifeladat szintű dolgokkal találkoznék itt, akkor nem olvasnám a topikot, és szerintem ezzel nem csak én vagyok így. (Főleg így, hogy ~2 éve nem is fejlesztek php-ban)
A topik címe "php kérdések", nem pedig "php gyorssegély kezdőknek".És bocs, de pont lesz*rom, hogy lesznek látogatók, akik nem értik azt, amiről a beszélgetés folyik. Én sem értek sokmindenhez, mégsem megyek oda a megfelelő szakmai topikba emiatt panaszkodni.
-
Sk8erPeter
nagyúr
válasz
Swifty #11852 üzenetére
"Másik oldalról a TDD és társai említése szerintem már a ló másik oldala... Tényleg lehet róla vitázni, elmélkedni, stb... De az "átlagközönség" fikarcnyit sem ért belőle... Na most ezeknek szeretnéd megtanítani az egyes tematikákat??? Nem hiszem, hogy a legtöbbjük tudja, hogy milyen egy interfész vagy egy absztrakt osztály..."
Megint csak nem értek egyet. Miért, szerinted ez a topic az "átlagközönségnek" van? NEM, a PHP iránt érdeklődőknek. Ha valaki nem érti, miről van szó, mert neki túl magas, az ne legyen felháborodva azért, hogy olyan témákat feszegetnek itt, amihez neki már nincs köze... hanem olvasgassa, tanuljon belőle, vagy ugorjon át rajta. Azért nehogy már meg legyen szabva a mérce, hogy milyen témákat lehet MÉG tárgyalni, tartva attól, hogy esetleg pár újonc nem érti azt... Így akár ki is halhatna a topic, és megmaradhatna "hogyan legyünk lusták, és kérdezzünk meg alapdolgokat próbálkozás és utánanézés nélkül a hozzáértőbbektől"-topic szintjén is.
Most épp Te estél át a ló túlsó oldalára, megpróbálod megmondani, miről szóljon a topic, újoncként. Bocsi, de ez azért nem így megy. És ezt most ne vedd sértésnek, mert nem annak szánom. -
cucka
addikt
válasz
Inv1sus #11848 üzenetére
Az a baj, hogy szar a reguláris kifejezés, amit használsz. A minta, amire keresni kell, az úgy néz ki, hogy width="...", ahol a három pont helyén bármilyen karakter lehet, ami nem idézőjel.
Én így oldanám meg, próbáld értelmezni. A minta végén a \s az bármilyen whitespace karakterre match-el, ebből tetszőleges számút szintén kidobok, szóval a végeredményben nem lesznek fölösleges szóközök, a minta végén az i betű pedig azt jelenti, hogy kis-nagybetűket ne vegye figyelembe (case insensitive) :
function process($str){
return preg_replace(
array(
'/width=\"[^\"]+\"\s*/i',
'/height=\"[^\"]+\"\s*/i'
),
array('', ''),
$str
);
} -
Soak
veterán
válasz
Swifty #11852 üzenetére
Félre ne érts! Beszélgessünk ilyenekről, de (szerintem) nem ezért van itt EZ a topik.... Vagy tévedek?
Tévedész, senki nem írta, hogy ennek a topiknak csak arról kell szólni, hogy hogyan dolgozzunk fel formot és hogyan olvassunk $_GETből . Ez egy szakmai topik ami szakmai kérdésekről szól, azért ne legyen senki hibás mert egy szinvonalas 'vitában' részt vesz, a véleményétől függetlenül , azért mert többen vannak akiknek csak annyira lenne szükségük, hogy megírjanak egy kódrészletet vagy valami alap tákolást kell gyorsan eszközölni még nem jelenti azt, hogy nem lehet másról beszélni.
U.i.: Akkor szoktak a legjobb válaszok érkezni amikor valaki a megoldásához (már folyamatban lévő) segítséget kér és logikai kérdéseket kell megvitatni, nem pedig szintaktikai meg alapvető dolgokat n+1szer elmagyarázni.
-
Swifty
csendes tag
válasz
Peter Kiss #11851 üzenetére
Nehéz kérdés, de legyünk őszinték: Ide azért írnak a kollégák, mert valami nyűgjük van és segítséget keresnek... Ha így nézem, akkor minden hozzátartozik... (Persze azért ne ott kezdjük, hogy hogy kell IP címet beállítani egy gépnek.)
Másik oldalról a TDD és társai említése szerintem már a ló másik oldala... Tényleg lehet róla vitázni, elmélkedni, stb... De az "átlagközönség" fikarcnyit sem ért belőle... Na most ezeknek szeretnéd megtanítani az egyes tematikákat??? Nem hiszem, hogy a legtöbbjük tudja, hogy milyen egy interfész vagy egy absztrakt osztály...
Félre ne érts! Beszélgessünk ilyenekről, de (szerintem) nem ezért van itt EZ a topik.... Vagy tévedek?
Semmi gond azzal, hogy tűzzel-vassal védesz valamit... De azért ne haragudj meg, ha valaki a Te tüzedre-vasadra ágyúval-atombombával fog válaszolni... (Azt gondolom, hogy több megértést kellene mutatnod a "pórnéppel".)
Kétségtelen, hogy sok pongyola megfogalmazású, elsőre érthetetlen kérés merül fel... De azért mindenre OOP-t zengeni...
Azt gondolom, hogy a körülmények ismerete nélkül a tömben tárolás is jobb megoldás (főleg, ha egy kezdőnek IDŐRE kell elkészíteni valamit, aminek "csak" mennie kell), mint hogy végigvezessük a különféle tematikákat....
Csapatban fejleszteni, és mindenféle szabályokat betartani közben teljesen más, mit a "most kell - egyszer - nekem" kategória... Ehhez meg én ragaszkodok foggal-körömmel...
Még egyszer elnézésedet kérem, ha túl erősek voltak a szavaim... De nekem tényleg kötözködés, és szerintem nem ide tartozik az amit írsz... És ezt mondom úgy, hogy nem akarom becsmérelni azt, hogy mit tudsz vagy mit tartasz ésszerűnek...
-
Peter Kiss
őstag
válasz
Swifty #11850 üzenetére
Igen, valóban kötődik hozzá, de vajon egy webszerver vagy a programozástechnika kötődik-e hozzá jobban (esetleg a második egyáltalán nem?), nehéz kérdés.
Ha jól rémlik, egy felvetődött problémára adott konkrét megoldás-válasz kombinációm indította el mások elméletgyártását, ennek következtében tűzzel-vassal védtem az enyém, és ez így is lesz. Volt már hasonló, akkor is leugattak (igen, neked is sikerült *), és ez nem is fog változni, következőnél újra le fog ez játszódni.
(Ágyúval verébre dologról jutott eszembe, ki csinált ilyesmit (tömbbe fogott össze pl. SQL query egy rekordját):
$user = array("ID" => "1", "Name" => "Bruce Wayne");
Ettől nem értelmesebb egy User osztály, ami, ha csak POPO is, de már értelmesebbé teszi az összes kódrészletet, ami használja?)
* azzal, hogy megkérdezted "mi a f*szt keresel itt", plusz kötözködésként nevezted meg az érvekkel alátámasztott nézeteimet, míg mások annyit mondtak, "felesleges bonyolítás" (ezért is mennyit fogok még kapni vajon).
-
Swifty
csendes tag
válasz
Peter Kiss #11842 üzenetére
Igen, ez PHP topik... De a PHP foglalkozik MySQL-el és kötődik hozzá az Apache...
Ha nem szeretnéd ezt olvasni, akkor javaslom, hagyd ki a kérdést.
Igazad van, én is kihagyhatnám, hogy Neked válaszoljak...Benne vagyok én is a témában (már ha itt arra célzol, hogy programozok-e PHP-ben vagy más nyelven, esetleg ismerem-e az OOP-t).
Természetesen enyém volt az "első" offtopic, de ha jól emlékszem, akkor meg is jelöltem, hiszen arra próbáltalak rávezetni, hogy nem csak beszélni kellene a howto-król, hanem meg is kellene mutatni hogy mit hogyan.... Javítom magam: inkább szerintem pont ezt kellene "erőltetni", és nem az elméleteket gyártani...
Személyes véleményem, hogy szép az OOP, de vannak olyan esetek, amelyikben teljesen "ágyúval a verébre" effektust generál, ha mindent objektumban kell legenerálni...
Már ne is haragudj, (és elnézésedet kell kérnem, ha úgy vetted) de nem kiabáltalak le... Nem annak szántam, hanem inkább annak, hogy légyszi gondold át, hogy mit írsz... Elhiszem, hogy milyen nagy dolgokat írtál már, illetve hogy milyen szuper tematikákat ismersz, de azt gondolom, hogy ez nem segít mindenkinek...
Itt problémák merülnek fel, amikre megoldásokat kell(ene) találni, akár a google segítségével, akár azzal, hogy elmondjuk, mennyire szarul képzeli el a delikvens az adott problémát...
Köszönöm, hogy elolvastad a válaszom és hogy bekattintottad az offtopic-ot !!!
-
Sk8erPeter
nagyúr
válasz
Inv1sus #11848 üzenetére
Igen, mivel te a stringed legvégére adtad meg a width és height attribútumokat...
Te arra számítasz, hogy mindig így lesz? És arra számítasz, hogy csak és kizárólag <img> tagek lesznek a stringedben? (utóbbi még talán előfordulhat)Próbáld már meg, amit mutattam.
2 próba:
De tessék, itt van, amit mutattál, csak úgy, hogy az elejére teszem a height és width attribútumokat:
<img height="118" width="118" style="float: left;" alt="Minta 1" src="../user_uploads/images/oldalak/kezdolap/pic1.jpg" />
Screenshot:
Most már hiszel nekem?
-
Inv1sus
addikt
válasz
Sk8erPeter #11847 üzenetére
Nálam csak a width és height tagokat szedte ki.
Ebből:
<img style="float: left;" alt="Minta 1" src="../user_uploads/images/oldalak/kezdolap/pic1.jpg" height="118" width="118" /> -
Sk8erPeter
nagyúr
válasz
Inv1sus #11846 üzenetére
Igen, elég sok hibalehetőséget rejt magában.
Pl. azt, hogy konkrétan kiszedi az összes attribútumot pl. egy ilyen esetben:<img width="123" src="asdasd.jpg" height="123" title="blabla" alt="akármi" style="border:1px solid red;" />
amit készít belőle:
<img />Asszem ez neked nem lesz túl jó.
itt kipróbálhatod:
http://preg_replace.onlinephpfunctions.com/Hint: (.*) - ez így nem igazán szűkíti le a dolgokat.
Szerk.: áááá, inkább mutatok rosszabbat, hogy még inkább elrettentsen.
<div title="valami"><img width="123" src="asdasd.jpg" height="123" title="blabla" alt="akármi" style="border:1px solid red;" /><div style="color:red;" title="asd">ezmegaz</div><p style="color:red;" title="itt is">namégegy</p>
</div>ebből csinál egy ilyet:
<div title="valami"><img>namégegy</p> </div>
elég brutálisan szétkúrja. -
Inv1sus
addikt
$pagecontent = preg_replace( array("#( width=\")(.*)(\")#e", "#( height=\")(.*)(\")#e"), array("", ""), $pagecontent);
Ezzel a sorral azt szerettem volna elérni, hogy egy szövegből, ami egy html kód, kiszedje a width és height attribútumokat.
Kérdésem az lenne (úgy tűnik, hogy sikerült ezt megcsinálni), lehet-e valamit szépíteni rajta, illetve valamilyen hibalehetőséget rejt-e magában? -
cucka
addikt
válasz
Speeedfire #11844 üzenetére
Így olvasva a köv. hozzászólásokat, nekem úgy tűnik, hogy kettőnk közül én értettem félre, és tényleg 1 fileról van szó.
-
válasz
Sk8erPeter #11839 üzenetére
"Nem kell rögtön megijedni vagy hogyan fogalmazzak. Csak és szigorúan a saját véleményem volt. Természetesen a szakmai vita részét fontosnak tartom én is, de sok hozzászólásból nekem nem "csak" ez jött le, de lehet az én hibám!"
Pontosítok. Megpróbálom úgy leírni, legegyszerűbben, hogy érthető legyen - Google volt ezeket megtaláltam csak nem tudom jó-e nekem, még nem próbáltam ki. Szóval úgy szeretném megoldani - és most egy buta példa - amit Chrome esetében tapasztaltam, hogy rákattintok és rögtön a képet tölti le, vagy adott esetben új tabot nyit, elindítja a letöltést majd bezárja (szempillantás alatt). Remélem így más érthetőbb!
-
Peter Kiss
őstag
válasz
Swifty #11834 üzenetére
Amennyiben ez PHP topik, akkor nem szeretnék látni semmit sem, ami MySQL vagy Apache (és hasonló jellegű) témával foglalkozik, köszi mindenkinek!
Nem tudom, mennyire vagy benne a témában, de egy idő óta (segítek: utoljára arról volt szó, mennyire kell ráállni PHP-ban az iobjektum orientáltságra, hogyan építsük fel a kódjainkat, hogy ne szívjunk nagyot véletlenül se, ilyesmi) a tiéd volt az első off topik hozzászólás, amiben senkinek sem segítettél, illetve nem a PHP-tól beszéltél. Csak azért, hogy lekiabálj valakit (főleg ilyen alapon), nem kell írni.Látod, most bekattintom az off topikot.
-
cucka
addikt
Nem kell hozzá curl. Lényegében a galéria letöltős linked egy php oldalra fog mutatni (mondjuk oldaladneve/download_gallery.php?gallery_id=5 ). A php szkript összeszedi a galéria file-jait, bezippeli és elküldi a kliensnek. A küldés lényegében annyit jelent, hogy beállítod a megfelelő header-eket (elsősorban content-type), majd egyszerűen kiírod a zip file tartalmát a standard kimenetre (vagy csinálhatod fpassthru-val is, gyorsabb).
A kényes kérdés itt a zip-elés. Több lehetőséged van:
- A php zip eszközeivel menet közben állítod elő a zip filet. Ezzel az a baj, hogy hamar ki fog futni a memóriából a php.
- A php meghív egy shell script-et, ami elvégzi a zip-elést (parancssoros zip-el), a zip filet lerakja a temp-be. Te onnan fpassthru-val kiköpöd a standard kimenetre, majd törlöd a filet.
- Minden galéria módosításnál elkészíted a zip filet, így bármelyik galériát is szeretné letölteni a júzer, csak átdobod neki a meglévő filet. Ez jó, ha ritkán változik a galéria, viszont gyakran töltik le egyben. A zip file elkészítésére a fenti 2 pont érvényes.(#11840) Speeedfire
Ez jó, csak az alap probléma, hogy nem 1 file-ról van szó, hanem többről (galéria). Ezért a zip-elés.mod: továbbá érdemes tudni, hogy a böngészők igyekeznek intelligensen kezelni az érkező file-okat. Ezért van az, hogy egy zip filet automatikusan felajánl letöltésre anélkül, hogy varázsolni kéne a http header-ekkel. Nyilván, egy jpeg file-nál rá kell erőltetni ugyanezt a viselkedést a megfelelő header-ek segítségével.
-
Speeedfire
félisten
Sima egyszerű header manipulálást.
<?php
$file = str_replace('../','',$_GET['file']);
header ("Content-type: octet/stream");
header ("Content-disposition: attachment; filename=".$file.";");
header("Content-Length: ".filesize($file));
readfile($file);
exit;
?>Még mielőtt Athlon beszóna' ez csak egy alap példa!
-
Sk8erPeter
nagyúr
Ennek örülök, bár ha egy modi mondja azt, hogy na kuss, akkor általában azzal agyon is van csapva a szakmai beszélgetés. Most már komoly felelősség terhel minden szavadért.
Bocs, de "force a download in php" kulcsszavakkal rákeresve, meg a PHP header() manualját megnézve is elég sok olvasmányt találni a témában...
Mintha épp az előbb lett volna szó a 2 perc Google-ről.
De a felvetést nem is értem, miért kell általad fejlesztett oldalhoz cURL?Vagy csak félreértettem a kérdésedet?
(#11837) j0k3r! :
jaja, pontosan. Elég régóta érdektelenek a topicbeli kérdések is, most legalább valami érdekesről van (volt) szó. -
válasz
Sk8erPeter #11836 üzenetére
Félreértés ne essék a hozzászólásom off, nem hivatalos!
Következő a problémám: olyan linket szeretnék készíteni, amire kattintva egy fájl le tudok "tölteni". Lényegében egy galériához "download" linkeket. Olvastam, hogy cUrl-el könnyen megoldható, viszont ennek a hiányában milyen módszert javasolnátok?
-
j0k3r!
őstag
válasz
Sk8erPeter #11836 üzenetére
teljesen egyetertek veled, habar en csak csendes szemlelokent kovettem az elmult napok hozzaszolasait. jo volt vegre valami "advanced" temarol olvasni, nem mindig csak a sablon (~ 2 perc google) kerdesekrol.
-
Sk8erPeter
nagyúr
Nekem aztán nem tisztem megvédeni Athlont, mert az eddigi kommunikációnk egymással nem volt túl sikeres, meg sokszor küldte már rám a modikat, és azzal is egyetértek, hogy általában túlságosan köti az ebet a karóhoz, és a saját elveit tekinti mindenhatónak, de ettől függetlenül szakmai szempontból érdekes olvasni a fenti vitákat, az ő hozzászólásaival együtt is, amikhez cucka és fordfairlane meg Soak és még esetleg mások is hozzászólnak.
A PHP-fejlesztés rejtelmeiről és mikéntjéről esik szó, összehasonlítva egyéb nyelvekkel is a lehetőségeket, nem tudom, miért kell leállítani egy ilyen szakmai vitát...Úgy érzem, ebben az esetben a moderálás nem jogos (nem anyázás folyik!), mert így csak agyoncsaptok egy végre érdekes eszmecserét, amiben nem az a téma, hogy hogyan kell validálni egy nyomorék formot. Szerintem a negatív kritika is része egy szakmának.
Szerk.: OFF.
Szerk. 2.: mobal, most látom, hogy ez te vagy, moderátor lettél, mik nem történnek (meg az avatarod is lecserélődött, ezért nem ismertelek fel)... -
Swifty
csendes tag
válasz
Peter Kiss #11833 üzenetére
Nem akarok beleszólni, de:
- Pár oldal óta ez a topic nem a PHP-ről szól, hanem hogy milyen fika, milyen szar az egész...
- Azt olvasom, hogy te milyen nagy programozó vagy, és aki nem úgy készíti el a programjait, mint te, aki már a magzatvízzel is kódokat szívtál magadba, az mekkora szar...
- Aki mást mond mint te, az hülyeséget beszél, belehány valamit valahova, egy szóval fikagép...Na ezek után nem értem mi a f*szt keresel itt... Merthogy nem segítettél senkinek "PHP kérdések"-ben, azt bárki láthatja...
Még offtopic-ként sem jelölöd meg a kötözködéseid...
-
Peter Kiss
őstag
Szkriptnyelvség: behányunk valamit valahová és valami kijön, ezt lehet könnyen levetkőzni.
Lambdák vannak típusos nyelvekben is, .NET-be egészen durván jelen vannak.
Ezt az általánosítást ne ferdítsd már el a hülyeség irányába.
Egyedi szoftvert is kell általánosítani, mert különben túl bonyolult lesz a megvalósítása, ez kimerülhet pl. egy IStatus interface egy metódusában is, de jelen van, mert kell.
Nálam az a keretrendszer, amivel nem lehet dolgozni, szarnak minősül. A "jól van megírva" dolognak két oldala van, maga a keret kódja penge, vagy az, ami kívülről lehet látni, mivel keretrendszert nem azalapján ítélünk meg, mi van benne, így a külsőleg látható elemekből kell döntést hoznunk arról, jó-e vagy sem.
Utolsó bekezdéshez annyit, hogy idézted a mondandó felét, illetve a kérdésedre még ebben a kis részben is megvan a válasz.
-
cucka
addikt
válasz
Peter Kiss #11821 üzenetére
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét
Nem kell levetkőzze magáról. A szkriptnyelv nem alacsonyabb rendű, mint a hagyományos, típusos, fordított nyelvek, hanem más.
Az egyik kedvenc tech blogomon pont ma jött ki egy bejegyzés, amivel maximálisan egyet tudok érteni, lásd itt . (Érdemes a többi bejegyzést is olvasgatni, nagyon jók)Mit vett át funkcionális nyelvekből?
Utánanézve azért túl sokat nem. Vannak lambdák, van closure, már csak valamiféle "list comprehension" kéne (tervezik), továbbá ott vannak régről a map, filter, reduce, stb. eszközök. Persze az új dolgok szintaxisa igazi kendácsolás, de hát az egész php nyelv ilyen, meg van kötve a kezük a sok évvel ezelőtti rossz döntések miatt.Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap
Na, hát csak kibújt a szög a zsákból. Igen, a .net (vagy a java, mindegy) tisztán oop-s szemléletet kényszerít rád, ez van, amikor előnyös és van, amikor annyira nem előnyös.
Mellesleg nagy feladatokat mostanában mindenhol oop elvek mentén fejlesztenek, igen, még szkriptnyelvekben is. Ami a szkriptnyelvek előnye itt, hogy a java/c# jellegzetességének számító boilerplate kódok hiányoznak.Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva.
Azokat a komponenseket, amelyek megállnak a saját lábukon és újra felhasználhatóak, azokat lib-eknek hívjuk. Egy egyedi szoftver egyedi megoldásaiból sosem lesz lib, sosem fogod újra felhasználni őket. Szóval akkor miért kéne magad azzal sz*patni, hogy úgy írd meg a szoftvert, mint ha egy csomó részét újra fel szeretnéd használni?
Nem azt mondom, hogy írjunk direkt szar kódot, hanem hogy a fejlesztés során megcsinált általánosítások nagy része teljesen fölösleges.Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.
A keretrendszer jól volt megírva és elméletileg k*rvajó kellett volna legyen, a probléma, hogy a valós igények nem pont olyanok, mint amit elméletileg előre el tudsz képzelni.TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelniű
Miért, oop-val nem tudsz nehezen tesztelhető kódot írni, ha nagyon akarsz? -
dodopek
addikt
Sziasztok!
Tudom, hogy nem kifejezetten php probléma, és volt is már itt vita, hogy a szerver konfig, és hasonló problémák ideférnek-e, de szerintem ha valahol, akkor itt biztos kaphatok választ,és szerintem igenis ideférnek az ilyen problémák.Xoo.hu ingyenes tárhelyére próbáltam feltolni phpbb fórumot. Már a file-okat sem sikerült feltelepíteni, mert a .htacces file-oknál (mindegyiknél) átviteli hibát jelzett. Minden más kiterjesztés gond nélkül felment, de ezt valamiért nem akarja megenni. TC-rel ftp-zek.
Van valami ötletetek, hogy mi lehet a gond?
Én barmolok el valamit?
Köszi!Közben válaszolt az ottani rendszergazda, nem fog menni.
"PhpBB és egyéb CMS rendszerek nem fognak működni az ingyenes tárhelyen. Arra fizetős tárhelyünket érdemes igénybevenni ahol komoly webpanellel , statisztikával, jelszavazott mappákkal és egyéb extrákkal lehet menedszelni a tárhelyet, mindamellett CMS-ek is gond nélkül futnak" -
Peter Kiss
őstag
válasz
DerStauner #11827 üzenetére
Vannak rá kész lib-ek, szóval nem az. Google a barátod.
-
DerStauner
senior tag
sziasztok!
van egy tábla egy honlapon, amibe az adatokat adatbázisból olvassa be a honlap (php-vel).
igaz az, hogy az ilyen táblának excel-be való exportálása php-val nehézkes? -
PazsitZ
addikt
ha itt minden sorban van két interface meg osztály akkor egy olyan hiba (vagy fejlesztés) ami amúgy egy logikus kódnál 3 óra, itt 2 nap
Megfelelő tesztekkel, rögtön ki kell, hogy bukjon a hiba helye. Ilyen szempontból pont jól beazonosíthatóan, mivel a felelősségi körök szét vannak osztva. Az interface pedig pont egyfajta contract, ami alapján az együttműködést lehet biztosítani.
A szar, logikátlan kódtól persze az OOP sem véd meg egyáltalán, de ezt senki nem állította.százezer (millió) sor
Olyan pedig pont nem létezik, hogy egy teljes rendszert részletesen, véglegesen lespecifikáljanak neked.
Tehát az esetek többségében, úgyis fejlesztési iterációk vannak, ezáltal pedig úgyis vagy aránylag rugalmasan oldod meg a dolgokat, vagy refactorálhatsz.az emberek számára kell azt logikussá tenni és könnyen átláthatóvá.
Itt nem tudom mire gondolsz, mi a nem logikus kód számodra.Jelentősen többet kódolok
Én pont nem azt írtam, hogy jelentősebben többet kódolj.A nem jól tesztelhető kódot, hogy tudja rendesen kitesztelni a megfelelő ember?
Én itt egy kis ellentmondást érzek. Avagy a kitesztelés nem az én gondom, oldja meg más, ahogy akarja?
Egyébként a rosszul tesztelhető kód a legtöbb esetben egy jelzés lehet a kódra nézve. -
Peter Kiss
őstag
Számomra itt a beszélgetés folyamán kicsit úgy tűnik, mintha két dologról lenne szó: az egyik, hogy megoldunk egy problémát, azt hogyan programozzuk le, a másik, hogy előbb megépítjük a környezetet, és azt hogyan programozzuk le. Nem tudom, lehet, hogy nekem tűnik így. Mindegy, tegyük túl magunkat a felhozott kódolási anti-pattern-eken:
@Soak: Abban az esetben, ha van egy üzleti problémánk, akkor semmiféle képpen sem fogunk attól többet fejleszteni, mint amennyi szükséges. Vegyük azt, hogy egy teljesen új dologról van szó, nem kell régi vacakkal foglalkoznunk, és emellett van egy keretrendszer (ez lehet bármi, .NET, Zend Framework, mindegy), amiben dolgozunk. Tételezzük fel, hogy tiszta a megvalósítandó üzleti logika, gyakorlatilag csak fejlesztenünk kell. Hogyan érdemes ezt elkezdeni?
Írunk teszteket, amelyek lefedik nagyvonalakban, amit szeretnénk kivitelezni, ilyen fázisban még a teszt is ocsmány lesz, mert csak körbelőjük, mit is szeretnénk. Ha ez megvan, megírjuk az első kódot, teszt, kódírás/refaktor/újabb teszt, innen már tudjuk, TDD.
Ha így fejlesztünk, akkor észrevetjük, hogy az elején nagyon sokat kódolunk (leginkább a tesztek megírása miatt, nem az interface-ekre (vagy akár a mock-okra, stub-okra) gondolok, mert az relatíve kevés időt vesz igénybe), ellenben automatán tudunk mindent tesztelni (UI-t nehézkes ilyen szempontból, törekedni kell arra, hogy ott a lehető legkevesebb hiba fordulhasson elő). Mikor jó egy unit teszt?
Ha azt és csakis azt teszteli, amit kell, gyorsan lefut, és egyértelmű a leírása. Ahhoz, hogy a teszt ilyen legyen az kell, hogy maga a tesztelendő kód is felvegye ezt a jelleget, normálisan megírt OO kód nélkül ez lehetetlen.
Persze, a unit tesztek önmagukban kevesek, hiszen attól, hogy egy-egy rész jól működik, a big-picture még lehet, hogy sz.rt se ér, ehhez integrity test-ek kellenek.
Mit látunk ezen a ponton?Összevetve egy nem TDD-s csapattal, sokkal több időt töltöttünk mindenféle kód (production + ami a teszthez kell [és a világos megoldáshoz!]) megírásával, viszont sosem kell amiatt aggódnunk, hogy nagy hibát vétenénk, ha kalapálunk valamit, segítenek a tesztek. Hibát keresni is sokkal gyorsabb lesz, hiszen rengeteg dolgot fejlesztési időben ki tudunk szűrni, illetve a kiadott verzióban is kevesebb lesz az utólagos hibák száma.
Azt már említeni se merem, hogy léteznek olyan eszközök, amelyek kódolás alatt automatán futtatják a teszteket, így mindig up-to-date lehetsz (PHP-hoz nem tudom, van-e ilyen).
-
Soak
veterán
Jah és amit még akartam írni , olyan szerenécs (?!) helyzetben vagyok, hogy egy 10éves legacy kódon és egy 1 éves (hasonlóan felépített kódot mint alább írtam, természtesen sok ezer munkaórával töketesítve ) kódon dolgozhatok és mind a kettővel meg lehet mindent oldani.
Persze akármilyen mozzanat a régiben komplett részlegek refactorálásához kéne hogy vezessen, de ez nem von le abból, hogy tökéletesen (és viszonylag elfogadható erőforrásigénnyel) fut.
-
Soak
veterán
válasz
PazsitZ #11822 üzenetére
Egyértelmű, nem is azt mondtam, hogy szar kódot kell írni, de amikor nem csak tul kell bonyolitani egy példa kódot hanem több százezer (millió) sort kell lekódolni akkor kicsit átértékelődik, hogy mit hogyan merre , mivel emberek írják a kódot, ezért az emberek számára kell azt logikussá tenni és könnyen átláthatóvá.
Nyilván ezt szinesíti amikor csapatban kell dolgozni és a folyamatos monitorozása annak, hogy ki-mit commitol a közösbe, mert amikor 50-60 ember dolgozik aktívan valamin akkor ha egy hibát kell javítani, az első 1óra azzal megy el, hogy feltérképezed a pontos folyamatot (és ez egy erősen OOP-s kód, viszont a projekthez mérten a lehető legátláthatóbban tartva és nagyon jól doksizva ) , na most ha itt minden sorban van két interface meg osztály akkor egy olyan hiba (vagy fejlesztés) ami amúgy egy logikus kódnál 3 óra, itt 2 nap.
Szvsz (ha csak szigorúan azt számoljuk ami a logikát végzi ) akkor 3 fő réteggel meg lehet oldani. controller-üzletilogika-adatbázis réteg. Itt az adatbázis müveletek jelentik az elemi müveleteket amik a konkrét adatot szolgáltatják, az üzleti logika ezt tetszés szerint kombinálja (a lehető legegyszerübben) , a controller pedig gondolkozik.
Innen már késöbb is el lehet indulni mondjuk egy bonyolultabb api megépítéséhez , vagy egy config réteget is betoldhat nagyon egyszerűen (ha indulásnál még nem volt).
Mérlegelni kell, hogy mire van nagyobb esély : Jelentősen többet kódolok, hogy majd egyszer valamit könnyen betoldok, de ugysem gondoltam felére sem ami lehet, tehát sokkal nem vagyok beljebb, vagy az egyértelmű és általános modulokat megépítem amik közé egy kicsit több kódolással, de ugyanolyan logikusan beillesztek bármit.
Szerk: Ahelyett, hogy a kód írást az vezetné, hogy mennyire jól tesztelhető, sokkal egyszerűbb egy komplett tesztkörnyezetet fenntartani (2 lépcsőbe- saját, aztán közös) ahol mindent rendesen ki tud tesztelni a megfelelő ember (hiba/feature bejelentője és a teszter vagy kinek mit teszik) egy jó dokumentáció mentén és jó rendszerismerettel .
-
PazsitZ
addikt
Alapvetően abban egyetértek, egy házi 2 formos php kódot, lehet felesleges OOP-ben megírni.
Továbbá, ha már adott is egyegyszerűbb kód, felesleges egy csv felolvasást köré 5-10 osztályt felhúzni.Viszont, ha én kezdenék bele, akkor már fognék egy framework-öt, ami segítségével oldanám meg a dolgokat.
Alapvetően a PHP-s framework-ök is OOP irányba mennek, amit az én észrevételeim alapján a nyelv is egyre inkább támogat.
Abban van igazság, hogy ez script nyelv, de ettől még nem a register globals és levegőbe lógó függvények szempontjából kell használni szvsz.Amennyiben pedig elkezdesz egy OOP framework-kel dolgozni, akkor viszont igenis namespace és osztálystruktúrát kell használni, nem kavarni a dolgokat.
A TDD hasznos dolog, kellő rálátás esetén jobban ki is kényszeríti a szebb kódot, SRP-t, amiből már könnyen jön a panaszolt "overgeneralization".
(#11820) Soak:
Egyébként nem olyan könnyű eltalálni a balanszot.
Egyik oldalról ott van az a szabály, hogy csak a kért feature-t fejleszd, ne űrhajót.
Másik részről viszont rá lehet/kell érezni, mi az, ami a következő iterációban biztos be lesz rendelve. Ebben az esetben pedig nem árt, ha kicsit előre gondolkozva tervezel, kellő mértékben absztrakt a kódod, hogy ne kelljen szétdúrni és gyors-hatékony lehess. -
Peter Kiss
őstag
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét, és klasszul lehetne használni, csak épp az elterjedtsége ellenére is kevesen próbálkoznak kiaknázni minden lehetőségét.
Mit vett át funkcionális nyelvekből?
Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap (@Soak: termelő vállalatnál kell ügyviteli és termeléstámogató szoftvereket fejleszteni, sajnos eddig szinte csak legacy [és szar] kódokat kellett támogatni). De akkor végül is azt mondod, hogy PHP-val hegesszen mindenki úgy, hogy csak az adott problémára koncentráljon, legyen kész, és rendben is van a dolog?
Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva. Premature optimization valóban veszélyes lehet, de igazából csak azt fenyegeti, aki rettentően unatkozik, és valamilyen oknál fogva előre látni véli a rossz teljesítményű pontokat.
Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelni, vagy nagyon nagy mocskot kell csinálnod, ezzel szemben egy interface-ből stub-ot/mock-ot hegeszteni nem nagy mutatvány. (Smoke tesztnek tényleg nincs köze az OO/nem OO dologhoz (bármit lehet rosszul tesztelni), de nem is azért írtam.)
-
Soak
veterán
válasz
Peter Kiss #11815 üzenetére
(csak nehogy egyszer én legyen a projektvezetője )
Ha nem titok akkor hol dolgozol?
-
cucka
addikt
válasz
Peter Kiss #11815 üzenetére
dupla
-
cucka
addikt
válasz
Peter Kiss #11815 üzenetére
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni
A szkriptnyelveknek nagyon is van létjogosultsága és jövője, ne írd le őket.
A php baja leginkább az, hogy egy inkompetens fickó tervezte és mai napig a régi verziók rossz megoldásait nyögi a visszafele kompatibilitás miatt.a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk
A Zend nem tudom, mire sarkall. Én úgy látom, hogy a php-ban egyre több a funkcionális nyelvekből átvett megoldás, ez pont nem az a tisztán oop-s irány.Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Úgy érzem, hogy te a lelked mélyén java-ban szeretnél fejleszteni (esetleg c#), a kérdés, hogy miért ragaszkodsz a php-hoz? Átveszed azt, amitől a java nem túl jó és kidobod azt, amitől meg a php igen. Hobbi szinten végül is mindegy, szerintem inkább érdemesebb minden eszközt arra használni, amire való.Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló?
Világos, viszont a túlzásba vitt általánosítás komoly veszély. Angolul "overgeneralization" néven fut ez az anti-pattern, amikor a lehető legáltalánosabb kódot szeretnéd írni anélkül, hogy tudnád, szükséges-e (kapcsolódik még ide a "premature optimization" nevű antipattern is).
Dolgoztam már ilyen, lehető legáltalánosabbra megcsinált php-s framework-el. A tapasztalat, hogy a korai általánosítás inkább ront a helyzeten, mint javít - nekünk folyamatos szopóroller volt, hogy ott volt a nagy, bonyolult keretrendszer, ami minden eshetőségre fel volt készítve, kivéve arra, amire épp szükség lett volna, tehát lehetett áttervezni/refaktorálni. A lehető legáltalánosabb kód írása papíron hangzik csak jól.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat
TDD-hez elég, ha moduláris a kódod, pl. globális függvényeket pont ugyanolyan jól fogsz tudni tesztelni. Persze, azért itt már előnyös az oop.
Smoke test-nek meg nincs igazán köze ahhoz, hogy oop-s vagy nem oop-s a kódod. -
blacee
csendes tag
válasz
Sk8erPeter #11806 üzenetére
Az opkg update leszedi az összes csomagot becsomagolva, de abban nincs benne. A linkről amit küldtél külön letöltöttem a zoneinfo-europe_2011n-1_ar71xx.ipk-t és bemásoltam a /var/opkg-lists-be, újra se indítottam a lighttpd-t és láss csodát: M Ű K Ö D I K !
Nagyon köszönöm a segítséget!!!BLacee
-
Peter Kiss
őstag
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni, pedig egyre komolyabb dolgokra képes, illetve a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk. Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló? Duplikálás. Nyilván a fenti kérdés egy kis dologra vonatkozott, de, ha esetleg van valami cifra folytatása, már megérhette, illetve abban az esetben, ha több helyen kell valamit használni (itt például a táblázatos történetet, a parser sántít).
Azt mondom, nem érdemes kicsiben gondolkodni.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat! Ha valaki fejlesztett már TDD módon úgy, hogy nem csak a covarege-et nézte, és gyártott a smoking test-eket, akkor tudhatja, hogy a jó tesztek kikényszerítik a fentebb látható kódstruktúrát, mert egyszerűen kell.
Mindenki elindulhat a saját útján, én megmutattam egyet, én hogyan csinálnám, akinek tetszik, használja, akinek nem, az ne (csak nehogy egyszer én legyen a projektvezetője
).
---
#11809
"amennyiben valaki már érti" - ez a varázsgondolat
Ha jó a kód, ordít magáról, hogyan kell használni. Nyilván, a PHP-nak itt vannak korlátai, de azért nem olyan rossz a helyzet. A fenti kódra szerintem senki sem tudná azt mondani, hogy nem tudja használ (a parser itt is kivétel, annak még bőven alá kellene dolgozni).---
#11810
Nem vagyok programozó, szoftverfejlesztést szeretem, illetve az architect jellegű kérdésekkel, megoldásokkal foglalkozni.---
#11814
Egyik tervezési mintát sem kell vakon követni, hiszen nem előírások, csak megfigyelt jó fogások, vagy épp rosszak. Amit mindig be kell tartani: egy osztály/metódus egy problémát oldjon meg, mindig mondja el, mire van szüksége a működéséhez, és minden a lehető legabsztraktabb maradjon. Ha valaki ezeket szemmel tartja, nagy baj nem történhet. -
cucka
addikt
válasz
Sk8erPeter #11812 üzenetére
Azutánira: szintén egyetértek, ha valaki igazi OOP-s környezetet akar, akkor álljon át valamelyik webes Java-technológiára vagy például ASP.NET-re.
Van rengeteg "köztes" megoldás is, igazából manapság kevés olyan nyelvet használnak, ami ne lenne így vagy úgy objektumorientált - a php is ilyen.A probléma az idézett kódnál elsősorban az, hogy megpróbál túlságosan általános lenni, miközben ennek az égvilágon semmi értelme. Oop-vel könnyű olyan osztály hierarchiákat kialakítani, ahol minden komponens cserélhető, kiterjeszthető. A nehéz dolog előre látni, hogy a rengeteg lehetőség közül melyikre is lesz szükség valójában, és melyek azok, amelyek csak a program hosszát és a zajt növelik, hasznuk semmi. Például az említett kódban az összes oop rész gyengíti az alap algoritmus szemléletességét, miközben a feladathoz által nem megkövetelt komplexitást hoz be, megvalósítva azt az anti-patternt, ami "excessive accidental complexity" néven fut. (Van erre valami jó magyar szakkifejezés?
)
annak az agya nyilván sokkal inkább rááll az OOP-s gondolkodásra, és nem valószínű, hogy engedni akar belőle
Szerintem a fejlesztő agya elsősorban a gondolkodásra kéne ráálljon. Mindenkinek javaslom, hogy hobbiból játszadozzon egy funkcionális nyelvvel (javaslatom a Clojure) - el fog bizonytalanítani, a szokásos pattern-ek nem működnek benne, pont ettől segít olyan sokat. Megtanít arra, hogy a feladatra és a program olvashatóságára figyelj, és ne foglalkozz semmilyen, valaki által kitalált és "one and only"-nak kikiáltott esztétikai iránymutatással. -
Sk8erPeter
nagyúr
"Nem az, ha valaki az informatikában megmondja a tutit, hogy csak és kizárólag egy módszer az elfogadható, na ő téved"
Na igen, én is ezt fejtegettem, hogy ne akarjuk itt megmondani a "one and only" módszereket.Azutánira: szintén egyetértek, ha valaki igazi OOP-s környezetet akar, akkor álljon át valamelyik webes Java-technológiára vagy például ASP.NET-re.
Persze ettől függetlenül nem megkérdőjelezhető az OOP létjogosultsága sem a PHP-ben.
Ahogy az is igaz, hogy amennyiben valaki az előbb említettekben IS programozik, annak az agya nyilván sokkal inkább rááll az OOP-s gondolkodásra, és nem valószínű, hogy engedni akar belőle (tehát ennek mentén fog kódolni PHP-ben is, amivel nincs baj). Viszont ez nem jelenti azt, hogy egy procedurális kód szar (sőt, nagyon jó is lehet, és nagyon nem arra utal, hogy az aszerint kódoló fejlesztő keveset tud [ettől a megjegyzéstől az agyam kinyílt]). -
cucka
addikt
válasz
Sk8erPeter #11809 üzenetére
cucka az előző hsz.-ben pedig elég tömören elmagyarázza azt is, amit én is éreztem a konkrét kérdés kapcsán, csak ő sokkal jobban megfogalmazta.
Igen, az az elméleti okoskodás rész, ami akár elfogadható is lehet. (Nem az, ha valaki az informatikában megmondja a tutit, hogy csak és kizárólag egy módszer az elfogadható, na ő téved)
A másik oldal meg a kód, amiből lényegében a class oriented dizájn állatorvosi lova, kb. mint ha egy java programozó első php-s kódja lenne.A php egy szkripnyelv, ezt érdemes szem előtt tartani, hogy valóban php-ban írjuk a php kódot, nem pedig javaban.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #11809 üzenetére
Csak nem bírom magamban tartani: mindenki már érti és kívülről fújja, hogy te nagyon vágod ám a tervezési mintákat, és odáig vagy értük, de ez nem azt jelenti, hogy csak te tudsz emiatt jó kódot írni, és mindenki más, aki procedurálisan kódol (pl. korábbi kódot fejleszt tovább), az "keveset tud".
Hozzászoktam, hogy szereted erős túlzásokkal megspékelni a mondandódat, de azért ez már egy kicsit erős volt. Bár gondolom nem nagyon tudsz elképzelni olyan programozót, aki nem kódol OOP-ben, mégis nálad sokkal jobban tud programozni (szerk.: félre ne értsd, nem feltétlenül itt a topicban aktívan írókkal kell "versenyezned") - hiszen ahhoz kell némi szerénység, hogy az ember ilyesmit is el tudjon fogadni. -
Sk8erPeter
nagyúr
válasz
Peter Kiss #11807 üzenetére
Alapvetően egyetértek, szerintem is adott esetben sokkal szebb és átláthatóbb lehet egy OOP-s kód, ha valaki tényleg jól tud kódolni.
Arra gondolok viszont, hogy pl. a Drupal magja sem teljesen OOP-s még, elsősorban örökség miatt - lásd PHP 4-es idők; nem egyszerű egy ilyen "rendszert" teljesen lecserélni; legalábbis a 7-esig, bár ott már sok minden OOP-sre lett alakítva, a 8-asnál meg még több dolgot ültettek át OOP-re, ezért van egy bizonyos keveredés egyelőre -, mégis alapvetően egész jól követhető a kód, amennyiben valaki már érti, miről is szól az egész, és itt is egy "rendszerről" beszélünk (azt írod, "rendszer nem lesz abból se", most erre reagálva mondom).
De én pl. a még jobb követhetőség miatt sokkal jobban örülnék, ha a modulfejlesztés is például osztályok leszármaztatásából, interfészek implementálásából és hasonlókból állna, mert számomra is jóval áttekinthetőbb lenne a kód. De van ilyen szinte full OOP-s modul: Views.
Igazad van abban, hogy így elég sok minden lóg a levegőben, ezt a hátrányt Drupalnál is érzem, a debuggolás is talán nehézkesebb emiatt. De a fejlesztők tudják, hogy van min javítani, ez is az irány. Itt és itt nálam sokkal jobban elmagyarázzák a miérteket.Ettől függetlenül szerintem picit túlzás, hogy csak az OOP-s kód a jó és mérvadó.
Szerk.:
cucka az előző hsz.-ben pedig elég tömören elmagyarázza azt is, amit én is éreztem a konkrét kérdés kapcsán, csak ő sokkal jobban megfogalmazta. -
cucka
addikt
válasz
Peter Kiss #11807 üzenetére
Az eredeti hozzászólásban írt, 20 sorban megoldható feladathoz talán mégiscsak túlzás a te próbálkozásod, ahol hosszú oldalakon keresztül csak az oop kód zaja látható. A megoldásod elsősorban nem a feladatot oldja meg, hanem azt próbálja demonstrálni, hogy ismered az php-s oop kulcsszavak használatát - lényegében pont azt mutatja be, hogy hogyan ne írj jó oop-s kódot.
-
Peter Kiss
őstag
válasz
Sk8erPeter #11806 üzenetére
Procedurálisan nem lehet szép kódot írni, mert minden lóg a levegőben (illetve a globális hipertérben). Ilyen esetekben maximum egy-egy függvény feladatát lehet a minimálisra szorítani, de rendszer nem lesz abból se. PHP esetében pedig még az is kihullik, hogy típusellenőrzést lehessen jól láthatóan végezni (kikötöda paraméter típusát a metódusok paraméterlistájában).
Az OOP nem tudja garantálni a normális kódot, mivel nincs normálisan definiálva (lehet egyáltalán?), hogy mit is jelent az OOP (sokaknál kimerül a class-ok használatában, de ekkor van az, hogy class oriented lesz a design).És nem baromarcú, csak keveset tud.
-
Sk8erPeter
nagyúr
válasz
blacee #11801 üzenetére
"Unknown package 'zoneinfo-europe'
Nem találja szegényke. Ő ugyanis a vargalex.uw.hu -ról rántja le a csomagokat, és azok közt nincs."
Ez azért furcsa, mert itt látom a listázásban a csomagot:zoneinfo-europe_2011n-1_ar71xx.ipk
Szóval nem nagyon értem, miért nem találja. Más package source-t (mirrort) beállítva (akár ezt) sem működik ennek telepítése?
==========
(#11805) Athlon64+ :
"Lehet ilyet osztály nélkül is?"
Nyilván költői volt a kérdés, de mindent lehet procedurálisan is, semmi katasztrófa nem történik akkor sem (bár tudom, hogy szerinted aki nem csak és kizárólag OOP-ben kódol, az egy baromarcú), csak akkor elveszti az osztályok használatának rugalmasságát, a könnyebb kezelhetőséget, esetleg áttekinthetőbb kódot. De önmagában az, hogy OOP a kód, az nem garantálja az áttekinthetőséget, jó kódot, a gányolás elkerülését; ahogy ugyanígy az is igaz, hogy procedurálisan is lehet szép kódot írni. -
Louro
őstag
válasz
Peter Kiss #11803 üzenetére
Uh, osztállyal.... - kezdő programozó vagyok - erre nem is gondoltam. Átnézem a kódot, hogy értelmezzem is.
Köszönöm a gyors megoldást.
-
Peter Kiss
őstag
Kódoltam egy keveset, szerintem erre gondoltál: http://pastebin.com/mc8eJwfQ
(Hiba lehet benne [Notepad teszt nélkül].)
-
Louro
őstag
Sziasztok,
nem vagyok teljesen kezdő, de azért segítségért fordulnék hozzátok.
Amiről szó van. Van egy űrlap. Bekérek adatokat, amit egy fájlban tárolok el.
Az űrlap első oszlopa egy sorszám - nem a bejegyzés sorszáma, szóval több sornak lehet ugyanaz a sorszáma.
A gond az az, hogy a kiíratáskor szeretnék egy olyat írni, hogy van - tegyük fel - 10 táblázat. A 10 táblázatba pedig szétszedni az adott sorszámmal kitöltött űrlapok adatait.Pl:
A fájl tartalma:
1;alma;torta;hétfő;
2;citrom;leves;csütörtök;
4;fahéj;tejberizs;vasárnap;
2;bors;pörkölt;kedd;
3;sajt;torta;hétfő;
2;krumpli;rakott krumpli;hétfő;======================================
A táblázatok nevei lennének a sorszámok (első adat) és az alattuk levő táblázatban jeleníteném meg a sorszám utáni 3 adatot soronként.
Amit csináltam: a fájlt egy változóba betettem - eddig alap -, után explode-dal szétszedtem egy tömbbe soronként.
De itt elakadtam, mert a foreach-et nem tudtam úgy megírni, hogy jó legyen. Próbáltam ciklussal, de nem ment. Nem tudom, hogy hogyan tudnám úgy szétszedni, hogy pl. a ciklus indexe a tömbelem első első karaktere legyen.Remélem sikerült érthetően megfogalmaznom. Adatbázissal még nem foglalkoztam, ezért nem abban "rögzítettem"/dolgoztam fel.
Köszönöm előre is a segítségetek.
-
blacee
csendes tag
válasz
Sk8erPeter #11799 üzenetére
Sajnos semmi változás, különben már sűrűn köszöntem volna a segítséget!
El nem tudom képzelni mi kell még neki...
Új hozzászólás Aktív témák
- Dell Latitude 5450 Intel Core Ultra 5 135U 4nm 32GB DDR5 érintőképernyős laptop Dell gari 2027.09.hó
- PlayStation 4/5 kontroller analóg cseréje HALL TMR érzékelősre, 1 év garancia!!! Nincs többé drift!!
- PlayStation 5/4 kontroller analóg cseréje HALL TMR érzékelősre, 1 év garancia!!! Nincs többé drift!!
- XBOX ONE/Series kontroller analóg cseréje HALL TMR érzékelősre, 1 év garancia!!! Nincs többé drift!!
- XBOX Series S 512GB, 6 hó garanciával Bp-i üzletből eladó!
- ÁRGARANCIA! Épített KomPhone i5 13400F 32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
- AKCIÓ! Lenovo Thinkpad P15 Gen1 15 FHD notebook - i7 10750H 16GB RAM 512GB SSD Quadro T1000 W11
- Szerezd be most az érzékelhető különbséget! Akár 0% THM-re
- BESZÁMÍTÁS! Apple MacBook Pro 16 M4 Pro 24GB RAM 512GB SSD - garanciával hibátlan működéssel
- Lenovo Thinkpad P16 G2 - i9-13980HX, 64GB, 1TB SSD, 16" WQUXGA (3840 2400), RTX 4090 (ELKELT)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest