[Ginga-argentina] Medias de property en Ginga-NLC

[Alejandro Alvarez]

Hola,

la forma de leer y escribir los settings desde ncl es mediante un objeto
media de tipo application/x-ginga-settings.
Entonces si se quiere definir una variable se puede realizar de la siguiente
manera:
 <media id="misVariables" type="application/x-ginga-settings">
 <property name="nombreDeVariable" value="unValor"/>
</media>

Por otro lado hay variables de sistema o usuario, por ejemplo la edad del
usuario que está utilizando el STB.  Un ejemplo de como leer esta variable
podría ser en la definición de una regla:

<ruleBase>
<rule id="esMayor" var="user.age" comparator="gt" value="18" />
</ruleBase>

y esa regla se podría utilizar en un switch para decidir si mostrar o no un
contenido.

Ahora bien, quien debe mantener estas variables a mi entender es el firmware
del STB, dado que el mismo es el que tiene la información  sobre el usuario,
control parental, OS, etc.

slds!

2010/12/23 Ezequiel García <elezegarcia at yahoo.com.ar>

> Hola,
>
> Quisiera saber si alguien tiene idea de como se pueden leer y escribir los
> "media" tipo "property" en la implementación Ginga.ar 1.1.0.
> En el documento "NORMA BRASILEÑA ABNT NBR 15606-2" (que se puede bajar, yo
> lo encontré por Google) se especifica lo siguiente:
>
> 10.3.4 Módulo settings
> Exporta la tabla settings con variables definidas por el autor del
> documento NCL y variables de ambiente
> reservadas, contenidas en el nudo application/x-ginga-settings.
> No se permite atribuir valores a los campos representando variables en los
> nudos settings. Un error debe ser
> generado en el caso que ocurra un intento de atribución. Las propiedades de
> un nudo settings solo pueden ser
> modificadas por medio de eslabones NCL.
> La tabla settings particiona sus grupos en varias subtablas,
> correspondiendo a cada grupo del nudo application/x-
> ginga-settings. Por ejemplo, en un objeto NCLua, la variable del nudo
> settings “system.CPU” es referida como
> settings.system.CPU.
> Ejemplos de uso:
> lang = settings.system.language
> age = settings.user.age
> val = settings.default.selBorderColor
> settings.service.myVar = 10
> settings.user.age = 18 --> ERRO!
>
> Sin embargo, en los programas de ejemplo que he intentado hasta ahora, la
> variable settings es siempre "nil". Lo mismo vale para el módulo
> "persistent".
>
> Quisiera saber si alguien tiene idea como es la sintaxis que permite
> acceder a estas variables desde NCL y/o Lua. Parecería que quizás las mismas
> no están implementadas en Ginga.ar 1.1.0, pero un vistazo rápido a los
> fuentes demuestran lo contrario.
>
> De hecho si hacemos un grep de "SYSTEM_OPERATING_SYSTEM" obtenemos:
>
> $ grep -r "SYSTEM_OPERATING_SYSTEM" .
>
> (Entre otras cosas)
> ./gingancl/src/adaptation/context/.svn/text-base/PresentationContext.cpp.svn-base:
>     (*contextTable)[SYSTEM_OPERATING_SYSTEM] = si->getOperatingSystem();
>
> Es decir que la variable SYSTEM_OPERATING_SYSTEM (que se mapea al campo
> system.operatingSystem del módulo settings) obtiene su valor del método
> getOperatingSystem(). Veamos pues que tiene ese método:
>
> En el archivo "gingacc-contextmanager/src/system/SystemInfo.cpp"
> encontramos:
>
>     string SystemInfo::getOperatingSystem() {
>         return sn.sysname;
>     }
>
> Y a su vez, esta variable se inicializa con la función uname() (ver man 3
> uname). Como verán las propiedades están implementadas. Ahora bien, ¿cómo se
> acceden?
>
> Saludos,
> Ezequiel.
>
>
>
>
>
> _______________________________________________
> Ginga-argentina mailing list
> Ginga-argentina at lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/ginga-argentina
>
>


-- 
Alejandro Alvarez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ourproject.org/pipermail/ginga-argentina/attachments/20110104/8d4059e3/attachment.htm