[LinkyB]

Sooviks kiirelt abi kuidas teha lihtsalt lehtede jaotus, nii > esimesed 10 on lk 1 , teised 10 on lk 2, kolmandad 10 on lk 3 jne. Lugesin küll PHP centerist jaotust MySQL'iga aga minu aju seda ära ei võtnud, väga väike
väheste teadmistega progreja, aga koodiga ise olen hetkel jõudnud nii kaugele:

[troglodyte]

http://dev.mysql.com/doc/refman/5.1/en/select.html, loe LIMIT kohta

[andrusny]

Sa küsid valesti, juba MySQL päringu saad selliselt teha, et vastus on teatud reast teatud reani.
limit on võtmeks. See, kuidas neid ridasid ja tabeli mahtu arvutad on juba teine teema.

[LinkyB]

Olen saanud hakkama sms aktiveerimisega, mysql insertiga, lugemisega jms. kuid soovin veel teada kuidas teha inserted.php kuva peale mysql inserti info 'nimi', 'vanus','elukoht' jne kas siis viimase id järgi või viimati listud järgi või hoopiski kõige loogilisem variant, see mis just sisestati formi ja postitati mysql tabelisee

[andrusny]

Kui seda on kohe peale postitust vaja, siis kasuta postituse andmeid. Baasist ära loe midagi. Kõige kiirem.

Kui tahad ikkagi andmebaasi viimast, sordi kõik tagurpidi id suhtes ja kuva esimene päring.

[mikk36]

[Renka]

[andrusny]

Sellega ta saab teada viimase id ainult peale insert tegemist, aga mis siis, kui ta ei soovi midagi sisestada ja tahab viimast teada?

[Renka]

andrusny, sellisel juhul on sinu näide ikkagi vägagi vale. Miks ta peaks näiteks 10MB või ekstreemsusse langedes 1GB tabeli iga kord SQL serverist PHPsse tõmbama?

Selle jaoks on LIMIT. Aga üldiselt eeldada ei ole mõtet - küsimus oli peale sisestust sisestatud andmete teadasaamine. Sellejaoks ongi viimase sisestuse ID + päring baasi.

[mikk36]

Optimeeringu suhtes küsimus et milleks oleks üldse vaja andmebaasist uuesti samu andmeid vaja välja tõmmata, mis sinna just sisse saadeti ?

[Renka]

mikk36, viisakas on peale formi submitti redirect teha järgmisele lehele, et mõni mees refreshi vajutades andmeid uuesti ei submitiks.

[mikk36]

Ja mis kasu on siis sellel scriptil endale andmed sisse tõmmata kui script niikuinii käsib hoopis redirecti teha ja see konkreetne script (see käivitus) neid andmeid brauserile ei jaga ?

[Renka]

mikk36, misasja sa sokid?

insert -> get ID -> redirect koos IDga -> select

[mikk36]

[Renka]

mikk36, viisakas on ikka järgmisel lehel seda kasutada. Samas oleneb kuidas keegi kasutab. Võib ka samal lehel ju - kuigi mina seda heaks ei kiidaks.

See, et samal lehel ei ole mõtet päringut baasi teha ei ole aga ka õige lähenemine. Loogika peaks ikka olema see, et kuvad kasutajale seda infot mis reaalselt baasi jõudis. Sellisel juhul võtad andmed baasist - mis siis, et need on sul POST'is või kus iganes olemas. Sellega jääb lehe ülesehituse loogika selgem ja saab ka kohest tagasisidet, et kas andmed ikka reaalselt salvestusid baasi ja mis kujul. Debugidagi lihtsam. Rääkimata olukordadest kus baasi sisestamisel toimub baasis endas veel andmete töötlus - Oracles laialt kasutav praktika. MySQLis küll vähem aga kohtab ka vahest. Kasvõi mõne timestambi lisamine näiteks.

[mikk36]

Hästi põhjendatud

[LinkyB]

[Renka]

http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html

[jnt]

[Renka]

jnt, ei ole hea ju.

Jällegi tuleb lehe ülesehituse loogika mängu. Formi submittimisega tegeleb üks osa koodist ja kuvamisega teine. Ei ole ilus neid segada.

[jnt]

Renka, koodi võib osadesse jagada ka teistmoodi, kui erinevate failidena juppe hoida.

[LinkyB]

Mis minu variandil viga on täiesti lihtne ja kõlblik ..

[Renka]

[jnt]

Renka, kes seda käskis sul segada? tokenite süsteem ei välista korralikku struktuuri veebilehe ülesehituses.

Minu arust on nt ka pidev refresh'imine jms teema erinevate lehe osade kasutamiseks ka väga vale lahendusviis. Lehe ülesehitus peaks minu arust olema selline, et kood on ees, ja lõpus lüüakse siis koodi tulemustele template ümber ja korras. Mingist "segamisest" on asi väga kaugel sel juhul. Ja tokenitega pole ka mingit probleemi.

[Renka]

jnt, eks oleneb projekti suurusest ja maitsest. Aga sellise lahendusega suuremat projekti ei ole küll võimalik normaalselt hallata.

[jnt]

Renka, oled sa ikka kindel? Sellise lahendusega projekte on tehtud küll ja küll ja pole mingeid probleeme esinenud. Hallatavus, kui selline, on ka kiire, lihtne ja konkreetne... Palju konkreetsem, kui mingid taustal refresh'imised igal juhul.

[LinkyB]

http://linkz.pri.ee/id1.php?lk=3

Kõiksugune tabelist võetud tekst jookseb lihtsalt nii välja, kuidas seda parandada, ei saa lihtsalt hakkama..

[jnt]

LinkyB, http://ee2.php.net/manual/en/function.wordwrap.php

mis teil inimestel lahti küll on? elementaarne manuali oskus võiks siiski olemas ju olla...

[inzinz]

[jnt]

inzinz, mis hea pärast sa kahelt aknalt sama vormi kaudu korraga midagi sisestad? No kammoon, alati on võimalik leida mingit jura, kuidas üks või teine asi ei tööta. Aga miks ta peaks töötama niimoodi? paras debiilsus sama vormi avada mitmes aknas ja neid mõlemaid kasutada.
Suva-refreshid taustal on veel rohkem mööda loogika, kui tokenid. Tokenid vähemalt tõstavad ka mõningal määral turvalisust.

Ja mulle pole vaja seletada, mis moodi küpsised/sessioonid toimivad ja mida tokenite süsteem endaga kaasa toob.

Vot sulle minu paar senti!

(Deem, leiaks ma nüüd ühe video, mis sulle puust ja punaseks teeb, miks tokenid head on, oleks tore... aga sellega läeb tsipa aega.)

[Renka]

jnt, niikaua kui ehitad väikeseid veebilehti ja/või mõne üksiku kasutajaga süsteeme ei ole su lahenduses võibolla tõesti midagi halba. Suudad asja hallata ja kuna kasutajate mass on nii väike siis ei teki ka probleeme (või pigem ei raporteerita nendest).

Kui süsteem on aga suurem ja pead töötama veel mitme inimesega tiimis siis sinu loogika ei tööta enam.

[jnt]

Renka, mitu inimest kasutab sama arvuti tagant sama brauserit? No tule taevas appi...

[inzinz]

jnt, palun väga, kirjuta siis omale formide alla suures ja punases kirjas kasutajatele "kui kahes aknas selle formi lahti võtad siis oled debiil"
Sa ei saa kasutajal keelata mingit postitamise formi kahes aknas lahti võtta. Googledades php form token oli kohe kaks esimest pealtnäha asjalikku tulemust (http://www.phpro.org/tutorials/Preventing-Multiple-Submits.html http://phpsec.org/projects/guide/2.html) sellises stiilis:
sisendi kontroll:
kasutaja submitib formi
kontrollime kas postitatud token on sama mis sessioonis
väljastamine:
genereerime unikaalse tokeni
paneme tokeni sessiooni muutujasse
kuvame tokeni formis

Nii, ja kui nüüd kasutaja võtab ühes aknas lahti mingi formi vaate, siis otsustab veel korra lahti võtta, siis avastab et krt juba oli lahti, paneb uue kinni ja üritab vana formiga submittida, siis selline loogika annabki talle piki hambaid.
Tokenite idee on hea, aga selline sessiooni salvestamine on lollus, katsu sa kasutajale seletada et tema oma süü et ta sinu lehel mingit formi vales järjekorras vaatas, kasutaja jaoks on sinu leht see mis on vigane mitte tema käitumine.
See ei ole koht, kus kommenteerida "alati on võimalik leida mingi jura kuidas asi ei tööta", vaid vaid koht, kus sa peaksid otsima paremat lahendust kus oleks olemas tokeni süsteem CSRF vältimiseks, kuid samas sa ei piira seda et kasutajad võivad, üllatus-üllatus, sinu lehte kahest aknast vaadata.

EDIT: Kui veel aru ei saanud, siis mitte samal ajal vaadata, vaid teha eelkirjeldatud viisil, et võtab kogemata lahti sama koha. Või kui sul on tokenite süsteem kõikidel formidel läbi ühise sessiooni muutuja siis võtab lahti teises aknas suvalise koha kus ka formi kuvatakse ja ongi perses

[jnt]

inzinz, siin on pakutud välja kahte varianti: token'id ja refresh'imine. Kas sa pooldad lehti, mis ise refresh'ivad ennast? Selline praktika on samamoodi ebasoovitatav, nagu ei ehitata täna ka lehti iframe'idega.

Ja kui tahad väga keeruliseks minna, võid ju samale formile tokeneid genereerides teha nii, et ühe formi kohta saab olla mitu tokenit. Kontrollitakse, kas vähemalt ühega ühtib, mis genereeritud on ja kui ühtib, submititakse asi ära + kustutatakse tokenite "arhiiv". Ongi probleem lahendatud... Pane need tokenid sessiooni kujul kasvõi "token|token|token|".

[inzinz]

Kui sessioonis kõik tokenid alles hoida siis jah kaob see jama ära, et teist tabi/akent lahti võttes kirjutatakse token üle ja siis eelmises tabis on asi metsas. Siis peab jälgima seda et neid tokeneid paljuks ei lähe ja sessiooni pirakaks ei aja.

Aga refreshimise all sa mõtled mida täpsemalt ? Ma kaldun arvama, et refreshimise all sa pead silmas neid lehti mis näitavad peale postitamist mingit vahelehte (näiteks phpbb foorum) mis siis suunab edasi uuele lehele (näiteks topicu vaatesse uue postituse juurde).
Mida mina ja pakun et ka teised silmas peavad on selline kood php's:

[Renka]

[jnt]

inzinz, ei, ma mõtsin ikka seda header()'i refresh'i, ehk sain aru, millest eelpool räägiti, kuid siiski on minu arust tegemist väheke jama lahendusega. Kui tekib viga, millest tahad teatada + tahad formi ka alla lüüa sisestatud andmetega, millest midagi oli vale, siis selle asja lahendamine pole kuigi lihtne refresh'imisel. Samas, kui sellist refresh'i koodi mitte vahele toppida, on võimalik luua ilus kena errorite/teadete kuvamise süsteem, mis formiga samal lehel kenasti kõik vead/teated ära kuvab, kui neid on.

Renka, aga miks sa tahad kiirvastusele tokeneid toppida?

[Renka]

jnt, kiirvastus ju tavaline form nagu iga teinegi. Või kuidas sa selle lahendaksid?

Kusjuures seesama phpBB foorum suunab su headeri abil peale formi submittimist uuele lehele ilusasti. Huvitav küll miks?

[jnt]

Renka, siin foorumis, kui vastust kirjutad, oled sa sisse logitud ja sind on võimalik mingilgi moel vasututsele võtta. Teema algas aga mingist kuulutuste süsteemist, kus vist igaüks sai kuulutuse lisada. Seal on igasugune turvanipp teretulnud, kuna kes iganes saab form'ile ligi ja saab kuulutusi ka lisada.

[Renka]

jnt, mis jama sa nüüd ajad? Loe nüüd uuesti millest vaidlus algas.

[inzinz]

[jnt]

inzinz, kuid mis juhtub siis, kui sa tahad õnnestumisel ka teadet kasutajale kuvada? Kui sul formiga leht tegeleb ka andmebaasi sisestamisega, mitte ei ole selleks mingi teine adre, mis pärast suunab nt formi juurde tagasi, siis on lihtne kontrollida andmeid ja kuvada vajalikud teated või vead. Kui sa aga peale sisestamist tahad kuskile ära suunata, siis see, kuhu sa suunad, sinna saata kaasa ka teade on märksa keerulisem. Pmst isoleerid ju kontrolli ja hiljem kuvatava osa ära. Okei, võib alati nii teha, et sul on mingi n+1 teadet, igal teatel on oma id, mis nt kahe astmed järjest ja siis liidad kokku, suunad edasi, andes selle liidetud tulemuse ja siis järgmisel lehel jagad uuesti osadeks, otsid igale id'le tema teate ja on ka tehtud, kuid miks nii kilplaslikult asjale läheneda?

Aga ei, ma saan su poindile kenasti pihta ja see vaidlus, mis meil on, aitab meil mõlemal ehk üht või teistpidi targemaks saada ja uusi ideid luua. Ja kõrvalvaatajal on eriti mugav selle vaidluse pealt õppida, mida saab teha ja mida tasub teha... ja millal.

[Renka]

jnt, mingisuguste teadete kuvamine on ju kõige lihtsam asi.

Kirjutad oma teate sessiooni ja järgmisel lehel kuvad selle välja ning kustutad sessioonist.

Mingi URLiga teate kaasaandmine aga ei sobi minusilmis kuidagi. URLis olev info peaks olema siiski ainult see mis on antud lehe kuvamiseks hädavajalik. Kui kasutaja URLI kopeerib siis ta näeb teadet ju igal korral uuesti - näiteks kui ta peaks selel teatega URLi bookmarkima.

Aga ürita asjast suuremat pilti näha. Sul on olemas lisamise vaade ja kuvamise vaade. Mõlemal vaatel on ka oma unikaalne URL. Juhul kui nüüd andmed on ilusasti lisatud läbi lisamise vaate. Siis loogiline on ju, et kasutaja näeb sisestatud andmeid läbi kuvamise vaate. Sellisel juuhl on sul kõik kuvamisega seotud kood/HTML ainult ühes kohas. Ei ole vaja meeles pidada, et kuskohast nüüd mul kuvamise HTMLi juurde inkluuditakse ja mis tingimustel. Hallatavus on parem ja ei pea lisatingimusi meelde jätma. Lisaks kaasneb sellega kasutajale parem kasutusmugavus kuna peale mingi asja siestamist saab ta aadressiribalt kopeerida omale kohe õige URLi mida siis vajadusel kellelegi mailida või omale bookmarkida jne jne.

[jnt]

Renka, sinu näitel ehk selline variant parem. Samas, kui tegemist on rohkem admin lehe laadse asjaga, kus sa tahad, et peale lisamist tuleb sul see sama form ette, kas siis just lisatud andmetega või uue vormina, siis mis suunamist sa siin ikka hakkad tegema...
Ühesõnaga, siin tuleb tõesti välja see, et tuleb progeda, kuidas vaja on.

[Renka]

jnt, kui vaja sama vormi siis suunad muutmisvaatesse nii nagu sa esimest kordagi sinna lehele satuksid. Sellest kirjutasin juba teema alguses.

[jnt]

Renka, kusjuures ma siin hetkel hakkasin mõtlema, et see teadete salvestamine sessiooni vmt on täitsa huvitav idee...