He estado creando Plugins PHPRunner y hay disponible un conjunto grande de posibilidades. En algunas ocasiones he tenido peticiones para hacer plugins de tipo EDIT que no he podido integrar ya que este tipo de código requiere que el código JavaScript tenga una estructura y característica especial y cómo os indico, muchos de ellos no lo cumplen.

También requiere que se ajusten a las versiones de JQuery (v. 1) y Bootstrap (v.3), que PHPRunner incorpora.

Objetivo:

Explicación cómo se puede incluir plugins de JavaScript como campo de entrada de información (ADD y EDIT) sin tener que escribir/hacer un Plugin PHPRunner.

Si te interesa esta información y quieres descargar el ejemplo, ves a este artículo.

Este artículo es, como todo lo que está en esta web, un ejemplo de qué herramientas disponemos para observar, medir y si se puede, corregir los rendimientos que nuestras aplicaciones de PHPRunner tienen.

En PHPRunner, se producen y ejecutan muchas querys que nosotros no definimos, en muchos casos desconocemos, y que en pocas ocasiones, pero muy importantes estas, tienen rendimientos que no son los esperados.

PHPRunner no te da muchas herramientas, una vez que se produce el «desastre» de observar y medir qué es lo que está pasando.

En el fichero «include/appsetting.php» en la primera sentencia se dispone de este código:

$dDebug = false;

Si ponemos «true» nos facilita trazas en el navegador, de los querys que hace pero al mezclar datos de traza con datos de aplicación, esto normalmente da muchos problemas y ayuda poco, aunque algunas veces puede ser suficiente.

Objetivo:

El objetivo del presente artículo es conocer todas las consultas que se hacen a la base de datos y una vez que se identifican las que nos pueden dar problemas, identificar planes de acceso del gestor de base de datos y algunas referencias de qué podemos hacer para mejorar los tiempos de acceso.

Si te resulta interesante sigue leyendo el artículo.

En varias ocasiones, he encontrado que tuve que almacenar y administrar caracteres en UTF8MB4.

De hecho, ha sido necesario para mí en estas 2 ocasiones:

• En el ejemplo, hice para recopilar los mensajes de una cuenta de correo electrónico y almacenarlos en tablas de base de datos. Ahora está muy de moda, o en el título o contenido, ponen Emoji (pequeñas imágenes) y estos suelen ser caracteres que usan UTF8MB4.
• He hecho un complemento para que «Emoji» se pueda incluir en un campo de área de texto y estos «Emoji» son caracteres en UTF8MB4, por defecto, utilizando PHPRunner, no pude guardar estos datos en la base de datos.

Bueno, he resuelto el problema y quiero compartirlo con vosotros. Para resolverlo, el campo del destinatario de este contenido debe especificarse con el conjunto de caracteres de UTF8MB4.

En el evento «after application initialized» de nuestra aplicación, debemos poner estas 2 líneas:

$sql = "SET character_set_results = 'utf8mb4', character_set_client = 'utf8mb4', character_set_connection = 'utf8mb4', character_set_database = 'utf8mb4', character_set_server = 'utf8mb4'";
DB::Exec($sql);

Y esto es todo, el resto de tu aplicación no tienes que tener nada especial en cuenta.

El PHPRunner 10.5, al igual que en casi todas las aplicaciones de los móviles a los datos de los usuarios se les añade una foto y de forma general, o ponemos  una foto nuestra o cualquier otra foto que deseamos que nos describa en dicha aplicación.

En todas estas aplicaciones te permite subir una foto y después te permite ajustar exactamente qué es lo que deseas exponer en la imagen de recorte.

Objetivo

Se desea dotar a PHPRunner de la funcionalidad de recorte de una imagen para crear la imagen o avatar de identificación del usuario de las nuevas aplicaciones de PHPRunner.

Toda la información, ejemplo y código, en este artículo

No sé exactamente cuando ha aparecido, pero la versión 10.5 dispone de un JavaScript Date API que nos permiten personalizar dinámicamente el componente estándar del selector de fechas y también, gestionar online (en JavaScript) los posibles controles de estas.

Una de las cosas que aún no dispone es añadir los controles de días festivos (en España son dependiendo de la localidad en la que estés) por lo que incluso pueden ser dinámicos dependiendo del contexto del aplicativo.

Objetivo

1. El objetivo del ejemplo es añadir al selector estándar de fechas los días festivos y que el usuario no pueda seleccionar uno de estos días.
2. Aprovechando este ejemplo, dar a conocer la existencia de este API y enseñar cómo se pueden hacer controles sobre los campos de tipo fecha.

El ejemplo y código en el artículo del ejemplo