ugrás a tartalomhoz

Mi az ami még rábízható a PHP+Ajax párosra?

ukrán · 2007. Nov. 5. (H), 16.27
Sziasztok!

Érdekes kérdéssel szembesültem a minap. Van egy megrendelőm, aki egy online szerencsejáték-alkalmazás elkészítésével bízott meg. Ez eddig még biztos nem ritka :) Ami viszont érdekesebb, hogy az egészet Ajax-szal álmodta meg.

Számomra furcsa, mert azért ezek már mintegy "enterprise-kritikusabb" területek szoktak lenni, az Ajax pedig azért még elég ingatag lábakon áll.

Mi a határ, ami még elmehet a PHP+Ajax kombóval? Ezt az alkalmazást Ajax-szal megvalósítani az nagyon szuicid dolog? El merjem ezt így vállalni, vagy próbáljam rábeszélni a megrendelőt valami Java applet / Flash típusú dologra, amit szívem szerint ilyen esetben tennék?

Köszi.
 
1

Mi az alapvető félelmed?

s_volenszki · 2007. Nov. 5. (H), 17.24
Szia!

Mi az alapvető félelmed? Amióta én megismertem az AJAX-ot, amit csak lehet és reális, azzal oldok meg!

Nem vagyok profi a témában, de ha minden igaz az AJAX is a HTTP protokollt használja. Akkor meg mi lenne a hatalmas különbség az között, hogy egy hivatkozásra kattintva mész a szerverre adatért, vagy rábízod AJAX-ra?

Én a Flash+PHP-t még soha sem próbáltam, de ha megnézed ezt a minntát megdöbbentő hasonlóságokat láthatsz Flash+PHP meg AJAX között!

onClipEvent(load){
  loadVariables("http://localhost/test.php", this, "GET");
}
A test.php:

$x = "abc";
print $x;
Az ActionScript valószínüleg hasonló módon kapcsolatot épít a szerverrel és kiprinteli az eredményt, amivel aztán AS visszatér.

Ha nem így van, helyesbítést kérek, mert ez a téma engem is nagyon érdekel! :)

s_volenszki
2

Szuicid-e?

tolmi · 2007. Nov. 5. (H), 17.29
Először is színt vallanék, így ekként kezeld az általam írtakat. :) Én ki nem állhatom a Flash-t, szerintem gusztustalan az Adobe politikája ez ügyben(is). Ennek ellenére belátom, hogy gyakran megkerülhetetlen, de mindíg a végső utáni megoldás nálam a Flash technológia alkalmazása.

Mennyit "bír el" az AJAX architektúra? Bármennyit. Lásd a felfutóban levő webes desktopokat(pl. eyeOS). A kérdés inkább az, hogy
1) Elég ügyes és tapasztalt vagy-e a feladatokat JavaScript-tel megoldani?
2) Elég türelmes vagy-e?

Egy ilyen oldalt szerintem könnyebb és gyorsabb Flash-ben megvalósítani, mivel jobb adottságai vannak ilyen tekintetben. Ezt nehéz elvitatni. Ellenben vannak ma már olyan megoldások, amivel JavaScript-AJAX alapokon lehet bonyolult dolgokat csinálni gyorsan és egyszerűen. Például Google Web Toolkit, persze csak ha Java/J2EE platformban gondolkodol. De megfelelő kiegészítésekkel szerintem szép eredményt lehet elérni például ExtJS segítségével is. Persze az én álmom, az SVG + JavaScript lenne az ultimate megoldás :) Kár hogy alig támogatott...

Tehát ha Flash-ben is megéri neked a munka, akkor javasold. De meg lehet ezt csinálni JavaScript-tel is ha értesz hozzá.
3

Nem az AJAX, hanem a DOM ami miatt aggódnék

vbence · 2007. Nov. 5. (H), 17.41
Az AJAX, tehát az XMLHTTP hívás elég egyszerű lépés ahhoz, hogy egykét órra alatt írj egy kompatibilitási réteget. Ebben még segítséget is kaphatsz meglévő keretrendszerektől (prototype, mootools stb)...
Ami a szívás forrása lehet az a DOM manipuláció, ami már komolyabb feladatokat is adhat. Itt (tapasztalataim szerint) kifulladnak a keretrendszerek (pl eseménykezelés). És ha belefutsz egy hibába, amire nincs workaround beleépítve a választott keretrendszerbe, a legegyszerűbbnek tűnő feladat is napokat emészthet fel (talán heteket is, ha rájössz, hogy egy IE bug miatt az eddigi elképzelésedet újra kell gondolni).
Szóval nézd végig a specifikációt, és ha mindent pontosan tudsz, hogyan fogod megcsinálni, nyugodtan álj neki az AJAXnak. Viszont ha még nem volt ilyen horderejű munkád JS-ben, ez az a terület, ahol a legnagyobbatt lehet szívni.
4

Bármi, amit közszemléle mersz tenni

kris7topher · 2007. Nov. 5. (H), 18.05
...rábízható az AJAX-ra, ha van hozzá rüelmed. De azért egy online szerencsejáték renszert, hát, kritikus. Mert ugye a JS kód minden titkosítás/kompilálás/tömörítés nélkül érkezik a böngészőhöz, azaz a visszafejtéséhez 0 energia kell. Tehát vagy szigorúan vékony klienst készítesz, vagy Flash, bár azt is .fla-vá lehet alakítani, de egy fokkal legalább nehezebb.
16

Védelem

Őry Máté · 2007. Nov. 11. (V), 14.22
Sosem szabad a kliensek hozzáértésére építeni biztonsági kérdésben. Főleg ha pénzről van szó.
5

szerintem mehet

Szekeres Gergő · 2007. Nov. 5. (H), 20.12
Bőven rábízhatod magad, azonban elötte én a helyedben környezetemben lévő összes AJAX-os irodalmat átnézném. Tényleg sokat lehet vele szívni, főleg ha az elején nem átgondoltan tervezed meg az egészet. ha viszont jók az alapok, akkor utána már talán nem lesz gond. Nyilván, mint minden kliens oldani technikának, itt is a platformfüggetlenség egy kritikus pont, ehhez pedig leginkább idő, türelem és egy "csepnyi" tapasztalat kell.

Nyilván te tudod, hogy fejlesztési időbe megéri-e neked, hogy ajaxozol, ahelyett, hogy a bevált technikáidat használnád.

vitatkoznék az elöttem szólóval: nem értem, miért lenne kevésbé biztosságos a rendszer, mintha az egész oldalt navigálnál.. ugyan úgy szerver oldalon authorizálsz. A JSt csupán a kérésre, illetve a válasz feldolgozására használod.
8

ebben az esetben baj lehet

kris7topher · 2007. Nov. 6. (K), 18.06
Nem tudom, te hogy vagy vele, de a topikindító által körvonalazott esetben (szerencsejáték rendszer) szerintem eléggé fatális következménye lehet, ha mondjuk a virtuális nyerőautomata által kidobott eredményt valaki "kicsit" meghamísítja (és jackpotot ér el egymás után 20000-szer)...
9

Vékony kliens

csla · 2007. Nov. 6. (K), 18.58
Ő arra gondolt, hogy ha nagyon vékony a kliens (gyakorlatilag semmi lényeges logika ill. adat nincs a kliens oldalon), akkor nincs külön biztonsági kockázata annak, ha másképp közlekednek az adatok a kliens és a szerver között.
10

hát az valóban gáz:)

Szekeres Gergő · 2007. Nov. 6. (K), 22.34
de nem hiszem, hogy egy normálisan megírt rendszerben az ajax lenne a kockázatnövelő tényező, jól kell megírni a szerver oldalon "csupán" ennyi a titka. ;)
6

szerintem sem kérdés

amonrpg · 2007. Nov. 5. (H), 23.12
Döntsön az, hogy te képes vagy-e megcsinálni. Mert meg lehet csinálni, ennél azért sokkal durvább dolgokat is. Ha nincs kedved molyolni a DOM-mal, akkor nézz rá az ExtJS nevű cuccra pl. Van benne crossbrowser DOM manipuláció is.
7

Eloszlattátok kételyeimet

ukrán · 2007. Nov. 5. (H), 23.51
Köszönök minden hozzászólást!

Ez a sok pozitív hozzászólás meggyőzött arról, hogy nincsen félnivalóm a PHP+Ajax megvalósítástól. Talán még azok az előítéletek élnek bennem, amelyek az Ajax-szal való ismerkedés kezdetén keletkeztek bennem. Összességében tényleg nem sok objektív félelmet tudnék felhozni.

Persze azóta már tevékenykedtem néhány Ajax projektben. Az a kijelentés, hogy profi vagyok benne, még enyhénszólva túlzó lenne, de van némi rálátásom. Éppen ezért megfogadom a tanácsaitokat:

-olvasok még egy kis szakirodalmat
-megnézem az ExtJS-t, és más keretrendszereket
-gondosan megtervezem a rendszert

Mégegyszer nagyon köszönöm.
11

Nem ajánlom DHTM-ben

w3net · 2007. Nov. 8. (Cs), 15.47
Ha csak nem vagy kliens oldali guru több éves tapasztalattal, akkor nagyon nagy kockázatot jelent a HTML megjelenitési réteget használni. Valakitől olvastam, hogy az Ajax arra jó, hogy elcsapjad az idődet vele, ha nagyon sok az időd.

Én nem tudom ajánlani az alkalmazás kliens oldali részét JavaScript-ben irni, mert őrületesen sok a csapda.
Mostanában egy Ajaxos file upload oldalat csinálok, de már ráment vagy egy napom, és állandóan problémák vannak. Talán irok is erről egy blogbejegyzést valamikor.

Ime néhány probléma, amivel szembesültem a tényleg rövidke file upload projektom fejlesztésekor:

A file uploadot egy iframe-on keresztül valósitom meg. Először úgy gondoltam, hogy az iframe-t dinamikusan hozom létre JavaScripttel, hogy valid legyen a web oldal. A form "target" tulajdonságát pedig beállitottam az iframe nevére (az iframenak "name" és "id" tulajdonságát is beállitottam). A form elküldésekor sajnos a form egy új ablakban nyilik meg MS IE alatt. Kénytelen voltam a HTML kódban egy iframet létrehozni.

Még igy sem működött MS IE alatt! És miert? mert a form 'target' tulajdonságát JS-el állitottam át. Ez persze IE-nak nem tetszett. Ezután kényzelen voltam a HTML kódban beállitani a form "target" tulajdonágát.
Igy már megy.

Azaz 1 darab upload megy. Ha második filet is fel akarok tölteni, akkor a form nem töltődik be újra az iframe-ba.
Persze rájöttem, hogy biztosan az iframe tartalma gyorsitótárazva van. Na erre az iframeba betöltődő HTML-kódban beállitottam a megfelelő meta tagokat. Persze nem ment. Ezután PHP-vel is beállitottam a megfelelő HTTP fejléceket, hogy kikapcsoljam a böngésző gyorsitótárazását. Még igy sem megy, és kifogytam az ötletekből.

További problémám, ha HTTPS-el kérem le az oldalat, akkor MS IE ilyez ir ki "This page contains both secure and nonsecure items ..". Biztosan orvosolni lehet a problémát, csak éppen rámegy pár óra ilyen szarságokra (bocs a csúnya szóért).

A te felvetett kérdésedre a válaszom: a világért se ird JS-ben!!
Néhány probléma:
- JavaScript-el nem lehet mindent megcsinálni, ha igen, akkor egy dual magos CPU kell hozza és nagy koponya plusz pár hét, vagy hónap.
- a böngészők inkompatibilitása még mindig nem a múlté (lásd a fenti problémákat az iframeval)
- memóriaszivárgási problémákra is ügyelni kellene (MS IE6-ra vonatkozik)
- kiszámithatatlan problémák tömkelege várhat rád (problámák versenyhelyzet kialakulásából, stb.).
- nehéz debuggolni a jS-t, egy rakás böngészőn kellene tzesztelni (Opera, MSIE6, MSIE7, Gecko, Safari, stbb..)
13

Nem támogatott dologgal lehet szívni

zila · 2007. Nov. 8. (Cs), 17.53
Azért rossz példa a file feltöltés, mert azt nem támogatja az XHR így "természetesen" lehet vele csúnyákat szívni. (persze mással is lehet szívni, de ha alapvetően egy támogatott dolgot csinálsz akkor jóval kevesebbet)

A többi felvetés jogos (memóriaszivárgás, versenyhelyzetek, debug nehézségek, böngésző inkompatibilitás).

Nem ismerjük a konkrét feladatot, lehet, hogy tényleg nem célszerű ajax-ozni, ha mindenáron javascriptben akarod megcsinálni, akkor inkább flash actionscript :)
15

na, azért ennyire nem vészes a helyzet

Szekeres Gergő · 2007. Nov. 11. (V), 11.20
Van néhány dolog, amit meg kell jegyezni, vagy utánanézni, de működhet a dolog. például:
A "This page contains both secure and nonsecure items .." problémára: ha https-en működik egy oldal, akkor ne használj '../' tartalmazó hivatkozásokat, sem iframebe sem img tagokban.

A probléma inkább abból adódik, hogy a fejlesztők szeretnek komplikálni, és mindent JSel megoldani. Lásd a form targetes dolgot. Amit meg lehet oldani JS nélkül oldjuk is meg! Ami nagy szívás lehet, az a https + ajax. ezzel mi is szívtunk nem is keveset, ugyanis itt egy explorer (6-os) buggal kell szembenézni.

A debuggot nem értem, miért ne lehetne, én ff alatt fejlesztek, és amit a firebug lefuttat, az 99%ban megy IE alatt is. Mellesleg egy webes alkalmazást nem nagyon szoktak minden böngészőre(sőt, igazából semmit) optimalizálni!

Az erőforrásigényességről: volt hogy én is belefutottam, de olyan feladatba még nem, amit ne lehetett volna megoldani. Van néhány trükk itt is, de ezekhez is hozzá lehet férni számos helyen.
12

Kár,hogy

w3net · 2007. Nov. 8. (Cs), 16.00
nem konkretizáltad, hogy mit kellene tudnia az interfésznek. Mert a szerencsejáték-alkalmazás elég tág fogalom. Ebbe belefér egy sima lottós oldal, de akár egy kemény online póker, esetleg sztriptiz online póker. Minden attól függ, hogy az interfésztől mit várnak el. Legyenek-e vakitó effektusok, drag and drop (például a kártyalapok mozgatására, legyen hang is benne, stb). Szóval a kérdésedre csak akkor tudnék pontosabb választ adni, ha konkrétan látnám az interfész-terveket és az UI interakciós terveket is.
14

Póker

ukrán · 2007. Nov. 11. (V), 09.18
Szia! Sima online pókerről van szó. A dizájn részét nem én fogom megvalósítani, tehát erről egyelőre nem tudok mit mondani. Pókerben kártyalapokat nem nagyon kell mozgatni, tehát ez kiesik. Egy asztal viszont lesz, amelyet a játékosok ülnek körbe. Konkrét dolgokat nem nagyon tudok neked mutatni, annál inkább sem, hogy ez nem a saját projektem.
17

gwt + póker

gex · 2007. Nov. 11. (V), 16.57
http://gpokr.com
18

Tanulságos

ukrán · 2007. Nov. 13. (K), 00.17
Tanulságos, köszi a linket!