Hola,
Tengo que hacer un sistema de ofertas, y necesito que al crear una
oferta, nos muestre un desplegable con las plantillas para crear esa
oferta. Al seleccionar el select nos rellenará los campos del
formulario.
Mi problema no es rellenar los campos del formulario, sino sobre las
plantillas.
Cómo modelo las plantillas de ofertas?
- La opción más trivial que se me ocurre es meter un booleano en el
modelo de oferta que nos pregunte si es una plantilla o no.
El problema de esto, es que me rompe la numeración de las ofertas,
y no termina mucho de gustarme.
Qué otras formas se os ocurren para hacer un sistema de
“plantillas”???
Un saludo y gracias por adelantado!
On Tue, Nov 11, 2008 at 12:16 PM, Juan José Vidal AgustÃn
[email protected] wrote:
Tengo que hacer un sistema de ofertas, y necesito que al crear una
oferta, nos muestre un desplegable con las plantillas para crear esa
oferta. Al seleccionar el select nos rellenará los campos del
formulario.
Mi problema no es rellenar los campos del formulario, sino sobre las
plantillas.
Cómo modelo las plantillas de ofertas?
Las plantillas difieren solo en el aspecto, o tienen campos distintos?
Tienen los mismos campos.
No es cuestión de aspecto, simplemente tienen datos, y al crear una
oferta, si se selecciona una plantilla le copiaremos todos esos datos
a la nueva oferta.
Quizá la palabra “plantilla” no es la más adecuada… modelo de
modelo? molde?
No quiero hacerlo con acts_as_tree como si de un hijo de tratase, pues
no tiene sentido que sea un hijo.
Imaginad que tenemos 3 tipos de ofertas modelo (OM) según nuestros
clientes:
- OM1 cliente plata (:descuento => 10 …)
- OM2 cliente bronce (:descuento => 30 …)
- OM3 cliente oro (:descuento => 50 …)
Cuando yo creo una nueva “Oferta Real (OR)”, seleccionaré OM1, OM2 o
OM3, y en el formulario me rellenará el descuento correspondiente, en
el campo descuento del new.html.erb de oferta.
En realidad quiero que sea un poco más complicado, pero eso ya lo
puedo hacer yo. Mi idea es que al crear un nuevo proyecto,
seleccionaré varios modelos de Ofertas Modelo (OM), y automáticamente
se crearán varias Ofertas Reales (OR) asociadas a ese proyecto, a
imagen y semejanza de sus Ofertas Modelo.
Un saludo!
El 11/11/2008, a las 12:54, Xavier N.
escribió:
El problema que le veo a esto, como dices, es que no puedo hacerlos
dinámicos dichas colecciones de defaults.
On Tue, Nov 11, 2008 at 1:07 PM, Juan José Vidal AgustÃn
[email protected] wrote:
El problema que le veo a esto, como dices, es que no puedo hacerlos
dinámicos dichas colecciones de defaults.
Entonces el siguiente paso es un fichero de configuracion, y si ha de
ser dinamico del todo entonces irias a un modelo AR y los idiomas que
ponia al final del mail.
2008/11/11 Juan José Vidal AgustÃn [email protected]:
Imaginad que tenemos 3 tipos de ofertas modelo (OM) según nuestros
clientes:
- OM1 cliente plata (:descuento => 10 …)
- OM2 cliente bronce (:descuento => 30 …)
- OM3 cliente oro (:descuento => 50 …)
Una aproximacion sencilla que has de ver si te cuadra, pero es por
donde empezaria, es tener sencillamente colecciones de defaults:
DEFAULTS = {
‘billionaire’ => {
:amount => 10**8
}}
class Offer < AR::Base
self.new_with_defaults(name)
new(PLANTILLAS[name])
end
end
Si esos conjuntos de defaults fueran configurables no serviria… etc.
depende. Pero pensar en defaults en lugar de en meta-modelos quiza
pueda ser mas sencillo.
En realidad quiero que sea un poco más complicado, pero eso ya lo
puedo hacer yo. Mi idea es que al crear un nuevo proyecto,
seleccionaré varios modelos de Ofertas Modelo (OM), y automáticamente
se crearán varias Ofertas Reales (OR) asociadas a ese proyecto, a
imagen y semejanza de sus Ofertas Modelo.
Si tuvieras ofertas ya creadas como “modelos” entonces son facilmente
copiables con #clone, o con Offer.new(offer_defaults.attributes),
modulo attr_protected etc.
Por lo que has contado, yo tiraría por algo más parecido a esto.
Un modelo de oferta y otro de plantilla de oferta con los mismos campos
class Offer < AR
end
class OfferTemplate < AR
end
cuando se realice una nueva oferta (offers/new) aparece sin ninguna
planilla. En la misma pantalla hay un selector de ofertas, que
onchange hace submit de ese valor.
class OffersController < ApplicationController
def new
@offer = Offer.new( OfferTemplate.find_by_id(params[offer_template])
end
Ahora mismo desconozco si AR mapearía los valores. De no hacerlo
deberías de implementar initialize de Offer
def Offer.initialize(object)
return super unless object.kind_of? OfferTemplate
self.descuento = object.descuento
…
self.offer_template = object.id # por si queremos guardar la
referencia de através de que plantilla se ha realizado
end
Si necesitas hacerlo muy configurable puedes crear un modelo AR para las
plantillas y las asocias a las ofertas, de esta manera no necesitarás
guardar los datos de la plantilla en el modelo oferta, los tienes
siempre
disponibles con la asociación, Si quieres copiarlos le metes un callback
(before_create) y le copias los datos cuando lo creas.
El 11 de noviembre de 2008 14:05, Xavier N. [email protected]
escribió:
Pero… esto no haría sino duplicar los datos, no?
El 11/11/2008, a las 15:39, Guillermo Álvarez Fernández
escribió:
Por lo que has contado, yo tiraría por algo más parecido a esto.
2008/11/11 Juan José Vidal AgustÃn [email protected]:
def new
@offer = Offer.new( OfferTemplate.find_by_id(params[offer_template])
end
Eso lo pondria en el modelo, con el idioma que apunte antes:
def self.new_from_offer_template(offer_template)
new(offer_template.attributes)
end
Pero… esto no harÃa sino duplicar los datos, no?
Has de asignar los valores por defectos a los atributos reales.
Las columnas puede que esten por duplicado o no, pero conceptualmente
es un duplicado que a priori tiene sentido.
Las columnas puede que esten por duplicado o no, pero conceptualmente
es un duplicado que a priori tiene sentido.
Yo no sabía explicarlo, pero me suena bien, no crees?
El día 11 de noviembre de 2008 16:23, Xavier N. [email protected]
escribió:> 2008/11/11 Juan José Vidal Agustín [email protected]:
Pero… esto no haría sino duplicar los datos, no?
¿por qué duplicas datos?
El día 11 de noviembre de 2008 15:57, Juan José Vidal
Agustín[email protected]
escribió:> Pero… esto no haría sino duplicar los datos, no?
El 11/11/2008, a las 15:57, Juan José Vidal
Agustín escribió:> Pero… esto no haría sino duplicar los datos, no?
Y menos mal que lo duplicas.
Si en un futuro modificas las plantillas de oferta, las ofertas reales
se modificarían. Si mal no he entendido, es lo que quieres.
El 11/11/2008, a las 16:23, Xavier N.
escribió:> Eso lo pondria en el modelo, con el idioma que apunte antes:
def self.new_from_offer_template(offer_template)
new(offer_template.attributes)
end
¡ Coño no me acordaba del attributes !
–
Firmas personalizadas en oferta.
Personaliza tu firma.
http://cientifico.net
El 11/11/2008, a las 16:44, Andrés gutiérrez
escribió:>>> Si en un futuro modificas las plantillas de oferta, las ofertas
reales
se modificarían.
¿Esto haciendolo como decis xavier y tu? ¿por qué?
Perdón me he explicado mal.
Cuando el 11/11/2008, a las 15:57, Juan José Vidal
Agustín escribió:> Pero… esto no haría sino duplicar los datos, no?
Solo quería confirmar la necesidad de duplicar los datos. Si una
oferta se deja con datos en blanco, haciendo referencia a la
plantilla, una modificación de plantilla supodría el cambio de todas
las ofertas que hacen referencia a esa plantilla.
El coste de riesgo de que se cambien todas las ofertas de golpe es
mucho superior al coste de duplicar los datos.
Eso si no he entendido mal lo que Juan José quiere.
Si en un futuro modificas las plantillas de oferta, las ofertas reales
se modificarían.
¿Esto haciendolo como decis xavier y tu? ¿por
qué?
El día 11 de noviembre de 2008 16:41, Guillermo Álvarez Fernández
[email protected]
escribió:> El 11/11/2008, a las 15:57, Juan José Vidal Agustín escribió:
Pero… esto no haría sino duplicar los datos, no?