Az OpenSocial fejlesztésekkel kapcsolatban több fejlesztő is nehezményezte, hogy körülményes a kialakított, JavaScript központú fejlesztés és ez nagyban nehezíti alkalmazásaik hatékony fejlesztését. Az OpenSocial 0.9-es szabvány erre próbál megoldásokat adni, amit ha jobban áttekintünk, akkor valóban sok-sok fejlesztő életét megkönnyítő megoldást találunk.
Mik is ezek az újdonságok:
- Data Pipelinening
- továbbfejlesztett OpenSocial Templating
- OSML - OpenSocial Markup Language
Nézzünk is pár példát, hogy miben egyszerűsödik az életünk:
Proxied Content
Sokan nem szerették, hogy a gadget.xml hordozza magában az alkalmazás alap megjelenését (különböző view-k html fragmentjét). Mostantól azonban lehetőség van arra, hogy az OpenSocial konténert egyszerűen, proxy megoldással emelje be ezeket a tartalmakat is:
1 2 | <Content view="canvas" href="http://myserver/canvas"> </Content> |
Itt annyi történik, hogy a CANVAS nézet meghívásakor a gadget szerver a http://myserver/canvas címen található html-t tölti be, ami természetesen továbbra is keresztül megy a gadget szerver rewrite/cache/stb. mechanizmusain. Ezzel még sokat nem nyertünk, egyedül a fejlesztésünk hatékonyságán javítottunk kicsit. Azonban csavarjunk a dolgon egy kicsit:
1 2 | <Content view="canvas" href="http://myserver/canvas" authz="signed"> </Content> |
Ezzel a kóddal egy apró csavart raktunk a kiszolgálási mechanizmusba, miszerint a http://myserver/canvas meghívása SignedRequest módon történik, tehát a saját kódunk már pontos információkkal rendelkezik az @owner és @viewer azonosítóiról.
Természetesen itt egy dologra figyelnünk kell, ahogy SignedRequest módba váltunk kiütjük az OpenSocial container cache megoldásait, tehát itt már bírnunk kell szerveroldalon a felhasználók által jövő lekérdezéseket!
Data Pipelinening
Az OpenSocial két féle lehetőséget biztosít nekünk az adott konténer social api-jának elérésére, az egyik a felhasználók böngészőjén keresztül egyszeráen elérhető rpc protokol, a másik pedig a szerveroldali restful interfész (utóbbi az iWiW-en belül egyelőre nem hozzáférhető). A böngészőben futó rpc hívásoknak sok hátránya van, sok esetben a felhasználónak az akár elég lassú internetkapcsolatán keresztül kell nagy adatokat megmozgatni a gadget betöltődése után. Azonban mostantól lehetőség van arra, hogy a felhasználó a renderelt gadgetet már a social adatokkal együtt kaphassa meg.
Nézzük is a példát:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | <?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="OpenSocial 0.9 Teszt" title_url="http://myserver" author="Bányai Zsolt [bazso]" author_email="banyai.zsolt@virgo.hu" description="Teszteljük az ópenszósölt!"> <Require feature="opensocial-0.9" /> <Require feature="opensocial-data"/> </ModulePrefs> <Content type="html" view="canvas"><![CDATA[ <script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data"> <os:PeopleRequest key="vf" userId="@viewer" groupId="@friends"/> <os:ViewerRequest key="viewer"/> </script> ]]></Content> </Module> |
Mi történt itt? Először is a <Require feature=”opensocial-data”/> sorral jeleztük, hogy használni szeretnénk az OpenSocial Data Pipelining megoldását. A Gadget szerver a renderelési fázisban látja, hogy két adatlekérdezést is szeretnénk (viewer ismerőseinek lekérdezése, valamint magának a viewernek a lekérdezése), ezeket megfuttatja az API szervereken és az eredmény elérhetővé válik a renderelt gadget html kódjában:
1 | <script type="text/javascript">opensocial.data.DataContext.putDataSet("viewer",{"hasApp":true,"thumbnailUrl":"http://approval.iwiw.hu/rest/person/HkVD909RD.jpg","name":{"formatted":"Bányai Zsolt","givenName":"Zsolt","familyName":"Bányai"},"profileUrl":"http://approval.iwiw.hu/rest/person/HkVD909RD.html","isOwner":true,"id":"approval.iwiw.hu:HkVD909RD","isViewer":true,"displayName":"Bányai Zsolt"});opensocial.data.DataContext.putDataSet("vf",{"list":[{"hasApp":true,"thumbnailUrl":"http://approval.iwiw.hu/rest/person/m8VhWkg8.jpg","name":{"formatted":"iWiW Root User","givenName":"User","familyName":"iWiW Root"},"profileUrl":"http://approval.iwiw.hu/rest/person/m8VhWkg8.html","id":"approval.iwiw.hu:m8VhWkg8","displayName":"iWiW Root User"},{"hasApp":false,"thumbnailUrl":"http://approval.iwiw.hu/rest/person/4pVS21R42.jpg","name":{"formatted":"Elfogadó Dezső","givenName":"Dezső","familyName":"Elfogadó"},"profileUrl":"http://approval.iwiw.hu/rest/person/4pVS21R42.html","id":"approval.iwiw.hu:4pVS21R42","displayName":"Elfogadó Dezső"}],"startIndex":0,"totalResults":2});</script> |
Elsőre ugye nem szép, azonban felettébb hasznos megoldás, hiszen nincs szükségünk már kliens oldali hívásokra, ezek az információk azonna elérhetőek JavaScript segítségével:
1 2 | var viewer = opensocial.data.getContext().getDataSet('viewer'); var viewerFriends = opensocial.data.getContext().getDataSet('vf'); |
OpenSocial Templating
Az előző példa elég meggyőző, azonban a fejlesztő még mindig nem szabadulhat a JavaScript mágiától. Ebben segítség az OpenSocal Templating, amely szerver és kliens oldalon egyaránt futtatható template lehetőséget biztosít, akár saját magunk által definiált template-ekkel.
Kicsit egészítsük ki az előző példát, és rögtön megvilágosodhatunk:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | <?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="OpenSocial 0.9 Teszt" title_url="http://myserver" author="Bányai Zsolt [bazso]" author_email="banyai.zsolt@virgo.hu" description="Teszteljük az ópenszósölt!"> <Require feature="opensocial-0.9" /> <Require feature="opensocial-data"/> <Require feature="opensocial-templates"/> </ModulePrefs> <Content type="html" view="canvas"><![CDATA[ <script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data"> <os:PeopleRequest key="vf" userId="@viewer" groupId="@friends"/> <os:ViewerRequest key="viewer"/> </script> <script type="text/os-template"> <strong>${viewer.name.formatted} ismerősei:</strong> <ul> <li repeat="${vf}">${name.formatted}</li> </ul> </script> ]]></Content> </Module> |
A példában nem tettünk mást, mint a gadget szerverrel szerver oldalon futtattatunk egy egyszerű template-et, amely segítségével a már előzőekben elérhető adatokat JavaScript mutyizás nélkül szépen html formában megjeleníthetjük, a következő eredményt kapva a renderelt gadgetünkben:
1 2 3 4 5 | <strong>Bányai Zsolt ismerősei:</strong> <ul> <li>iWiW Root User</li> <li>Elfogadó Dezső</li> </ul> |
Egy kis nyalánkság
Bár eddig csak ízelítőt kaphattunk az újdonságokból, azért egy dolgot még körbejárunk. Sokszor előfordul, hogy a felhasználónak a kapcsolati hálója alapján szűrve szeretnénk tartalmat visszaadni, de körülményes dolog megjáratni az adatokat a böngésző és a szerverek között. Ehhez a fenti példákat kicsit összemixelve kapunk egy nagyon hasznos megoldást. Csapjunk rögtön a lovak közé:
1 2 3 | <Content view="canvas" href="http://myserver/canvas" authz="signed" xmlns:os="http://ns.opensocial.org/2008/markup"> <os:PeopleRequest key="vf" userId="@viewer" groupId="@friends" /> </Content> |
No, lássuk mire megyünk ezzel a bűvészkedéssel. Külön-külön már tudjuk értelmezni ezeket a sorokat, azaz látjuk, hogy egyszer a gadget szerver SignedRequest alkalmazásával bekéri saját szerverünktől a gadget html tartalmát, valamint az is tudjuk, hogy az os:PeopleRequest előkészíti nekünk a @viewer ismerőseit. De hogy ér össze a kettő, merül fel a kérdés… Jelen esetben a sorrend megfordul, a gadget szerver lekérdezi a @viewer ismerőseit, majd az eredményt POST-olja a canvas nézet megjelenítéséért felelős oldalunknak, ráadásul úgy, hogy közben megbizonyosodhatunk a SignedRequest segítségével arról is, hogy valóban az iWiW-től érkezett a kérés. Íme az egyszerű szerveroldali php kód - a SignedRequest feldolgozása nélkül -, amely segítségével már dolgozhatjuk is fel az adatokat:
1 2 3 4 5 | $data = file_get_contents("php://input"); $my = json_decode($data); foreach ($my[0]->data->list as $d) { print $d->name->formatted."<br />"; } |
Konklúzió
Látszódik, hogy az OpenSocial szabvány keresi azokat az utakat, amelyek segítségével a fejlesztők számára kényelmesebbé és JavaScript-függetlenebbé válhat a fejlesztés, ezzel igyekezve felzárkózni a Facebook sokak által kényelmesebbnek ítélt platformja mögé.
Aki a fentiekről bővebben akar tájékozódni, az olvasgassa a http://opensocial.org oldalain található dokumentációkat, aki pedig arra kíváncsi, hogy az újdonságok mikor és milyen formában lesznek az iWiW-en is elérhetőek, az kövesse @iwiwdevet, valamint kísérje figyelemmel az iWiW Fejlesztői Blogot.




Templating-et tud a mostani Shindig is, meg be lehet hívni kívülről is az ostemplates-demo.appspot.com-ról, mondjuk a tapasztalat szerint elég kényelmetlen, ill. az iWiW-en fél decembert végighisztiztem, hogy ha már van, működjön is, mert csak kiköpi a forrást. Helyette én más rendszert javasolnék.
A data pipelining nem rossz, az összes demoappunk így kezdi
A nyalánkság helyett pedig kéne REST API, matematikailag belátható, hogy éppúgy átkerül az idegen szerveroldalra az alháló, csak kérdés, ezt az Origo elfogadja-e. De tőlem ez is jöhet, nekem mindegy, csak minden fejlesztő körülöttem azért sír, mert ő PHP-ból akarja programozni a rendszert, szerveroldalról.
Szívem szerint OAuth-ot kérnék, de tudom, hogy az nem lehetséges, mert ütközik az iwiw érdekeivel.