Keresés

Új hozzászólás Aktív témák

  • Sk8erPeter

    nagyúr

    válasz mobal #8725 üzenetére

    Jópofa. Bár gondolom ez még erősen alakítgatás alatt van, javaslatként annyi, hogy az archívumnál lévő dátumok linkek legyenek, valamint ugyanez vonatkozik a cikkhez tartozó címkékre is. Egyébként a "szerviz" szó - még ha az ember nem is ezt várná - rövid i. :K

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz biker #8731 üzenetére

    Hát nem tom, szerintem egy "jól" összezagyvált kódot visszafejteni úgy, hogy aztán sikerüljön értelmezni is, mi mit csinál, aztán megváltoztatni mindent úgy, hogy értelmes változó- és függvénynevek legyenek a kódban, ismét felkommentezni, hogy következő hozzányúláskor ne kelljen már megint hajadat tépni, hogy átlásd, nem egy egyszerű munka.
    Nem tartom magam amatőrnek (ha az az állítás, hogy csak azok ellen véd), de nem szívesen vállalkoznék ilyenre... :U
    Persze gondolom a query-ket meg stringeket nem lehet összezagyválni, úgyhogy az sokat segít.
    Az ismerősöd meg lehet, hogy szintén nem szívesen vállalkozna egy visszafejtegetésre, vagy kis túlzással ennyi idő alatt már meg is írná inkább magától az egészet.
    Aztán lehet, hogy vannak zsenijelöltek, akiknek mindez pikkpakk megy, most így hirtelen nehéz elképzelni, hogy lehet egy "jól" obfuszkált, más által megírt kódot visszafejteni, értelmezni, majd annyira belejönni, hogy máshol is alkalmazni tudd, mindezt normális idő alatt, hogy ne érezd úgy, hogy ezzel értékes, valós pénzt kínáló munkaórákat dobálsz ki az ablakon...

    Ettől függetlenül még mindig választhatod az API-t vagy web service-t, csak ezt is elég melós lehet megírni jól.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Tele von Zsinór #8733 üzenetére

    köszi, ez a példa teljesen érthető. :R Amúgy közben megnéztem a Wikipédiás, JavaScriptes példát is, az is teljesen világossá teszi, hogy tulajdonképpen mire is való az egész.

    Mostanában én a Drupalra és az ahhoz való modulírogatásra vagyok rákattanva, meg azonbelül is van template-ezés, szerintem nagyon jól átlátható.
    Egyébként Ti hogy álltok a CMS-kérdéshez?
    Régebben, amikor belecsöppentem az egészbe, és még nem sokat tudtam erről a témáról, fura módon azt gondoltam, a CMS-ek inkább kezdőbbeknek való, gyors honlap-összepakolásra. Amióta a Drupalt használom, rájöttem, hogy ennél sokkal komolyabb dologról van szó - nagyon komplex dolgokat is össze lehet hozni egyéni modulírással vagy mások moduljának felhasználásával, a modulírásba való beletanulás után egészen gyorsan, szóval nagyon ki van ez találva. Nektek mi a véleményetek ezekről? Ahogy elnézem, sokkal szívesebben használtok frameworköket, mint pl. bármilyen CMS-eket.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8737 üzenetére

    Igen, de az "inkább kezdőknek való" résszel már abszolúte nem értek egyet, pont azóta, mióta jobban belemerültem a Drupal-fejlesztésbe. Ahogy elnézem a Drupal-közösséget, ott is nagyon nagy számban fordulnak elő jó programozók, nem olyanok, akik tegnap kezdték. Tulajdonképpen most már nem látom be, hogy mitől lenne "profibb" mondjuk egy keretrendszerrel, a széles körű testreszabást lehetővé tévő grafikus admin-felület nélkül összehozni egy honlapot, mint egy CMS-sel. Drupal-modulfejlesztés sokszor bizonyos komplikáltabb feladatokat alaposabb PHP-ismeret nélkül egyszerűen lehetetlen összehozni. Viszont az egész "rendszer" átgondoltsága és a meglévő API-k miatt radikálisan redukálódik (ezt a két szót most muszáj volt egymás mellé raknom, annyira jól hangzik :DD) a fejlesztésre fordítandó idő. Nemrég már némi Drupal-tapasztalattal hoztam össze egy egyszerű, többnyelvű céges honlapot, egyszerűbb kódolásra is szükség volt, de nagyon gyorsan össze tudtam kalapálni. De komolyabb célokra is esélyes, hogy a Drupalt választanám. A jól megírt és szintén alaposan testreszabható jogosultsági rendszer (szinte a legapróbb részletekig beállítható, melyik felhasználónak mire van jogosultsága), valamint a cache-elési mechanizmusok, a security és egyéb update-ek gyors megszületése, valamint a mögötte álló nagy közösség is mellette szólnak.
    Igazából a modulfejlesztés széleskörűsége miatt nem is nagyon látom a Drupal alatti fejlesztés korlátait, ami miatt feltétlenül át kellene térni inkább keretrendszerre - persze bizonyára vannak olyan feladatok, amik esetleg gyorsabban összehozhatók épp egy komolyabb frameworkkel, de akkor talán még mindig egálban van a kettő, mivel a Drupalnak ugye elég komoly grafikus alapú admin-felülete is van, meg a meglévő modulok miatt rengeteg megoldás már tálcán van kínálva a hivatalos honlapon.

    Az mondjuk lehetséges, hogy épp a nagy felhasználói bázis miatt talán több a kísérlet a rendszerek feltörésére. Bár tudtommal a biztonság kérdésében is egész jól helytáll (most hirtelen mondjuk nincs előttem erről szóló kimutatás).

    Ezek miatt a szempontok miatt érdekelne, hogy ki miért tartja mondjuk kevesebbre a CMS-eket, miért gondolja úgy, hogy akkor is a framework a nyerő egy profi környezetben. (Bár gyorsan hozzáteszem, elég sok profi környezetben használják a Drupalt is.)
    Itt nyilván elég sok szempont van, érdekelnének a különböző vélemények.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8739 üzenetére

    Persze, a frameworköknek is bőven megvan a létjogosultsága, ez nem is kérdés.
    Csak az én kezdeti véleményemet befolyásolták fórumos hozzászólások is (nem feltétlenül itt, és most nem linkelek konkrétakat, mert honnan tudjam már, hol vannak azok :D), miszerint elsősorban kezdőknek valók a CMS-ek, ami ebben a formában baromság.
    Arra lennék kíváncsi, hogy vajon mi az oka a CMS-ek degradálásának.

    "Viszont itt van is egy kis hátulütője a dolognak. Sok zugweblapkészítő wp-t használ, de ha már kell valami extra dolog, akkor sírnak rínak a megrendelőnek, hogy ezt nem tudja kivitelezni."
    Ez nem látom be, miért a CMS-ek hátulütője. Ez a zugweblapkészítő gyökérségét (finomabban: hozzá nem értését) igazolja, ez a szememben nem a CMS-ek "hátulütője". :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CSorBA #8743 üzenetére

    És mi ezzel a filozófiával a probléma? Úgy tűnt, mintha ezt negatív dolognak akarnád beállítani.

    (#8744) Speeedfire : "4. Adjuk el pofátlanul drágán (a sz*rt)."
    Ezt a hozzáállást megint nem értem. Miért kellene, hogy szar legyen?
    Attól még, mert valaki ingyenes CMS-sel dolgozik, vesz hozzá egy igényes sablont, mert mondjuk nincs pénze külső, brutális pénzekért dolgozó dizájnerre, vagy csak simán talált egyet, ami neki megfelel, és aztán még módosítgatja az oldalt ízlésének és az igényeknek megfelelően, nem értem, miért kellene, hogy szar legyen egy weboldal!
    Azt meg el kell fogadni, hogy ami jól néz ki, megfelel az igényeidnek, azt általában igenis meg kell fizetni.

    Tudod, mi a nevetséges? Amikor hozzánk bejött az irodába egyszer egy csávó, hogy ő 35 ezer Ft-ért (!!!) komplett ingatlanközvetítő portált akar összetett keresővel, admin-felülettel, képfeltöltési lehetőséggel, stb.
    Azt hittem, eldobom az agyam... :DD

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CSorBA #8748 üzenetére

    Ja, látom ezt a template-et alkalmaztad. :)

    Nekem a Joomla már akkor komolytalanná vált, amikor széjjeldobálta a fél éve legfrissebb verziója az oldalamat mindenféle PHP-s hibával, ami az E_STRICT bekapcsolása miatt történt - de nem kevéssel, hanem úgy minimum ötvennel, vagy többel. Egy sokak által használt CMS-nél ugyan figyeljenek már azokra az alapvető programozási technikákra, amikkel az ilyen hibadobálások elkerülhetők. Nem, az nem érv, hogy "dehát ne legyen E_STRICT" - de, fejlesztés alatt igenis legyen.
    Aztán nekem személy szerint valahogy gyorsan elment a kedvem a Joomlától, nem láttam benne a potenciált, hogy annyira testreszabható lenne, mint a Drupal, hogy bizonyos felhasználók kezéből kivegyem az irányítást, és csak valami apró részletre adjak jogot, nem tartottam átláthatónak és következetesnek a kódját (ami fejlesztői szempontból - ha modulokat akarok írni, stb. - nem mindegy), és valahogy számomra összecsapottnak tűnt. Senki ne vegye sértésnek, aki Joomla-rajongó.
    Megerősítve láttam azokat az érveket, amiket a Joomla ellen írtak különböző fórumokon.
    Ahogy a Drupalt használtam, eleinte az is rettenetes káosz volt számomra, de már kezdetektől fogva úgy éreztem, hogy ez egy alapvetően egészen profi rendszer, csak még nem ismerem ki magam rajta - nem volt az az érzésem, mint Joomlánál, hogy mintha egy könnyen összedőlő kártyavárba akarnék berendezkedni (inkább mintha egy erődítménybe :D).
    Nem akarok papolni a Drupal mellett, de számomra a Joomla emellett akkor is komolytalan marad.
    Ettől függetlenül természetesen elhiszem, hogy egész jó honlapokat össze lehet benne hozni.

    Ja, és bocsánat, mielőtt elfelejtem: kollégámmal majdnem egyszerre kezdtünk fejleszteni két tök különböző oldalt, ő Joomlát használt, én Drupalt. Az ő oldalát nagy meglepetésünkre egyszer csak feltörték (valami török zene szólt egy iframe-ből az index.php cím alatt), az enyémet nem, és - lekopogom - eddig azóta sem törték fel. Lehet, hogy ebből nem feltétlenül szabad messzemenő következtetéseket levonni, de valahogy az volt az érzésem, hogy ez valamelyest utal az egyik vagy másik rendszer megbízhatóságára is.
    Ahogy sok fórumon azt is olvastam, amikor még vacilláltam, melyik legyen, Joomla vagy Drupal, hogy állítólag a Joomla elég sok biztonsági rést tartalmaz(ott) - lehet, hogy ezeket azóta mind befoltozták, és lettek helyettük újak, nem tudom. Mindenesetre a régebbiek ezek szerint egész jól támadhatók.

    Azt nem tudom, Joomlához milyen tempóban jelennek meg security update-ek a felfedezést követően, de Drupalhoz nagyon gyorsan elkészítik, ha találnak biztonsági rést, így ez kellő prioritást élvez a fejlesztők munkájában - számomra ez is elég pozitív.

    ===

    (#8749) biker : az már valamennyire közelít a rendes árhoz. Kár, hogy az egész oldal Flash-alapú, pedig jó lenne, de én ezekről az oldalakról valahogy ösztönösen menekülök... :(

    ===

    (#8752) mobal: én fentebb egy kicsit fáradtan, de próbáltam elmondani a szempontjaimat, hátha érdekel ez a vélemény is a Joomla vs. Drupal témáról.

    (#8754) mobal: "Hát nem tudom. Szerintem semmi gond nincs a Joomlával, semmi ilyet nem olvasok róla."
    Pedig ezeket a véleményeket kb. 5 perc Guglizás alapján meg lehet találni, én is ugyanezeket olvastam, amikről Speeedfire beszél, pedig elején mindkettőre nyitott voltam.
    Ahogy fentebb láthatod, ki is próbáltam mindkettőt, és végül saját tapasztalat alapján döntöttem. Választottam a nehezebbet, de profibbat.

    ===

    (#8753) Speeedfire :
    ja, világos. Attól még, mert valaki össze tud dobálni mondjuk egy blogos oldalt Wordpress-ben, attól még tényleg nem ő lesz a webfejlesztők királya, ez tény. :D Amúgy értem, mit akarsz mondani, mintha a CMS-ek használatától valaki venné a bátorságot, hogy elmondhassa magáról, hogy ő profi weboldalakat tud készíteni, pedig az anyja vasporosát. :DDD

    "CSorBA: Mutatós oldal, bár nem értem a joomla-sokat, hogy miért nem szeretik használni az apache mod_rewrite modulját."
    Tényleg, ezt én is megfigyeltem, hogy ez valahogy náluk rendszerint lemarad. :D (tisztelet a kivételnek) Drupal már a kezdetek kezdetén felajánlja, hogy ezt igazán bekapcsolhatnád, mert van rá mód (ha van).

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CSorBA #8760 üzenetére

    "Drupalban nem vagyok annyira otthon, de úgy vélem, ha valamire nem jó a Joomla, akkor nem a Drupálhoz nyúlnék, hanem sajáthoz :) Azt hiszem ezzel Te is így lehetsz."
    Nem, mert én eleve a Drupallal kezdenék. :DDD
    Na, de tulajdonképpen pont erre akartam kitérni, hogy manapság már nagyon megfontolnám, hogy érdemes-e belekezdeni saját rendszer megírásába - az esetek többségében nem biztos, hogy megéri beáldozni azt a rengeteg hasznos munkaórát, amit csak példaként azzal töltök, hogy egy szép fastruktúrát építsek a menürendszeremhez, hogy akár több egymásba ágyazható menüpontom is legyen. Persze ilyenkor jól jön, amikor az embernek van korábbról kódja, csak valahogy a saját kódjaimmal eleve úgy vagyok, hogy állandóan találok benne valami javítanivalót, így rengeteg időt eltöltök a kód felülvizsgálatával. :D Na mindegy, pl. egy ilyen eleve megvan egy CMS-ben, vagy akár egy framework is ezeket a feladatokat sokkal könnyebbé teszi. Most, hogy talán mondható, hogy eléggé belejöttem a Drupalhoz való modulfejlesztésbe, tényleg egyre kevésbé látom a határait, hogy hogyan oldjak meg dolgokat rugalmasan, egyre inkább híve vagyok annak, hogy komplett saját rendszer helyett érdemes felhasználni egy meglévőt, aminek a hibáit sokan felülvizsgálják, javítják, nem kell saját óriási erőforrásokat (pénz, idő, fáradság) szánnom erre a részre is.
    Azt is megértem, hogy Te ragaszkodsz a Joomlához: miután az ember átesik azon a szakaszon, hogy "hű, de gyűlöllek, nem értek semmit, nem értem, ezt miért nem tudom elkészíteni, na akkor debuggoljunk megint több órát", majd sikerei vannak vele, és rájön a dolog hátterére, már egészen kezd hozzánőni a szívéhez. :D
    Egyébként a CMS-ekkel készített, igazán igényes honlapok elkészítéséhez szerintem elengedhetetlen a PHP-ismeret: sokszor a számtalan modul felrakása, próbálgatása, majd a jobb füled bal kézzel, a tarkód mögül történő megvakarása helyett lehet, hogy a fejlesztői API segítségével csak néhány sort kell kódolnod a megfelelő helyen, és még erőforrás-takarékos is marad a dolog.

    Bocs, hogy ennyit ugatok a témáról, csak lököm, ami hirtelen eszembe jut. :DD
    Na meg még mindig érdekel a dolog, hogy ki mit gondol a CMS-ekről, és miért - főleg, ha negatív véleménnyel van róluk.

    ===

    (#8758) biker: jah, akkor jó. :D Gondolom azért nem két perc volt összehozni, ahhoz túl igényes. Bár őszintén szólva fogalmam sincs a Flash-alapú fejlesztésről, hogy milyen segédeszközöket lehet hozzá felhasználni - valószínűleg nem is fogok tudni erről a témáról komolyabban semmit. :) Inkább a csillivilli dolgokhoz valami JS-alapú UI-t igyekszem használni, bár tudom, a Flash-eshez képest ez még mindig korlátosabb, vagy talán nehézkesebb. Bár attól függ, pl. az Ext JS elég komoly dolgokra képes.

    ===

    (#8759) Speeedfire :
    "Lényeg, hogy érdemes cms-t használni/ismerni szerintem. Kisebb munkákhoz pikk-pakk, egyedi rendszerhez meg framework."
    Na, épp ez az, amit felvetettem. Hogy egyedi igényekhez is bőven használható pl. egy Drupal. Ezt próbáltam megérteni, vajon mi az oka, hogy sokan ennyire ragaszkodnak ahhoz az állásponthoz, hogy egyedi és profi dolgokhoz márpedig csak egy framework jó.
    Aztán persze lehet, hogy tényleg simán elképzelhető olyan honlap, aminél könnyebb összehozni framework segítségével, mint CMS-sel.

    ===

    (#8761) Athlon64+ : na igen... ez amúgy érdekes probléma. Kíváncsi lennék, Windows-on mi a workaround az APC helyes működtetésére.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8763 üzenetére

    Legutóbb én pont IIS-en + FastCGI PHP-vel próbáltam az APC-t, és hasonló eredménnyel - az oldalak állandóan crash-eltek.

    (#8764) Speeedfire : ja, az open source-t mindenki láthatja, ez igaz. Ettől függetlenül saját kódba is bőven lehet tenni biztonsági réseket, és nincs "több szem többet lát"-alapon történő hibafelderítés, igaz, itt a bugokat valóban talán tovább tart felfedezni épp a rendszer ismeretlensége miatt.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz biker #8766 üzenetére

    Ja, hát még mindig van, amire a Flash vagy a Silverlight az üdvös megoldás, pl. tipikusan az ilyen 3D-s, "bejárom a szobát"-jellegű dolgokra.
    De komplett honlapot építeni erre az számomra nem túl tetszetős. Ha vegyítve van, az már valamennyire okés.

    Amúgy a 3 hét alatti elkészítés igen korrekt idő... Akkor ott túl sok tökölésre nincs lehetőség.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8768 üzenetére

    Mondjuk ezt most nem nagyon értem, miért is kerülő megoldás. Nálam amikor crash-elt, be is volt töltve az extension, és engedélyezve is volt, épp ezért crash-elt.
    Ezzel legfeljebb azt kerülöd el, hogy amennyiben nincs engedélyezve, vakvágányra fusson.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8772 üzenetére

    Az se rossz, de hogy az URL elmenthető és elküldhető legyen úgy, hogy azt megnyitva eleve növekvő sorrendben jelenjenek meg a dolgok, lehet, hogy ésszerűbb lenne azt is inkább GET metódussal átadni. De nehogy ez alapján tegyél bármit is közvetlenül a lekérdezésbe.
    Inkább pl. így nézhet ki egy URL vége:
    keres.php?page=2&asc=true

    PHP-ban pedig:
    if( !empty($_GET['asc']) ){
    // akkor növekvő sorrendben mutatja a találatokat
    }

    Az empty függvény itt ellenőrzi a változó meglétét is (isset - tehát nem kapsz notice-t, ha a csekkolás után felhasználod a változót), meg azt, hogy az nem üres vagy hamis értékű-e.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Chrystall #8775 üzenetére

    Pl.:
    ...
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de"', $context['right_to_left'] ? ...

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz fulton #8773 üzenetére

    Nem ártana ellenőrizni, hogy mi a hiba konkrét oka. Hibaellenőrzés nálad sehol nincs.
    Ráadásul erről szokj le, hogy előbb kiíratod a sikerről szóló üzenetet, mielőtt egyáltalán az érdemi feladatot végrehajtanád.
    Azt az ellenőrzések UTÁN írasd ki - előbb csekkold le, hogy a levél egyáltalán elment-e, majd attól függően írj ki bármit is.

    Pl. leellenőrizhetnéd az $smtp változót is, illetve a $sentmailt is:
    magyar nyelvű doksi:
    factory
    send

    A kommentek között meg van egy lehetséges példa hibaellenőrzésre:
    To handle errors when sending mail use the following. Great for checking if the SMTP server accepted all the addresses.

    $send = $mail->send($to, $headers, $body);
    if (PEAR::isError($send)) { print($send->getMessage());}

    :K

    ===

    Egyébként mi értelme van PHP-vel kiíratni itt a formot?

    <?php
    echo 'Ez egy teszt mail mert a * már * * * és remélem menni fog<br><br><br><br>';
    echo '<form method="post">'
    . 'Név: <input type="text" name="nev"><br>'
    . 'Téma: <input type="text" name="theme"><br>'
    . 'E-mail Címed: <input type="text" name="email"><br>'
    . 'Üzeneted:<br> <textarea name="message" rows=5 cols="40">Ide írhatod az üzeneted!</textarea><br>'
    . '<input type="submit" name="submit" value="küldés">'
    . '</form>';

    if(isset($_POST['submit'])) {
    ...

    HELYETT (!!) lehetne így:

    Ez egy teszt mail mert a * már * * * és remélem menni fog<br><br><br><br>
    <form method="post">
    Név: <input type="text" name="nev" /><br>
    Téma: <input type="text" name="theme" /><br>
    E-mail Címed: <input type="text" name="email" /><br>
    Üzeneted:<br> <textarea name="message" rows=5 cols="40">Ide írhatod az üzeneted!</textarea><br>
    <input type="submit" name="submit" value="küldés" />
    </form>

    <?php
    if(isset($_POST['submit'])) {
    ...

    Ami statikus rész, úgysem változik, azt felesleges PHP-val kiíratni.

    De vegyíteni is lehet a kettőt:
    <?php
    if( !empty($tokmindegy) ) :
    // itt jön a HTML-rész...
    ?>
    <form method="post">
    .........
    </form>
    <?php
    // HTML-rész vége...
    endif;
    ?>

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Louloudaki #8781 üzenetére

    Vagy jQuery, vagy más, teljesen mindegy.
    Amúgy miért kell neked másodpercenként AJAX-szal lekérni a szerveridőt?
    Miért nem jó itt kliensoldali számolgatás, és legfeljebb ritkábban szerveroldali időlekérés az ellenőrzés/korrekció érdekében?

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8783 üzenetére

    Jaja, teljesen egyetértek.
    Legfeljebb első oldalbetöltéskor lekéri a szerveridőt, aztán tovább már csak kliensoldalon számol.
    Különben tökéletesen feleslegesen zabál fel rengeteg szabad erőforrást a szervertől.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8785 üzenetére

    Pl. úgy megoldható, ha kiegészíted a jelenlegi keresőformodat így:

    <form ........>
    <div class="form-elements-wrapper">
    ...................
    <label for="price_asc">Rendezés:
    <select id="price_asc" name="price_asc">
    <option value="true"<?php if(isset($_GET['price_asc']) && $_GET['price_asc'] == 'true'){echo ' selected="selected"';}?>>Növekvő</option>
    <option value="false"<?php if(!isset($_GET['price_asc']) || $_GET['price_asc'] == 'false'){echo ' selected="selected"';}?>>Csökkenő</option>
    </select>
    </label>
    ....................
    </div>
    </form>

    A pontok helyére nyilván helyettesítsd be a saját attribútumaidat, illetve mezőidet.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8787 üzenetére

    Én is erről a formról beszéltem, amit kitöltenek... Akkor az index.php-n lévő formodat (ahova beírják a keresendő kulcsszót) egészítsd ki azzal, amit mutattam. Aztán a keres.php oldalon elhelyezhetsz még egy linket, ami a $_GET['price_asc'] értékét módosítja, tehát van egy link, ami a jelenlegi keresendő érték+'&price_asc=false' vagy épp true.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8789 üzenetére

    Ja, már minden világos.
    Akkor ez egy jó megoldás lehet (kipróbáltam, műxik):

    <?php
    $_GET_array = $_GET;
    $_GET_array['price_asc'] = 'true';
    $path_ascending_for_markup = $_SERVER['SCRIPT_NAME'].'?'.http_build_query($_GET_array, '', '&amp;');
    $_GET_array['price_asc'] = 'false';
    $path_descending_for_markup = $_SERVER['SCRIPT_NAME'].'?'.http_build_query($_GET_array, '', '&amp;');
    ?>
    <div>
    <a href="<?php echo $path_ascending_for_markup;?>">Növekvő &uarr;</a> |
    <a href="<?php echo $path_descending_for_markup;?>">Csökkenő &darr;</a>
    </div>

    (A $_GET tömböt szándékosan adtam át egy másik változónak, mert közvetlenül módosítani szerintem nem szép (ahogy a $_POST tömböt sem szoktam közvetlenül módosítani).)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Louloudaki #8791 üzenetére

    Akkor sem indokolt, hogy másodpercenként AJAX-os kéréseket intézz a szerver felé... :U

    Használd ezt a visszaszámláláshoz, ez elintézi neked, ki is írja, testreszabható:
    jQuery Countdown
    Nyilván úgy inicializálod, hogy mondjuk egy script tagbe berakod PHP-vel a kezdeti időt.
    Egy oldalon én is pont sorsoláshoz ezt használtam fel.
    Ezzel azt is meg tudod oldani, hogy a visszaszámlálás lejártakor meghívsz egy tetszőleges függvényt - pl. újrakezded a visszaszámlálást. Nagyon hasznos, visszaszámlálásokhoz "must-have".

    Egyébként mint említettem, ha nagyon parázol a kliensoldal pontossága miatt, akkor se másodpercenként korrigálj és vesd össze a kliensoldali számláló értékével.
    De ha szerveroldali idővel inicializálod a visszaszámlálót, akkor a kliensoldal nem lesz annyira pontatlan, hogy emiatt különösebben meg kellene ijedned.

    (#8792) cAby: Szívesen! :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Louloudaki #8795 üzenetére

    Szívesen.
    Ha sorsolás, és azt akarod megmutatni, pontosan hány másodperc van még a sorsolás lezárásáig, akkor nem igazán látom be, miért nem visszaszámlálóval oldod meg... :U
    "nem is akarok másodpercenként servert kérdezni időről, be is halna az egész"
    Én is erről beszéltem korábban... de épp Te magad írtad, idézlek:
    "szerveridőt lekérdem phpval, majd kiíratom a html fájlomba, és azt szeretném, hogy onnantól kezdve a másodpercek is ketyegjenek meg frissüljön az idő magától [.....] nem flash, és nem kliens oldali idő kell."
    Ezt lehetett úgy értelmezni, hogy nem akarsz kliensoldalon számolgatni. De akkor félreérthető volt: tehát a megoldás, hogy először szerveroldalról berakod a pontos időt a kliensoldalon megjelenő kódba, majd kliensoldalon számolsz tovább. Ha nem visszaszámlálót szeretnél, hanem csak egy normál órát, akkor itt van egy: [link].

    Ja, egyébként a jQuery Countdown-nal felfelé is tudsz számoltatni: [link] (bár a visszaszámláló még mindig indokoltabb).

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Louloudaki #8797 üzenetére

    Jaja, engem mezei felhasználóként rohadtul nem érdekelne, hogy a szerver szerint mennyi az idő, legfeljebb az, hogy mennyi időm van még a sorsolás lezárásáig.
    Látványosabb is, meg egyértelműbb is.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8818 üzenetére

    Na ezt a kódot inkább nem kellett volna...

    Sorban, amit csak elsőre észrevettem, így még tuti lehetnek benne hibák:
    $jelszo1 = $_POST['jelszo1'];
    eleve ez az ugyanolyan nevű változónak átadás, meg az, hogy nem is csekkolja, létezik-e egyáltalán a $_POST tömbben a 'jelszo1' kulcson valami, vagy még el sincs küldve ez az érték.
    Ezért lehet kapni egy ocsmány notice-t, ha nincs kikapcsolva.
    Meg vegyíteni ilyen durván a magyar nyelvet az angollal szintén nagyon rossz szokás.
    Plusz ez a megoldás:
    $statusz = "OK";
    vagy épp
    $statusz= "HIBA";
    :W
    Ahelyett, hogy mondjuk true, false vagy hasonló, értelmes értékekkel dolgozna.
    Na meg hibakezelésre a kivételkezelés a szép.
    Vannak szimpla szintaktikai hibák is, pl.:
    if (emptyempty($jelszo1))

    Ha hiba van, akkor egyszerűen megjeleníti az üzenetet, majd egy "Vissza" linket, ahelyett, hogy mondjuk a form tetején megjelenítené a hibát.

    Jujj... de csak most látom a legrosszabbat:
    $parancs = mysql_query("INSERT INTO regisztracio (felhasznalo,jelszo,email,regisztralt) VALUES('$felhasznalo','$jelszo','$email',NOW())");
    Nem gáz ám, hogy lazán lehet SQL Injectiont alkalmazni... :W
    Ja, de van egy valosf() függvény, az még előbb lehet, hogy megtalálja, ha nem engedélyezett karakter van benne. De akkor is, ettől a kódtól feláll a szőr a hátamon, abszolúte nem újrafelhasználható, pl. ha ugyanezt valaki kimásolja, és máshol alkalmazza, azt a függvényt meg nem küldi rá korábban, akkor ott van lazán az SQL Injection.

    Aztán a sikeres regisztráció megtörténte után számomra rejtély, hogy mi a büdös francnak rak ki egy "regisztráció" linket, és csak azt.

    Később:
    $belepoid = $_GET['belepoid'];
    Ez már megint ellenőrzés nélkül, plusz nehogy már hozzá legyen csapva az URL-hez a 'belepoid'...

    Vegyük a kilepes.php-t:
    $parancs = "UPDATE regisztracio SET belepoid='' where felhasznalo='$felhasznalo'";
    mysql_query($parancs);
    //OLDAL TARTALMA
    echo"Sikeresen kiléptél.";

    Ez most komoly? :Y
    Úgy léptet ki, hogy a belepoid mező tartalmát üres stringre állítja? :W

    Ez a kód botrányosan szar.
    Ha javasolhatom, ezt többet ne ajánlgasd senkinek referenciaként.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CSorBA #8821 üzenetére

    A "kirohanásom" oka az volt, hogy nem szeretem, amikor valaki felrak egy hibákkal és sebezhetőségekkel telerakott hosszú példát, amiből aztán kezdők nagyon rossz mintát vehetnek, mert gyorsan megörülnek, hogy "jujj de jó, itt egy kész példa, akkor nekem már nem is kell megtanulnom programozni".

    ===

    (#8822) Speeedfire : hát ha valaki ebből szűri ki a lényeget, akkor az rövid és hosszú távon is nagyon rosszul jár.
    Ezért érdemes megnézni, mit linkel az ember, nehogy rossz példát mutasson. :)
    Amikor nagyon kezdő voltam, és ilyen linkeket találtam, én is mindig megörültem, hogy de jó, valaki most megmutatja nekem, hogy kell. Aztán később kapartam az arcom, amikor kezdtem belejönni.

    Amúgy a kód még csak említést sem tesz a sessionök használatáról.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Scobbyka #8835 üzenetére

    Azért előbb kifejthetnéd, hogy ha csak ez van a fájlodban, és nem használod még template-ezésre sem, mi a büdös francnak echo-zni stringként a táblázatot, amikor sima HTML-ként is kiírhatnád, és nem rontanád a teljesítményt feleslegesen. :)
    Plusz nem ártana valid kódot használni.

    Többiről bővebben: [link].

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8841 üzenetére

    Szerintem annyira nem hülyeség maga az alapötlet, hogy más aldomainen van, ha más témakörről van szó, így legalább jobban elkülöníthető, ráadásul a cím is könnyebben megjegyezhető, aztán lehet, hogy SEO-val kapcsolatos előnyei is vannak.

    Egyébként mindezt nem Yii-vel akarod megoldani? Csak mert szerintem tuti van rá valami beépített megoldás, hogy subdomainek vagy teljesen más domainek szerint elkülönítve jelenjen meg más tartalom, legalábbis ha Drupalban van erre mód (azonos motor kapcsolódik más-más domainekhez, és az más-más tartalmat jelenít meg - sőt, akár más-más modulok is tartozhatnak ezekhez), akkor feltételezem, hogy egy olyan népszerű frameworkben is megoldották, mint a Yii. Saját megoldás készítgetése előtt azért nézz körül alaposan a Yii doksijában. :K

    ===

    (#8842) Coyot : jogos a reakció. :K

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8844 üzenetére

    "Seo ebben a kategóriában nem nagyon szokott lenni, inkább direkt marketing."
    Ezt a megjegyzésedet most nem igazán értettem. :) Az nem direkt marketing a szó szoros értelmében, ha javítanak a keresőoptimalizálási technikákkal a találati listán való megjelenésben. Mivel ebben még nincs semmi közvetlen kapcsolatfelvétel az értékesítés ösztönzésére...
    Arra céloztam, hogy ha a teljesen különálló témák különböző domaineken vannak, az még javíthat is a Google-féle értékelésen, mert nem keverik a szezont a fazonnal azonos domain alatt.

    A Yii-t nem ismerem, de gondolom valami hasonló gondolatmenetet kéne követni, mint ahogy itt a többnyelvűsítésre különböző aldomaineket hoznak létre: [link].

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8846 üzenetére

    Na, akkor jó.
    Amúgy érdekes téma, mit sorolnak direkt marketingbe, én alapvetően a keresőoptimalizálást nem sorolnám ide, mert marketing tanulmányok alapján (jó, ez lóf@sz, amit én tanultam belőle) ez számomra valahogy már kiesik ebből a fogalomból - itt mégis részben ezt is említik, mint szempontot: [Wikipedia - Direct_marketing]
    "Online Tools
    [...]
    Search: 49% of US spending on Internet ads goes to search, in which advertisers pay for prominent placement among listings in search engines whenever a potential customer enters a relevant search term, allowing ads to be delivered to customers based upon their already-indicated search criteria.[12] This paid placement industry generates more than $10 billion dollars for search companies. Marketers also use search engine optimization to drive traffic to their sites.
    "

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Tele von Zsinór #8850 üzenetére

    Jaja, ez így van.
    Csak a motornak kell lekezelnie megfelelően a különböző (sub)domaineket.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz rii #8852 üzenetére

    Egyszerű blogolásra elvileg WordPress a legkönnyebb megoldás.
    Nem ajánlom, hogy mindenféle összeollózott free PHP-kódokkal szutykolj, mert nagyon sok a hibás, és az olyan, ami tele van biztonsági résekkel. Ráadásul egy népszerű, komplett CMS-hez sok tutorialt és modult is találsz, egy összeollózott kódhoz meg általában nem a legjobb a dokumentáció sem...

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz sekli #8854 üzenetére

    Nem próbáltam még, de számomra ez alapján nem annyira szimpatikus:

    "Simple - simple to install and easy to modify. The entire site is stored in a single HTML-file - no database is needed. You edit your entire site with your favorite HTML-editor, upload the content file and get a dynamic website!"
    Nem igazán értem, hogy amennyiben mindenféle adatbázis nélkül működik, szimplán HTML-editorral kell szerkeszteni, majd feltölteni a tartalmat, akkor ez mitől lesz a klasszikus értelemben vett CMS. Ahogy azt sem, hogy ez mitől nevezhető "dinamikusnak"...
    A klasszikus CMS-ekben azért mód van a tartalmak különböző szempontok szerinti kigyűjtésére, rendszerezésére, szerepkörök állítgatására, és így tovább, lásd: [Tartalomkezelő rendszerek].
    Ez ennyi alapján ezekből elég kevés szempontnak felel meg. Kicsit komolytalannak tűnik.
    De leírhatnád, szerinted miért is jó ennek a használata azonkívül, hogy gondolom ad valamiféle keretet a szerkesztendő oldalaknak - nem próbáltam még, így érdekelne, de nekem már az elég gyanús, hogy nincs szükség adatbázisra.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8866 üzenetére

    Azért legközelebb azt is mutasd meg, mit raktál a konfigfájlba, mert néma gyereknek az anyja se látja a fától az erdőt. :DD

    ===

    (#8859) mobal : mi az a hosts.etc? Én olyanról még soha nem hallottam. ;]

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz sekli #8856 üzenetére

    Igen, ez lehetséges, viszont általában itt nem szokott megállni egy tudomány. Egy egyszerűnek kikiáltott oldal többnyire azzal indul, hogy "csak annyi kéne, hogy ...... és semmi más", aztán majd úgyis felmerül az igény valami jobbra, szebbre, könnyebben kezelhetőre, stb... akkor meg már egy túlságosan leegyszerűsített dolog nem lesz egyszerű, amihez ráadásul nem készül annyi modul, smink (theme, template), stb.
    Ezért is gondolom úgy, hogy hosszú távon is jobban járna egy népszerű és folyamatosan bővített, moduláris CMS-sel, főleg, ha még nem igazán lát bele a dolgok mélyébe.

    Azért ajánlottam a WordPress-t, mert többnyire ezt szokták klasszikus blogolós feladatokra ajánlani, meg többektől hallottam már, hogy a felülete tényleg kezdők számára is intuitív - a Drupal eléggé tanulós. Joomlát meg elvből nem ajánlanék senkinek, a topicban már több ízben kifejtettem, miért nem. :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8871 üzenetére

    Csodás. :D
    Csak arra céloztam, hogy ha még nem műxik, akkor mutasd meg, addig mivel próbálkoztál, gondolom ez már a működő változat. :)
    Egyébként már épp gondoltam, hogy írok cikket VirtualHostokról, de közben találtam egy egész jót:
    XAMPP telepítése, helyi mail szerver beállítása és domének kialakítása.

    ===

    (#8869) mobal :
    "/etc/hosts akart lenni, persze most megint nem tudom, hogy ez linux esetén van e."
    Őőőő, miért, talán Windows esetén lenne? :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8874 üzenetére

    Korábban definiálj egy default szervert, ServerName localhost és a többi értékkel, az mindenképp kerüljön bele, aztán jöhetnek a VirtualHostok. Aztán persze ez is lehet külön VirtualHost. Mondjuk nem lenne szar látni a teljes konfigfájlt, mit alkottál eddig, így úgyis csak nyújtani tudjuk a témát, mint a rétestésztát. :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8880 üzenetére

    Egyébként itt az if és "?:" operátor keveréke a kódodban eleve rossz, szóval rosszul használod a kiértékelést, most akkor el kell döntened, hogy mit használsz:

    if-fel:

    if(isset($_GET['kategoria'])){
    $button='Next';
    }
    else{
    $button='Register';
    }

    vagy inkább (!!):

    $button='Register';
    if(isset($_GET['kategoria'])){
    $button='Next';
    }

    "?:" ("ternary") operátorral:

    $button = ( isset($_GET['kategoria']) ? 'Next' : 'Register' );

    U.i.: hozzáteszem, azért nem épp a "kategoria" $_GET-érték meglététől tenném függővé egy regisztrációs űrlap gombjának feliratát (a regisztrációs folyamat köv. lépése vagy épp maga a regisztráció elkezdése). Persze ez egyéni döntés kérdése.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8882 üzenetére

    Mondjuk szerintem praktikusabb lenne teljesen szétválasztani a dolgot.
    Akkor megvizsgálod, hogy mik a feltételek, ha mindenképp meg kell jeleníteni egyik vagy másik formot, akkor bizonyos feltételek fennállása esetén x formot jeleníted meg, más feltételek esetén pedig y formot. De ne kelljen minden egyes elem létezéséhez vizsgálgatni, majd azok értékét a vizsgálatok eredménye szerint beállítgatni, hanem legyen egy kész formod mindkettőre (mivel ezek szerint úgyis teljesen eltér a kettő "témája").
    Persze nem akarok okoskodni, csak tanács, kevesebb szívás van vele, és jobban elkülöníthető.

    Szerk.:
    "Amúgy ezzel is megy. :U"
    Azért megy, mert már kiszedted az "if" szócskát, ami az előbb teljesen értelmetlenné tette az egészet. :U
    Egyébként meg így sincs túl sok értelme szerintem, mert akkor tök felesleges a "?:"-operátor, nem ilyen használatra való.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8884 üzenetére

    Nem sebességről beszéltem. :N Logikus és átlátható struktúráról. Legalábbis amennyire értettem, egyik form regisztrációra szolgálna, a másik meg valami teljesen más feladatra. De ahogy érzed, ez csak tanács volt, nem kötekedés!

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Speeedfire #8886 üzenetére

    Ja, hát azt még eddig nem mondtad, hogy pontosan ugyanarra készül a form, csak egyik esetben ki lesz egészítve egyebekkel is. :D
    Na mindegy, azért jól elvoltunk. :DD

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8888 üzenetére

    Erre próbáltam azóta forrást találni, de nem sikerült - tudsz ilyet, ahol ezt igazolják?
    Nem világos számomra, miért másolódna le.
    Elvileg ez csak egy másfajta módszer feltételvizsgálatra.

    Példa:
    $is_true = false;
    $test_array = array('blabla'=>'asdasd', 'qweqweqw'=>123, 45, 123, 232);

    $test_array['blabla'] = ($is_true) ? 'yxcyxc' : 'qwertz';

    Itt nem világos, hogy az $is_true feltételvizsgálathoz minek másolódna le az egész $test_array tömb.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8892 üzenetére

    Köszi szépen, ezt jó tudni! :R
    Nekem új a copy-on-write, mert ezek szerint ha egy buzinagy tömböt átadok pl. egy függvénynek, akkor amennyiben az nem vár referenciát, nem is másolódik le az egész tömb, amennyiben a paraméterként kapott tömböt nem módosítom - pedig erre eddig más nyelvekben tanultak miatt gondosan odafigyeltem. Ergo nem is muszáj referenciát odatenni (csak ha az eredeti tömböt amúgy is módosítani szeretnénk).
    Ez hasznos infó volt!

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8910 üzenetére

    Nem igazán értem, miért kellene feltétlenül limitálni. Sehol nem írta, hogy az example.com/archive/2011/01/27 oldal megnyitására csak egyetlen darab postnak kellene megjelenni - na meg miért is feltételezzük, hogy aznap csak egyetlen cikk íródott...

    "Nem tudom, hogy a count() mit csinál a háttérben"
    Nem Kohanáztam soha, de nem nehéz kitalálni, hogy a count a query által visszaadott vagy érintett sorok számát jelenti... :U :D
    És ja, kb. 5 másodperces Guglizás alapján ki is derül: [link].

    A lényeg: mivel egy napon nem feltétlenül csak egy cikk készülhetett, ezért nem hiszem, hogy korlátozni kellene a lekérdezés eredményét (legalábbis eddig erről nem volt szó), így a count teljesen jó annak eldöntésére, hogy van-e egyáltalán eredménye a lekérdezésnek...

    ===

    (#8909) cAby : finoman szólva ocsmány a kód (Te kérdezted meg a publikumot :) ), és azt sem értem, mitől működik nálad úgy, ahogy akarod (sanszos, hogy nem is úgy működik, ahogy kellene), amikor teljesen indefinit, hogy a form elküldésével melyik valamit akarod a kedvencek közé tenni.
    Az index.php-dben meg vidáman használod a $row['id']] változót, ami számomra teljesen ismeretlen, hogy honnan kéne, hogy valami valós értéket kapjon. (A fav.php-dben van egy $row az adatbázis-lekérés eredményét megjelenítő cikluson belül, de annak ehhez köze nincs.)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8912 üzenetére

    "Index.php-ben is nyilván van ilyen ciklus"
    Szerintem ez a kódod alapján nem annyira nyilvánvaló.

    "Így működik ahogy akarom, felveszi a listába és onnan el lehet küldeni e-mail-ben."
    Honnan fogod tudni, MELYIKET kell felvenni a listába?
    Hadd "idézzek" a kódodból:

    if ( $_SESSION['fav_' . $row['id']] == 'false' )
    {
    echo "<form action='index.php' method='post'>
    <input type='submit' name='add' value='add' />
    </form>";
    }
    elseif ( $_SESSION['fav_' . $row['id']] == 'true' )
    {
    echo "<form action='index.php' method='post'>
    <input type='submit' name='del' value='del' />
    </form>";
    }

    Itt kiraksz egy formot, de magában a formban egy darab azonosítót nem rejtesz el (mondjuk egy hidden inputtal, vagy másképp), így nem tudom, honnan szeded, hogy mondjuk épp az 5-ös azonosítójút szeretném eltárolni a kedvencek közé.
    Egyébként itt az if-elseif vizsgálat nem túl ésszerű - inkább azt kéne vizsgálnod, hogy mondjuk true értéke van-e, ha igen, kirakod a törlőformot, KÜLÖNBEN (simán else) a hozzáadó formot.

    Amúgy ha mutatsz egy hasonló kódot, akkor nem ártana a teljeset, hogy el tudjuk dönteni, valamilyen kód indokolt-e egyáltalán.
    Az például nem túl szép megoldás, hogy az ismeretlen eredetű $sum_items mennyiségig végigmész az elemeken, és egyesével, cikluslépésenként kéred le adatbázisból a különböző azonosítójú elemeket.

    További tipp: ha azt szeretnéd, hogy egy form ugyanoda legyen elküldve, ahol ki is van írva, akkor érdemes az action attribútumot inkább üresen hagyni a formnál (action=""), ez egy valid megoldás, és könnyebben "költöztethető" - tehát ha az index.php helyett megváltoztatod a fájl nevét asdasdasd.php-re, akkor is működni fog.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8918 üzenetére

    Basszus, adj már egy értelmezhető nevet is a kedvenceidnek... Pl. az adattábládban a különböző azonosítók mellé vegyél fel még egy mezőt, aminek az a neve, hogy mondjuk "fav_name", vagy hasonló, és aztán lekéréskor pedig írasd ki, hogy melyik azonosítót is adtad hozzá a kedvencekhez. Akkor meglátod, hogy valóban jól működik-e.
    Nézd is meg, mit csinálsz, ne csak azt csekkold, hogy egy azonosító a sok közül kedvencek közé lett mentve.
    Pl. ha a hozzáadható kedvencek a következők: alma, béka, cékla, dió, eke, és én épp a békát szeretném kedvencek közé menteni, akkor nem szeretném, ha helyette ekét kapnék az arcomba. :D

    Az index.php-det egyébként így kezded:
    <?php
    session_start();
    ?>

    <?php
    $sql = ......

    ahelyett, hogy a tökéletesen felesleges záró- és nyitótaget kiszednéd:
    <?php
    session_start();
    $sql = ......

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8921 üzenetére

    "Keress egy nagy adatbázist, és számoltasd meg valamilyen feltétel után, hány darab rekord van benne. Utáne tedd meg ugyanezt EXISTS-cel. Na, látod?! "
    Ez nem tudom, hogy jön ide. :F
    Ha van egy archívum, amiből csak az adott napra eső bejegyzéseket szeretnéd megjeleníttetni, ráküldesz egy SELECT-et. Akkor már megvan, hány bejegyzést is sikerült lekérni, ezt megtudni pedig nem egy erőforrásigényes feladat a lekérés után.

    "Nyilván, ha kell neki minden post, és nem csak az, hogy van-e benne, akkor okés, csak nem nyálaztam vissza, mi volt a lényeg, csak odáig láttam, hogy true / false jön ki belőle."
    Akkor indokolatlan a kötekedés. :)

    "Egyébként, ha én ORM-et fejlesztek, akkor akár azt ics megcsinálhatom, hogy módosítom on-the-fly a query-t, hogy az adatbázis számolja össze az összes sort, ne pedig a memóriában történjen meg ugyanez."
    Ezt kifejthetnéd bővebben is.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8925 üzenetére

    Minél lehet gyorsabb? :F
    Annál kétlem, hogy gyorsabb, mintha ráküldesz egy COUNT(*)-ot az eredeti táblára, az eredeti WHERE feltételekkel, mint az, ha subquery-be teszed az eredeti query-t, max. egyszerűbb megírni.
    De ez a számolgatásra történő optimalizálás továbbra sem értem, hogy jön ide.
    Ha ráküldesz egy SELECT-et a bejegyzésekre, és lószart sem ad vissza, akkor abból elég egyértelmű, hogy nincs egy darab bejegyzés sem. A megadott dátumok meg eleve korlátozást jelentenek a bejegyzésekre, így nem mindent kérünk le egyszerre, és csak utána szűrünk. A szűrt feltételeknek megfelelő bejegyzéseket lekérjük, és ezután már tudni fogjuk, hogy van-e eredménye a lekérdezésnek.
    Azt is lehetne csinálni, hogy először szépen lekérdezed, hogy van-e egyáltalán a feltételeknek megfelelő bejegyzés, majd ha van, akkor egy újabb query-vel ismét lekéred a feltételeknek megfelelő bejegyzéseket, de ekkor már pl. ki is íratod őket, de szerintem teljesen felesleges kétszeri query-t ráküldeni, ha a feladat úgyis csak az, hogy jelenítsük meg az adott dátumhoz tartozó postokat. Ha nincs ilyen, akkor azt jelezzük.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz cAby #8924 üzenetére

    Na, akkor most kezdd elölről, egy másik sessionnel. Küldj rá egy session_destroy-t, majd kezdd elölről a folyamatot.
    Nagyon nagy csoda lenne valóban, ha a PHP csak úgy magától kitalálná, hogy te melyik azonosítójú elemet is szeretted volna kedvencek közé menteni, mivel szerveroldalon a form elküldése után csak annyi látszik, hogy létezik mondjuk a $_POST['add'], vagy épp a $_POST['del'], tehát megnyomtad a hozzáadó gombot, vagy megnyomtad a törlő gombot, de annak SEMMI nyoma nincs, hogy te most melyik azonosítóhoz tartozó hozzáadó-törlő gombot nyomtad meg. Mégis honnan a büdös francból kellene látnia a szerveroldalnak, hogy mi a szándékod?

    A CIKLUSON BELÜL van egy ilyen részed:

    if ( $_POST['add'] )
    {
    $_SESSION['fav' . $row['id']] = 'true';
    }

    if ( $_POST['del'] )
    {
    $_SESSION['fav' . $row['id']] = 'false';
    }

    Ergo az $sql = "SELECT * FROM items WHERE sitelink = '" . $site_link . "'"; query-d összes eredményén végigrohangászol, majd ha épp létezik szerveroldalon a $_POST['add'] vagy a $_POST['del'], akkor az aktuális cikluslépés sorazonosítójához tartozó sessionváltozóba eltárolod a "true" értéket.
    Így ha egyszer megnyomtad azt a szaros gombot, akkor elméletben mindegyik adatbázisban megtalált azonosítóhoz tartozó session-változónál true lesz az érték.

    De lassan kifogyunk a magyarázat-kombinációkból.

    Szerk.:
    ... és ahogy látom, modder nagyjából ugyanazt írta le közel egyidőben, mint én, más szavakkal.

    Egyébként könnyebb lenne látnod az egész eredményét, ha mondjuk adott felhasználóhoz nemcsak sessionbe mentenéd a kedvenceit, hanem úgy, ahogy van is értelme, adatbázisba. Mert így csak a munkamenet erejéig fognak élni a kedvencek.

    [ Szerkesztve ]

    Sk8erPeter

Új hozzászólás Aktív témák