mobiles web app

[tasmaniski]

Postoji standardni nacin za resavanje autorizacije korisnika, a to je ACL

Skoro svaki framework ima svoje biblioteke za to, a mozes da ih koristis i bez fremeworka. (za ovako nesto bi trebalo otvoriti novu temu ako vec ne postoji ...)

[dee]

Originalno napisao tasmaniski

Postoji standardni nacin za resavanje autorizacije korisnika, a to je ACL

Skoro svaki framework ima svoje biblioteke za to, a mozes da ih koristis i bez fremeworka. (za ovako nesto bi trebalo otvoriti novu temu ako vec ne postoji ...)

cek, nije valjda da acl stoji na clientu?

acl je na serveru, ali kako se to rjesava u kontekstu jquerymobilea? recimo, koristim li data-prefatch kao neregistrirani korisnik za stranicu koja trazi registraciju - gdje cu i kako handlati unauthorized odgovor servera?

ne zanima mene registracija korisnika generalno vec kako se rjesava u jquery mobile-u specificno u kontekstu ajax navigacije? dakle, client side prije svega.

[tasmaniski]

ACL je sa serverske strane.

Ja to resavam tako sto ako acl vrati da user nema pristup nekoj stranici vrati mu login stranicu kao view fajl. u jquery mobile-u nisam radio nista ...

[dee]

Originalno napisao tasmaniski

ACL je sa serverske strane.

Naravno. Taj dio imam i ja rijesen na serveru po ulogama, bla bla. (iako nisam imao pojma da to ima neko posebno ime )

Medjutim, imam npr implementiran swipeleft|right event za navigaciju medju stranicama, a stranice su mi data-prefetch. Kako rijesis mogucnost da stranica koja ne treba autorizaciju prefetch-a neku koja treba? Odnosno, sto se u tom slucaju desi ako nelogirani korisnik dodje i napravi swipe prema stranici koja treba autorizaciju?

Za sad koliko vidim, to bi se jedino moglo ako se prefetch radi iz javascripta i lovi pageloaded (nisam siguran u ime) event za svaku i na njoj provjerava sto je server vratio.

Poanta je...da bi swipe radio lijepo i smoothly, stranica mora imati prefetch. A prefetch moze naici i na unauthorized.

[dee]

e, jos nesto...
ne mogu taj dio nigdje naci, a vidio sam implementirano (npr na app.ft.com)

naime, u jquerymobile swipe ima neki treshold. pod time mislim, prati prst i kad ga pomaknes odredjeni broj pixela u neku stranu on okine odgovarajuci swipe event. medjutim, tad vise ne slusa prst. ne mozes npr. zaustaviti swipe upola na nacin da recimo prstom kontroliras tranziciju izmedju 2 stranice (i da, recimo, postavis tako da ti je pola svake stranice vidljivo).

da li je to uopce izvedivo u jquerymobile-u za swipe medju stranicama ili bi to podrazumijevalo ciganjenje sa overflow:hidden containerom koji bi listao <ul><li>... u sebi, a svaki <li> bio jedan page?

i, ako je to na tragu rjesenja, koliko je to u duhu mobile ux, a koliko ciganjenje?

tnx

[_korso_]

Lepo si rekao - swipe-flow.
Jeste malo izmena klasicnog shvatanja requesta, ali je u sustini isto. Imas request koji je asinhron, server vraca 200/403. Verovatno ces imati neki centralni objekat/objekte koji sluze za tu namenu - da kordiniraju dobavljanje podataka i renderovanje sledece stranice. U tom kontekstu ti i dalje dobijas na isti nacin podatke, kroz istu "proceduru" sve to prolazi, samo sto ih da kazem "baferujes" i cekas da korisnik odradi sledecu akciju. I na osnovu toga ti se prakticno on-the-fly definise sledeca stranica aplikacije.

Gore pomenuti js fw-rci nisu nesto teski za savladjivanje. To su light verzije. Imas mnogo teze dojo.mobile i kompaniju, pa senchu. Tome se bas treba posvetiti i istraziti. Ovi mislim da mogu u hodu da se uce. Ja sam bar tako i ucio, mada opet sam radio i sa dojo-om duze vreme, pa je lakse bilo.
Probaj, dosta stvari su resene vec ispod haube. Ako nemas iskustva sa tezim javascript aplikacijama, ovo moze da ti pomogne dosta, nego da pises sam. Ti najbolje znas, sta ti je najprihvatljivije.

Nisam radio sa jqmobile, pa je ovo malo i nagadjanje da tako radi ispod haube. Takodje css mi nije jaca strana. Ali pretpostavljam da postoji neki swipeOut ili kako god da ga zovu event, gde ako se to desi, pozoves centralni page objekat koji:
1. ako je request u toku otkaze ajax request (jer on i sluzi imzedju ostalog za dobavljanje podataka). Opet kako nisam radio sa jqmobile ne znam kako funkcionise. Ali verovatno da u pozadini poziva $.ajax f-ju gde ako imas referencu na trenutni xhr objekat, mozes da pozoves xhr.abort. To znaci da ako je na "pola" swipea otkazao, da ce ostati na prethodnoj stranici, a podaci se nece vratiti sa servera, pa se nece ni procesirati.
2. ako su vec podaci dovuceni sa servera, verovatno da postoji neki property tog eventa na osnovu koga mozes da zakljucis da li je odradio ceo swipe ili ne. Cesto ti eventi imaju kordinate u px, ili neke interesantne podatke, pa na osnovu njih zakljucujes sta se u stvari desilo.
3. takodje mozes da kada se tek odradi ceo swipe onda da zamenis stranicu, koja ce da ide sa nekim slide efektom ili kako se bese zove u jq.

Pretpostavljam da se moze napraviti jedna od ovih varijanti, jer i ja sam cesto odradim swipe i zadrzim jos par sec, pa tek onda pustim (npr. ako mi je u tom trenutku nesto zapalo za oko) i tek onda dobijem sledecu stranicu, bez polovicnih i sl.

Za ovu app sto ima implementirano, procitao sam negde da ima web inspector sa iOS Safari ili tako nesto. Proguglaj, pa gledaj log sta se desava kada radis te akcije koje tebi trebaju. Ono sa overflow mislim da je samo neka vrsta hacka. Verovatno da postoji elegantnije resenje.

[dee]

js kao takav mi nije nikakav problem. odradio sam puno toga s njim (sto raw sto uz pomo raznih frameworka). ne bi bio cak problem ni kuckati nesto sam medjutim je to besmislena rabota. em je tona stvari rijesena sto kazes 'ispod haube' em je nemoguce predvidjeti buducnost i potrebe, a ipak puno koristen framework (koji god), ako nista, barem dijelom ima te stvari na umu. a vrijeme razvoja (i mogucnost prosirenja) svakako su mi vazni.

pogledat cu svakako detaljnije kako i sto jquery radi i kakav je event-cycle od pocetka swapa do loada nove stranice.

u svakom slucaju, jos jednom, puno ti hvala!

[_korso_]

Ako sam te razumeo u ovom zadnjem delu poslednjeg posta, to je upravo single-page-app tj RIA "pristup" (proguglaj da vidis, ako vec nisi). Server je zaduzen samo za biznis logiku (ACL, auth, data, jos po neku sitnicu), dok cela UI logika je u Javascriptu koji je u browseru.
Prefetch u ovom tvom primeru vidim isto kao i fetch na click/swipe samo sto podatke dovuces u pozadini bez znanja korisnika. Ali ukoliko na prefetch dovlacis i dinamicki generisan html, onda sva UI logika ti nije na klijentu vec je ima i na serveru.

Da li je najcistije, zavisi ko i kako gleda na to. Npr. Googlovi proizvodi koriste upravo tu tehniku. Neki ljudi koji nemaju mnogo poverenja u clienta i sam javascript, misle da je to losa metoda, dok neki ne bi radili nista osim takvog pristupa.

Ja licno varijante ove tehnike (server: data, client js: UI) koristim za razvoj nekoliko godina inazad i meni je princip dosta cist. Ima i svojih mana naravno - kao i sve.
Mada opet sve to zavisi od app, nekada ima smisla kombinovati par tehnika kako bi napravio najbolje resenje za problem koji resavas.

[dee]

Originalno napisao _korso_

Ako sam te razumeo u ovom zadnjem delu poslednjeg posta, to je upravo single-page-app tj RIA "pristup" (proguglaj da vidis, ako vec nisi). Server je zaduzen samo za biznis logiku (ACL, auth, data, jos po neku sitnicu), dok cela UI logika je u Javascriptu koji je u browseru.
Prefetch u ovom tvom primeru vidim isto kao i fetch na click/swipe samo sto podatke dovuces u pozadini bez znanja korisnika. Ali ukoliko na prefetch dovlacis i dinamicki generisan html, onda sva UI logika ti nije na klijentu vec je ima i na serveru.

Da li je najcistije, zavisi ko i kako gleda na to. Npr. Googlovi proizvodi koriste upravo tu tehniku. Neki ljudi koji nemaju mnogo poverenja u clienta i sam javascript, misle da je to losa metoda, dok neki ne bi radili nista osim takvog pristupa.

Ja licno varijante ove tehnike (server: data, client js: UI) koristim za razvoj nekoliko godina inazad i meni je princip dosta cist. Ima i svojih mana naravno - kao i sve.
Mada opet sve to zavisi od app, nekada ima smisla kombinovati par tehnika kako bi napravio najbolje resenje za problem koji resavas.

Da, da, RIA prica.

Ma, kako sam novi u mobile web razvoju i kako sam krenuo s jQueryMobile primjerima, prirodno je stvar na pocetku otisla u smjeru njihovih primjera (koji podrazumijevaju UI sa servera, vise manje). Medjutim, vec na prvom koraku mi smeta cinjenica da razdvajam UI na klijenta i server jer to nekad do u beskraj komplicira stvari.
S druge strane, u javascript imam gotovo pa potpuno povjerenje (a i, po mom skromnom misljenju, dugorocno je dobra odluka sto vise ici sa javascriptom jer u kombinaciji sa HTML5 to ponovno postaje top vazan jezik) i RIA na klasicnom webu su mi normalna stvar za koju bih se uvijek odlucio. Tako da nije proslo dugo dok sam shvatio upravo to sto govoris:

Ja licno varijante ove tehnike (server: data, client js: UI) koristim za razvoj nekoliko godina inazad i meni je princip dosta cist. Ima i svojih mana naravno - kao i sve.

ja to koristim par godina na klasicnom webu, a sad vidim da je i na mobilnom prica zapravo ista uz tu razliku sto je workflow mrvu drugaciji (al nista sustinski).

u ovom istrazivanju sam cak naisao na primjere gdje ljudi rade serverske komponente/kontrole za generiranje client side UI logike (npr. stare navike Microsoftovih design-developera) sto je potpuno suprotno od smjera koji meni odgovara.
Server: data, client js:UI = za mene je to dobitna kombinacija. A trenutkom kad sam to otkrio konacno se osjecam puno vise kao kod kuce u mobilnom svijetu

[xippi]

Originalno napisao dee

Server: data, client js:UI = za mene je to dobitna kombinacija. A trenutkom kad sam to otkrio konacno se osjecam puno vise kao kod kuce u mobilnom svijetu

upravo to. radis kao bilo koji drugi one page app, js klijent kacis na rest api koji vraca json data. kakav html u odgovoru, kakvi bakraci