Blog

Conoce las últimas novedades sobre todo lo relacionado con el mundo online.

Información útil sobre todo lo que te interesa, desde las mejores herramientas de desarrollo a las últimas tendencias en redes sociales. Si no te enteras es porque no quieres.

Modal dinámico en Bootstrap 4

bootstrap 4

En un artículo anterior explicamos cómo refrescar contenido en un modal de Bootstrap 3, algo muy útil para una ventana de información tras añadir un producto al carrito con Woocommerce por ejemplo. Si no lo recordáis o queréis echarle un vistazo, podéis hacer click aquí. En esta ocasión explicaremos cómo podemos hacer lo mismo con un modal en la versión 4 de Bootstrap, pues el método anterior ha sido eliminado del framework. No entraremos tanto en detalle explicando el por qué hemos elegido hacerlo así o para qué sería útil porque ya lo hicimos en el artículo anterior, así que vamos directamente al nuevo método para poder actualizar el contenido del modal de Bootstrap o lo que es lo mismo, hacer modals dinámicos en Bootstrap 4. Puesto que ya no funciona como antes, en el que utilizábamos el atributo ‘href ‘ de la etiqueta ‘a’ o bien un atributo ‘data’ con el nombre ‘remote’, no veo necesario utilizar el elemento de enlace para abrir el modal, por lo que vamos a usar un span en esta ocasión.Antes: [crayon-6766b63eb060f768901369/] Ahora: [crayon-6766b63eb0616982959902/]   El código de la ventana o popup en este caso hemos preferido tener varios elementos estáticos como lo son el header y footer del modal, pero también podrían ser dinámicos si necesitáramos que tuvieran alguna otra función o información a mostrar. En nuestro caso el botón de continuar con la compra y finalizar la compra serán siempre los mismos. [crayon-6766b63eb0618403984483/]   Lo realmente diferente viene ahora, pues necesitaremos tener el código jQuery que ponemos a continuación para que al hacer click sobre nuestro elemento ‘Añadir al carrito’, el modal cargue la información deseada. [crayon-6766b63eb061b578120415/] Si os fijáis, el código contiene una pequeña comprobación que hace ligeramente más óptima la carga del servidor, pues en lugar de eliminar el contenido y volver a cargarlo en cada click, lo que hacemos es comprobar si el atributo ‘remote’ sigue siendo el mismo. Por ejemplo, el modal podría contener los términos y condiciones de uso desde varios enlaces en la misma página. También se ha añadido una variable de php por GET que nos servirá para comprobar si debo mostrar únicamente el contenido de la página solicitada, o por lo contrario debo mostrar la página junto con toda la cabecera, menús, footer, etc. Por último el template de la página contendrá el contenido del modal. Comprobaremos si existe la variable GET llamada modal para mostrar más o menos contenido. [crayon-6766b63eb061e290311704/]   Por último, aclarar que el código jQuery se lanzaría en todos los modals de la web, por lo que si quisierais tener contenido estático y dinámico en diferentes modals, no deberíais aplicar el evento click a todos los elementos data-toggle modal. Una solución serían crear una clase específica para los divs dinámicos.

Más info

Cómo estar en todos los dispositivos de tus clientes

aplicaciones-web-avanza

Cuando hablamos de en qué canales queremos estar disponibles para nuestros clientes, la respuesta suele ser: EN TODOS. Evidentemente, si podemos conseguir llegar a nuestros clientes a través de todos los canales posibles, es muy probable que también podamos obtener ventas mayores. Aunque no siempre debemos pensar que por estar en todos los canales va a ser mejor para nuestro negocio, ya que tenemos que trabajar cada uno de ellos de la mejor forma posible y esto puede requerir recursos que actualmente no tenemos disponibles. Las aplicaciones web Aquí es donde entran las protagonistas de nuestro artículo: las aplicaciones web o web apps. Por si todavía nos las conocías, las aplicaciones web son programas que se ejecutan directamente en el navegador, por lo que no necesitamos instalar nada adicional. Esto permite que cualquier dispositivo con un navegador pueda ejecutarlas (con matices). El uso de las aplicaciones web está cada vez más extendido, en parte porque desde hace unos años y gracias a los smartphones, todos tenemos un navegador web en nuestras manos en algún momento del día. A estos también se suman los ordenadores (portátiles y de sobremesa), las tablets, videoconsolas e incluso algunos smartwatches. Las ventajas de estas aplicaciones son numerosas, aquí te dejamos las más interesantes: Compatibilidad multiplataforma: como ya hemos comentado anteriormente, cualquier dispositivo con un navegador web es susceptible de poder ejecutarla. Además no importa si el sistema operativo es Linux, Apple o Windows entre otros. Actualizaciones constantes: las actualizaciones se pueden realizar sin necesidad de solicitar al usuario que realice ninguna acción. Lo que hará que siempre se utilice la última versión disponible. Uso inmediato: al no necesitar instalación, los usuarios acceden a todas las funciones de forma instantánea. Esto mejora mucho la utilidad en aplicaciones recurrentes que necesitan rapidez de uso. Coste de desarrollo: al estar basadas en estándares tan extendidos como PHP o Javascript, el coste de desarrollo es muy inferior en comparación al desarrollo de una app nativa. Además no necesitas un desarrollo específico para cada plataforma, por lo que el tiempo requerido para lanzarla al mercado es mucho menor. Como ves, no es casualidad que existan cada vez más aplicaciones de este tipo para distintos sectores. Google es una de las que más fuerte apostó por este concepto y no le ha ido nada mal. Facebook por ejemplo, permite que utilices (casi) todas las funciones que tienes en su aplicación nativa directamente en tu navegador móvil o de cualquier otro dispositivo. ¿Cómo pueden ayudarme en mi negocio las aplicaciones web? Como decía alguna que otra vez Pau Donés en su canción, todo depende. Y es que tenemos que tener claro nuestro objetivo y saber qué necesidades tienen nuestros usuarios a la hora de desarrollar una aplicación web. Puede que sencillamente necesitemos facilitar información a nuestros usuarios a través de nuestra web app o que debamos proporcionar servicios y funcionalidades más complejas. Por ejemplo tenemos aplicaciones web que permiten conocer el estado meteorológico de una región concreta para gestionar cultivos y gracias al GPS integrado en la mayoría de los dispositivos, podemos utilizarlo en nuestra aplicación web para facilitar al usuario esta tarea. También puede ser útil para proporcionar soporte mediante un chat en directo o interconectando a usuarios con la mismas dudas. Gracias a que la mayor parte de los procesos se ejecutan en el servidor, podemos ofrecer funciones avanzadas a usuarios que tienen dispositivos con especificaciones limitadas, que si fueran aplicaciones nativas, no podrían aprovechar. Las posibilidades que nos brindan este tipo de aplicaciones son casi ilimitadas, así que tienes a tu alcance la oportunidad de ofrecer a tus usuarios la solución a sus necesidades sin gastar mucho dinero. En Avanza hemos desarrollado aplicaciones web para nuestros clientes y han supuesto una gran mejora en el servicio que ofrecen a nuestros clientes. Si quieres ver algún ejemplo de lo que somos capaces de hacer, puedes echarle un vistazo a Bornay, donde desarrollamos BPlanner, una calculadora para conocer qué instalación solar necesitas. Nuestro proyecto para AVIS con el que gestionar su flota de vehículos o GestiRep, que permite obtener la mejor valoración para tu vehículo de una forma fácil y rápida. Esperamos que hayas sacado alguna idea para tu proyecto y si quieres que charlemos para ayudar a llevarla a cabo, contacta con nosotros.

Más info

Symfony 4 y Sonata Admin: seguridad mediante voters

Symfony Sonata Voters

Si estamos desarrollando nuestra aplicación web en Symfony 4 y hemos optado por usar como «bundle» de administración Sonata, llegará un momento si la aplicación es medianamente compleja que tendremos que definir la gestión de privilegios a aplicar a los usuarios que pueden acceder al entorno de administración o «backend». La documentación de Sonata nos da básicamente 2 alternativas para gestionar la seguridad: Gestión mediante ROLES (sonata.admin.security.handler.role) La gestión mediante ROLES consiste en definir roles a los que asociar a los usuarios y en función de dichos roles dar acceso a modificar, eliminar, etc las diferentes entidades de la aplicación. Esta opción es poco flexible ya que si le das permiso a un rol para modificar un tipo de objeto podrá modificar todos los objetos de ese tipo sin restricción. Gestión mediante Listas de control de acceso ACL (sonata.admin.security.handler.acl) La gestión mediante ACL es bastante compleja y en Symfony 4 se ha eliminado del desarrollo principal y se necesita instalar un «bundle» adicional para disponer de ella:  ACL Bundle. Como alternativa a ACL en la documentación de Symfony se recomienda usar voters, combinándolos con los roles de usuario podemos abordar la gestión de privilegios en Sonata sin necesidad de implementar ACL. Puedes ver y descargar todo el código que comentaré a continuación desde los enlaces de interés. Combinando roles y voters en Symfony 4 y Sonata Vamos a plantear un ejemplo en el que ver el uso de voters de forma sencilla. Estamos desarrollando una aplicación web para la gestión de concesionarios de una marca de automóviles, los usuarios con el rol de «concesionario» tendrán acceso de edición a los vehículos vendidos o por vender. Los propietarios de los vehículos podrán ver aquellos vehículos que posean y los administradores de la plataforma tendrán todos esos privilegios y también la opción de eliminar los vehículos. Existirán por tanto estos roles en la aplicación: ROLE_ADMIN (Administradores) ROLE_CONCESIONARIO (trabajadores del concesionario) ROLE_PROPIETARIO (Propietario de vehículos) Por comodidad en la administración, usaremos los grupos de usuarios que proporciona Sonata User Bundle y crearemos 3 grupos de usuarios. Con el propio panel de administración de Sonata aparte de asignar los usuarios a grupos también podremos darle roles específicos si fuese necesario, los 3 grupos de usuarios serían:   La estructura de la base de datos quedaría de la siguiente forma:   La configuración de roles en config/packages/security.yaml para implementar la política de seguridad deseada quedaría de la siguiente forma: [crayon-6766b63eb103b759207472/] Con esta configuración de roles delimitamos los accesos por objetos, los administradores pueden listar, editar, crear, ver y eliminar vehículos, los concesionarios listar, editar y ver y los propietarios solo listar y ver. Sin el uso de voters estos privilegios son generales y da igual si los vehículos pertenecen o no a un concesionario que los usuarios con ese rol los podrán editar todos al igual que un propietario podrá ver cualquier vehículo sin necesidad de que le pertenezca. Mantengo el rol de superusuario (ROLE_SUPER_ADMIN) que tendrá acceso a todo por encima de nuestra política de seguridad. Para añadir el uso de voters debemos realizar los siguientes cambios en los archivos de configuración: config/packages/security.yaml [crayon-6766b63eb1041513464140/]   Añadimos la estrategia «unanimous» al determinar el acceso o no, ya que nosotros vamos a definir unas políticas mediante voters pero aparte tenemos los Roles, al obligar a que la decisión sea unánime, todas las políticas deben permitir el acceso para que éste se conceda. Se pueden ver las diferentes estrategias disponibles en la documentación de Symfony. config/packages/sonata_admin.yaml [crayon-6766b63eb1044573261485/]   Definimos nuestro propio gestor de seguridad en la configuración de Sonata Admin, y vamos a implementarlo, creamos el archivo src/Security/Handler/VoterSecurityHandler.php con el siguiente contenido: [crayon-6766b63eb1047829172762/] Esta clase con ligeras variaciones la obtuve de este gran artículo (Usando Voters con Sonata) de Sergio Gómez, que explica e implementa el sistema de voters con Sonata en versiones de Symfony anteriores a la 4. Te recomiendo que consultes en artículo de Sergio para obtener más información del funcionamiento de la clase.   Damos de alta el servicio en config/services.yaml: [crayon-6766b63eb104a715771090/]   Ahora vamos a crear nuestro voter para el objeto vehículo que determinará quien puede hacer qué con él según los criterios que hemos establecido. Creamos el archivo src/Voter/VehiculoVoter.php con el siguiente contenido: [crayon-6766b63eb104c592410868/] Con el método «supports» nos aseguramos que el objeto se del tipo deseado (Vehículo) y que las acciones a comprobar sean las que tiene definidas dicho objeto. Luego con el método «votoOnAttribute» implementamos la lógica que queremos, en la línea 30 damos acceso completo a los usuarios que tienen los roles SUPER_ADMIN y/o ADMIN, de la 34 a la 39 comprobamos para aquellos usuarios con rol CONCESIONARIO que el vehículo en cuestión esté dado de alta en al menos uno de los concesionarios en los que están dados de alta los usuarios, y por último de la línea 41 a la 44 comprobamos que los usuarios con el rol PROPIETARIO además sean propietarios del vehículo. Un tema importante a tener en cuenta es que es recomendable ir de roles con más privilegios a menos, así aquellos usuarios que tengan varios roles por ejemplo un usuario que esté a la vez en el grupo de administradores y concesionarios, con la primera comprobación ya se le concede el acceso si lo hacemos al revés habría que pasar por varias comprobaciones. Ahora ya tenemos implementada la política de seguridad deseada, salvo un detalle, Sonata en los listados no aplica los voters y muestra todos los resultados, por ejemplo si accedemos con el usuario «propietario1» al listado de vehículos vemos los siguiente:   El usuario «propietario1» solo puede entrar en la ficha del vehículo del que es propietario tal y como hemos definido en el voter, pero sí puede ver el resto de vehículos aunque no sean suyos, para solventarlo debemos modificar la consulta encargada de generar el listado, modificamos la clase Admin de vehículo para Sonata: [crayon-6766b63eb104f653374280/]   Si volvemos a acceder al listado de vehículos con el usuario «propietario1», tenemos el listado que buscamos:   Este sería el listado

Más info

Campos personalizados en formularios de edición para Prestashop 1.7

Prestashop

En este artículo vamos a hablar sobre la creación de módulos en Prestashop 1.7 y más concretamente hablaremos sobre la creación de campos personalizados en formularios de edición. Cuando estamos creando módulos en Prestashop, la creación de formularios de edición es fundamental, ya que mediante esta edición podemos interactuar con los datos que guardamos: leerlos, actualizarlos… Para la creación de formularios de edición en Prestashop, necesitamos utilizar la clase HelperForm. Esta clase nos ofrece unos tipos de campos concretos: ‘text’, ‘select’, ‘textarea’, ‘radio’, ‘checkbox’, ‘file’, ‘shop’, ‘asso_shop’, ‘free’, ‘color’. Esta sería una declaración de campo básico, campo de texto, para un formulario de edición: [crayon-6766b63eb178d670795512/] Pero además de crear campos básicos, puede que necesitemos crear algún tipo de campo especial, que podamos personalizar, para que trabaje de una forma concreta… distinto a los que Prestashop nos ofrece por defecto. Esto se realizaría de la siguiente forma para módulos creados utilizando “Modelo – Vista – Controlador”. La estructura MVC se encarga de separar la lógica de negocio de la interfaz de usuario, para seguir esta estructura en la creación de módulos, tendremos que crear las siguientes carpetas dentro del módulo: mimodulo/models mimodulo/views/templates/admin/_configure/helpers/form mimodulo/controllers/admin El ejemplo que vamos a mostrar, crea un campo personalizado, que nos servirá para seleccionar artículos con un ‘autocomplete’ y retornarlos en el mismo campo personalizado, para posteriormente excluirlos en un proceso concreto. Sigue estos sencillos pasos: 1.- Dentro de la carpeta del controlador (mimodulo/controllers/admin/AdminAvanzaTestController.php), donde creamos el formulario de edición, introducimos el siguiente código: [crayon-6766b63eb1793332676516/] Este código nos crea un campo llamado AVANZA_TEST_PERSONALIZADO, el cual vamos a personalizar en el siguiente paso. 2.- Dentro de la carpeta de vista (mimodulo/views/templates/admin/_configure/helpers/form/form.tpl) introducimos el siguiente código, que será el que nos dé los datos a mostrar y la funcionalidad autocomplete del campo. [crayon-6766b63eb1796742375213/] 3º.- El tratamiento de estos datos se realizaría de nuevo en la carpeta del controlador (mimodulo/controllers/admin/AdminAvanzaTestController.php). Introducimos el siguiente código: [crayon-6766b63eb179a052463373/] De esta forma hemos conseguido crear un campo de una forma y características concretas… y de forma relativamente sencilla. Al igual que hemos creado este campo, podemos crear cualquier otro campo que necesitemos dándole las características y funcionamiento necesarios.

Más info

Contáctanos
966 27 81 05 info@avanzaeninternet.com
O si lo prefieres
Visítanos
C/ Gabriel Miró 45, 3º I 03420 Castalla (Alicante)
de lunes a jueves de 9:30 a 14:00 h. de 15:00 a 18:00 h.
viernes de 9:00 a 14:00 h.
Nuestras Redes Sociales