Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz #68216320 #13058 üzenetére
Jól csináltad, ez localhoston, fejlesztői környezetben nyugodtan maradhat így. Ahogy tildy is mondta, arra viszont figyelj, hogy a notice-ok kijelzését viszont nem szabad úgy hagyni éles környezetben, ott, ahol már külső szemlélők olyan információkat is láthatnának ezáltal, amit nem szabadna (értsd: egy rossz szándékú illetőnek minden plusz információ csak további segítség). Éles környezetben is el kell azonban kapni minden hibát, azokat naplózni, és a felhasználónak csak "felhasználóbarát hibaüzenetet" megmutatni. (Pl. a felhasználó ne tudja, a kód hányadik sorában lett valami elrontva, vagy konkrétan mi volt a hiba.)
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #13069 üzenetére
Értem, ettől függetlenül viszont szerintem érdemes elkerülni az idézőjel használatát tömbindexeléskor, és lehetőleg egyéb esetekben is - természetesen ez pusztán szubjektív megítélés, de én rendkívül olvashatatlannak tartom a stringben "elrejtett" változók használatát a konkatenálás helyett.
Szóval szerintem PHP-ben idézőjel helyett aposztróf.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #13078 üzenetére
Jó is, hogy jelezted.
Na igen, a placeholderek használata is jóval elegánsabb megoldás.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13096 üzenetére
Újraindítottad a webszervert, miután átírtad?
A Default timezone-nál is "Europe/Budapest" kéne, hogy szerepeljen, de nálad az a default UTC, szóval valami tényleg nem okés.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13110 üzenetére
A jQuery még mindig nem framework, hanem csak egy library...
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13115 üzenetére
Ebben a topicban úgy látszik, már nem lehet KORRIGÁLNI egyes mondatokat a helyes infók érdekében, mert valaki biztos, hogy magára veszi. Miért lenne "belekötés" egy egyszerű korrekció?
Sk8erPeter
-
Sk8erPeter
nagyúr
Volt hosszas témázás róla itt a topicban, érdemes lenne átfutnod:
http://prohardver.hu/tema/php_kerdesek_2/keres.php?stext=singletonSk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #13135 üzenetére
Gondolom csak szemléltetés akart lenni, de sztem nem árthat egy
if(file_exists('classes/' . $class . '.class.php')){
// ...
}
ellenőrzés is előtte, végül is a file_exists() relatíve gyors.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #13138 üzenetére
Igen, ebben igazad van. Habár kérdés, hogy valósítja meg valaki, hol keletkezzen a fatális hiba, vagy akár egy exception mondjuk itt, akkor, ha a fájl nem létezik, vagy akkor, amikor példányosítani akarja valaki az osztályt.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Dave-11 #13164 üzenetére
Ne viccelj már... csak gondold végig, mi mindent kell tudnia egy webshopnak. A manapság népszerű webshopokat is évekig fejlesztették, gondolj csak bele: biztonsági rések, plusz szolgáltatások, fizetési lehetőségek, AJAX-osítás, képfeltöltés, rendes kategorizálás, menürendszer (utóbbi kettő fastruktúrában), rendes admin-felület, jogosultságok, és még nagyjából egy órán át sorolhatnám.
Vannak különálló webshopmotorok, és vannak CMS-ekbe (Drupal, WordPress, stb.) beépülő webshopmodulok/pluginek is, igen nagy kódbázissal.
Könnyű végiggondolni, hogy egyedül egyáltalán nem megtérülő vállalkozás fejleszteni saját webshopmotort, de általában csapatban sem.
De egy új webshop kezelésének megtanulása is sok időt igényel, ha nem csak alapfeladatokról van szó.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13176 üzenetére
Migrálni a saját meglévő tábláid adatait az új táblákba, a kritériumoknak megfelelően, úgy, hogy az új webshopba megfelelően bekerüljenek a termékek, most így konkrétumok nélkül csak általánosságokban lehet tanácsot adni. Ha van a migrálásra/importálásra valami jóféle, rugalmas "keretrendszer" (mint a Drupalos Migrate modul), akkor az a legjobb. De nézz utána, van-e valami "híd" a két rendszer összehozására. Pl. Drupal esetén volt a Drupal saját táblái és a Gallery2 összehozása esetén, tudtommal ott kicsit gányolósan úgy működött, hogy minden felhasználói adaton történő változás mentődött a másik táblában is, ez mondjuk nem a legjobb megoldás, nem biztos, hogy egy hiba esetén szinkronban lesz a két adat. Szóval a legjobb talán az lenne, ha azonos felhasználói adatbázisban dolgozna a kettő.
Melyik webshop ez?
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13186 üzenetére
Végül is egy felhasználónak lehet külön állandó lakcíme vagy levelezési címe, és egy szállítási címe... Semmi gond nincs abból, ha a kettő szinkronban van. A cím pont, hogy elég ritkán változik. Szerintem nem történik semmi tragédia, ha itt ennél duplikáció van.
Hogy nálad nincs country, az pedig könnyen pótolható. Legfeljebb mindegyiknél "hu" lesz a kód, aztán annyi.Amúgy ezt írják:
"Note that this Module does NOT handle User/Admin authentification. You have to do this by yourself, either by CAuthManager, CDbManager, the yii-user-management or the srbac Module. Instructions on how to integrate this Module with the Yii User Management Module will be available soon, it is already prepared"De amúgy biztos van Yii-hez más webshopmodul is, ezt amúgy is fikázzák páran a kommentekben, amennyit láttam, hogy gányolások vannak benne, megpróbálkozhatnál esetleg egy másikkal is, nehéz elképzelni, hogy ne lenne valami bevált webshop extension Yii-hez is, hátha van olyan, aminél normálisan leírják a felhasználók adatainak lazán csatolt kezelését.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz #36268800 #13193 üzenetére
Soakhoz csatlakozva ez innentől már erősen OFF topic, nem annyira PHP-s kérdés, hacsak még nem a szerveroldali kimenetgenerálásról, template-ezésről van szó.
De hogy választ is írjak:
A táblázatokat jogosan nem szokás ajánlgatni, mert macerás, kisebb rugalmasságot kínál legfőképp olyan esetben, amikor az oldal tele van ilyen-olyan lebegő-úszkáló elemekkel, blokkokkal; az egymásba ágyazott táblázatok kódja ráadásul gusztustalan, plusz a böngészőre felesleges többletrenderelési feladatokat ró. Erre az ember leginkább akkor jön rá, amikor már megpróbálkozott mindkét módszerrel, és látta, hogy összességében tényleg nem véletlenül ajánlgatják a dives megoldást, nem puszta hype-olásból. Ha megnézed, manapság a népszerű oldalak nem táblázatos felépítésben készülnek, nem véletlenül; ergo ez jobban bevált. (Nyilván nagyon sokan még mindig megrögzöttségből azt mondják, hogy márpedig a table is pontosan ugyanolyan jó, és hülye az, aki az új divatot nyomatja - nem kell rájuk hallgatni. Valószínűleg nem kellett még szopniuk undorító egymásba ágyazott táblázatokkal. Tényleg nem erre találták ki. Ettől függetlenül nagyon sokan sajnos túlzásokba esnek, és még a ténylegesen táblázattal megoldandó feladatokra is képesek diveket alkalmazni, és aztán CSS-sel ráerőltetni a display:table, display:table-row, display:table-cell, stb. kényszermegoldásokat, ami meg már megint nagyon gány. A layout tehát ne táblázat legyen, viszont ha neked tényleg egy táblázat kell a tartalmi részre (pl. adatok rendezett megjelenítésére), akkor az maradjon is táblázat.)
Jól gondoltad, azt sem két perc megtanulni, a sitebuild igazából külön "szakma". A sitebuilderek sokszor grides, pl. SASS-sal támogatott megoldásokat is igénybe vesznek a munkájuk gyorsítása érdekében (pl. Zen Grids, de kismillió példa van még). A layoutot valóban generálni szokás, de erre saját motort nem hiszem, hogy kezdőként megérné írnod. Max. ha gyakorlásnak szánod.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13197 üzenetére
DeltaPower leírta, miről szól.
Ez nem osztott tárhelyes téma. Lokális környezetben viszont nagyon jól hasznát tudod venni, megírod a SASS-fájlt, legeneráltatod ebből a CSS-kimenetet (figyelteted a változásokat az adott könyvtárban, és fájlmentéskor automatikusan legenerálódik a CSS-fájl belőle, majd frissíthetsz is a böngésződben), majd a végeredményt feltöltheted (a generált CSS-fájlokat, persze érdemes a *.scss fájlokat is feltöltve is megtartani). Gyorsítja a munkádat a CSS-ben pöcsölés helyett. Mindenképp érdemes kipróbálni, újrafelhasználható kódokat tudsz vele írni, egymásba ágyazott tulajdonságaid lehetnek, használhatsz változókat a kódodban, akár matematikai kifejezéseket lehet kiértékeltetni vele a kódodban, feltételvizsgálatokat használhatsz, ciklusokat írhatsz vele, stb., szóval rengeteg olyan lehetőség nyílik meg így, amire egyébként CSS-ben nincs lehetőséged, kényelmessé teszi a melót, tényleg fasza. Ha szintaktikai hibát követtél el, akkor a mentéskor, a konzolon fog általában látszani a para (vagy ha van hozzá jó progid, pl. beépülő egy IDE-ben, még jobb). Kukkantsd meg ezt, itt van egy csomó kódrészlet, elsőre nem minden triviális, de ki kell próbálni, meg utána kell olvasni, és akkor nagyjából megvilágosodsz. Lehet használni a szintaktikáját amúgy a jsFiddle-ön is, ha a Languages-nél kiválasztod az SCSS-t, szóval akár ott is próbálkozhatsz, ha most localhoston nincs kedved.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Peter Kiss #13200 üzenetére
"mint a Notepad vagy a Netbeans"
Heh? Ezt most ugye csak poénnak szántad?Sk8erPeter
-
Sk8erPeter
nagyúr
Szarul fogalmaztam meg azt a részt, így utólag elolvasva. A generálásnál igazából template-ezést akartam írni, valamint azt, hogy előre megírt sablonokat, kereteket, jól bevált CSS reset fájlokat, a grides megvalósítást elősegítő SASS-kódrészleteket szoktak sokszor felhasználni, és hasonlók. Csak már nem volt kedvem jobban kifejteni, és a végét összecsaptam.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Peter Kiss #13204 üzenetére
De elég félrevezető a Notepadhez és a NetBeans-hez hasonlítani, mert a SASS/SCSS se nem szövegszerkesztő, se nem egy komplex fejlesztőkörnyezet , ez igazából olyasmi, mint egy szkriptnyelv, ami szabványos CSS-re "fordul", megfelelő előfeldolgozóval.
Amúgy közben itt találtam egy nagyon gyors összehasonlításra (LESS vs. SASS vs. Stylus) elég jó diasort: http://www.slideshare.net/presidento/css-elfeldolgozk.
Kissé hosszabban:
http://net.tutsplus.com/tutorials/html-css-techniques/sass-vs-less-vs-stylus-a-preprocessor-shootout/Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13209 üzenetére
Hümm, eszerint támogatnia kellene:
http://stackoverflow.com/questions/11321708/netbeans-scss-file-autocomplete-just-like-css-file/12198873#12198873
Próbáld meg innen letöltve:
https://code.google.com/p/scss-editor/downloads/list[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Félreértetted, eddig sem tömbindexekről volt szó, arra kérdezett rá, hogy hogyan vizsgálja, hogy "asszociatív tömb értéke" üres-e. Tehát pontosabban az asszociatív tömb kulcsainak/indexeinek értékét szeretné vizsgálgatni, hogy az egyenlő-e az üres stringgel.
Egyébként meg pont ebben az esetben nem látom be, miért is ne lenne jó akár az empty()-t is használni, hacsak nem azért, mert nem fejezi ki pontosan a kódot kutatva, mire is szeretnénk vizsgálgatni (üres string); de működést tekintve jelen esetben az elvártak szerint működne... Ha bármely olyan eset igaz abból, ami az empty() esetekre vonatkozik, akkor nem íratunk ki semmit.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13215 üzenetére
Kétszer szerepel a lezáró </td>, ez így hibás szintaktika. Gondoltam jelzem, mielőtt elkezdesz vele szívni.
A második lezáró helyett egy </tr> kéne oda.(#13218) Speeedfire :
így is át lehet rendezni, hogy ne kelljen neked a $data változó (nem mintha olyan sok vizet zavarna, de végül is tényleg nem muszáj használni):if($specs) {
$tablerows = '';
foreach($specs as $key => $spec) {
if($spec != '') {
$tablerows .= sprintf('<tr> <td> %s: </td> <td> %s </td> </tr>', $key, $spec);
}
}
if($tablerows != '') {
echo '<table>';
echo sprintf ('<tr><td colspan="2"><strong>%s</strong></td></tr>',
Shop::t('Product Specifications'));
echo $tablerows;
echo '</table>';
}
}most csak gyorsan összedobáltam
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Jaja, ez így szebb lehet, habár annyi hátránya mondjuk van, hogy így kétszer kell végigmenni a tömbön 1 helyett, ami meg lehet, hogy felesleges (bár sanszos, hogy futási időben nem tesz hozzá sokkal többet, max. ha óriástömbről van szó).
Asszem amúgy 5.3-tól vannak lambdák, igazából illene már az osztott tárhelyeken áttérni erre, ha még nem tették.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Con Troll #13274 üzenetére
Persze, úgy, hogy először kiíratod a <table> csomópontot, majd a for ciklusod csak ezután kezdődik, ekkor íratod ki a sorokat-oszlopokat, majd a ciklus után lezárod a </table>-lel.
Itt úgy lenne logikus, hogy van egy fejléce a táblázatnak, "Eltelt idő" és "Pillanatnyi aktivitás" feliratú oszlopokkal, és ezalatt kezdődik rendezve a kiíratás.
Csak gyorsan bepötyögött szemléltetésként: http://ideone.com/hCnDEr
Nyilván a for ciklusmagban lévő részt cseréld le a saját szövegeidre, értékeidre a <td>-ken belül.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Brown ügynök #13289 üzenetére
Kerülő megoldásnak a kommentekben szereplő módszerek:
http://www.php.net/manual/en/security.magicquotes.disabling.php#91653
http://www.php.net/manual/en/security.magicquotes.disabling.php#91585Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Brown ügynök #13292 üzenetére
Miért is nem játszanak? A request feldolgozásának kezdetére nem tudsz injektálni saját kódot?
Egyébként .htaccess fájlba ez kell, hogy kerüljön:
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_flag magic_quotes_gpc off
</IfModule>Így nem "száll el", ha az adott modul nincs betöltve.
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz #68216320 #13322 üzenetére
Ilyenkor érdemes megnézni a visszatérési értékeket, és ha gond volt, akkor megnézni a hibát, pl. a Te kódodnál valahogy így:
$result = curl_exec($handle);
if($result === false){
echo 'Curl error: ' . curl_error($handle) . '. Curl error no.: '. curl_errno($handle);
}
else {
..................
}a hibaüzenet pedig ezt fogja írni:
"SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"
(hibakód: 60)Ezt a hibát pedig ez fogja megoldani:
http://stackoverflow.com/questions/6400300/php-curl-https-causing-exception-ssl-certificate-problem-verify-that-the-ca-cer/10566962#10566962curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
Viszont figyelj a biztonsági problémára, amire a linkelt hsz.-ben felhívják a figyelmet.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #13328 üzenetére
még annyi, hogy ha nem akarod kiíratni a fejléceket, akkor kommenteld ki ezt a sort:
curl_setopt($handle, CURLOPT_HEADER, true);
ezután így használhatod könnyedén:$json_decoded_data = json_decode($result);
echo $json_decoded_data->pool_name;Sk8erPeter
-
-
Sk8erPeter
nagyúr
válasz sebastien19 #13338 üzenetére
JavaScripttel lehet ellenőrizni, hogy milyen gomb lett lenyomva a billentyűzeten vagy az egéren, erre korábban írtam egy szemléltető kódot, amit itt ki tudsz próbálni:
http://jsfiddle.net/Sk8erPeter/EAjYe/A baj viszont az, hogy elvileg az event object módosítható, meghamisítható, így talán csak a másodpercenkénti irreálisan magas kattintásszámot tudnád kiszűrni kliens- és szerveroldalon egyaránt. Na, hogy ez mennyi, az már jó kérdés.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz spammer #13345 üzenetére
"Azzal működött, nem az volt a probléma, hanem hogy simán beírva a $dest vagy $dest2 nem ment."
Pedig de, az probléma, amit írtam.
Nézd meg még egyszer ezt a stringet:
'origins=04429&destinations=$dest&mode=driving&units=imperial&sensor=false'
mint látható, sima aposztrófot használsz, így a $dest nem fog behelyettesítődni, még jó, hogy rossz eredményt kapsz, mert így küldi el a szervernek: destinations=$dest, ahogy van (szóval a szerver a $dest-et kapja értékül).
Amúgy Te magad mondtad, hogy nem működött úgy.<form id="destCalc" action="<?php echo $_SERVER["PHP_SELF"]; ?>" method="post">
itt ez az echo-zás tökéletesen felesleges.
Ezt nyugodtan cseréld le így:
<form id="destCalc" action="" method="post">
az üres action pont azt csinálja, hogy önmagára küldi el a formot.
Mondjuk gondolom azt vágod, hogy ennek megvan az a hátránya, hogy a böngésző cs×szeget F5 nyomkodásakor, hogy biztos el akarod-e küldeni még egyszer a POST-adatokat.Amit viszont most nem értek, hogy miért POST-metódussal küldöd el az adatokat, amikor korábban GET-et használtál. Így nem is merülne fel az a probléma, amit az előbb említettem.
"oldalfrissítés nélkül betöltse a php kódot (hogy lássam az eredményt)"
Ezt most nem egészen értettem. Mit is szeretnél?Ha jQuery+AJAX témáról van szó, akkor javaslom a jQuery topicot. A PHP-része persze jöhet ide, mindenesetre hint: json_encode()-dal küldd vissza a kliensnek az adatokat, úgy lesz a legkönnyebb kezelni.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz spammer #13373 üzenetére
Igazából mi a nem szimpatikus rajta? Hogy nem olyan egyszerű, mint a lepkefing?
Amúgy sokszor CMS-eknél/frameworköknél azt csinálják, hogy minden URL-t ráfuttatnak az index.php-re, fix query stringként (pl. index.php?q=adsasd/123/asd), aztán az adatbázisban az URL aliasok táblájában keresik meg a kapott query stringet, és ez van leképezve az alkalmazás működésének megfelelő "valós" címekre.
De az általad linkelt módszer is teljesen jó.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz spammer #13381 üzenetére
Úgy, hogy olyan regexpet használsz a RewriteRule-nál, ami a számokra illeszkedik, a "view" szócskát meg "beledrótozod".
Pl. ilyesmi:
RewriteRule ^(\d+)$ index.php?page=view&id=$1 [QSA,L]Ez illeszkedik arra, amit írtál. A \d minden numerikus karakterre illeszkedik. A +-szal pedig azt várod el, hogy egy vagy több ilyen minta legyen a stringben (tehát szerepelhet benne simán 9 vagy 6432 is). A ^ a string kezdetét jelöli, a $ pedig a legvégét, azért jó jelen esetben így korlátozni, mert pl. nem illeszkedik arra a mintára, hogy "a321b" vagy "a321" vagy "321b".
De egyébként érdemesebb beszédes neveket használni az URL-nél, pl. ilyesmi:
www.example.com/articles/110/ez-egy-nagyon-erdekes-cikkRegExp tesztelésére tudom ajánlani többek közt ezeket:
http://regexpal.com/
http://gskinner.com/RegExr/
utóbbi Flash-alapú, de nagyon beszédes segédlet van hozzá. Mindkettő ajánlott.[ Módosította: BomiBoogie ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz spammer #13383 üzenetére
Jaja, jól teszed, az úgy a legjobb.
Most látom, már én is megzavarodtam, és szintén RewriteEngine-t írtam RewriteRule helyett Mindjárt szerkesztetem egy modival az előzőt, hogy ne ez maradjon benne.
www.example.com/articles/110/ez-egy-nagyon-erdekes-cikk
erre meg valami ilyesmi illeszkedik:
RewriteRule ^(\w+)/(\d+)/(.+)$ index.php?page=$1&id=$2 [QSA,L]
(itt a 3. részt, tehát az "ez-egy-nagyon-erdekes-cikk" stringet nem vettem figyelembe, mert a struktúrád szerint az most nem is kell)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz don.racz #13400 üzenetére
Sok szerencsét hozzá, de azért ez itt nem így működik. Inkább úgy, hogy leírod szépen a komplett problémát, mutatsz példakódot, megmutatod, mire jutottál eddig, aztán megpróbálunk segíteni. De a fórum nem privát segítség-megoldásokra, meg egyéni Skype-olásokra való. Tiszteld mások szabadidejét is.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13399 üzenetére
Ebben a formában azért ez elég furcsa... Nem is tudod felülbírálni? Mert ez alapján olyan, mintha komolyabb hibákra nem dobhatnál egy szép felhasználóbarát hibaoldalt, hanem majd a Yii szépen megmondja, hogy itt aztán gáz van, de feltételezem, azért ezt megoldották valahogy, elég régi keretrendszerről van szó...
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Andoidtibi #13418 üzenetére
Amit most csinálsz:
egy <table> elembe 15-ször kiíratod egy <ul>-be az aktuális elemet.
Ez szintaktikai hiba (meg nem a feladatnak megfelelő): <table> elemen belül ezek lehetnek:
http://www.w3.org/TR/html-markup/table.html.
Tehát <table> után jöhet egy <caption>, <colgroup>, <thead>, <tbody> vagy <tfoot> elem, vagy esetleg egyből a <tr> (táblázat sora), ami pedig <td>-(ke)t (táblázat oszlopa) tartalmazhat.
De <ul> semmiképp sem következhet egyből. Ezenkívül az <ul> elemen belül csak <li> elemek szerepelhetnek.
Itt van egy egyszerű 3 oszlopos, 3 soros táblázat, a felső sor a fejléc:
http://jsfiddle.net/JH48Z/amit Te szeretnél, annak a kimenete így néz ki szintaktikailag helyesen:
http://jsfiddle.net/JH48Z/1/
vagy <tbody> nélkül is jó:
http://jsfiddle.net/JH48Z/2/Na, tehát ennek megfelelően kell kiíratnod, ez az első, amit végig kell gondolnod. Próbáld meg az összes lépést egyesével végiggondolni, akár papírra is leírhatod, ha úgy egyszerűbb (algoritmizálj).
Először ki kell íratni a <table> elemet (majd a végén, a tartalom bepakolása után le kell zárni). Aztán jön a <tr>, most csak egy sort szeretnél, tehát akkor ezt csak egyszer kell kiíratnod, majd ebbe kerül majd a 3 <td>, a <td>-ken belülre pedig az 5-5 listaelem (<ul><li>...</li></ul>). De hülyebiztosra kell elkészítened a kódot, számítani arra, hogy a tömb elemeinek száma változni fog. Pl. működjön úgy is, ha csak 10 elemed van, meg akkor is, ha 632.
Most vegyük azt, hogy mindenképp azt szeretnéd, hogy mindig legyen 3 oszlop, és mindig 5 elemet írjon az adott oszlopba, már ha van annyi (ha már nincs annyi, akkor a maradékot pakolja bele az aktuális cellának aktuális listájába).
Ha tök általánosan akarod megoldani, lesz három ciklusod egymásba ágyazva. Egyikben kiírod a szükséges számú sort (itt most 1, de lehetne jóval több is), a benne lévő ciklusban a szükséges számú cellát (itt 3), az azonbelül lévő ciklusban pedig a listaelemeket íratod ki.
Amire szükséged lesz, a felső egészrész egyszerű kiszámítására vonatkozó függvény: ceil()Egy elég általános megoldás, amit gyorsan bepötyögtem, kipróbáltam, jó:
$elementsArray = array("Egy","Kettő","Három", "Négy" , "Öt" , "Hat" , "Hét" , "Nyolc" , "Kilenc" , "Tíz", "Alma" , "Dió" , "Mák" ,"Körte" , "Cseresznye"
, "asd", 'asd', 'qwe', 'retkljwer', 'xycbm'
);
$nrOfElements = count($elementsArray);
// szükséges listaelemek száma
$nrOfNeededListElements = 5;
// szükséges oszlopok száma
$nrOfNeededColumns = 3;
$nrOfNeededRows = ceil($nrOfElements/($nrOfNeededListElements*$nrOfNeededColumns));
// $nrOfCellsToFill = ceil($nrOfElements/$nrOfNeededListElements);
$nrOfElementsPrinted = 0;
echo '<table class="list-items-table">';
for($row = 0; $row < $nrOfNeededRows; $row++){
// sor
echo '<tr>';
for($cell = 0; $cell < $nrOfNeededColumns; $cell++) {
// <td>-t mindenképp kiírjuk, üresen is (bár elvileg nem feltétlenül muszáj)
echo '<td>';
// akkor írjuk csak ki az <ul>-t, ha szükséges
if($nrOfElementsPrinted < $nrOfElements) {
echo '<ul class="list-items">';
for($i = 0; ($i < $nrOfNeededListElements) && ($nrOfElementsPrinted < $nrOfElements); $i++) {
echo '<li>';
echo $elementsArray[$nrOfElementsPrinted];
echo '</li>';
$nrOfElementsPrinted++;
}
echo '</ul>';
}
echo '</td>';
}
echo '</tr>';
}
echo '</table>';Azért jó, hogy általános, mert változtathatod benne ezt a két változót:
$nrOfNeededListElements = 5;
$nrOfNeededColumns = 3;így az elsővel meghatározhatod, hány listaelemre lesz szükséged (neked most 5 kellett), a másodikkal pedig azt, hogy hány oszlopra van szükséged (itt 3). Ha átállítod másra, úgy is működőképes.
Itt láthatod, mi lesz a kimenet (egy sorba pakolja, ezzel most nem foglalkoztam, hogy legyen elválasztva a kódban sortöréssel - lásd PHP_EOL):
Ergo így fog kinézni, ide bemásoltam a kimenetet:
http://jsfiddle.net/JH48Z/3/[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz Speeedfire #13426 üzenetére
"De ha gondolod próbáld rekonsturktuálni oracle alatt pdo-val ezt a dolgot, mert kíváncsi lennék rá."
Milyen dolgot? Én már az elejére sem emlékszem.Igazából csak arra lettem volna kíváncsi, rájöttél-e, hogyan bírálhatod felül a Yii erőszakos kivételkezelését, mert úgy tűnt, nem tudod elkapni a keletkező kivételt, mert már előbb kitolja a kimenetre a Yii, ami gáz.
"Egyszerűen az oracle nem akarja támogatni a pdo-t. "
Nem fordítva kéne, hogy legyen a fejlesztési irány?Sk8erPeter
-
Sk8erPeter
nagyúr
válasz pvt.peter #13428 üzenetére
Igazából azt pötyögted be, ami kommentekben is megtalálható, túl sok új nincs benne. Ez a query1(), query2() elég mágikus név, mit akarsz vele megvalósítani? Mindenesetre már az elnevezés is rossz. De legfőképp az, hogy fel akarod fedezni a spanyolviaszt: ne akarj n+1-edik adatbázis-kommunikációs wrapper osztályt csinálni, ott a mysqli és a PDO, valamint remek ORM-ek vannak. Írtad, hogy a mysql_ függvények használatára vagy kényszerítve, de ezt az érvet sajnos nem tudjuk elfogadni. Tehát minimum mysqli vagy PDO, a mysql_ kezdetű függvények használatáról 2013-ban már nincs is értelme beszélni.
Volt már korábban itt egy (v. több) hitvita a topicban, hogy Singleton-minta jó-e vagy sem, a vége az lett, hogy több érv szól a nem mellett (itt olvashatsz róla többek közt: [link], meg persze a topicban, a Singleton szóra rákeresve).Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #13431 üzenetére
"Hogy fordítva?"
Úgy, hogy nem az Oracle-fejlesztőknek kell ráfeküdniük izomból a PHP-val való együttműködésre, hanem a PHP fejlesztőinek...Sk8erPeter
Új hozzászólás Aktív témák
- Skoda, VW, Audi, Seat topik
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen NAS-t vegyek?
- Samsung Galaxy Watch6 Classic - tekerd!
- Gyúrósok ide!
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- PlayStation 5
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Politika
- Lalikiraly: MSI notebook kijelző. A bolt szerint ez természetes.
- További aktív témák...