Mejora del Shopping Portlets

[Miguel Jiménez Gama, geändert vor 12 Jahren.]

Buenas a todos:

tras lanzar la pregunta en Twitter, Juan Fernández de Liferay (@juanferrub) me insta a abrir un hilo en el foro para definir o aportar funcionalidades deseadas para una actualización del Shopping portlet.

La idea es que este hilo sirva para sugerir o realizar una definición de requisitos deseables para el portlet de Compras que por defecto incluye Liferay para acercarlo, en la medida de lo posible, a las funcionalidades que hoy en día ofrecen herramientas exclusivas de e-commerce.

Entiendo, que dada la arquitectura de Liferay, se podría, por ejemplo, haciendo uso de Contenidos Webs, hacer que estos contenidos fueran artículos/productos, y haciendo uso de las Comunidades, se podría tener un entorno no sólo monotienda, sino multitienda. Entended este uso de Contenidos Webs, como entidades independientes pero con la misma idiosincracia, es decir, elementos con campos configurables, visibles, etc.

Espero, y @juanferrub también, aportaciones y puntos de vista.

[Juan Fernández, geändert vor 12 Jahren.]

A cuento de este hilo, he hecho una búsqueda rápida en JIRA y he encontrado tres tickets con propuestas de mejoras de la comunidad:
LPS-1079
LPS-4607
LPS-5648

Habría que tenerlas en cuenta, y cuando tengamos varias, crear una nueva página en la wiki de proposals para que quede constancia de los requisitos propuestos por la comunidad de cara al roadmap de las versiones futuras de Liferay.

[Jorge Ferrer, geändert vor 12 Jahren.]

Hola Miguel,

Gracias por abrir el hilo y a Juan por proponerlo.

La verdad es que este es un asunto que surge de forma recurrente, por lo que está claro que hay interés. Hasta la fecha en todos los proyectos de ecommerce con Liferay siempre he visto que se integraran productos a medida que o bien ya tenía el cliente o bien se integraban para la ocasión. De los productos OpenSource he visto en varias ocasiones integrar KonaKart.

Creo que sería interesante que Liferay incorporara bien de serie o bien como un plugin o conjunto de plugins más funcionalidades de comercio electrónico, pero también creo que debería aportar un valor añadido específico porque de lo contrario estaríamos reinventando la rueda. En particular, la idea que tengo en la cabeza es aprovechar la flexibilidad que ofrece la plataforma de Liferay para ser muy modular, de forma que sea posible construir tiendas completamente diferentes unas de otras a partir de una serie de componentes básicos. Eso aportaría un valor importante sobre los productos existentes que por lo que me comentan tienen en su flexibilidad el punto más débil.

Por supuesto el aprovechar las funcionalidades que ya tiene Liferay como los contenidos web encaja perfectamente con esta estrategia. Quizá haya que revisar también el actual portlet de shopping e identificar módulos que puedan extraerse para aportarle más modularidad y extensibilidad.

¿Qué os parece? ¿Alguien se anima a hacer este trabajo?

Jorge

[Juanjo Hernández Cánovas, geändert vor 12 Jahren.]

Hola,

Es un tema muy interesante y que para nuestra empresa sería un paso hacia delante. Por motivos obvios hemos recibido peticiones de clientes para desarrollar tiendas online. Nosotros somos profesionales java y tenemos mucha experiencia en Liferay, por lo tanto nos hubiera gustado poder ofrecer una solución basada en estas plataformas, pero finalmente hemos tenido que tender a plataformas php para dar salida a estos proyectos, con el fin de no incrementar demasiado el coste.

Por lo tanto me subo al carro y respaldo la propuesta,

Un saludo,

Juanjo.

[Juan Fernández, geändert vor 12 Jahren.]

Gracias por contestar, Juanjo:
ya que tienes experiencia montando tiendas online con otros productos, ¿podrías compartir tu conocimiento con la comunidad y decirnos los requisitos básicos que crees que nos faltan?
¿Cuáles son las funcionalidades básicas que debería tener Liferay (y sus portlets) para comenzar a competir en el mercado de las tiendas online con el mínimo esfuerzo de desarrollo posible para el usuario final?
¡Muchas gracias!
Un saludo

[Juanjo Hernández Cánovas, geändert vor 12 Jahren.]

Hola Juan,

A continuación dejo algunas propiedades y características que creo que debería incluir la hipotética extensión de Liferay para E-commerce:

Básicamente los módulos que habría que mejorar y/o "portletizar" serían:

- Carro de la Compra.
- Catálogo (Productos destacados, Impuestos, moneda)
- Registro de usuarios (aunque este tema se podría suplir modificando el sistema de usuarios propio de Liferay).
- Sistema de Categorización.
- Módulos de pago
- Sistema de cupones (descuentos, ofertas, etc...)

Caldria integrar todo ello y permitir acceder a estos módulos desde API o desde los contenidos mediante velocity.

Por supuesto se debería afrontar la perspectiva de crear un backoffice "unificado" para la tienda, que permita gestionar todos los parámetros de la tienda de manera individualizada y precisa.

A nivel de look & feel y experiencia del usuario considero que Liferay es más potente y flexible que la mayoría de plataformas de ecommerce.

Por supuesto invito a toda la comunidad a añadir o rebatir cualquier punto comentado en este post.


Muchas gracias,

Un saludo,

Juanjo.

[Juan Fernández, geändert vor 12 Jahren.]

¡Hola Juanjo!

Juanjo Hernández Cánovas:

Básicamente los módulos que habría que mejorar y/o "portletizar" serían:
- Carro de la Compra.

Ya tenemos el "Cart" como parte del portlet de Shopping. ¿De qué funcionalidad crees que carece?¿Cómo se podría mejorar el existente? De momento te permite ir navegando por el catálogo e ir añadiendo productos al carrito para luego hacer check-out

Juanjo Hernández Cánovas:

- Catálogo (Productos destacados, Impuestos, moneda)

Existe la posibilidad de gestionar un catálogo organizado y jerarquizado por categorías. Para cada producto se puede añadir esas tres cosas y algunas más: destacados, impuestos, moneda, gastos de envío...

Juanjo Hernández Cánovas:

- Registro de usuarios (aunque este tema se podría suplir modificando el sistema de usuarios propio de Liferay).

Ya cubierto con los usuarios de Liferay, no creo que hubiera que modificar nada aquí

Juanjo Hernández Cánovas:

- Sistema de Categorización.

Hecho

Juanjo Hernández Cánovas:

- Módulos de pago

Tenemos Paypal, Visa, MasterCard, American Express y Discover. ¿Cuáles más añadirías?

Juanjo Hernández Cánovas:

- Sistema de cupones (descuentos, ofertas, etc...)

Hecho, ¿qué cosas mejorarías?

Creo que como moraleja, se podría decir que ya en Liferay ya tenemos *mucho* hecho y que lo que queda es mejorarlo para que sirva como plataforma completamente profesional para la construcción de tiendas online

Este tipo de feedback es valiosísimo y me encantaría seguir escuchando vuestras propuestas.
Un saludo y gracias

[Jose Luis Monteagudo, geändert vor 12 Jahren.]

Hola Juan,

Comento algunas funcionalidades que creo que debería cubrir el software de e-commerce, aunque desconozco si éstas ya están implementadas en Liferay:

1) Categorías de cliente: De esta forma podríamos aplicar tarifas especiales o descuentos a los clientes que pertenezcan a una categoría determinada. Mediante esta funcionalidad podrías aplicar descuentos especiales a clientes que sabes que te van a garantizar un volumen de compra.

2) Gestión del envío del material: El envío del material normalmente tiene un coste asociado. Es necesario un módulo que permita definir los transportistas con los que trabaja la tienda, y establecer un coste del transporte en función de dónde se tenga que expedir el material, así como del peso de los distintos productos que se van a enviar.

3) Gestión de descuentos: Módulo que permite definir que un producto o un grupo de productos tienen un descuento especial. Este descuento, normalmente se puede definir su validez por un periodo de tiempo limitado. Por ejemplo, desde el 20 de Diciembre hasta el 31, los Kindle tienen un 15% de descuento.

4) Gestión del stock: Mediante esta funcionalidad sería posible informar al cliente si actualmente el producto está disponible en la tienda.

5) Gestión de la facturación: Permitir la creación de facturas y su posterior consulta.

6) Gestión del estado de los pedidos, para que el cliente pueda consultar en qué situación se encuentra actualmente su pedido.

7) Gestión de devolución de material.

8) Consultas y estadísticas.

Estas son algunas de las funcionalidades que se me ocurren sin profundizar mucho en el tema.

Saludos,

José Luis Monteagudo

[Juan Fernández, geändert vor 12 Jahren.]

Hola José Luis:
Te contesto sobre tu respuesta (¡super completa, por cierto! )

Jose Luis Monteagudo:

1) Categorías de cliente: De esta forma podríamos aplicar tarifas especiales o descuentos a los clientes que pertenezcan a una categoría determinada. Mediante esta funcionalidad podrías aplicar descuentos especiales a clientes que sabes que te van a garantizar un volumen de compra.

Interesante ¿Podrías entrar en más detalles al respecto?¿Cómo diferenciarías unos de otros? ¿Crees que se podría gestionar vía roles de Liferay? Es decir, cuando a un usuario le asignamos el rol "comprador VIP", puede ver ciertos productos que otros no ven (por ejemplo)

Jose Luis Monteagudo:

2) Gestión del envío del material: El envío del material normalmente tiene un coste asociado. Es necesario un módulo que permita definir los transportistas con los que trabaja la tienda, y establecer un coste del transporte en función de dónde se tenga que expedir el material, así como del peso de los distintos productos que se van a enviar.

Actualmente hay una sección de gestión de los gastos de envío, pero se calculan en base al precio del objeto vendido, no en base a su situación geográfica o peso. Muy interesante extensión/mejora para el portlet.

Jose Luis Monteagudo:

3) Gestión de descuentos: Módulo que permite definir que un producto o un grupo de productos tienen un descuento especial. Este descuento, normalmente se puede definir su validez por un periodo de tiempo limitado. Por ejemplo, desde el 20 de Diciembre hasta el 31, los Kindle tienen un 15% de descuento.

Ya está implementado tal y como lo planteas

Jose Luis Monteagudo:

4) Gestión del stock: Mediante esta funcionalidad sería posible informar al cliente si actualmente el producto está disponible en la tienda.

Ya está implementado

Jose Luis Monteagudo:

5) Gestión de la facturación: Permitir la creación de facturas y su posterior consulta.

Importantísimo y no cubierto por el momento. ¿Podrías entrar en más detalles?

Jose Luis Monteagudo:

6) Gestión del estado de los pedidos, para que el cliente pueda consultar en qué situación se encuentra actualmente su pedido.

Ya está implementado

Jose Luis Monteagudo:

7) Gestión de devolución de material.

Humm... ¿cómo sería esto? ¿Esto es algo que se gestiona habitualmente en tiendas online? No recuerdo haberlo visto hasta ahora... Interesante...
Genial tu aportación! Muchas gracias
Juan

[Jose Luis Monteagudo, geändert vor 12 Jahren.]

Hola Juan,

A mí me ha pasado lo mismo que Juanjo Hernández comentaba más arriba. Estoy especializado en Java pero para desarrollar tiendas online he tenido que recurrir a soluciones PHP, en mi caso concreto a Prestashop. Por este motivo, las características que te comento que creo que debería tener Liferay están basadas en mi experiencia con Prestashop.

Acerca de las categorías de cliente, para asignar un cliente a una categoría concreta es necesario hacerlo a través del back-office, y se trataría de una operación manual. Es el administrador de la tienda quién puede asignar de forma explícita clientes a categorías, y a cada una de estas categorías se le puede asignar un % de descuento determinado. Para decidir que un cliente pertenece a una categoría determinada, entiendo que previamente ha habido un contacto entre el propietario o comercial de la tienda y el cliente, que ambos han llegado a un acuerdo y que tras este acuerdo se decide que al cliente se le va a aplicar un descuento a los productos que compre.

Sobre la gestión de la facturación, entiendo que aquí caben dos posibilidades. Que la facturación se lleve mediante un software externo, un ERP por ejemplo; o que la facturación la lleve el propio Liferay. Bajo mi punto de vista, Liferay debería de dar la opción al administrador de la tienda de elegir cuál de las dos opciones quiere emplear. Hay empresas que no se basan en un negocio puramente online y que ya tienen soluciones de software para distintos módulos de gestión (facturación, por ejemplo). Estas empresas seguramente tendrán que seguir utilizando sus propios sistemas de software para emitir las facturas. En cambio, habrá empresas que sí sean puramente online, a las cuáles sí les resultará de utilidad que la propia tienda online genere las facturas y permita el envío de éstas vía email.

Sobre la gestión de devoluciones, creo que este módulo tiene sentido de cara a la obtención de estadísticas y para la elaboración de ciertas consultas. Es una gestión que la llevaría a cabo el administrador a través del back-office, no la llevaría a cabo el propio usuario. Si el sistema dispone de consultas que permiten ver, por ejemplo, los beneficios que la tienda ha proporcionado en un rango de fechas de determinado, tendrá que tener en cuenta las devoluciones que se han realizado. Quizá, al realizar una devolución y dependiendo de ciertos factores, el sistema también podría hacer un retorno de stock en el almacén.

Una funcionalidad muy importante que no sé si ya la incluye Liferay y que se me olvidó comentar en el anterior post, es la importación de los productos. Hay tiendas que tienen miles de productos, y hacer la carga de éstos manualmente sería muy costoso. Por ello, disponer de herramientas que faciliten la importación de los productos es una característica muy importante.

Saludos,

JL Monteagudo

[Daniel Gorroño, geändert vor 12 Jahren.]

Hola.

Llevo un tiempo desarrollando una solución de venta on-line para una pizzeria, basada en Liferay y más concretamente su portlet ShoppingCart:
www.masquepizzas.es

Aunque creo que falta mucho por hacer (sobre todo, personalizar el tema), pongo el enlace para que lo echéis un vistazo y me aportéis críticas y sugerencias.

Un saludo.
[e-mail]

[Juan Fernández, geändert vor 12 Jahren.]

Daniel Gorroño:

Llevo un tiempo desarrollando una solución de venta on-line para una pizzeria, basada en Liferay y más concretamente su portlet ShoppingCart

Hola Daniel! Interesante. ¿Podrías compartir con la comunidad tu experiencia?
¿Qué ha sido más útil, qué te gustaría mejorar?
Gracias por tu participación

[Daniel Gorroño, geändert vor 12 Jahren.]

Hola.

Pues la idea vino de intentar ayudar a un amigo comerciante que quería una forma de poder acceder a los datos de ventas de su tienda desde internet y, como llevo en paro unos meses, me presté a desarrollarlo.

En la tienda usan un programa de escritorio, hecho en VB, que les sirve para atender pedidos a través del teléfono. Este programa introduce los datos de los clientes (nº de tfno) y los pedidos en una BD Access. Lo que hago es monitorizar esta BD mediante un JAR ejecutable e ir enviando los nuevos registros, a través de servicios web, a la aplicación Liferay, de forma que esta aplicación pueda presentar en tiempo real las ventas que se hacen en la tienda, estadísticas, etc.

Esta sería básicamente la integración, amén de hacer una importación semiautomática de las categorías y productos que tienen en Access. Esta integración estaría suficientemente completa, pero también tendría que integrar los datos de un TPV que les sirve para las ventas en mostrador. Ahí, la dinámica sería la misma, pero no sé por qué razón el programita del TPV (Visual Basic) no escribe en la BD (MSSQL) los datos en tiempo real, es decir, puedo acceder a los datos de un día a los tres o cuatro días de haberse producido esas ventas. Aprovecho para que me aportéis ideas de por qué ocurre esto así.

En cuanto al portlet, tal como viene en LR tiene bastantes carencias. Sobre todo para poder ser aplicado en un negocio de estas características. Por ejemplo, las zonas de reparto han de ser cercanas a la tienda, con lo que he de restringir las direcciones que puedan aportar los posibles clientes, lo cual hago mediante combos dinámicos de municipios, calles y portales. El portlet "de serie" admite cualquier cosa a introducir en los campos del formulario de pedido. Otra cosa que no debería, a mi parecer, es tomar como válidos los datos de la cuenta del usuario y que éste pueda cambiarlos a su antojo. En fin, una serie de cosas que deberían cambiarse.

Saludos.
[e-mail]

[Miguel Pau, geändert vor 12 Jahren.]

Después de ver ayer el retweet de @juanferrub, por interés en el tema y por alusiones (LPS-5648) me uno a lo tratado en este hilo.

Todas las propuestas de ampliación del shopping portlet me parecen interesantísimas pero como dice Jorge, el objetivo no debería ser reinventar la rueda, si se desea disponer de una aplicación de ecommerce en Liferay debería ser para aprovechar características y funcionalidades incluidas en el portal (CMS, Permisos/Roles, Colaboración, Social, ..).

Desde mi punto de vista la aplicación debería cubrir unos mínimos ampliando el portlet con varias de las opciones que comenta Jose Luís (por ejemplo, el tema de portes por destino de envío y peso es muy importante) pero debería aportar más o algo diferencial respecto a otras herramienta que ya existan en el mercado.
A priori detecto estas fortalezas por parte de Liferay:

• Flexibilidad, aplicaciones incluidas por defecto (encuestas, blog, CMS avanzado, ..) , versión multi-idioma y opción multi-tienda aprovechando organizaciones/comunidades.
• Posibilidad de añadir campos a los perfiles de usuario (expando) que podrían aprovecharse para temas de facturación (CIF/NIF) o para hacer segmentación de tipos de clientes. Los campos deberían poder configurarse como obligatorios en el registro.
• Posibilidad de acompañar la tienda, además de con un sito web completo, con una red social vertical/comunidad de usuarios con intereses comunes que genere más información e implicación por parte de los clientes (generación de contenido por parte del usuario - UGC, comentarios, valoraciones, “recompensa” mediante social equity...)
• SSO con Facebook y otros sistemas.
• Integración/portlet con Jasper-iReport/Pentaho para montar informes para Business Intelligence (informes de ventas, previsión, estacionalidad de ventas, ...)
• Workflow para gestión de pedidos¿? (gestión del envío,facturación, postventa en función de roles)...

En resumen y para no extenderme más por ahora, esta parte de segmentación es la que veo con un potencial elevado aprovechando las características de social shopping que puede aportar Liferay.

Saludos!!

[Juan Fernández, geändert vor 12 Jahren.]

Hola José luis:
gracias de nuevo por tu detallada aportación

Jose Luis Monteagudo:

Acerca de las categorías de cliente, para asignar un cliente a una categoría concreta es necesario hacerlo a través del back-office, y se trataría de una operación manual. Es el administrador de la tienda quién puede asignar de forma explícita clientes a categorías, y a cada una de estas categorías se le puede asignar un % de descuento determinado. Para decidir que un cliente pertenece a una categoría determinada, entiendo que previamente ha habido un contacto entre el propietario o comercial de la tienda y el cliente, que ambos han llegado a un acuerdo y que tras este acuerdo se decide que al cliente se le va a aplicar un descuento a los productos que compre.

Entendido y aclarado. Sería una extensión fácilmente realizable sobre el portlet actual. Creo que la mejor forma de implementar esto es basándonos en el sistema de roles de usuarios.

Jose Luis Monteagudo:

Sobre la gestión de la facturación, entiendo que aquí caben dos posibilidades. Que la facturación se lleve mediante un software externo, un ERP por ejemplo; o que la facturación la lleve el propio Liferay. Bajo mi punto de vista, Liferay debería de dar la opción al administrador de la tienda de elegir cuál de las dos opciones quiere emplear. Hay empresas que no se basan en un negocio puramente online y que ya tienen soluciones de software para distintos módulos de gestión (facturación, por ejemplo). Estas empresas seguramente tendrán que seguir utilizando sus propios sistemas de software para emitir las facturas. En cambio, habrá empresas que sí sean puramente online, a las cuáles sí les resultará de utilidad que la propia tienda online genere las facturas y permita el envío de éstas vía email.

Es algo habitual en Liferay Portal el tener una funcionalidad básica y que si el cliente necesita algo más potente se integre con herramientas específicas, por lo que mientras que no tiene sentido implementar un ERP en Liferay desde cero (hay mil herramientas que ya hacen eso!), sí tendría sentido un mínimo módulo de facturación. ¿Qué pensáis que debería tener ese módulo básico? Una descripción detallada sería genial de cara a la futura implementación de esta funcionalidad.

Jose Luis Monteagudo:

Sobre la gestión de devoluciones, creo que este módulo tiene sentido de cara a la obtención de estadísticas y para la elaboración de ciertas consultas. Es una gestión que la llevaría a cabo el administrador a través del back-office, no la llevaría a cabo el propio usuario.

Anotado para la extensión del back-office

Jose Luis Monteagudo:

Una funcionalidad muy importante que no sé si ya la incluye Liferay y que se me olvidó comentar en el anterior post, es la importación de los productos. Hay tiendas que tienen miles de productos, y hacer la carga de éstos manualmente sería muy costoso. Por ello, disponer de herramientas que faciliten la importación de los productos es una característica muy importante.

¿Cómo se suele hacer esta carga de productos? Imagino que será un formulario de alta común ¿no?
¿Estás proponiendo la posibilidad de hacer una importación de productos desde otras tiendas a Liferay? ¿Hay formatos estándar para dicha acción?

Muchas gracias, José Luis

[Jose Luis Monteagudo, geändert vor 12 Jahren.]

Hola Juan,

Respecto al tema de la importación de productos, en Prestashop se hace mediante ficheros CSV. Prestashop permite la importación de categorías de productos, productos, clientes, fabricantes y proveedores (además de otros conceptos). Cada uno de estos conceptos tiene su propia estructura de datos. Por ejemplo, la estructura de las categorías de producto es la siguiente:

ID
Activo (0/1)
Nombre*
Categoría madre
Descripción
Meta-título
Meta-palabras clave
Meta-descripción
URL reescrita
imagen URL

Y la estructura de los productos es esta otra:

ID
Activo (0/1)
Nombre*
Categorías (x,y,z...)
Precio sin IVA o Precio IVA incluído
id regla de impuestos
Precio mayorista
En rebaja (0/1)
Importe del descuento
Porcentaje del descuento
Descuento desde (aaaa-mm-dd)
Descuento hasta (aaaa-mm-dd)
Referencia nº 
N° de referencia proveedor 
Proveedor
Fabricante
EAN13
UPC
Ecotasa
Peso
Cantidad
Descripción breve
Descripción
Etiquetas (x,y,z...)
Meta-título
Meta-palabras clave
Meta-descripción
URL reescrita
Texto cuando haya disponible
Texto si se permiten pedidos en espera
URL's de las imágenes (x,y,z...)
Características
Exclusividad Internet

Prestashop tiene una funcionalidad en el back-office que permite subir los ficheros CSV's al servidor, y otra funcionalidad para indicar qué CSV se quiere importar a la tienda.

Saludos,

JL Monteagudo

[Juan Fernández, geändert vor 12 Jahren.]

¡Hola equipo!

Voy a hacer un pequeño resumen de lo que se ha hablado en este hilo.
De esta forma propongo que se cree un post equivalente en inglés para que los anglo-parlantes también puedan dar sus ideas y luego crear una página en la wiki de proposals.
Liferay Social Shopping... ¡suena bien!

Lista de ideas de mejora:

[indent]- Integrar los productos con el sistema de assets - tendríamos etiquetado, categorización, posibilidad de interrelaciones, comentarios, social equity, puntuación de productos, campos personalizados...
- Integrar con el sistema de workflow para el proceso de compra
- Separar el portlet en diversos módulos para facilitar la gestión y evolución
- Mejora del cálculo de gastos de envío en base a ubicación geográfica y peso del producto
- Gestión de facturación: implementación de un ERP básico, más sistema de integración para ERPs externos.
- Gestión de devolución de material (como parte de la gestión de stock)
- Importación/exportación de productos desde otros sistemas
- Integración con herramientas de informes y estadísticas para la explotación de la información (Jasper-iReport/Pentaho...)
- Facilitar añadir nuevas pasarelas de pago
[/indent]

Si se me olvida algo, comentadlo
¡Un saludo!

[Actualización] Ya he publicado la página en la wiki de propuestas con todas las ideas que habéis aportado, más las de los del foro en inglés. -> http://www.liferay.com/es/community/wiki/-/wiki/Proposals/Liferay+as+an+e-commerce+platform

[Miguel Pau, geändert vor 12 Jahren.]

Hola Juan!
Acabo de ver el wiki gracias a una alerta de google, no se porqué no me llegó el aviso de tu último post a pesar de estar suscrito.

Iba a añadir un par de cosas que vi durante el congreso al que asistí el mes pasado.
- He visto esto en el wiki :"those who have bought this product also bought this" . Si hablamos de social commerce o mejor, de Liferay Social Shopping me gusta mucho la idea de "AMIGOS que compraron esto compraron esto otro" o "Alguno/s de tus AMIGOS compraron este producto".
- Junto al botón "add to cart" podría aparecer un "Ask your friends" para comparar por ejemplo entre 2 productos o para solicitar opinión de un producto
- Posibilidad de añadir comentarios a cada producto (ya está en el wiki)
- Links sociales por producto (masunos, megustas y retuitses)

si quieres que lo añada al wiki dímelo!

saludos!!

[Asier Del Pozo, geändert vor 12 Jahren.]

Buenas!!!

Interesante la opción de integrarlo con la opción de "Amigos", pero ¿cómo considerarías la privacidad de la compra? Un usuario puede no querer mostrar nada de información que le pueda relacionar con un amigo o similar; es diferente estadísticas de compra, como por ejemplo "25 usuarios compraron tal artículo", a "un amigo tuyo compró tal artículo"... si sólo tienes un amigo en el site .

Sinceramente, lo que más le he echado de menos a este portlet (como a otros) es la internacionalización de contenidos. En mi opinión, la posibilidad de integrar la opción de compra con la gestión de contenidos de Liferay solucionaría la mayoría de los problemas.

Saludos
Asier

[Sergio Romero Zayas, geändert vor 12 Jahren.]

Asier Del Pozo:

Buenas!!!

Interesante la opción de integrarlo con la opción de "Amigos", pero ¿cómo considerarías la privacidad de la compra? Un usuario puede no querer mostrar nada de información que le pueda relacionar con un amigo o similar; es diferente estadísticas de compra, como por ejemplo "25 usuarios compraron tal artículo", a "un amigo tuyo compró tal artículo"... si sólo tienes un amigo en el site .

Sinceramente, lo que más le he echado de menos a este portlet (como a otros) es la internacionalización de contenidos. En mi opinión, la posibilidad de integrar la opción de compra con la gestión de contenidos de Liferay solucionaría la mayoría de los problemas.

Saludos
Asier

Esto como todo es solucionable, al igual que en las redes sociales, más temprano que tarde, Liferay deberá implementar una nueva forma de gestionar la privacidad de los usuarios, mejorando y ampliando el área personal de cada usuario, pudiendo cada usuario indicar que niveles de privacidad decide tener, gestionar niveles de privacidad por amigos, etc.

Por ejemplo persona "A" tiene un único amigo "B", si el amigo "A" pulsara en "ask your friends" y el amigo "B" tuviera configurado su usuario a un nivel de privacidad que no quisiera aparecer en "ask your friends" pues al amigo "A" le aparecería que ningún amigo ha comprado ese artículo, aunque el amigo "B" lo haya comprado.

Sé que el tema de la privacidad se sale un poco del tema que estamos tratando, pero me ha parecido genial tu asunto para poder exponer esto a la comunidad, ya que llevo bastante tiempo con la idea rondando la cabeza, y los proyectos que se están realizando ahora relacionados con Social tienen esta carencia.

[Asier Del Pozo, geändert vor 12 Jahren.]

¡Buenas!

Sergio Romero Zayas:

Esto como todo es solucionable, al igual que en las redes sociales, más temprano que tarde, Liferay deberá implementar una nueva forma de gestionar la privacidad de los usuarios, mejorando y ampliando el área personal de cada usuario, pudiendo cada usuario indicar que niveles de privacidad decide tener, gestionar niveles de privacidad por amigos, etc.

Por ejemplo persona "A" tiene un único amigo "B", si el amigo "A" pulsara en "ask your friends" y el amigo "B" tuviera configurado su usuario a un nivel de privacidad que no quisiera aparecer en "ask your friends" pues al amigo "A" le aparecería que ningún amigo ha comprado ese artículo, aunque el amigo "B" lo haya comprado.

Sé que el tema de la privacidad se sale un poco del tema que estamos tratando, pero me ha parecido genial tu asunto para poder exponer esto a la comunidad, ya que llevo bastante tiempo con la idea rondando la cabeza, y los proyectos que se están realizando ahora relacionados con Social tienen esta carencia.

¡¡¡Interesante!!! Sobre todo para el portlet de actividades :-). Igual es que soy un poco excéptico, pero para compras no lo acabo de ver... debería ser una funcionalidad muy simple, sencilla de entender y de usar, para que un usuario al comprar un regalo para un amigo (por ejemplo) sea capaz de cambiar el nivel de "publicidad" para esa compra y que fuera privada.

Miguel Pau:

Otras plataformas ofrecen la opción de controlar la privacidad, un "Compartir tu actividad con amigos" S/NO podría ser suficiente, y si no TERMINOS DE USO AL CANTO! XD

Jejeje, menos mal que tenemos los términos de uso de respaldo Lo de compartir "si/no" podría cuadrar, ¿quizás un mix?: una configuración que pudiera seleccionar si quiero compartir siempre, sólo en algunos casos (con selección de "comparte tu compra" o similar) o nunca. Podría cuadrar :-).

¡¡¡Pero no nos desviemos!!! ¿Qué opinais de integrar los portlets de compra / catálogo con el gestor de contenidos de Liferay (y aprovecho catalogación, etiquetado, internacionalización, relación entre contenidos, publicación, etc. que me da la herramienta)? Una opción sobre el contenido / tipo de contenido que me permita gestionarlo como comprable, y me aparezca la opción de comprar en el publicador de contenidos o en el visor de contenido web...

¡Saludos!
Asier

[Juan Fernández, geändert vor 12 Jahren.]

¡Buenas! Perdonad la respuesta tardía (estaba de vacas...)
Me parece interesante lo de los amigos y entiendo las cuestiones que planteáis. Creo que la solución es mostrar toda la información relacionada con un producto. Algo así como "24 usuarios y 7 amigos han comprado este producto - ver comentarios" o algo así. Esto sería la fusión de ambas informaciones y lo mejor para los usuarios.
Respecto a la privacidad, lo veo tan fácil como un checkbox en el formulario de compra que diga "¿desea que sus amigos vean que ha comprado este producto?", marcado a true por defecto y listo
¿qué os parece?

Respecto al tema de las traducciones y extras de los assets que plantea Asier, simplemente integrando en el framework de assets (como expliqué en este post) nos daría toda esa funcionalidad.

Que un asset sea "comprable" o no, podría ser una extensión del asset renderer con su default a false...interesante.

En fin, me alegro de veros tan hiperactivos por aquí
¡Un saludo!
Juan

[Miguel Arenal, geändert vor 12 Jahren.]

Buenas a tod@s,
he estado leyendo este post, y creo que sería interesante empezar a concretar si realmente se quiere hacer algo. Desde mi humilde opinión creo que se podría empezar por fijar un equipo para este proyecto, y desde aquí ofrezco mi colaboración.

En cuanto a experiencia nosotros hemos desarrollado un programa de venta en tiempo real en java + PostgreSQL, aunque no completamente integrado con Liferay, quien sabe, quizás sea el momento.

para que os hagais una idea os resumo de manera sucinta:
Entidades:
Productor, Proveedor, Canal de Distribución, Usuario(liferay), Comunidad (Liferay) y Agente:

* Productor --> (1,n) Proveedores.
Es decir un Productor comercializa sus Items con 1 o n Proveedores, ciones con esa Comunidad
* Proveedor --> (1,n) Comunidades.
Es decir cuando se pide el Producto de un Proveedor, en la búsqueda, solamente aparecera el producto de los Proveedores relaciones con esa Comunidad
* Canal de Distribución ---> (1,n) Comunidades.
Desde un Portal(Comunidad) se realizan Reservas on line, aparecerán solamente los Canales de Distribución asignados a esa Comunidad,
*Agente
(Contact o Call Center) persona que efectua la reserva on-line solamente. Estos están asociados a una Comunidad.
* Usuario Liferay--> (1,n) Comunidades
Lo que ya conocemos todos

Un fuerte abrazo a tod@s y adelante

[Alvaro del Castillo, geändert vor 12 Jahren.]

Pues justo en Ándago andamos evaluando el shooping cart para adoptarlo ya dentro de nuestras soluciones, así que nos viene en un buen momento para participar en este desarrollo. Parece que necesitamos un empujón final para ponernos con las manos a la masa. ¿Qué estrategia de desarrollo proponéis? ¿Trabajar directamente dentro del portlet de Liferay? ¿Intentar hacerlo en el plugin de entorno de extensión? He hecho algún intento de sacarlo a un plugin portlet independiente pero depende de demasiadas cosas del núcleo de Liferay como para que sea viable (es así en 5.2.3 y en 6.0.6 me ha dado la misma sensación).

Es una pena que los portlets de Liferay no estén como plugins!

[Sergio Romero Zayas, geändert vor 12 Jahren.]

Alvaro, yo también veo que es una pena que lo portlets de Liferay no sean plugins, pero, también es entendible. Se busca vender un producto, y por este motivo esta todo integrado en un mismo paquete. De este modo crean mayor dependencia, aunque siempre puedes "hookear" y adaptarlo a tu antojo, aunque evidentemente, con muchas limitaciones.

[Juan Fernández, geändert vor 12 Jahren.]

Hola Álvaro:
me alegro de que te subas al carro y de que queráis contribuir.

Creo que sería un movimiento muy importante extraer este portlet del núcleo y sacarlo como plugin para la siguiente versión (para la 6.1 ya es imposible, por que estamos cerrando la versión), y me gustaría proponerlo internamente, pero aún así no es una condición indispensable para desarrollar las mejoras.

Se me ocurre que podemos crear una rama de evolución en GitHub donde podremos ir realizando cambios y mejoras, de forma que cuando tengamos cambios y mejoras probadas y seguras, podamos fusionar con trunk y contribuir dichos cambios al core de Liferay.

Esta forma de trabajar tiene sus pros y contras:

pros: los cambios irían directos al núcleo y todos nuestros cambios irían directos a la siguiente versión de Liferay para disfrute de todos los usuarios globales de Liferay. La forma de trabajar sería muy cómoda: cada uno de los miembros del grupo de trabajo desarrollaría mejoras y haría pull requests (o envíos de parches) a un ingeniero core de Liferay, que tras revisarlo lo manda al core. No necesitaríamos trabajar en plugins, sino directamente sobre trunk.

contras: esto estaría disponible para la siguiente versión (6.2 ?), no para la actual (6.1). Si lo quisiéramos para la actual, tendríamos que hacerlo vía hooks y ext, pero sería mucho más trabajo y no sería tan fácil de contribuir, ya que a posteriori habría que reescribir los cambios para integrarlos en trunk... cosa que al final no se haría por ¿pereza/montaña de trabajo? y el esfuerzo habría sido en vano. Si se decidiera trabajar de esta forma (mediante un conjunto de hooks/ext) se podría liberar en formato plugin de la comunidad (lo que estaría bien), pero no se sacaría provecho de que Liferay (Inc) lo mantuviera como parte del producto en versiones futuras y su mantenimiento recaería en manos de los que lo desarrollemos.

En fin, muchas ideas y opciones. Espero vuestras opiniones, ¡yo ya he expuesto la mía!
Un saludo

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola Juan,

Si me pongo con el gorro de Ándago, lo que nos interesa es tener el shopping portlet como un plugin tan pronto como sea posible en 6.0.x, que es la versión que tenemos en producción. Eso nos daría total libertad para irlo adaptando a nuestras necesidades desde ya.

Si me pongo con el gorro de promotor de Liferay, creo que en el largo plazo, como comentas tu también, el objetivo debería ser el mismo: tenerlo como un plugin. Aunque entiendo que esto no es sencillo hacerlo *bien* y además, sería bueno que entrara en una estrategia común de llevar los portlets del core no indispensables a plugins. Habría que confirmar si Liferay quiere seguir esta estrategia y ver que prioridad le podría dar.

Si todo fuera bien, tanto el interés de Andago (y seguro que el resto de empresas) como el de Liferay, confluirían en el mismo resultado. Pero sería en 6.2 o 6.3, dentro de varios meses. Para Andago el comercio electrónico cada vez tiene más peso, así que ese objetivo final lo apoyaríamos en cualquier caso (tendría aún que conseguir apoyo interno, pero entiendo que se lograría).

¿Pero qué hacer por ahora? Trabajar dentro del trunk de Liferay, coordinados por ejemplo con github como propones, es trabajar para un resultado que se verá dentro de meses. Para nosotros es lo mismo que tenerlo en 6.2/6.3.

¿Cómo podríamos tener antes cubiertas las necesidades? Aún nos queda por estudiar a fondo lo que ofrece el portlet actual, y si nos podemos apañar con su estado actual. Si fuera así, pues apostaríamos por el escenario a medio/largo plazo. Si necesitáramos ya cubrir ciertos requisitos, pues tendríamos que estudiar irnos a trabajar en entorno de extensión y/o hooks y/o realizar un nuevo intento de convertir en plugin el portlet.

Juan, ¿podrías ir pulsando la opinión de Liferay sobre pasar el portlet a un plugin?

Siento no poder cerrar más los posibles escenarios aún.

Hasta luego!

[Juanjo Hernández Cánovas, geändert vor 12 Jahren.]

Hola a todos,

Me uno a este movimiento en pro del ecommerce sobre Liferay.

Aunque nuestra empresa basa casi todos sus desarrollos en Liferay, cuando hemos tenido que poner en marcha proyectos de comercio electrónco hemos optado por soluciones más maduras (nos gusta mucho Joomla+Virtuemart, pero también hemos usado Magento), pero sin lugar a duda lo que sería perfecto para nosotros es poderlo desarrollar íntegramente en Liferay y Java en lo que tenemos mucha más experiencia.

Por mi parte me ofrezco a colaborar en lo que mis conocimientos y mi tiempo me permitan.

Un saludo,

Juanjo.

[Sergio Romero Zayas, geändert vor 12 Jahren.]

Juanjo Hernández Cánovas:

Hola a todos,

Me uno a este movimiento en pro del ecommerce sobre Liferay.

Aunque nuestra empresa basa casi todos sus desarrollos en Liferay, cuando hemos tenido que poner en marcha proyectos de comercio electrónco hemos optado por soluciones más maduras (nos gusta mucho Joomla+Virtuemart, pero también hemos usado Magento), pero sin lugar a duda lo que sería perfecto para nosotros es poderlo desarrollar íntegramente en Liferay y Java en lo que tenemos mucha más experiencia.

Por mi parte me ofrezco a colaborar en lo que mis conocimientos y mi tiempo me permitan.

Un saludo,

Juanjo.

Cito a Juanjo, me uno a vosotros. En mi tiempo libre intentaré aportar mis conocimientos en Liferay para aportar mi granito de arena. Me gustaría "enfangarme" asumiendo tareas de desarrollo, siempre dentro de mi tiempo libre, en pro de que nos beneficiemos todos.

A Alvaro le diría que si tiene poco tiempo para incluir una solución a su proyecto para la 6.0.x, no tiene más remedio que realizar un hook o extender el ext y "enfangarse". Lo ideal sería plugin, y he de decir que me ha sorprendido la postura de Juan, puesto que a mi entender (gracias Dios estaba equivocado) Liferay no era partidario de convertir plugings sus portlets incluidos en su producto. La verdad que sería lo ideal y no lo solo para Shopping, sino para otras muchas funcionalidades, que haría mucho más reutilizable y adaptable a las necesidades que tienen los clientes, a los que vendemos como solución Liferay.

ánimo a todos a unirse por la causa

[Miguel Pau, geändert vor 12 Jahren.]

Siguiendo con las posibilidades del social commerce con Liferay...

Acabo de ver el funcionamiento del "Recent Activity" de esta sección y gracias a Juan Fernández he dado con este artículo del blog que se me había pasado.

Lo que sí que conocía es esta página de Book Depository dónde muestran de forma similar las compras que van realizando los usuarios.

Lo dejo en el hilo como posible funcionalidad a tener en cuenta.

Por mi parte también haré por aportar (UX, aspectos SEO, testing..)
Seguimos!!

Saludos!

[Juan Fernández, geändert vor 12 Jahren.]

Bueno, pues para dejar de "hablar" y empezar a hacer cosas, y aprovechando que este asunto parece tener bastante tirón: ¿qué os parece si nos ponemos en marcha?

Ahora mismo trunk está hiperactivo preparándose para la release de la 6.1, por lo que lo ideal es que nos hagamos una rama en github para este proyecto.

Mi propuesta para los primeros pasos a dar es:

1. Crear en github un proyecto nuevo para un plugin separado de trunk
2. Separar de trunk el portlet y convertirlo en plugin (para ello sólo hay que copiar el service.xml y regenerar los servicios, copiar todos los jsps, copiar las clases XXXLocalServiceImpl y XXServiceImpl y luego convertir las acciones struts en métodos de un portlet MVC)

A partir de ahí tendríamos el portlet como plugin separado y ya podríamos empezar a implementar nuevas funcionalidades libremente. Creo que de esta forma será mucho más fácil evolucionar y que la gente colabore en su desarrollo.

¿Quién se anima a comenzar a dar pasos? Yo me encargaré de ayudar y guiar en el desarrollo de esta iniciativa de la comunidad
Un saludo,
Juan

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola!

Juan Fernández:

Bueno, pues para dejar de "hablar" y empezar a hacer cosas, y aprovechando que este asunto parece tener bastante tirón: ¿qué os parece si nos ponemos en marcha?

Ahora mismo trunk está hiperactivo preparándose para la release de la 6.1, por lo que lo ideal es que nos hagamos una rama en github para este proyecto.

Estupendo. ¿Partimos de la versión "trunk" del portlet o mejor de la 6.0.6 que estará más estable y probada? Entiendo que lo más útil para el futuro será que esté el plugin para 6.1, pero lo mismo está ahora mismo el portlet en mitad de cambios y es mejor partir de 6.0.6. ¿Opiniones? En cuanto cerremos esto creo en github el proyecto.

Juan Fernández:

Mi propuesta para los primeros pasos a dar es:

1. Crear en github un proyecto nuevo para un plugin separado de trunk
2. Separar de trunk el portlet y convertirlo en plugin (para ello sólo hay que copiar el service.xml y regenerar los servicios, copiar todos los jsps, copiar las clases XXXLocalServiceImpl y XXServiceImpl y luego convertir las acciones struts en métodos de un portlet MVC)

El paso 2 es el que veo que será más trabajoso. Juan, ¿con dar esta conversión crees que se eliminarán gran parte de las dependencias con el "core" de Liferay? ¿Algún ejemplo que podamos ir viendo para ir allanando el camino?

Juan Fernández:

A partir de ahí tendríamos el portlet como plugin separado y ya podríamos empezar a implementar nuevas funcionalidades libremente. Creo que de esta forma será mucho más fácil evolucionar y que la gente colabore en su desarrollo.

¿Quién se anima a comenzar a dar pasos? Yo me encargaré de ayudar y guiar en el desarrollo de esta iniciativa de la comunidad
Un saludo,
Juan

Pues hale, yo me animo a dar estos primeros pasos. ¿Partimos del trunk o de 6.0.6?

Hasta ahora!!!

[Juan Fernández, geändert vor 12 Jahren.]

Hola Álvaro:
me alegro de que te animes a comenzar este proyecto

Este portlet no ha sido modificado en la última versión apenas, así que no hay problemas de compatibilidades hacia atrás. Lo más inteligente aquí es desarrollar sobre la versión de trunk: será lo mejor de cara a futuro.

Respecto a las dependencias con el core, tal vez haya que extraer algún método a una clase de utilidad, pero va a ser poco trabajo: por lo general podemos hacer llamadas a los servicios externos de Liferay.

Ahora estoy de vacaciones, pero en cuanto vuelva me subo al carro y os echo un cable en lo que pueda.
Un saludo,
Juan Fernández

[Alvaro del Castillo, geändert vor 12 Jahren.]

Tengo idea de ir subiendo ahora a GitHub el esqueleto del portlet de shopping convertido en un plugin basado en service builder, el primer paso claro del proceso. Partimos entonces de la versión Liferay 6.1, tanto para la extracción de service.xml y de los JSPs, como para el entorno de creación de plugins.

Hale, ya le tenéis en: https://github.com/acs/shopping-plugin-portlet

El siguiente paso es copiar todos los JSPs y comenzar a ir transformando la capa de servicios y de persistencia para convertirla de struts al modelo MVC. Iremos avanzando en ello y consultando las dudas por aquí. A ver hasta donde llegamos.

Hasta luego

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola!

Hemos ido avanzado y ya está muy avanzada la migración a plugin del portlet. Aún queda por completar la migración de la lógica de struts a MVC pero el camino parece ya despejado.

Espero mañana poder invertir tiempo suficiente como para dar por cerrado este primer paso.

He utilizado el espacio de nombres: "com.liferay.shopping". Ya vemos luego si cambiarlo.

Estoy pensando en presentar la experiencia de migración en el próximo evento de Liferay. ¿Qué os parece? Comenzaríamos con un portlet al lado del otro para mostrar que todo funciona igual y luego ya contar las ventajas de tenerlo como plugin y los desarrollos que se plantean.

¿Alguien más va a ir al próximo Symposium de Liferay?

Bueno, a descansar que están siendo días intensos. Lo tenéis todo ya en:

https://github.com/acs/shopping-plugin-portlet

Hasta luego

[Alvaro del Castillo, geändert vor 12 Jahren.]

Bueno, en el plugin ya está funcionando toda la gestión de categorías. La de items y de pedidos entiendo que va a ser sencillo. Las pasarelas de pago quizá introduzcan algo más de complejidad. Pero vamos, no preveo problemas.

He enviado una propuesta al final para el Symposium de Liferay:

* Tipo de Sesión: Demo
* Título: De Portlet del Núcleo a Portlet Plugin: Shopping
* Resumen:

Liferay incluye dentro de su distribución de portal diversos portlets
que permiten añadir funcionalidades al portal de forma sencilla. En
muchas ocasiones estas funcionalidades están muy cercanas a lo que
necesitamos, pero requieren de adaptaciones y extensiones. ¿Cómo
realizarlas? El portal Liferay nos proporciona mecanismos como el
entorno de extensión, que implica un tipo de desarrollo menos ágil, o
los hooks, que no siempre nos dejan modificar o extender lo que
necesitamos. ¿Cómo se podrían modificar los portlets que incluye
Liferay?

En esta demo se presentará como migrar el portlet Shopping de Liferay
desde el portal a un plugin, describiendo el proceso de extracción del
modelado de servicio, su implementación y la conversión del modelo de
portlet basado en struts del portal, al nuevo modelo de portlet MVC más
ligero.

Es un esfuerzo que se ha realizado dentro de una iniciativa de la
comunidad de Liferay para mejorar las capacidades de Liferay de comercio
electrónico y es previsible que permita un desarrollo en comunidad sobre
este plugin. Detalles dentro de los foros en:

http://www.liferay.com/es/community/forums/-/message_boards/message/8943653


Para acabar se planteará la pregunta, ¿deberían de ser todos los
portlets de Liferay plugins? Ventajas e inconvenientes.


* Tema de la Ponencia: Metodología de Desarrollo, Desarrollo
rápido de aplicaciones, Promover el crecimiento en Comunidad
* Información sobre el Ponente:
* Nombre completo: Alvaro del Castillo San Félix
* Empresa o Particular: Empresa Andago
* Número de Teléfono: XXXXXXXX
* Biografía:

Álvaro del Castillo participa en el mundo del software libre desde la
aparición de las primeras distribuciones de Linux donde tuvo sus
primeras experiencias con el núcleo Linux en la escuela de
Telecomunicación de la UPM donde se licenció. Desde entonces su vida
laboral ha estado muy ligada al software libre donde ha participado en
proyectos como la fundación de Barrapunto.com, GNOME Hispano o Mono
Hispano. Ha participado en proyectos como la primera versión de LinEx o
Compatiblelinux.org, participando como desarrollador en GNOME en Planner
y F-Spot. Participó también como ingeniero de Liferay en el desarrollo
del portal y su implantación en clientes. Actualmente es Open Source
Manager en Ándago.

A ver si interesa y podemos presentar este trabajo. Y ya de paso, los que vayáis al symposium, podemos tener una reunión de hacking entorno al plugin.

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola!

Acabo de crear una nueva rama para tener una versión del plugin para la versión LR 6.0.6. Ahora mismo el estado de funcionalidad de ambas ramas es similar. Esta semana es previsible que trabajemos más en la versión de 6.0.6 que en la de 6.1 aunque espero que se pueda compartir trabajo entre ambas versiones y por eso las he puesto dentro del mismo repositorio.

Hasta luego!

[Alvaro del Castillo, geändert vor 12 Jahren.]

Pequeña actualización del estado: en ambas ramas ya se puede ir hasta realizar ordenes de pedido. Lo siguiente que voy a mirar es el tema de configuración del portlet para poder configurar Paypal y comprobar esta funcionalidad, y para estudiar el añadir Google Checkout como método de pago. Hay que darle un repaso general a todo pero no veo ya ningún obstáculo relevante en lo que queda de camino.

Cuando esté el portlet por completo acabado (beta) creo que podemos pasar la actividad a la página del Wiki en inglés sobre nuevas funcionalidades e ir viendo si hay ya fuerzas para comenzar a implementar de todas las cosas de las que se ha hablado.

Hasta luego!

[Alvaro del Castillo, geändert vor 12 Jahren.]

Acabo ya de dejar funcionando tanto en 6.0.6 como en 6.1 todo el proceso incluyendo el pago por Paypal (no lo he probado aún en real pero debería de funcionar). Está siendo divertido alguno de los cambios que ha habido que hacer.

En el estado actual, sólo queda un repaso general de todo, volver a introducir código de control de errores (excepciones) en algún punto y estaremos ya en un buen punto de partida. A ver si comienza a volver actividad por aquí

[Alvaro del Castillo, geändert vor 12 Jahren.]

Vamos a terminar de retomar el pulido final del plugin y tras ello, vamos a añadir soporte para Google Checkout. A continuación tenemos en mente mirar otras pasarelas de pago como 4b. ¿Alguien tiene experiencias en pasarelas de pago y su complejidad de integración?

Un ejemplo de 4b: https://github.com/schmittjoh/jmsPaymentPlugin/pull/7#issuecomment-2408227

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola!

Sólo añadir que ya hemos añadido la implementación de Google Checkout. De momento está en la rama 6.0.6 pero la subiré también a 6.1 en cuanto quede estabilizada del todo. Hemos dejado como ejemplo los identificadores de la cuenta de pruebas de Andago de Google Checkout pero esta parte habría que modificarla. Vamos a ver si la sacamos a un property para hacerlo más sencillo. Seguiremos informado!

[Juan Fernández, geändert vor 12 Jahren.]

¡Genial, Álvaro!
A ver si alguno de los que han aportado tantas ideas se suma al carro y al menos lo prueba para reportar bugs.
¿Por qué no lo publicas en el foro inglés y globalizas el portlet (cuando estabilices las dos versiones)? Seguro que a nivel mundial aparece gente dispuesta a ayudar.
Ya nos dirás
Un saludo,
Juan

[Juan Fernández, geändert vor 12 Jahren.]

Ey Álvaro, no consigo clonar el portlet para la 6.1
¿Estoy haciendo algo mal o no lo has publicado todavía?
¡Un saludo y gracias!
Juan

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola Juan,

Están metidas las dos versiones en ramas diferentes. Ojo, que aún no he subido de 6.0.6 a 6.1.x los últimos cambios de pagos con Google Checkout.

Probemos:

acs@lenovix:/tmp$ git clone https://github.com/acs/shopping-plugin-portlet.git
acs@lenovix:/tmp$ cd shopping-plugin-portlet/
acs@lenovix:/tmp/shopping-plugin-portlet$ git branch
* 6.0.6
acs@lenovix:/tmp/shopping-plugin-portlet$ git co master
acs@lenovix:/tmp/shopping-plugin-portlet$ git branch
  6.0.6
* master

Esta rama "master" es donde está el desarrollo para 6.1.x.

[Juanjo Hernández Cánovas, geändert vor 12 Jahren.]

Hola Álvaro,

He estado un tiempo muy ocupado, pero ahora me gustaría retomar este tema. Cómo lo llevais? Ha habido alguna novedad desde la última actualización del foro? Habéis marcado un road map?

Muchas gracias,

Un saludo,

Juanjo.

[Juan Fernández, geändert vor 12 Jahren.]

Hola Juanjo:
no sé mucho del estado del proyecto, pero mirando su repositorio github, tienen unas cuantas tareas abiertas
Échale un ojo a ver cómo van: https://github.com/acs/shopping-plugin-portlet
Un saludo y mantennos informados!
Juan Fernández

[Luis Antonio Rodríguez González, geändert vor 11 Jahren.]

Buenos días,

otra mejora que veo necesaria, no se si ya lo permite el portlet, es poder definir una Cantidad en Stock ilimitada, sin necesidad de tener que introducir un número muy grande. Esto es útil cuando lo que vendes son servicios y no productos en Stock.

Saludos

Luis

[Jesús Pérez, geändert vor 11 Jahren.]

Gracias a todos por la información que se aporta en este foro y a ti en especial Juan quien ha tenido la iniciativa. Una vez instalado, para la moneda Euro tengo problemas para que grabe correctamente el precio, es decir al poner 4,95 se guarda como 495. No entiendo bien que esta pasando.

Por otro lado, me gustaría saber si es posible que el portlet haga uso de los estilos de la plantilla que uso en el portal de forma automática, como hacen otros portlets.

Atentamente,
Jpe Franco (@jpefranco)

[Alvaro del Castillo, geändert vor 12 Jahren.]

Hola!

Para que quede registrado, otra opción posible es dejar la implementación struts tal cual y luego implementar el plugin como un portlet struts no? ¿Qué ventajas/incoveinentes le veis?

Hasta luego

[Jorge Ferrer, geändert vor 12 Jahren.]

El problema de mantener el uso de StrutsPortlet es que para que funcione debe instalarse el plugin en el classloader del portal. Esto puede hacerse fácilmente en tomcat pero quizá no en otros servidores de aplicaciones. Adiconalmente quita la flexibilidad de poder añadir librerías diferentes a las que tiene el portal.

Teniendo eso en cuenta, mi recomendación sería que lo convirtierais en un MvcPortlet.

[Alvaro del Castillo, geändert vor 12 Jahren.]

Jorge Ferrer:

El problema de mantener el uso de StrutsPortlet es que para que funcione debe instalarse el plugin en el classloader del portal. Esto puede hacerse fácilmente en tomcat pero quizá no en otros servidores de aplicaciones. Adicionalmente quita la flexibilidad de poder añadir librerías diferentes a las que tiene el portal.

Nosotros hemos probado en LR6.0.6 con JBoss 5.1 y el ejemplo de Struts de los plugins funciona sin modificar JBoss más allá de lo que ya viene modificado en el bundle. Lo mismo ahí ya está modificado para permitir que este plugin se cargue con el class loader de Liferay.

Entiendo que te refieres Jorge a la clase "org.apache.portals.bridges.struts.StrutsPortlet", que proviene de "portals-bridges.jar". Viendo que en el plugin se declaran dependencias con ciertas librerías en el servidor en "liferay-plugin-package.properties", veo que todas estas librerías luego se copian dentro del "war" del plugin, por lo que diría que quizá el plugin tenga su propio class loader que carga de forma duplicada clases que están ya en el class loader del servidor, pero que evita que plugin tenga que instalarse en el classloader del portal.

Si esto fuera así, el problema con el StrutsPortlet es la duplicidad de un montón de librerías (18 librerías, 5 M, que haría que todos estos plugins sean mucho más pesados.

Comparando en la migración que hay hecha hasta ahora al modelo MVC, tenemos 10 librerías del portal que ocupan 1.8 MB.

Si fuera correcto esto que estoy diciendo, la decisión entre MVCPortlet o StrutsPortlet vendría de que MVC parece más ligero en tamaño ocupado y en uso de librerías, y seguro que en rendimiento también será más ligero. Aunque la verdad, convertir los portlets Struts de Liferay a plugin Struts es bastante más directo

Teniendo eso en cuenta, mi recomendación sería que lo convirtierais en un MvcPortlet.

[Alvaro del Castillo, geändert vor 12 Jahren.]

Me respondo a mi mismo. El ejemplo de Struts del que hablaba era: "sample-struts-portlet". Este ejemplo funciona sin necesidad de utilizar el portal de Liferay ya que no usa la implementación específica de Liferay de Struts. Pero este ejemplo da problemas si intentas reutilizar dentro de plugins portlets del portal de Liferay, ya que estos portlets usan el struts modificado de Liferay. El ejemplo "sample-struts-liferay-portlet" sí que usa el struts de Liferay, como indica su nombre, y sólo funciona si comparte el class loader del portal liferay.

Así que este hecho refuerza lo que comentaba Jorge y apunta hacía una conversión a MVC como lo más aconsejable. El dar visibilidad del class loader del portal en general es una idea que en entornos en producción, con varios productos integrados, no es muy viable por posibles colisiones entre librerías. Según el servidor de aplicaciones, se podría lograr que sólo determinados plugins vieran el classloader del portal, pero es una solución muy "ad-hoc" y que podría servir para proyectos concretos, pero no como una solución general.

Así que como resumen, parece que habrá que hacer el esfuerzo de pasar a MVC como ya estábamos haciendo. Seguimos en ello.

[Miguel Pau, geändert vor 12 Jahren.]

Hola Asier!
Estamos dando un paso más allá del ecommerce tradicional (que raro me suena esto, jeje), es social commerce con lo que deben asumirse este tipo de funcionalidades.
Otras plataformas ofrecen la opción de controlar la privacidad, un "Compartir tu actividad con amigos" S/NO podría ser suficiente, y si no TERMINOS DE USO AL CANTO! XD

Un saludo

[Sergio Romero Zayas, geändert vor 12 Jahren.]

Pongo mi granito de arena.

Creo que no vendría nada mal un área de estadisticas, mensuales, trimestrales, semestrales y anuales. PTI, portlet de tratamiento de la información.

¿Se ha pensado solo como posibilidad de uso de venta en la red?

En caso de no sea de uso exclusivo para venta online.

¿Se ha pensado que pueda usarse directamente desde la tienda para venta no-online? Una tienda tendrá un stock y deberá replicarse con el stock de la tienda y de las ventas de la tienda (no online) con las ventas online. Es una posibilidad en cuanto a poder comercializar esta idea.

[Juan Fernández, geändert vor 12 Jahren.]

Hola Sergio:
¡gracias por tu aportación!
El portlet tiene gestión de stock (posibilidad de definir la cantidad que tienes en almacén de cada objeto a comprar), pero no tiene lo que comentas de un área de gestión de las ventas. En la sección de pedidos puedes realizar búsquedas por distintos criterios, pero no puedes ver informes detallados de las ventas. Sería bastante interesante este punto en concreto.

De hecho creo que es tan interesante que debería aplicarse a muchas partes del portal, no sólo a ventas. Sería genial tener una sección de cuadro de mandos con posibilidad de generar informes numéricos o gráficos de las actividades de los usuarios del portal y su evolución temporal. Hay muchas herramientas Open Source en Java que podríamos integrar para este tipo de funcionalidades de generación de informes... interesante idea para el futuro de Liferay.

Muchas gracias por tu contribución,
Un saludo!

[Sergio Romero Zayas, geändert vor 12 Jahren.]

Juan Fernández:

Hola Sergio:
¡gracias por tu aportación!
El portlet tiene gestión de stock (posibilidad de definir la cantidad que tienes en almacén de cada objeto a comprar), pero no tiene lo que comentas de un área de gestión de las ventas. En la sección de pedidos puedes realizar búsquedas por distintos criterios, pero no puedes ver informes detallados de las ventas. Sería bastante interesante este punto en concreto.

De hecho creo que es tan interesante que debería aplicarse a muchas partes del portal, no sólo a ventas. Sería genial tener una sección de cuadro de mandos con posibilidad de generar informes numéricos o gráficos de las actividades de los usuarios del portal y su evolución temporal. Hay muchas herramientas Open Source en Java que podríamos integrar para este tipo de funcionalidades de generación de informes... interesante idea para el futuro de Liferay.

Muchas gracias por tu contribución,
Un saludo!

Mira solución que ya use en algún que otro proyecto.
http://teethgrinder.co.uk/open-flash-chart/

Amigo que Español nos habla de esta solución y sus bonanzas, aunque yo usé esto mucho antes de este árticulo, viene muy bien leerlo para tener una idea de su uso actual
http://www.sopadebits.com/open-flash-chart-graficos-estadisticos-open-source

seguiré mirando y te pasaré idea e información.