Forum: Rails-ES Plantilla para modelos (Modelos de Modelos)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Juan José Vidal Agustín (Guest)
on 2008-11-11 13:17
(Received via mailing list)
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!
Xavier N. (Guest)
on 2008-11-11 13:25
(Received via mailing list)
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?
Juan José Vidal Agustín (Guest)
on 2008-11-11 13:41
(Received via mailing list)
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!
Xavier N. (Guest)
on 2008-11-11 13:55
(Received via mailing list)
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.
Juan José Vidal Agustín (Guest)
on 2008-11-11 14:08
(Received via mailing list)
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.
Xavier N. (Guest)
on 2008-11-11 15:11
(Received via mailing list)
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.
Emili P. (Guest)
on 2008-11-11 15:22
(Received via mailing list)
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ó:
Guillermo Álvarez Fernández (Guest)
on 2008-11-11 16:39
(Received via mailing list)
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
Juan José Vidal Agustín (Guest)
on 2008-11-11 16:58
(Received via mailing list)
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.
Andrés G. (Guest)
on 2008-11-11 17:23
(Received via mailing list)
>>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<removed_email_address@domain.invalid>
escribió:> Pero... esto no haría sino duplicar los datos, no?
Xavier N. (Guest)
on 2008-11-11 17:23
(Received via mailing list)
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.
Andrés G. (Guest)
on 2008-11-11 17:26
(Received via mailing list)
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>:
Guillermo Álvarez Fernández (Guest)
on 2008-11-11 17:42
(Received via mailing list)
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
Andrés G. (Guest)
on 2008-11-11 17:45
(Received via mailing list)
>>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?
Guillermo Álvarez Fernández (Guest)
on 2008-11-11 19:17
(Received via mailing list)
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.
This topic is locked and can not be replied to.