Mostrando entradas con la etiqueta jsClient. Mostrar todas las entradas
Mostrando entradas con la etiqueta jsClient. Mostrar todas las entradas

16 octubre 2017

Componentes JSON&JS (Parte 8 de 12)

multivalueproperties 

El grupo de propiedades multivalor es opcional y permite configurar propiedades que pueden contener múltiples valores. A continuación describimos cada uno de sus miembros:
  • itemlistproperty
Es obligatorio. Cuando un control admite propiedades con varios valores, éstas son guardadas en una lista. Cada fila de la lista contendrá el conjunto de propiedades de la pestaña o columna en particular. Llamaremos a la pestaña o columna "elemento". Esto significa que éstas propiedades mostrarán una lista de tipos, que se ocultará automáticamente sobre el "Property manager". 
  • itemcountproperty
Es obligatorio y debe ser el nombre de una propiedad "integer" definida en el grupo de propiedades, de modo que se podrá especificar el número de elementos en la lista. Se podrá especificar un valor máximo para esta propiedad, a fin de restringir el número de elementos, de lo contrario se limitará a no más de 256. 
  • currentitemproperty
Es obligatorio y debe ser el nombre de una propiedad "integer" definida en el grupo de propiedades. Identifica al elemento actual seleccionado en el "Property Manager", los cambios aplican sólo a propiedades multi-valor. 
  • moveitemproperty
Es obligatorio y debe ser el nombre de una propiedad "integer" definida en el grupo de propiedades. Es utilizado para mover el elemento actual a una nueva posición en la lista de elementos.
  • properties
Es obligatorio. Permite conformar su lista de valores. Cada miembro ("Property Name") deberá corresponder con el nombre de una propiedad de entre el grupo de propiedades principal; El valor para cada miembro conforma la lista de valores para la propiedad. Es importante no cambiar el orden de las columnas una vez se haya comenzado a utilizar el control.
Ejemplo: 
"multivalueproperties": { 
     "currentitemproperty": "curitem",
     "itemlistproperty": "itemlist",
     "moveitemproperty": "move",
     "itemcountproperty": "itemcount", 
     "properties": {
          "mvprop1": 1,
          "mvprop2": 2
         }
      }
}

constants 

Es obligatorio y permite definir las constantes del control. Cada miembro del objeto constantes es en sí mismo un objeto que contiene los miembros que describen cada constante. Su nombre será también el nombre de la constante. Los elementos válidos para definir cada objeto constante son:
  • value
Es el valor de tipo "integer" de la constante y es obligatorio.
  • desc
Descripción de la constante. Un texto obligatorio, utilizado por el IDE como información adicional para la herramienta "catalog". 
  • group
Identifica al grupo en el "catalog" al que pertenece la constante y es opcional. De forma predeterminada, todas las constantes pertenecerán al grupo "RF:jsControls-≤control name≥". Todas las constantes que figuren a continuación de la que contenga un nombre del grupo, se entenderá como pertenecientes a ese grupo, hasta que se especifique un nuevo nombre de grupo (si procede).
Ejemplo: 
"constants": { 
     "kNetOmnisControlHeaderColor": {
         "value": 123,
         "desc": "The description of this constant"
     },
     "kNetOmnisControl1Range1": { 
        "value": 3,
        "desc": "Range constant 1”, 
        “group": “Ranges"
     },
     "kNetOmnisControl1Range2": { 
        "value": 5,
        "desc": "Range constant 2"
     }
}

09 octubre 2017

Componentes JSON&JS (Parte 7 de 12)

properties

Éste grupo es obligatorio. Contiene el conjunto de propiedades específicas del control. Cada uno de sus miembros es una propiedad y es en sí mismo un objeto que a su vez contiene los elementos que la describen. El nombre de cada miembro constituye el nombre de la propiedad, sin el prefijo "$".
Los miembros válidos para cada propiedad son los siguientes:

  • id
Es el identificador de la propiedad. Un entero positivo. Es obligatorio y es un campo crítico ya que Omnis usa éste dato para identificar la propiedad. Lo cual significa que no deberá cambiar estos valores de ID una vez que se ha comenzado a hacer uso del control. Id, debe ser único para todas las propiedades del control. Cuando "jsControls" carga el control, validará su unicidad. Normalmente se comenzar a numerar las propiedades desde 1. 

  • desc
Es la descripción de la propiedad. Un texto obligatorio, utilizado por el IDE, por ejemplo, como "tooltip" de la propiedad en el "Property Manager". 

  • tab
Es opcional y es el texto que identifica la ficha a la que pertenece en el "Property Manager". "custom" será la ficha predeterminada, si se omite. De lo contrario, deberá usarse uno de los siguientes valores: "custom", "general", "data", "appearance", "action", "prefs", "text", "pane", "sections", "java" o "column".

  • type
Es obligatorio. Identifica el tipo de la propiedad. Puede ser uno de los básicos (integer, character, boolean o list) o uno específico como (color, dataname, font, icon, pattern, fontstyle, linestyle, multiline, set, o remotemenu). 

  • runtimeonly
Es opcional y booleano, si es "true" indica que la propiedad es "runtime only". Su valor predeterminado si es omitido es "false". 

  • findandreplace
Es opcional y booleano, si es "true" indica que la propiedad puede ser localizada mediante "find and replace". Su valor predeterminado es "false". 

  • extconstant
Es opcional y booleano, si es "true" indica que la propiedad está restringida a un rango de constantes predefinidas para este control. Esto afectará al menú emergente en el "Property Manager". Puede usarse tanto con propiedades de tipo "integer" como con las de tipo "set"; En este último caso, el primer miembro del rango deberá ser una constante con valor cero, para representar al "set" vacío. 

  • intconstant
Es opcional y booleano, si es "true" indica que la propiedad está restringida a un rango de constantes predefinidas desde el núcleo de Omnis. Esto afectará al menú emergente en el "Property Manager". Puede usarse tanto con propiedades de tipo "integer" como con las de tipo "set"; En este último caso, el primer miembro del rango deberá ser una constante con valor cero, para representar al "set" vacío. "extconstant" y "intcontant" no deben ser "true" al mismo tiempo. 

  • constrangestart y constrangeend
Ambos deben existir si "extconstant" o "intconstant" son "true". En el caso de "intconstant", son "idents" (identificadores) de constantes que conformarán el rango de constantes a usar (podrá saber cuales son los "idents" de las constantes de núcleo Omnis, consultando el grupo "$constants" mediante el "Notation inspector"). En el caso de "extconstant", serán los nombres de las constantes definidas para el control; El conjunto estará entre "constrangestart" y "constrangeend" y en el orden en que figuren en el fichero "control.json". Tenga en cuenta que cuando se utiliza con un "set", los valores de las constantes deberán corresponderse con el "bit mask" (máscara) usada para representar el "set". 

  • min  y 
--> max
Son opcionales y solo se aplican cuando el tipo es "integer". Especifican los valores mínimos y máximos de la propiedad. 

  • initial
Es opcional y puede ser utilizado para indicar el valor inicial de la propiedad. Para los tipos "character", deberá ser un texto. Para tipos "integer", deberá ser un número entero. Para tipos "boolean" deberá ser un valor booleano.
Ejemplo:
"properties": { 
     "headercolor": {
          "id": 1, 
          "desc": "The header color of the control", 
          "type": "color",
          "tab": “appearance”,
          "initial": 255
     },
     "headericon": { 
          "id": 2,
          "desc": "The header icon of the control", 
          "popuptype": "icon",
          "tab": "appearance"
     },
     "rangeofexternalconstants": { 
       "id": 3,
       "desc": "Range of external constants", 
       "type": "integer",
       "extconstant": true,
       "constrangestart": "kNetOmnisControl1Range1",
       "constrangeend": "kNetOmnisControl1Range3",
     }
}

02 octubre 2017

Componentes JSON&JS (Parte 6 de 12)

JSON Control Object


Cada control posee un archivo JSON denominado "control.json" conteniendo su definición. A continuación describiremos en detalle cada uno de los miembros de este objeto según sus secciones:

name


    El nombre es obligatorio; Determina el nombre del control como componente externo y también el nombre de la clase JavaScript en la forma "ctrl_≤nombre≥", por ejemplo para...
     "name": “net_omnis_control1"
    ...la clase JavaScript sería ctrl_net_omnis_control1. 

     flags


      El grupo "flags" es obligatorio. Permite configurar ciertas características del control. Cada miembro de éste grupo es opcional y si son omitidos su valor por defecto será "false", siendo sus miembros válidos los siguientes:
      • beforeafterevents y beforeevents  (excluyentes mutuamente
      Indica si el control admite el uso de "evAfter" y "evBefore", o sólamente "evBefore", respectivamente. Si ambos son omitidos, indicará que el control no soporta ninguno de éstos eventos (véase "events")
      •  backcolorandalpha
      Indica si el control admite las propiedades "backcolor" y "backalfa". 
      •  noenabled
      Indica si el control puede no tener habilitada la propiedad. 
      •  transparentbackground
      Indica que el control posee fondo transparente y que no hace uso de las propiedades "backcolor" y "backalfa". No puede ser usado con "backcolorandalpha" a "true". 
      •  hasdefaultborder
      Indica si la propiedad "$effect" del control, puede contener el valor "kJSborderDefault". 
      •  hasdisplayformat
      Indica si el control contiene propiedades en formato de fecha y número. 
      •  hasdragevents
      Indica si el control permite eventos de arrastrar y soltar (véase "events"). 
      Ejemplo:
      "flags": {
          "beforeafterevents": true, 
          "backcolorandalpha": true, 
          "noenabled": true, 
          "hasdefaultborder": false, 
          "hasdisplayformat": true, 
          "hasdragevents": true
      }, 

       standardproperties



        El grupo "standardproperties" es opcional. Contiene las propiedades estándar soportadas por el control; La inclusión de cualquiera de sus miembros significa que el control admitirá la propiedad. Se trata de propiedades básicas aplicables a todos los controles.
        Miembros válidos del grupo son: "“dataname", “effect", “bordercolor", “borderradius", “linestyle", “font", "textcolor", "align", “fontstyle", “fontsize", “horzscroll", “vertscroll", "autoscroll" y “dragmode”.
        Ejemplo:
        "standardproperties": [
             "dataname", 
             "effect", 
             "bordercolor", 
             "borderradius", 
             "linestyle",
        ],
          

          25 septiembre 2017

          Componentes JSON&JS (Parte 5 de 12)

          JSON Control Definition


          En esta entrada describiremos las diferentes propiedades que pueden ser definidas en el archivo JCD, todas ellas editables mediante el "JSON Control Editor" (recuerde que también pueden ser editadas mediante cualquier otro editor de textos externo).

          La nueva carpeta "html/controls", contiene a su vez una subcarpeta por cada control JSON ya definido. Los nombres de estas subcarpetas no son críticos, pero tiene sentido usar el mismo nombre que el usado para el control.

          El "JSON Control Editor" creará la carpeta "html/controls" tras construir su primer control, de lo contrario (si está usando un control ya existente) necesitará crear esta carpeta manualmente. (IMPORTANTE: No confundirse con la carpeta "htmlcontrols" la cual contiene los controles definidos para su uso con el objeto oBrowser)

          Cada carpeta de control, contendrá un archivo denominado "control.json". Además, podrá contener archivos PNG, con cualquier nombre pero siempre incluyendo los archivos PNG: "16x16", "16x16_2x", "48x48" y "48x48_2x", ya que serán los usados como icono representativo del control, en el "Component Store" y en los formularios remotos. Los archivos PNG deberán tener la extensión ".png".

          Un nuevo componente externo denominado "jsControls", (situado sobre la carpeta "jscomp") es el encargado de gestionar todos los controles JSON, éste realiza la carga y validación de cada uno de los controles durante el arranque. Todos los que pasan la validación son mostrados en el "Component Store". Si un control no pasa la validación, "jsControls" abre el registro de seguimiento (log) y agrega un mensaje para indicar que existe un problema con el control. El problema exacto se podrá consultar en un archivo denominado "control_errors.txt" situado sobre propia carpeta del control.

          Cada control deberá tener un nombre único y estar indicado dentro del fichero "control.json" (ver más adelante), podrá usarse una convención similar a Java, excepto que Omnis utiliza el carácter de subrayado en lugar del punto, por ejemplo. "net_omnis_control1", ya que el uso de puntos causaría problemas de incompatibilidad con la sintaxis de notación usada en Omnis.

          18 septiembre 2017

          Componentes JSON&JS (Parte 4 de 12)

          Uso de componentes JSON&JS ya preparados


          Para hacer uso de componentes JSON&JS ya preparados, (es decir los obtenidos de terceros) deberá comenzar por agregar los archivos con extensión ".js" a la carpeta "html/scripts", así como cualesquiera otros archivos CSS y de imagen necesarios para el correcto funcionamiento del control sobre las carpetas correspondientes. También necesitaremos disponer de las propiedades, métodos y eventos del control, contenidas en el fichero JSON de definición y creado mediante el "JSON Control Editor".

          Una nota técnica en el sitio web de Omnis describe con detalle el procedimiento a usar, siguiendo como modelo un componente JSON&JS disponible para descargar e instalar libremente:

          También necesitará consultar la guía "JavaScript Control Reference" del "JS SDK" y que podrá encontrar aquí:


          11 septiembre 2017

          Gestión de licencias del Servidor de Aplicaciones Omnis versión 8.1 y Web Service

          Desde la versión 8.1, las conexiones hacia el Servidor de Aplicaciones Omnis (mediante jsClient) realizadas desde un mismo navegador del cliente, ahora cuentan como un solo uso de licencia para el servidor. Anteriormente se contaba cada conexión como usuarios independientes, lo que incluía el consumo adicional de licencias de servidor.

          La tecnología "jsClient" ahora genera automáticamente un UUID de identificación, el cual guardará como una cookie (denominada OMNISCLIENTID) y que se enviará como parámetro con cada conexión. La cookie caducará tras un año, generando entonces un nuevo UUID. Las cookies deben estar habilitadas tanto en el servidor web, como en cualquier cliente que desee conectarse, para que esto funcione.

          En cuanto al uso de la extensión "Web Services", mencionar que ya no necesitamos un número de serie para hacer uso de servicios web basados en REST, no obstante recuerde que si hacemos uso del objeto "HTTPClientWorker" para generar un cliente de Servicios Web (WSDL), necesitaremos instalar y configurar Java (no será necesario con los nuevos objetos de OW3 CURL).

          Componentes JSON&JS (Parte 3 de 12)

          Propiedades


          Para establecer las propiedades del control, disponemos de los apartados siguientes:

          • Flags
          Permiten indicar que eventos estarán o no habilitados, si el control tendrá fondo transparente, si se permite la capacidad de arrastrar-soltar y otros por el estilo.

          • Standard properties
          Tabla de propiedades estándar soportadas por el control además de las básicas, tales como su nombre.

          • Properties
          Permite la definición de un objeto con las propiedades específicas del control; La columna nombre, (name) determina cada uno de los miembros del "object-properties" es el nombre de la propiedad, la cual deberá escribirse sin el símbolo "$". El resto de las columnas determinarán cada aspecto de la propiedad.

          • Multivalue properties
          Permite configurar posibles valores (múltiples valores) para las propiedades que así lo requieran.

          • Constants
          Permite la definición de un objeto con las constantes que tendremos disponibles para su uso con el control. (Name, Value y Desc) 

          • Events
          Permite definir que eventos generará el control (además de los especificados en el grupo "Flags") e incluye eventos estándar como "evClick"; Note que sus nombres incluyen el prefijo "ev" 

          •  Methods
          Permite indicar los nombres de los métodos de tipo "client-executed" (ejecución del lado del cliente) proporcionados por el control; El nombre del método deberá incluir el prefijo "$".

          •  Html
          Permite indicar cómo deberá generarse el HTML que enviará el control al cliente.

          La opción "Save" creará el archivo JSON del control sobre la carpeta "html/controls". La opción "Build" creará el archivo JavaScript correspondiente al control, sobre la carpeta "html/scripts" (localizable sobre el directorio raíz de instalación Omnis). También se le preguntará sobre la idónea inclusión de una referencia al archivo JavaScript del control, en el archivo "jsctempl.htm", lo cual garantizará que el control esté disponible para probarlo con cualquier formulario remoto que pueda contenerlo.

          Tras la creación de cualquier control JSON, deberá reiniciarse Omnis, a fin de que esté disponible para su uso. Después del reinicio, el control aparecerá sobre la pestaña "JSON Components" del "Component Store" listo para ser usado. Para su entrega con la aplicación final, deberá colocar los archivos JSON y JavaScript sobre las carpetas correspondientes del servidor Web y verificar que se esté haciendo referencia al mismo, desde la página html, encargada de cargar el formulario remoto.







          05 septiembre 2017

          Indicador de carga personalizado (comando "showloadingoverlay")

          Desde la versión Omnis Studio 8.0.2 en adelante es posible agregar un indicador de carga (imagen animada) sobre un determinado componente o bien cubriendo el entero formulario remoto, ésto es posible gracias a un nuevo "clientcommand", denominado "showloadingoverlay".

          Esto es realmente útil, pues nos permite mostrar al usuario un indicador de que se está la espera de la conclusión de un proceso largo, hasta que la información deseada aparezca actualizada para ese componente o formulario, al mismo tiempo que se evita posibles acciones del usuario sobre los elementos mostrados en el mismo. Resultará especialmente útil si están realizando operaciones asíncronas, como cargar una lista con valores desde un acceso SQL. Cómo ya sabemos, los llamados comandos-cliente, tales como "showloadingoverlay", deben ser ejecutados mediante el método "$clientcommand", del siguiente modo:

          Do $cinst.$clientcommand("showloadingoverlay",rowvariable)

          Donde "rowvariable" es "row(show,controlName,message,cssClass)".

          • show
          Valor booleano "kTrue" indica que deberá mostrarse, "kFalse" para ocultarlo.

          • controlName
          Es el la propiedad "$nombre" del componente en el formulario, sobre el que se deberá mostrar o eliminar el indicador. Dejar éste parámetro vacío, causará que el indicador se muestre sobre el entero formulario. 

          • message
          (Opcional) Texto para mostrar junto con el indicador.

          • cssClass
          (Opcional) Clase CSS para aplicar al indicador. Nos permite personalizar su apariencia.
          De forma predeterminada, el indicador oscurecerá lo que haya detrás, mostrando una animación, junto con el texto (opcional) incluido. Si desea personalizar su apariencia, puede hacerlo mediante el uso de CSS. Cree una clase CSS sobre el archivo "user.css" y pase su nombre de clase como parámetro cssClass.

          El indicador de carga estará contenido en un "div" de tipo "toplevel", a la que se le asignará el nombre de su clase CSS. Este div tiene como nombre de clase "indicator", la clase CSS tiene el nombre "container", además de un elemento "p" con "message" como nombre de clase . Son los nombres que deberemos usar al aplicar los estilos CSS.

          La clase "omnisLoadingOverlay" contenida en el fichero "omnis.css" puede servirnos como base.


          04 septiembre 2017

          Componentes JSON&JS (Parte 2 de 12)

          JSON Control Editor


          Un control o componente JSON&JS, es definido mediante un archivo JSON, denominado "JSON Control Definition" (en adelante JCD), el cual podrá ser creado o editado mediante cualquier editor de textos JSON o bien mediante una nueva herramienta disponible desde el menú "Tools>>Add Ons", denominada "JSON Control Editor".


          El "JSON Control Editor" muestra una plantilla con todas las propiedades necesarias para crear un JCD básico. El editor nos permite fijar las propiedades del control bajo cada pestaña, para finalizar haciendo clic sobre la opción "Save", la opción "Build" nos permitirá llevar a cabo la creación del control así definido, la opción "Reset" permite eliminar los cambios realizados sobre la plantilla predeterminada, haciendo posible comenzar de nuevo. Antes de configurar las propiedades y los métodos de nuestro control, necesitaremos conocer sus definiciones, cosa que iremos desgranando en sucesivas entregas de éste blog.

          Control Name


          El nombre del control debe ser único, por lo que la primera cosa será cambiar su nombre (o simplemente aceptar el nombre predeterminado, si es que sólo estamos probando el editor). El nombre de control predeterminado tiene el prefijo "net.omnis" para mostrar la convención de nomenclatura preferida, la cual deberemos cambiar por el correspondiente a nuestro propio nombre de empresa, por ejemplo: "com.miempresa.micontrol1", o cualquier otra convención de nomenclatura apropiada. Note que utilizamos puntos en el nombre del control, pero Omnis finalmente los sustituirá por caracteres de subrayado, ya que los puntos causan problemas con la sintaxis de notación usada en la programación con Omnis.



          31 agosto 2017

          Notificaciones "Push" con Omnis Studio 8.1

          La versión 8.1 de Omnis Studio, permite el uso de notificaciones "push" en el desarrollo de aplicaciones para Android, iOS y Windows 10 (necesitaremos hacer uso de los "wrappers" versión 2.0 o posteriores).

          Para quienes no estén familiarizados con el uso de notificaciones "push", mencionar que ésto significa que ahora podremos enviar mensajes a cualquier cliente que tenga instalada nuestra aplicación para dispositivos móviles, aunque (en ese momento) no la esté ejecutando. En este sentido, la capacidad de enviar notificaciones "push" otorga a nuestras aplicaciones una funcionalidad muy potente e interactiva, ya que permite animar proactivamente a los usuarios finales a abrir y usar la aplicación.

          Una notificación o mensaje enviado de éste modo al cliente, podría (por ejemplo) incluir una noticia importante, un mensaje acerca de una nueva entrada en la base de datos o cualquier otra cosa que deseemos. Incluso es posible la inclusión de información útil, que se adjuntará a la notificación y que se pasará al "remote-form" de la aplicación, permitiendo al usuario interactuar con la aplicación a partir de la notificación recibida.

          El soporte para éste tipo de notificaciones es proporcionado a través del servicio de mensajería en la nube o servicio de notificación "push", para cada plataforma respectiva y deberá haber sido habilitada para nuestro proyecto de aplicación móvil, mediante el SDK y el "JavaScript Wrapper" correspondiente. Para configurar el uso de notificaciones para Android e iOS, necesitaremos activar el servicio "Firebase" de Google y en caso de Windows 10 necesitaremos configurar los servicios de notificación "push" del "Store Dashboard".


          Herramienta de administración de notificaciones push


          Para administrar las notificaciones, podemos optar por crear grupos de dispositivos, a fin de enviar notificaciones a determinados grupos o bien a dispositivos concretos. Toda esta funcionalidad puede ser manejada desde el propio código Omnis (mediante el uso de nuevas propiedades y métodos), o bien mediante una nueva herramienta de administración, denominada: "Push Notifications", localizable bajo el menú de opciones "Tools≥≥Add Ons" de Omnis. Tenga en cuenta que la herramienta es en si misma una librería Omnis (un fichero .lbs) ubicado en la carpeta "startup", por lo que deberá estar presente para que la funcionalidad de notificaciones "push" pueda ser usada con nuestras aplicaciones para móviles, además de nuestro código Omnis y también es necesaria para configurar el servidor de aplicaciones de Omnis.

          Métodos y nuevo "Client Command"


          Un nuevo "clientcommand" nos permite habilitar y deshabilitar el uso de notificaciones "push" en nuestras aplicaciones móviles:

          $clientcommand(“enablepushnotifications”, row(bEnable))

          bEndable: Es booleano - Si es "true" habilita las notificaciones push, "false" las deshabilita.
          returns: (Booleano) - Indicará si el comando ha terminado con éxito. (método client-execute)

          Además de éste comando, disponemos de un nuevo método denominado "$pushnotifycommand" que podremos utilizar para configurar las "Notificaciones Push".

          Para obtener más información sobre la configuración de notificaciones "push" en nuestras aplicaciones para móviles, así como el uso de comandos y métodos, consulte el nuevo documento "Push Notifications" eque podrá encontrar bajo el siguiente enlace:


          28 agosto 2017

          Componentes JSON&JS (Parte 1 de 12)

          Otra interesante característica que incorpora la versión 8.1 de Omnis, es la de poder definir nuestros propios controles para formularios remotos (remote-form) mediante JSON y JavaScript, dejándolos listos para ser usados en cualquier momento con nuestras aplicaciones web y móviles. Seguramente, pasando el tiempo veremos muchos componentes de éste tipo ya construidos por terceros, abriendo infinitas posibilidades a la incorporación de nuevos controles, listos para usar en nuestras aplicaciones.

          Este nuevo método proporciona una alternativa real al uso de C++ y el SDK JavaScript. (método actualmente en uso para la creación de componentes JavaScript) Sin duda una buena noticia, pues tan sólo necesitaremos poseer conocimientos de JSON y JavaScript, para crear y usar nuestros propios controles JavaScript en aplicaciones web o móvil o bien como contribución a la nuestra y cada vez más amplia comunidad de desarrolladores Omnis.

          Tras la creación de un "JSON Component", bastará con reiniciar Omnis para que aparezca sobre el "Component Store", bajo un nuevo grupo denominado "JSON". Su uso será muy similar al de cualquier otro componente, lo arrastraremos sobre nuestro formulario remoto y estableceremos sus propiedades mediante el "Property Manager".

          La representación (en modo de diseño) de los controles JSON en un formulario remoto es muy básica y no refleja el control real, su presentación real sólo la obtendremos en tiempo de ejecución, aunque para aquellos controles que no requieran de una interfaz visual ésto no será un problema, si que está previsto que en futuras versiones de Omnis, pueda mejorarse ésta cuestión.

          En ésta serie de 12 artículos breves, intentaré explicar como hacer uso de ésta nueva característica.

          Sigan atentos a éste blog.

          17 noviembre 2016

          Omnis Studio 8 y la localización con jsClient

          En ésta entrada nos ocuparemos de mencionar un cambio que se ha producido desde la versión 6.1 de Omnis y la localización a otros idiomas de los mensajes que de forma nativa puede recibir el usuario en su navegador, cuando desarrollamos aplicaciones con jsClient.

          En versiones anteriores de Omnis Studio, hemos estado haciendo uso del fichero "Studio.stb", con éste propósito, pero desde la versión 6.1 en adelante ha dejado de ser operativo, en nuestros desarrollos para la Web, decir que para otros entornos todo sigue siendo igual.

          Es decir, "Localization" y "StringTables" siguen funcionando como antes, pero para los mensajes que se envían desde de núcleo del cliente JavaScript, se necesita hacer otra cosa, decir que aparece parcialmente documentado en el manual "Omnis_WebDev.pdf", bajo el apartado "Localization for the JavaScript Client" en la página 187, pero desafortunadamente, resulta difícil de entender y la información es incompleta (Omnis Software a prometido corregir esto pronto).

          En mi caso tropecé con ésta "falta de información" al tratar de localizar al castellano el mensaje que Omnis muestra sobre el navegador del usuario, cuando el tiempo de conexión a expirado, el mensaje en ingles dice: "You have been disconnected. Refresh or restart application to reconnect"

          Centrándonos en la localización para éste texto, mostraremos las dos opciones de que disponemos para resolverlo:

          1) Agregar las siguientes líneas al archivo HTM inicial (marcamos en rojo las líneas que ya existen en el fichero:

          <!-- The following placeholder is replaced with either a script tag for the remote task string table or nothing when there is no remote task string table -->

          jOmnisStrings.en = {"disconnected":"You have been disconnected. Refresh or restart application to reconnect" };
          jOmnisStrings.es = {"disconnected":"Ha sido desconectado. Refresque el navegador o vuelva a cargar la aplicación para conectarse de nuevo" };

          <title></title>
          </head>
          Sin embargo, esto puede resultar algo incómodo si son muchas los textos y el número de idiomas a traducir (Existen más de 30 textos de error), por lo que se recomienda hacer lo siguiente:

          2) En la carpeta o directorio HTML del raiz de instalación Omnis, crear una nueva carpeta a la que denominaremos "strings" y agregar a ella un archivo denominado "Error_Strings.js" con el siguiente contenido:

          jOmnisStrings.en = {"disconnected":"You have been disconnected. Refresh or restart application to reconnect"};
          jOmnisStrings.es = {"disconnected":"Ha sido desconectado. Refresque el navegador o vuelva a cargar la aplicación para conectarse de nuevo.(es_es)"};

          Ahora necesitaremos modificar el archivo HTML indicado en el punto 1 (o el jsctemp.htm) para que lea como sigue:

          <!-- The following placeholder is replaced with either a script tag for the remote task string table or nothing when there is no remote task string table -->
          <script type="text/javascript" src="strings/Error_Strings.js"></script>

          <title></title>
          </head>
          Obviamente, tanto la nueva carpeta como el archivo htm modificado deberán ser llevados al Servidor Web.

          06 enero 2016

          Creación dinámica de formularios Web

          Éste artículo es una traducción del proporcionado por Kris Geerts (desarrollador Omnis www.it8-projects.com) de los Países Bajos, la librería ejemplo mencionada (LOGIN.zip), puede ser descargada desde Aula Omnis.

          Como ya sabemos el formulario web JavaScript que genera automáticamente Omnis para llamar a nuestros “remote form”, pueden integrarse fácilmente en cualquier sitio web ya existente. Pero me parecen  interesantes los apuntes que hace Kris en su artículo sobre la integración de Omnis Web con un sitio Web ya construido, por esa razón me he permitido la licencia de tomar sus notas y publicar éste artículo.

          Lo que Kris propone, es un modelo para la integración en un sitio web ya existente, con nuestros “remote forms” jsClient de forma dinámica. El escenario propuesto también podría resultar útil cuando se desea tener diferentes librerías (diferentes versiones) que a su vez conectan con diferentes bases de datos atendidas desde un solo proceso Omnis/MySQL (escenario habitual para los desarrollos en la “nube”). Como resultado de esto, podríamos llegar a tener librerías casi idénticas, con incluso nombres iguales para sus “remote forms”, bajo tales circunstancias podría resultar muy difícil su mantenimiento. De hay la propuesta de creación dinámica de “remote forms”, aunque seguramente podrían encontrarse otras razones para justificar el enfoque propuesto por Kris.

          En primer lugar deberemos asegurarnos de que nuestra solución Web funcione correctamente. Podemos realizar pruebas con la página HTML que Omnis genera automáticamente desde nuestro “remote form”, con la versión Omnis de desarrollo (127.0.0.1/jshtml/≤nombredelremoteform≥.htm). Sin embargo, cuando tengamos que portar la solución a un servidor web real, deberemos asegurarnos de contar con todos los archivos necesarios, páginas HTML en el directorio correcto y de que todo este funcionando correctamente. Para IIS (Windows), deberemos disponer de los siguientes directorios y archivos:

          Inetpub (normalmente en c:\inetpub) 
            Cgi-bin
              omnisapi.dll
              nph-omniscgi.exe
              …… 
            Scripts
              nph-omniscgi.exe
              nph-owscgi.exe
            wwwroot 
              scripts
                omjqclnt.js
                pie.htc
                …
            Css
              Omn_menu.css
              …
              Smoothness
                Jquery -ui-…
              Images

          Header-columns-bg.gif


          Para portar la solución al servidor Web, tendremos que copiar el contenido de la carpeta de “HTML” desde el directorio raíz de instalación de la versión Omnis para desarrollo, al raíz del servidor web. También debemos comprobar que estemos utilizando las últimas versiones del omnisapi.dll (o nphomniscgi.exe) y de los scripts. Una vez que el servidor esté funcionando correctamente, estaremos dispuestos para el paso siguiente.

          Ahora vamos a realizar pruebas con la librería de demostración (LOGIN.lbs) que seguramente ya ha descargado desde Aula Omnis, ábrala con el Omnis Runtime Server. Pegue la siguiente URL en un navegador, sustituyendo los valores indicados entre ≤≥ por la dirección IP y número de puerto correctos:

          http://≤IPServidorWeb≥/cgi-bin/omnisapi.dll?OmnisClass=rtDir&OmnisLibrary=LOGIN&OmnisServer=≤IPServidorOmnis≥:≤PuertoOmnis≥&param1=CompanyName

          Nota: En la demo proporcionada por Kris, se hace uso de un solo parámetro, pero, por supuesto, nada impide añadir otros parámetros (param2 = loquequiera, etc.). El modelo generado automáticamente puede hacer uso de hasta cuatro parámetros, pero pueden añadires más. Si se desea utilizar un formulario HTML aún más simple para acceder a la pantalla de inicio de sesión, consulte la entrada “statical-Submitexample” que encontrará en la “Remote Task” de nombre “rtDir” de la librería. Esto proporciona un inicio de sesión más cómodo para el usuario.

          Cuando introduzca la URL anterior, la clase “Remote Task” “rtDir” generará automáticamente una página HTML con el Omnis JavaScript (observe el método “$CreateDynam” de la “Remote Task” “rtDir”). De éste modo tendremos la ventaja de poder abrir otra librería, incluso estando ubicada en otro servidor, o cualquier otro formulario Web donde incluir lo que necesitamos para que funcione. La librería demo proporcionada se llama de nuevo a la misma librería mediante el formulario “rlogin”, por lo que (si queremos hacer un uso práctico de la solución propuesta) tendríamos que cambiar éste comportamiento.

          Como podrá observar en la librería ejemplo, se han codificado las rutas hacia las carpetas css y otros directorios, la ruta hacia la página HTML generada por la “Remote Task” es relativa al directorio “cgi-bin” y no al “wwwroot”. Esto significa que en lugar de “http://servidor/≤fichero≥.htm” la ruta URL siguiente será: “http://servidor/cgi-bin/≤fichero≥.htm”

          Tenga en cuenta que se usan rutas pre-codificadas para las carpetas css y otras, usadas en la creación de la página HTML dinámica, con sus propios parámetros ya rellenados, listo para que el usuario haga simplemente clic en “login'”.

          02 diciembre 2015

          jsClient: uso de “assignpdf” y “showpdf”

          Desde la publicación de la versión 6 de Omnis Studio, ha sido posible imprimir y visualizar archivos PDF mediante el componente PDFDevice y sus métodos javascript “addignpdf” y “showpdf”. Pero debido a un ajuste de seguridad (publicado en la nota ST/WT/1860) el uso de éstos métodos puede generar un error de tipo “You are not allowed to get the file D:/temp/test.pdf using the getpdf command”. ¿Cómo podemos resolver este problema?

          La solución, pasa por realizar un pequeño cambio en su archivo “Config.json” a fin de especificar en él, qué carpetas o directorios deben ser accesibles a la función “GetPDF()”. Éste archivo lo podremos encontrar bajo la carpeta “Studio” dentro del directorio raíz de instalación de Omnis.

          Concretamente, deberemos incluir, bajo su sección “Server” algo como lo siguiente:

          "getpdfFolders": ["c:\\Temp", "c:\\MyPDFFile"]

          Deberemos asegurarnos de que no quede ningún separador de los usados en los nombres de directorios sin ser “escapado” y de que estén encerrados entre comillas dobles. Esto permitirá el uso de los documentos PDF ubicados en las carpetas referenciadas.

          05 agosto 2015

          Gestión de sub-formularios dentro de un mismo panel o “Paged Pane”.

          En éste artículo queremos destacar una, de las muchas cosas que nos ha traído la versión 6 de Omnis, se trata de la posibilidad de gestionar un grupo de subformularios dentro de un mismo contenedor, creando un efecto de paneles plegables al estilo de lo que sucede con el menú de un “Paged Pane”. Los diferentes subformularios quedan dispuestos verticalmente pudiendo ser expandidos o contraídos, haciendo clic/tocando sobre su barra de título o bien sobre el icono dispuesto al efecto


          Configuración de los paneles


          Para crear el grupo de paneles tendremos que hacer uso del método “clientcommand”  denominado “subformset_add”, junto con algunos nuevos parámetros, cuyas constantes podremos encontrar bajo el grupo ”Subform sets” y con el epígrafe “kSFSflag...”. El comando “subformset_add” creará el conjunto de subformularios dentro de la instancia “remote form” actual, tal y como si se tratase de un “Paged Pane”.

          Do $cinst.$clientcommand("subformset_add",row-variable)

          La variable de tipo “row” es definida como: row(grupo,padre,flags,orden,lista). A continuación describimos las principales banderas o “flags” que pueden ser usadas con el comando “subformset_add”.

          kSFSflagOpenMin

          Éste “flag” o bandera causa que el grupo de paneles se abra en estado minimizado. Normalmente, todos los subformularios se abren en estado de no-minimizado, de modo que deberemos hacer uso de ésta bandera para evitar su comportamiento predeterminado.

          kSFSflagMinAsTitle

          Cuando se minimiza un panel (subformulario) del grupo, se mostrará sólo la barra de título. Esta bandera anula su comportamiento predeterminado y que es ocultar completamente (cerrar) el subformulario. Para añadir el botón de minimizar a cada subformulario, deberá usarse la bandera “kSFSflagMinButton”, lo cual permite al usuario expandir o contraer el panel mediante su pulsación y no sólo mediante hacer clic en su título.

          kSFSflagAutoLayout

          Dispone automáticamente los paneles (subformularios del grupo) verticalmente dentro de su matriz, ignorando su posiciones originales “left” y “top”. Se activa la bandera  “kSFSflagMinAsTitle” y se desactivan “kSFSflagResize” y “kSFSflagMaxButton”. Si además activamos “kSFSflagAutoLayout”, el usuario podrá arrastrar y soltar la barra de título de los diferentes paneles del grupo, para reordenarlos, colocándolos en el orden que prefiera.

          kSFSflagParentWidth

          Sólo es aplicable si antes se ha activado “kSFSflagAutoLayout”. Su posición original “width” (ancho) será ignorada, tomándose en su lugar el ancho del subformulario “padre” para todo el grupo. También fija el “edgefloat” de cada subformulario a “kEFright”. De modo que, el uso de “kSFSflagParentWidth” nos permite, la creación de un “Paged Pane” compuesto a modo de varios paneles creados a partir de un grupo de subformularios, que se redimensionan o ajustan automáticamente dentro del panel que los contiene.

          kSFSflagSingleOpen

          Sólo es aplicable si antes se ha activado “kSFSflagAutoLayout” y “kSFSflagMinButton”. Permite asegura que al menos una ventana o panel esté siempre abierto.

           

          Un ejemplo vale más que mil palabras


          La imagen que mostramos al inicio de éste artículo, muestra un conjunto de paneles o grupo de subformularios contenidos en un “Paged Pane”, con las opciones “Auto Layout” y “Parent Width” activadas.

          El método que mostramos a continuación, construye el grupo de subformularios asignándolo a un “Paged Pane” colcado a su vez dentro de un “remote form”. En el ejemplo, el subformulario tan solo contiene un campo de edición, con un pequeño texto ("This is panel #"). La lista o grupo de subformularios es construida incluyendo dicho texto, además del color de fondo, todo dentro de la variable “row” indicada para en el método “clientcommand” y su opción “subformset_add”.

          ; defina las variables para “lFormList”, “lSetRow” y para todas sus columnas
          ; construya el grupo de subformularios sobre “lFormList”
          Do lFormList.$define(lFormID,lClassName,lFormParams,lFormTitle,lFormLeft,lFormTop,lFormWidth,lFormHeight)
          Do lFormList.$add(1,'jsSubformSetPanelsSubForm',con(1,chr(44),rgb(221,221,255),chr(44),chr(34),"This is panel 1",chr(34)),'Panel 1',,,,160)
          Do lFormList.$add(2,'jsSubformSetPanelsSubForm',con(2,chr(44),rgb(204,204,255),chr(44),chr(34),"This is panel 2",chr(34)),'Panel 2',,,,160)
          Do lFormList.$add(3,'jsSubformSetPanelsSubForm',con(3,chr(44),rgb(187,187,255),chr(44),chr(34),"This is panel 3",chr(34)),'Panel 3',,,,160)
          Do lFormList.$add(4,'jsSubformSetPanelsSubForm',con(4,chr(44),rgb(170,170,255),chr(44),chr(34),"This is panel 4",chr(34)),'Panel 4',,,,160)
          ; defina la variable “row” para el comando “subformset_add” como “lSetRow”
          Do lSetRow.$define(lSetName,lParent,lFlags,lOrderVar,lFormList)
          Do lSetRow.$assigncols("SubformPanelsSet",'PagedPane:1',kSFSflagSingleOpen+kSFSflagMinButton+kSFSflagAutoLayout+kSFSflagParentWidth,'iOpenForms',lFormList)
          Do $cinst.$clientcommand("subformset_add",lSetRow)

          En este caso las banderas “kSFSflagSingleOpen”, “kSFSflagMinButton”, “kSFSflagAutoLayout” y “kSFSflagParentWidth” son sumadas para dotar al grupo en construcción de todas las propiedades simultáneamente.