ugrás a tartalomhoz

site vezérléselmélet

PHPprogramozo · 2009. Nov. 4. (Sze), 11.33
Sziasztok!

Egy olyan kérdésem lenne, hogy Ti hogy oldjátok meg bizonyos oldalak vezérlését?!

Adott mondjuk egy admin felület, ahol a userek kezelését kell összerakni. Namost.. A userek kezeléséhez 3 különböző oldalra van szükség minima.

1. userek listázása
2. userek módosítása
3. új userek felvétele

Ennek elvileg 3 url címe van

pl: index.php?page=user&do=list, index.php?page=user&do=mod, index.php?page=user&do=new

Ez eddig szép és jó. Simán eldöntöm az url címekben kapott paraméterek alapján, hogy melyik osztályokat és view fileokat includálom be az adott feladathoz. És itt jön a kérdés.

Ha felveszek egy új usert, akkor az index.php?page=user&do=new oldalon vagyok éppen. A rendszer lekezeli a felvételt és örömmel közli hogy a usert létrehozta. Na de, most is még mindig az új user felvételének url címén vagyok azaz a index.php?page=user&do=new címen. Azt szeretném megoldani redirect nélkül, hogy ebben az esetben ugorjon újra a listázásra és ott jelenítse meg a sikerüzenetet.

Redirect nélkül van erre lehetőség? Ti hogy oldjátok meg az ilyen jellegű oldalak vezérlését?

köszi a válaszokat előre is
 
1

Redirecttel

fchris82 · 2009. Nov. 4. (Sze), 11.50
header() fv-nyel átirányítom a lista oldalra. Egyébként olvass utána a CRUD-nak. A felhasználónál eleve 4 oldal kell (nálam esetek 100%-nál):
- létrehozás
- módosítás (pont felhasználó esetén általában változni szokott a két form)
- listázás
- törlés

Mi a bajod a redirecttel?
2

redirect

PHPprogramozo · 2009. Nov. 4. (Sze), 12.02
Nincs semmi bajom a redirecttel, csak úgy hallottam hogy nem túl elegáns megoldás, ezért is kértem véleményeket. Nekem is ez lett volna az első amire tippeltem volna, csak hátha van valami olyan megoldás is amiről még nem hallottam :)

A törlést azért nem vettem külön, mert azt a listázásnál szoktam megoldani, külön oldalt nem csinálok neki.

A CRUDdal kapcs amit írtál. Ezekkel nincs gondom, azaz a létrehozás, törlés, egyebek. Ennek csak az oldalvezérlése érdekelne, hogy miként lehetne ezt a legszebben megoldani.

Köszi a javaslatot, akkor ez egyelőre 1 pont a redirectnek, ha jól vettem ki szavaidból Te is így oldod meg?! :)
3

CRUD

PHPprogramozo · 2009. Nov. 4. (Sze), 12.11
Utána olvastam a CRUD-nak amit említettél. Itt is úgy oldják meg, ahogy eddig én is csináltam, azaz egy visszalinket tesznek ki az aktuális oldal aljára.

Szóval még mindig a redirect marad ami a legjobb megoldás lehet?! Másvalaki?
4

Teljesen fölösleges 3 vagy több oldal...

whiteman0524 · 2009. Nov. 4. (Sze), 14.00
...amennyiben JavaScriptet használsz. Az összes funkciót (létrehozás, törlés, módosítás, listázás, keresés, szempontok szerinti rendezés) egy tető (oldal) alá lehet hozni, sőt, még azt is meg lehet csinálni hogy egyszerre több usert regisztrálhassál be, vagy egyszerre többet töröljél, esetleg módosítsál. Továbbá egyszerre töröljél is és módosítsál is, ha arra szükség van (természetesen itt különböző userekről van szó. Nyilván nincs értelme ugyan azt a usert egyszerre módosítani és törölni is :))

A fentiekhez feltétel viszont a JavaScript. Ha ettől ódzkodsz akkor tényleg szükséges a 3 vagy több külön lap. Én szívesen bemutatnám neked az én megoldásomat, de sajnos ezt csak videón tudnám jól érzékeltetni, mert ha ide belőném a teljes kódját, az több mint 600 sorra rúgna. Ehhez a több mint 600 sorhoz legalább 400 sor komment is tartozna hogy érhető legyen mit miért csináltam. :) A lényeg hogy meg lehet csinálni, és sokkal szebb mint minden funkciónak külön lapot nyitni, viszont sokkal bonyolultabb is.
5

Ajax

PHPprogramozo · 2009. Nov. 4. (Sze), 14.19
Köszi a véleményedet!

Az ajax technikával nemrég kezdtem ismerkedni és valóban sok mindenre hibátlan. Azt mondod, hogy jobb lenne pl. kirakni egy lapkitakaró réteget és azon megvalósítani az adatbevitelt mint egy új lapot betölteni?

Én azt olvastam az Ajax és javascriptről általánosságban, hogy ott használjuk, ahol feltétlen értelme is van és ahol a usereknek erre szükségük lehet. Pl. csekkolni, hogy létezik-e már egy adott usernév, vagy pl kirakni egy új beviteli mezőt vagy akár elpostolni egy űrlapot (megúszva a php időkorlátból fakadó adatvesztést)

Csináltam egy loglistát, abban pl. ha kiválasztasz egy logot, akkor betölti alá ajaxal a log teljes tartalmát úgy hogy betesz egy tr tagot meg abba a tartalmat. Ha már nem kell, akkor meg egyszerűen becsukod és kiszedi a tr-t a táblából.

Nagyon szívesen megnézném még akár videón is, hogy Nálad milyen egy javascriptes vezérlés, de gondolom, hogy hadititok számba megy :)
6

Nem hadititok... :)

whiteman0524 · 2009. Nov. 4. (Sze), 14.42
És nem is bonyolult ha megérti az ember a lényegét. Az Ajaxnak ehhez viszont az ég világon semmi köze sincs :) Persze lehetne azt is használni de nem feltétel hozzá. Rétegekre sincsen semmi szükség... :) Az igazság az, hogy ezt így nagyon sok idő lenne elmagyarázni... Már többször belekezdtem itt hogy mutassak neked egy-egy rövid példát de mindig oda lyukadtam ki, hogy akármennyire is próbálnám egyszerűen leírni az újabb és újabb kérdéseket vetne föl benned hogy "nade miért ?" :) Épp ezért inkább bele se fogok. Egy rövid videót esetleg tudnék csinálni neked róla, csak azt nem tudom hova töltsem fel...Meg a netem se valami nagy szám, szóval ha élvezhető minőségben szeretném feltenni akkor az elég sokáig tartana :)
7

üzenetet hogy adsz át

safipeti · 2009. Nov. 4. (Sze), 14.54
Sziasztok!

Én is hasonló problémába (?) ütköztem. Ha a header()-rel visszairányítasz, akkor hogy adod át elegánsan a megerősítő/hiba üzenetet?

Általam használt egyik megoldás, hogy siker/hiba esetén egy session változóban tárolom az üzenetet, ezt hozzárendelem egy view változóhoz, majd törlöm a session változót. Így a view oldalon a template kap egy változót (a view változót), amit megjelenít (mert pl. nem null, vagy mert isset(), stb). De mivel törlődött a session változó, más oldalbetöltődéskor ez nem jelenik meg.

Nem tudom, ez mennyire fapados megoldás (főleg, ha a user nem fogad cookie-t), valakinek van más ötlete?

Köszönöm,

safipeti
8

Üzenetek

PHPprogramozo · 2009. Nov. 4. (Sze), 15.21
Szia!

Ezen filóztam én is...

Azt agyaltam ki, hogy ilyen esetben úgy csinálom, hogy pl. még az új usert felvevő oldalon jelenítem meg az üzenetet, majd betolok egy 5-10 mp-es késleltetésű redirectet ami átdobja pl a listaoldalra. Plusz egy linket az üzenet aljára, hogy klikk ide és mész vissza a listához. Csinosítva lehet egy redirect számláló is js-ben az üzi mellett, hogy 4-3-2-1 és visszadob.

Nemtom ez mennyire szép, de hátha. :)
9

SESSION változó

PHPprogramozo · 2009. Nov. 4. (Sze), 15.34
A SESSION változó a szerveren jön létre, és független attól, hogy a usernél le van-e tiltva a cookie vagy nem. A SESSION változót ha létrehoztad, mindenképpen meg tudod jeleníteni és a user nem befolyásolhatja a tartalmát. De javítsatok ki ha nem így lenne...
10

A session változó

safipeti · 2009. Nov. 4. (Sze), 15.41
valóban a szerver oldalon jön létre, de a session id cookiban tárolódik a user gépén.
11

Session

PHPprogramozo · 2009. Nov. 4. (Sze), 16.11
Valóban igazad van! Nohh akkor már a site betöltésekor figyelni kéne, hogy a user engedélyezte-e a cookiet, különben a site session alapú szolgáltatásait nem fogja tudni használni?! Szupper jó hír. Bár aki nem engedélyezi a cookie-t az ezen alapon szerintem egy jóadag siteot nem fog tudni használni. De a legszebb ha erre figyelmeztetjük a usert.

És, hogy a témánál maradjunk. Pont ebből kifolyólag, amire rávilágítottál, talán érdemesebb a redirect előtt megjeleníteni az üzeneteket, hogy ne kelljen session-t használni.
12

header() előtt

safipeti · 2009. Nov. 4. (Sze), 16.23
már (még) ne legyen output.

A cookie-k általában nincsenek letiltva (sokan a userek közül nem is tudnak a létezéséről).

Letiltott cookie-kra ált. két lehetőség van:

1. url-ben hozzáadod a session id-t(nem szerencsés, biztonsági szempontból)

2. Amióta az Amazon és egyéb tekintélyes oldalak nem foglalkoznak a letiltott cookie-kkal (ergo, nem tudod használni a szolgáltatást), a user ne tiltsa le a cookie-t 8)
13

SESSION?

PHPprogramozo · 2009. Nov. 4. (Sze), 17.18
Ergo maradnál a session alapú üzenetjelzésnél?
14

+1 a sessionre

dragi · 2009. Nov. 4. (Sze), 21.21
+1 a sessionre