Cuándo usar los componentes de Seaside, y cuándo usar objetos de renderizado simples?

Question

He estado desarrollando una aplicación web en Seaside + Squeak recientemente, y he encontrado que es una experiencia maravillosa. Seaside realmente está muy por encima de cualquier otro marco, y creo que estoy trabajando con un nivel de abstracción más alto (por encima del ciclo de solicitud/respuesta HTTP y de plantillas HTML con el que otros frameworks se ocupa).

Dicho esto, estoy un poco confundido acerca de los componentes de Seaside. Recientemente tuve que mostrar una lista de objetos en un componente (similar a la página principal de stackoverflow). Al principio hice que cada objeto fuera un componente (una subclase de WAComponent), pero resultó ser realmente un desperdicio, y tuve que configurar #children dinámicamente en el componente principal para que funcionara. Luego intenté hacerlos renderizar objetos (objetos que no son subclases de WAComponent, y renderizar usando renderOn: en lugar de renderContentOn :, como lo hacen los componentes). Esto funcionó, pero ahora ya no podían acceder al estado global en el objeto de sesión como pueden hacerlo los componentes (usando #session). Luego descubrí el valor "WACurrentSession", que otorga a cualquier objeto acceso al objeto de sesión Seaside actual. Ahora pude hacerlos renderizar objetos. Además, descubrí que podía reescribir muchos de mis otros componentes más pequeños como objetos de renderizado también.

Además de necesitar el estado de llamada/respuesta o retroceso, ¿qué otras razones existen para usar componentes sobre objetos de representación?

Answer 1

Este es un punto frecuente de confusión para los nuevos usuarios de Seaside. Hemos intentado hacerlo más claro en Seaside 2.9, que actualmente está en Alpha, pero trataré de centrarme en 2.8 aquí, ya que parece que eso es lo que estás usando.

En primer lugar, tiene razón en que no necesita usar un Componente para acceder a la Sesión. Seaside 2.9 mueve #session hasta una nueva clase WAObject que lo hace accesible para casi todos los objetos de Seaside (incluidos los componentes) pero definitivamente puede referirse a WACurrentSession por el momento en 2.8.

Los componentes proporcionan aproximadamente la siguiente funcionalidad en 2.8:

1. #renderContentOn: se llama con una instancia de cualquier clase de procesador que especifique en #rendererClass (en lugar de cualquier procesador está en uso cuando se le pide su objeto a representar en sí)
2. Un gancho (#updateUrl:) para permitir la actualización la URL utilizada por el procesador para generar enlaces
3. ganchos (#updateRoot:, #style, #script) para permitir la actualización de la sección HEAD del documento HTML
4. la capacidad de ser la raíz de una aplicación
5. ganchos (#updateStates:, #states) para hacer estado dando marcha atrás más fácil
6. Un gancho (#initialRequest:) para permitir la inicialización en base a la solicitud que hizo que la sesión se creó
7. Una instalación (#children) para asegurarse de que todos los componentes por debajo de usted también tendrán los ganchos anteriores llamados en ellos
8. La posibilidad de añadir las decoraciones
9. La capacidad de mostrar/respuesta/llamada (utiliza las decoraciones)
10. Algunos métodos de conveniencia (#inform:, #isolate:, etc)

Si no necesita ninguna de las opciones anteriores, no necesita un Componente. Si necesita alguno de los anteriores, prácticamente necesita un Componente a menos que desee implementar la funcionalidad equivalente en su propia clase.

La medida más simple es probablemente: si tiene la intención de mantener el objeto entre las solicitudes HTTP, debe ser un Componente; Si tiene la intención de tirar el objeto y crearlo en cada pase de representación, probablemente no sea necesario. Si imagina una aplicación que muestra páginas de blog, probablemente tenga Componentes para un menú, una hoja de blog, el cuerpo del blog, cada comentario, etc. Es posible que desee restar importancia a la lectura del marcado del blog y la generación de su HTML para que pueda admitir diferentes marcas o diferentes representadores y para que el comentario Componentes pueda admitir el mismo marcado. Esto podría hacerse con una clase que no sea Componente que implemente #renderOn: y que otros componentes puedan crear y usar según sea necesario.

Seaside 2.9 actualmente divide la funcionalidad anterior haciendo WAPresenter de hormigón e introduciendo WAPainter como su superclase. 1-3 más arriba se implementan en WAPainter y 4-7 en WAPresenter por lo que puede elegir qué subclase dependerá de sus necesidades. También elimina muchos métodos de WAPresenter y WAComponent en un esfuerzo por hacerlos más fáciles de entender para los usuarios finales.

Espero que ayude.