Preview de contenido

[Miguel_Angel_Callej]

Hola,
Necesito hacer un preview de contenido, estoy en una aplicación lo más
parecida a una web de grupo de trabajo donde hay perfiles de usuarios,
un administrador que adjudica acciones a usuarios, tales como cambiar un
texto, una imagen, todo el contenido de una página, etc, lo que sea, el
usuario recibe la notificación de la acción, efectúa el cambio y se
envía el preview de la página al administrador donde éste debe
validarlo, si se valida el preview se sube a producción y si no, se
vuelve a adjudicar la acción al usuario.
Para hacer el preview a bote pronto había pensado en crearme campos
extra en el modelo, tales como titulo_preview, cuerpo_preview,
imagen_preview, … algo
así:
titulo
titulo_preview
cuerpo
cuerpo_preview
imagen
imagen_preview

, entonces cuando se visualiza el preview de la página se cargan esos
campos, y si se valida esos datos se graban a sus campos de
producción.
Puedo hacerlo a mi manera pero no se si en ror hay algo parecido hecho,
algún plugin que haga preview y quede almacenado en la base de datos
para luego poder tratarlo. Muchas gracias

[Miguel_Angel_Callej]

Hola,

Necesito hacer un preview de contenido, estoy en una aplicación lo más
Para hacer el preview a bote pronto había pensado en crearme campos
extra en el modelo, tales como titulo_preview, cuerpo_preview,
imagen_preview, … algo así:

Así sin saber más de la aplicación ni de las implicaciones a nivel de FK
que pudiera haber potencialmente, puede que sea más recomendable añadir
un único campo a tu tabla que se llame preview o status o incluso
version. De esa forma sólo tienes un campo extra por registro, en lugar
de tener un montón. Además, si usas la opción de version tienes incluso
un histórico por el mismo precio.

Cuando vayas a hacer una preview simplemente duplicas la fila afectada
con el valor del flag en cuestión. Si se rechaza, puedes borrar la fila
o trabajar directamente sobre la preview mientras el resto de gente
sigue viendo la versión estable.

Si te decides por la opción de version, juraría que hay un plugin que se
llama acts_as_versionable o algo parecido.

suerte,

javier ramírez

[Miguel_Angel_Callej]

On 07/11/2007, Miguel Angel Calleja Lázaro [email protected] wrote:

Puedo hacerlo a mi manera pero no se si en ror hay algo parecido hecho,
algún plugin que haga preview y quede almacenado en la base de datos
para luego poder tratarlo. Muchas gracias

La forma de hacerlo es simplemente manejando diferentes estados del
objeto, mediante un campo ‘status’ o similar. Normalmente suele haber
al menos dos valores de status: ‘borrador’ para permitir que la
creación o edición de un objeto se haga en varias veces y ‘publicado’
para objetos que ya pueden y deben visualizarse en
producción.
Según tus necesidades, puedes aprovechar ‘borrador’ o, más elegante,
usar un estado ‘pre-validación’ que sólo el administrador puede
convertir en ‘publicado’.

–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o http://simplelogica.net/logicola/
Recuerda comer mucha fruta y verdura.

[Miguel_Angel_Callej]

On 07/11/2007, Miguel Angel Calleja Lázaro [email protected] wrote:

javier ramirez escribió:

Si, voy a optar mucho mejor por el status, muchas gracias por el consejo
a los dos, obviamente no puedo duplicar la fila si mi primary key del
modelo es id, claves duplicadas, tendría que crear dos claves para
duplicar la fila, id y status por ejemplo, pero no se si en ror se puede
crear una migración con dos primary_key, sería crearme el modelo con dos
índices, valdría con ésto?

Me he dado cuenta de que Javier sí contestaba exactamente a lo que
necesitabas, pero yo no (típico por mi parte) Lo que yo te decía era
para el caso de que lo sujeto a aprobación fuese el objeto tal cual,
no las ediciones.

Cómo resolvimos el problema de las revisiones en un proyecto fue de la
siguiente forma:

Modelo Post
id
title
body
created_at
status

Sacamos todos los campos editables del modelo a otro, hijo del
primero. En este ejemplo, los campos “editables” (title y body) a un
modelo PostData, belonging_to Post

Modelo Post
id
created_at
status

Modelo PostData
id
post_id
title
body
status

Post has_many PostData
PostData belongs_to Post

De esta forma, cuando el usuario edita un Post, lo único que hace es
crear un nuevo PostData (de forma transparente para él). El
administrador puede revisar entonces los PostData con estatus
“pendiente de revisión” y pasarlo a “aprobado” si corresponde.

Al Post puedes ponerle también un has_one CurrentPostData, que es el
PostData más reciente con estatus “aprobado”. Así, al visualizar
pasarías de utilizar “post.title” a “post.currentPostData.title”

Es un patrón mejorable, pero es sencillo de implementar y funciona sin
problemas. Espero haberlo explicado bien

–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o http://simplelogica.net/logicola/
Recuerda comer mucha fruta y verdura.

[Miguel_Angel_Callej]

javier ramirez
escribió:

Así sin saber más de la aplicación ni de las implicaciones a nivel de FK

Si, voy a optar mucho mejor por el status, muchas gracias por el consejo
a los dos, obviamente no puedo duplicar la fila si mi primary key del
modelo es id, claves duplicadas, tendría que crear dos claves para
duplicar la fila, id y status por ejemplo, pero no se si en ror se puede
crear una migración con dos primary_key, sería crearme el modelo con dos
índices, valdría con ésto?