SAPUI5: Varios botones usando el mismo onPress

En el post anterior, vimos cómo crear un botón mediante Javascript, en lugar de hacerlo en la vista XML. Le añadimos un texto y una función que se ejecutaba cuando se pulsaba el botón, con el evento press.

Ahora vamos a ir un paso más allá, vamos a crear dos botones que hacen prácticamente lo mismo: Al pulsar cada uno de ellos, crea un nuevo botón con un texto. Si hemos pulsado el primer botón, el texto del botón será "Hola" y si hemos pulsado el segundo botón, el texto será "Mundo".

Además, si pulsamos alguno de los botones recién creados, mostrarán el texto "Hola" o "Mundo", respectivamente.

La funcionalidad para cada botón es, a todos los efectos, la misma, y sólo cambia el texto mostrado. Si vamos a añadir una funcionalidad nueva en un futuro, habrá que aplicarla igualmente a los dos botones.

El siguiente código haría lo que estamos buscando. A cada uno de los dos botones le añadimos como manejador del evento press una función específica (ver attachPress). Por tanto, si queremos añadir una nueva funcionalidad, habrá que replicarla dos veces.

SAPUI5: Crear un elemento dinámicamente

Hasta ahora, en los ejemplos que hemos ido viendo para crear aplicaciones en SAPUI5, siempre hemos creado los objetos en la vista.

Pero resulta que podemos crear los objetos dinámicamente en el controlador mediante Javascript (o en una vista de tipo JS, claro). Esto nos va a permitir tener aplicaciones más complejas, en las que podamos decidir cuando hay que crear, modificar o eliminar un elemento y, además, no tenemos que definirlo obligatoriamente en la vista.

Vamos a verlo con un ejemplo facilito, y luego ya podremos buscar cosas más complicadas en posteriores posts. Partimos de una vista XML en la que sólo tenemos una página (sap.m.Page) y, en dicha página, añadiremos un botón que, al pulsar, nos mostrará un mensaje. Casi tan sencillo como destruir una Estrella de la Muerte.

¿Dónde vamos a codificar la creación del objeto? Pues como la vista es XML pero para crearlo necesitamos javascript, no nos queda otra que hacerlo en el controller.

Qué necesitamos saber

Para poder crear un objeto dinámicamente, tendremos que conocer el código (métodos, propiedades, eventos) que nos permita construir el objeto y modificar sus características. ¿Dónde podemos obtener esa información? Cómo no, en la SDK de SAPUI5. Ahí vamos a tener la información necesaria:

• La definición del constructor para crear el objeto: new sap.m.Button.

• Los métodos que podemos usar para modificar propiedades. Haremos una primera versión de la aplicación modificando las propiedades mediante estos métodos:
• setText para asignar el texto;
• attachPress para asignar una función que se ejecutará cuando salte el evento press. A este tipo de funciones se les llama manejadores, handlers.

• Las propiedades y eventos que podemos asignar a la función cuando se crea el objeto. Haremos una segunda versión de la aplicación asignando las propiedades dentro del propio constructor.

Ante cualquier duda, a tirar de la documentación de SAPUI5, ahí se va la mitad de nuestro trabajo

Cursos febrero 2018

Hoy llega otro post más de cursos, vamos a ver qué cursos interesantes nos podemos encontrar estos días, que puedan estar relacionados con SAP UX, HTML5 o incluso para gestionar los proyectos con los que tengamos que lidiar.

Como siempre, tengo dos sitios web de referencia, con MOOCs gratuitos: OpenSAP y Miríadax. El primero, cursos relacionados con SAP, en inglés y, si nos hace falta, con subtítulos. El segundo, cursos en español, que no tienen que ver con SAP pero que nos pueden interesar.

Me tengo que buscar algún sitio más de referencia...

Estimando precios para SAP CP

Hace unos meses hablábamos del tema de precios de SAP Cloud Platform, donde contábamos cómo podíamos hacernos una idea de lo que nos iba a costar la broma de usar SAP CP.

El enlace sigue siendo el mismo, no ha cambiado, https://cloudplatform.sap.com/pricing.html, aunque desde entonces la cosa ha cambiado un poco. Claro, es que ya han pasado tres meses, el post anterior está más obsoleto que la película de Tron.

¿Con qué nos encontramos ahora? Con dos formas de soltar la pasta:

• Mediante subscripción, donde podemos utilizar un pdf con los distintos paquetes ofrecidos, que es lo que ya había antes. Eliges un contrato y lo que firmas es lo que pagas. Si quieres algún servicio adicional, tienes que modificar el contrato.
• Basado en consumo, donde (entiendo) pagas una cantidad y, a cambio, te dan "Cloud Credits" (cual jueguecito de móvil), que se van reduciendo según consumas servicios. Puedes coger los servicios que te apetezcan y se te irá reduciendo el crédito.

¿Y cómo saber cuánto vas a pagar en "créditos nebulosos"? Esto lo podemos descubrir gracias a una calculadora que han puesto en la propia página, la "Estimator".

Dentro de la sección de "Consumption-based" puedes listar los servicios, acceder a uno de ellos y ahí te informarán del propi servicio y de su coste.

Coste para el servicio de Workflow, por usuario

Desde ahí, podemos añadirlo a la Estimator, donde tendrás el coste total de todos los servicios que hemos elegido, para poder hacernos una idea.

Planeando hacer algo chulo con el servicio de gamificación

Ojo, que no todos los servicios se pueden coger mediante el modelo basado en consumo. Por ejemplo, podemos ver que el oData Provisioning sólo se puede coger por subscripción. En el propio servicio nos informan.

Por último, la web nos ofrece una tercera opción... bueno, no es una opción como más, sino un apartado donde nos aconsejan qué servicios contratar, dependiendo del grupo de casos de uso que tengamos: Internet of Things, Big Data, UX... Por si, con tantos servicios, no tenemos muy claro cuál necesitamos.

SAP Screen Personas 3.0: Flavors adaptativas

SAP Screen Personas 3.0 es una herramienta de la que se oye menos de lo que se debería, sobre todo teniendo en cuenta que es gratuita (¡si tienes SAP, claro!). A mí me parece un bombazo, pero depende para qué, claro. Tiene su nicho de uso, un grupo de usuarios especialistas con un número limitado de transacciones.

Es una herramienta que te permite preparar una demo rápida para mostrar su potencia, pero que luego requiere un análisis más detallado de lo que el usuario va a querer hacer. Al final, lo que menos lleva es hacer las variantes (las flavors) y lo que más lleva es aprender cómo trabaja el usuario para poder diseñar lo que necesita.

Una de las pegas que tiene (debido al "público objetivo" que tiene la herramienta), es que está orientada a escritorio, pese a usarse con un navegador web, que hoy por hoy nos hace pensar en aplicaciones "utilizables en cualquier dispositivo" (aunque no siempre sea cierto).

En Screen Personas no tenemos eso de aplicaciones responsive como en Fiori: Donde pongamos los controles, ahí se quedarán, y si la ventana del navegador web es más pequeña que la variante, nos aparecerá el odioso scroll horizontal que nadie quiere ver en un dispositivo pequeño.

Pues ya podemos dejar de preocuparnos por eso, porque a partir del SAP Screen Personas 3.0 SP05, la cosa ha cambiado. Ahora SAP nos presenta las adaptive flavors, variantes adaptativas. Por fin vamos a poder adaptar la misma variante de una dynpro a varios tamaños de pantalla.

Así que vamos a ver cómo funcionan en los siguientes apartados:

• Primero veremos que son las adaptive flavors.
• Después echaremos un ojo a las notas que necesitamos o que deberíamos revisar.
• Vamos a trastear con un ejemplo curradísimo (pero muy, muy currado).
• Y finalmente veremos qué podemos hacer si no podemos pasarnos a SP05 pero queremos adaptabilidad.

Fiori, ESS/MSS y la SPRO

Andaba yo navegando por la SPRO, en Gestión de personal (estamos hablando de SAP HCM), para revisar la configuración de los absentismos disponibles en portal (para que la gente pueda pedir vacaciones y cosas de esas), cuando me ha venido a la mente un problema que a veces nos ocurre cuando a uno le toca trastear, por primera vez, con las aplicaciones de HCM para Fiori: Volvernos locos con las entradas disponibles en la SPRO.

Los que ya hayáis configurado alguna vez algo del Employee/Manager Self-Service en Web Dynpro ABAP (con EHP5) ya sabéis en qué punto de la parametrización nos encontraremos. Si tenemos instalado al menos un EHP6, puede que veamos algo así:

¡Si es que tenemos donde elegir! Que si SAPUI5, que si Web Dynpro ABAP, que si Java...

Pues la pildorita de hoy dice: La entrada de SAPUI5 no es de Fiori, quitáoslo de la cabeza. Es específica de HR Renewal.