Ir al contenido principal

Ubercart, atributos o CCK ?

El uso de atributos y clases para categorizar los productos de la tienda puede resolver en muchas situaciones y está muy bien pensado. Pero como no todo es perfecto acabo de chocar con una de esas situaciones que parece ser la excepción de la regla y donde he tenido que sacrificar los atributos de Ubercart por los conocidos y siempre bienvenidos campos de CCK.
La idea inicial era facilitar al vendedor que subiera un solo producto, con su modelo y precio básico, y que luego los clientes pudieran seleccionar los atributos requeridos. La cuestión se complicó porque los cinco (5) atributos asociados a la clase de producto X están muy poblados. Cuando intenté crear los números SKU únicos para cada combinación posible el servidor de la base  colapsó y es que no me había percatado de que las posibles combinaciones ascendían a más de 10 millones!!
Evidentemente no hay forma humana de controlar esto, y además no resulta una solución real, puesto que evidentemente, el proveedor nunca tendrá en stock las 10 millones de opciones posibles de ese producto. En este caso, es más conveniente usar los campos de CCK dentro del tipo de contenido del producto X y que el proveedor suba al sitio los productos que tiene. Dejar solamente para los atributos quizás un solo campo, me imagino que el que más varíe, pienso por ejemplo, en el siempre recurrido ejemplo de las camisetas, dejar el atributo color o talla, y eso reduciría muchísimo las posibles combinaciones.
Concluyo, hasta que me demuestre lo contrario, que en el caso de que los atributos sean muy numerosos, es mejor usar CCK. La comparación la estoy estableciendo entre la cantidad de combinaciones posibles que puedan generar el uso de los atributos, que obligaría al vendedor a contabilizar el stock de esa cantidad, y por otra parte la cantidad de productos que el vendedor tuviese que ingresar al sitio en caso de que usara CCK.
Poniendo un ejemplo hipotetico, si se venden camisetas con 3 tallas y 3 colores posibles, se usarían los atributos de UC y tenemos 9 combinaciones. Así que el vendedor sube solamente 1 producto y actualiza el stock de 9 SKU posibles. Por otro lado suponiendo que un producto, por ejemplo zapatos, tengamos 12 posibles tallas y 15 colores posibles, eso nos generaría 180 (12x15) combinaciones. si además por ejemplo, dieramos la opción de que ese modelo tenga cordones o no, se duplicaría a 360!!! No creo que nadie que tenga una tienda de zapatos tenga las 360 variantes de un modelo de una marca en específico!! Si acaso tendrá quizás 5 tallas de 2 colores cada una y entonces seria más conveniente usar fields de CCK y que el vendedor entre 10 productos diferentes. La otra opción sería dejar para los atributos uno de los campos, por ejemplo, los colores y que el vendedor entre solamente un producto por cada talla.
Por supuesto, es sólo mi teoría... cualquier otra opinión o experiencia será bienvenida.



Publicar un comentario

Entradas populares de este blog

Drupal Commerce - producto con varios precios

Montando un marketplace con Drupal Commerce, apareció un caso de uso donde el cliente quería agregar a cada producto un precio de envío diferente. Por tanto no valía una Flate Rate u alguna solución clásica de 'shipping', así que pensé que Rules y encontré esta simple solución de Josh Miller:
La idea es agregar un campo 'envío' tipo 'price' al tipo de producto en cuestión, y luego con rules, sumar al precio del producto, el precio del envío.
Crear una nueva regla de cálculo de precio. Ir a admin/commerce/config/product-pricing/rules/add y darle un nombreAgregamos una primera condición "Entity has field" a la entidad "commerce-line-item" y seleccione el campo "commerce_product". Con este paso se carga el producto para la siguiente inspección.Segunda condición, cargamos el campo con el precio: "Entity has field" a la entidad "commerce-line-item:commerce-product" y seleccionamos el campo creado previamente en el ti…

Actualizar Ruby con RVM en OS X 10.9 Maverick

Cocoapods me pide una versión de Ruby mayor que 2.0, pero Maverick viene por defecto con 1.9.3 así que tiré de rvm pensando que serían un par de líneas pero no, he pasado un buen rato en el proceso. Hagamos el cuento corto:

$rvm list known

y no aparece ninguna versión 2 o superior, así que:
$rvm get latest

y ahora con:
$rvm list known

tenemos:
# MRI Rubies [ruby-]1.8.6[-p420] [ruby-]1.8.7[-head] # security released on head [ruby-]1.9.1[-p431] [ruby-]1.9.2[-p330] [ruby-]1.9.3[-p551] [ruby-]2.0.0[-p643] [ruby-]2.1.4 [ruby-]2.1[.5] [ruby-]2.2[.1] [ruby-]2.2-head
ruby-head
ahora si,
$rvm install 2.2.1
pero
Error running 'requirements_osx_brew_libs_install automake libtool libksba', showing last 15 lines of /Users/hedmon/.rvm/log/1428514809_ruby-2.2.1/package_install_automake_libtool_libksba.log
Las dependencias estaban instaladas pero no linkeadas, así que vamos a resolverlo con Homebrew.
$brew update $brew upgrade $brew link automake libtool libksba
ahora vuelvo a intentar $rvm install 2.2.1

Entonces …