Un punto de vista (frontpage) para muchos controladores (vistas sub)

Question

Notas: No se puede utilizar Javascript o iframes. De hecho no puedo confiar en el navegador del cliente a hacer casi cualquier cosa pero los fundamentos de ultra.

Estoy reconstruyendo una aplicación de legado PHP4 como una aplicación MVC, con la mayor parte de mi investigación se centró actualmente con el marco del pilón.

Una de las primeras cuestiones extrañas me he encontrado y que yo he resuelto en el pasado mediante el uso de marcos flotantes o mejor aún Javascript se exhibe una colección dinámica de "widgets" que son como digerir vistas de la vista del índice de un controlador típico .

La mejor manera de visualizar mi problema sería la de mirar a página principal personalizada de Google. Que resuelven el problema con Javascript, pero para mi escenario javascript y casi cualquier cosa por encima de XHTML básico no es posible.

Una de las ideas que empecé a trabajar en la era tener mi encuesta controlador Frontpage una base de datos u otro servicio para los widgets que están activadas, a continuación, teniendo una lista de tuplas / dicts, crear dinámicamente una instancia cada controlador y crear una lista / dict de rendir sub puntos de vista y que pasan a la vista de FrontPage y se deja entender las cosas.

Así que con código peusudo:

Get request goes to WSGI
WSGI calls pylons
Pylons routes to Frontpage.index()
Frontpage.index() 
   myViews = list()
   for WidgetController in ActiveWidegets():
        myViews.append(subRender(WidgetController, widgetView))

c.subviews = myViews
render(frontpage.mako)

bits de extraño sobre subRender

• importa dinámicamente controladores vía __import__ (actualmente hardcoded al espacio de nombres del proyecto :()
• tiene un potencial para ser muy caros (la mayoría de las funciones del widget puede almacenar en caché, pero uno es un panel de usuario)

Me siento como que tiene que haber una manera mejor o tal vez un mecanismo ya implementado en WSGI o mejor aún los pilones para hacer esto, pero hasta ahora el más cercano que he encontrado es este método de utilidad: http://www.pylonshq.com/docs/en/ 0.9.7 / modules / controllers_util / # pylons.controllers.util.forward pero parece un poco loco para construir casos N de torres de alta tensión en la parte superior de las torres sólo para obtener una vista de colección.

Answer 1

Mientras que en la mayoría de los casos me gustaría recomendar lo que inicialmente fijado, usando Javascript para cargar cada widget, ya que no es una opción Creo que usted tiene que hacer algo un poco diferente.

Además de utilizar el enfoque de tratar de tener un solo controlador frontal pasar por todos los controles necesarios y la construcción de ellos, una alternativa es posible que desee considerar está haciendo un uso más potente de la plantilla en Mako.

En realidad se puede definir como pequeños bloques de Mako def, que por supuesto tienen el poder de Python completa. Para evitar la contaminación de las plantillas Mako con la lógica de dominio, asegúrese de mantener que todo está en sus modelos, y acaba de hacer llamadas a las instancias de modelo en el Mako def según sea necesario para ese componente de la página para construirse a sí misma.

Una gran ventaja de este enfoque es que, dado que Mako definición de args caché de apoyo, que en realidad puede tener componentes de la página decidir cómo almacenar en caché a sí mismos. Tal vez la barra lateral debe almacenar en caché durante 5 minutos, pero la barra superior cambia cada golpe, por ejemplo. Además, dado que el componente está desencadenando el golpe db, se ahorrará golpes db cuando el componente almacena en caché en sí.

ToscaWidgets no tiene el rendimiento para que sea una opción muy viable en una escala más grande, así que me alejaría de tratar de eso.

En cuanto a algunos ajustes a su idea existente, asegúrese de no utilizar realmente los controladores de torres para widgets ', como lo hacen mucho más según sea necesario para apoyar WSGI que no es necesario para la construcción de una página de widgets.

Me considero tener todas las clases Widget funcionan de esta manera:

class Widget(object):
    def process(self):
        # Determine if this widget should process a POST aimed at it
        # ie, one of the POST args is a widget id indicating the widget
        # to handle the POST

    def prepare(self):
        # Load data from the database if needed in prep for the render

    def render(self):
        # return the rendered content

    def __call__(self):
        self.process()
        self.prepare()
        return self.render()

A continuación, sólo tiene su plantilla principal Mako iterar a través de las instancias de widgets, y llamar a ellos para hacerlos salir.

Answer 2

Se puede usar ToscaWidgets para encapsular sus widgets, junto con una lista almacenada de los widgets habilitadas para cada usuario ( la base de datos u otro servicio, como usted sugiere). Pasar una lista de los ToscaWidgets habilitados a la vista y los widgets se hacen a sí mismos (incluyendo la adición de referencias dinámicamente CSS / JavaScript a la página si requiere widget de esos recursos).