Plantilla para modelos (Modelos de Modelos)


#1

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!


#2

On Tue, Nov 11, 2008 at 12:16 PM, Juan José Vidal Agustín
removed_email_address@domain.invalid 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?


#3

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!


#4

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.


#5

On Tue, Nov 11, 2008 at 1:07 PM, Juan José Vidal Agustín
removed_email_address@domain.invalid 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.


#6

2008/11/11 Juan José Vidal Agustín removed_email_address@domain.invalid:

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.


#7

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


#8

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. removed_email_address@domain.invalid
escribió:


#9

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.


#10

2008/11/11 Juan José Vidal Agustín removed_email_address@domain.invalid:

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.


#11

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. removed_email_address@domain.invalid
escribió:> 2008/11/11 Juan José Vidal Agustín removed_email_address@domain.invalid:


#12

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ínremoved_email_address@domain.invalid
escribió:> Pero… esto no haría sino duplicar los datos, no?


#13

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


#14

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.


#15

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
removed_email_address@domain.invalid
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?