Es DRY distinguir entre backend y frontend?

Hola

Pongo como ejemplo un modelo noticias… la index (maquetación o
diseño) que ven los usuarios no tiene por que ser igual a la index
que ve el administrador de las noticias ¿no? debido a que por ejemplo
al administrador no le hace falta ver todo el texto de las noticas o
por que este dispone de mas opciones (borrar, no publicar, etc) que
los demás usuarios no tienen.

Entonces esto me lleva a pensar que tengo que duplicar las vistas y
controladores, una index para los usuarios y una index para el
administrador y lo mismo con el controlador noticias, uno para los
usuarios y otro para el administrador.

Pero claro, esta manera me parece que es poco DRY.

Para evitar repetir vistas y controladores estaba probando con aislar
los contenidos mediante content_for y según el tipo de usuario
mostrar una cosa u otra, pero esto me da unas vistas bastante
grandes… con lo cual me parece que tampoco es el camino correcto.

Cual es su opinión al respecto? distinguen claramente la parte de
manejo de contenido (backend) de la parte visual (frontend)
tratandolos de forma independiente o mediante if y partial lo ponen
todo en la misma vista?

Gracias por las opiniones.
Un saludo.

Hola, lo que podrias hacer es utilizar parciales con los botones de
administrador, o los contenidos especiales para el administrador.
y luego le pones como condicion al render :partial que si esta logueado
lo
muestre, si no, no lo muestra. algo asi:

if logged
render :partial ‘botones_admin’
end

espero que eso sirva.

Saludos

Piensa en el caching … tu aplicación se podrà “cachear” con facilidad?

Yo siempre distingo entre frontend i backend. De hecho he desarrollado
un plugin que genera el admin automaticamente, como el de Django, i
así yo no tengo que preocuparme más del tema.

Supongo que lo liberaré en unas semanas.

Un saludo,

Francesc

On Dec 13, 2007, at 7:26 PM, alarkspur wrote:

controladores, una index para los usuarios y una index para el
Cual es su opinión al respecto? distinguen claramente la parte de


Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es


name. Francesc E. i Martí
voice. +34 678.681.603

On Dec 13, 2007, at 7:26 PM, alarkspur wrote:

Pongo como ejemplo un modelo noticias… la index (maquetación o
diseño) que ven los usuarios no tiene por que ser igual a la index
que ve el administrador de las noticias ¿no? debido a que por ejemplo
al administrador no le hace falta ver todo el texto de las noticas o
por que este dispone de mas opciones (borrar, no publicar, etc) que
los demás usuarios no tienen.

Depende un poco del backoffice.

En algunos proyectos, si tiene sentido, nosotros proponemos que no
haya backoffice. Justo por el problema que explicas. Supon un web site
donde un usuario tiene su pagina de datos, y supon que los usuarios se
pueden bloquear. El admin puede navegar por todas partes, y al ir a
esa pagina de cada usuario simplemente le aparece un boton “Bloquear”.
Judo! Hemos reaprovechado al maximo todo el codigo. Si quiere editar
una entrada de blog la interfaz de edicion ya esta construida, asi que
solo tiene que navegar a ella, y por ser admin puede editar lo que
quiera, no hace falta un backoffice para editar el blog!

Claro que a veces es insuficiente, o simplemente el cliente quiere un
backoffice “separado”. A veces se hace un backoffice funcional y
espartano a base de ajax/active scaffolds mas o menos maqueados.

Si la interfaz esta sofisticada ya hay que ver segun el caso como
reaprovechar codigo.

– fxn

+1 para no usar backend si no es necesario… Si se trata de editar
los mismos datos del front, podemos hacer aparecer los controles
necesarios en caso de ser admins, un poco como en los foros phpBB…
si eres admin o moderador, aparte de todo lo que ven los usuarios de a
pie, tienes también botones para modificar o eliminar posts.

Siempre hará falta un backend para otros tipos de datos que los
usuarios no pueden gestionar, o para gestionar los propios usuarios.

Jaime

2007/12/13, Xavier N. [email protected]:

puedes aplicarle una ruta diferente cuando estás como admin
con los nuevos :namespaces de Rails2
para q además de que seas admin darle al usuario algo más de
información de donde está
incluso puedes cambiar el color de fondo de la página con otro css un
poco distinto para modo admin

así no duplicas controladores,
ahora bien

si hay mucha lógica para el admin igual si que es interesante pasarlo
a una carpeta admin
todo, ya que eso no lo vas a cachear

un saludete,
marze

El 13/12/2007, a las 22:59, Jaime I. escribió:

Yo creo firmemente que las decisiones relacionadas con el interfaz de la
aplicación conviene tomarlas únicamente pensando en el usuario,
centrándose en hacerle la aplicación lo más amigable y fácil de usar
posible. A veces será mejor separar el área de administración y en otras
será mejor integrarlo con las vistas del usuario de a pie: depende de la
aplicación y del usuario que va a utilizarla.

Una vez definido el interfaz llega el momento de pensar cómo
codificarlo, pero si se diseña pensando en facilitar el desarrollo o
generar código más elegante seguramente sea a costa de perjudicar a los
usuarios, y eso puede hacer que nadie use la aplicación por muy bueno
que sea el código.


Raul M. - Freelance Web D.
http://raul.murciano.net

Muchas gracias a todos por los comentarios, han sido de mucha ayuda.
Saludos.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs