urls plantillas for filtros extender create contexto smalltalk squeak seaside

smalltalk - plantillas - if en django



¿Cuándo usar componentes de Seaside y cuándo usar objetos de renderizado simples? (1)

Recientemente he estado desarrollando una aplicación web en Seaside + Squeak, y me ha parecido una experiencia maravillosa. Seaside realmente está muy por encima de cualquier otro marco, y me siento como si estuviera trabajando en un nivel más alto de abstracción (por encima del ciclo de solicitud / respuesta HTTP y las plantillas HTML con las que otros marcos hacen que trabaje).

Dicho esto, estoy un poco confundido acerca de los componentes de Seaside. Hace poco tuve que mostrar una lista de objetos en un componente (similar a la página frontal de stackoverflow). Al principio hice que cada objeto fuera un componente (una subclase de WAComponent), pero esto resultó ser realmente un desperdicio, y tuve que poner a #children dinámicamente en el componente principal para que funcionara. Luego traté de hacer que los objetos se renderizaran (objetos que no son subclases de WAComponent, y se renderizan utilizando 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 (utilizando #session). Luego descubrí el "valor WACurrentSession", que le da a cualquier objeto acceso al objeto de sesión actual de Seaside. Ahora era capaz de hacerlos renderizar objetos. Además, descubrí que también podría reescribir muchos de mis otros componentes más pequeños como objetos de render.

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

Este es un punto frecuente de confusión para los nuevos usuarios de Seaside. Nos hemos esforzado por aclarar esto en Seaside 2.9, que actualmente está en Alpha, pero intentaré concentrarme 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 a una nueva clase WAObject que lo hace accesible a casi todos los objetos de Seaside (incluidos los Componentes), pero definitivamente puede referirse a WACurrentSession usted mismo por ahora en 2.8.

Los componentes proporcionan aproximadamente la siguiente funcionalidad en 2.8:

  1. #renderContentOn: se llama con una instancia de la clase de renderizador que especifique en #rendererClass (en lugar de cualquier renderizador que esté en uso cuando se le pide a su objeto que se procese)
  2. Un gancho ( #updateUrl: para permitir la actualización de la URL utilizada por el procesador para generar enlaces
  3. Enganches ( #updateRoot: #style , #script ) para permitir actualizar la sección HEAD del documento HTML
  4. La capacidad de ser la raíz de una aplicación.
  5. Enganches ( #updateStates: #states ) para facilitar el retroceso del estado
  6. Un gancho ( #initialRequest: para permitir la inicialización basada en la solicitud que causó la creación de la sesión
  7. Una instalación ( #children ) para asegurarse de que todos los componentes a continuación también tengan los ganchos mencionados arriba en ellos
  8. La posibilidad de añadir decoraciones.
  9. La capacidad de mostrar / responder / llamar (usa Decoraciones)
  10. Algunos métodos de conveniencia ( #inform: , #isolate: etc.)

Si no necesita ninguno de los anteriores, no necesita un componente. Si necesita alguno de los anteriores, necesita un componente a menos que desee implementar la funcionalidad equivalente en su propia clase.

La métrica más simple es probablemente: si pretende mantener el objeto entre las solicitudes HTTP, debería ser un componente; si tiene la intención de tirar el objeto y crearlo en cada paso de renderizado, probablemente no sea necesario. Si imagina una aplicación que muestra páginas de blog, probablemente tenga Componentes para un menú, un rollo de blog, el cuerpo del blog, cada comentario, etc. Es posible que desee factorizar la lectura del marcado del blog y la generación de su HTML para que pueda admitir diferentes marcados o diferentes representadores y para que los componentes de comentarios puedan admitir el mismo marcado. Esto podría hacerse con una clase que no sea de componente que implemente #renderOn: y podría ser creada y utilizada por otros componentes según sea necesario.

Seaside 2.9 actualmente divide la funcionalidad anterior haciendo concreto a WAPresenter e introduciendo WAPainter como su superclase. 1-3 anteriores se implementan en WAPainter y 4-7 en WAPresenter para que pueda elegir qué subclase según 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.