Változások az OpenSocial alapú fejlesztésben

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.

“Változások az OpenSocial alapú fejlesztésben” - 1 hozzászólás


  1. 1 Aadaam

    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.

Szólj hozzá: