2008-10-01 21 views
5

Digamos que tiene varias partes web, una como controlador y varias que toman información del controlador y actúan en consecuencia. Esto es bastante fácil de modelar utilizando la interfaz Consumer/Producer presentada en ASP 2.0.Sharepoint WebParts

¿Cómo sería posible agregar interacciones al revés mientras se mantiene lo anterior?

Un ejemplo simple sería: el usuario ingresa información en webpart A que realiza una búsqueda y los resultados se mostrarán en la parte web B. Webpart C le permite filtrar los resultados que deberían desencadenar la parte web A para volver a enviar la consulta y, por lo tanto, actualice los resultados en B.

No parece posible hacerlo en WSS 3.0 porque solo se permite utilizar 1 interfaz en todas las conexiones al mismo tiempo.

¿Este siquiera tiene sentido? :-)

Respuesta

2

Una solución rápida y sucia para permitir una comunicación de control arbitraria es usar eventos y control de búsqueda recursivo. Haga que los controles busquen en el árbol de control por tipo de control lo que necesitan y luego suscríbase a los eventos públicamente expuestos en el control de publicación.

He utilizado anteriormente el truco para permitir que los controles de servidor estándar se encuentren entre sí cuando están incrustados en sistemas CMS de diferentes proveedores para evitar por completo una API de comunicación específica.

+0

eso es un poco desagradable: D –

1

No veo nada malo con la parte web A obtener una referencia a la parte web B y llamar a los métodos/propiedades públicos/internos o a los controladores de suscripción a eventos públicos/internos. Un punto de mención al hacer esto es: EnsureChildControls. He sido testigo, con mis propios ojos, de que una parte web se ejecuta sin problemas para PreRender, mientras que otra parte web ni siquiera había ejecutado CreateChildControls.

De webpart de una, ir a buscar su referencia a Webpart B (en este caso webpart de B es del tipo de calendario), así:

 private Calendar _calendarWP = null; 
    public Calendar CalendarWP 
    { 
     get 
     { 
      if (_calendarWP != null) 
       return _calendarWP; 
      else 
       foreach (System.Web.UI.WebControls.WebParts.WebPartZone zone in this.WebPartManager.Zones) 
        foreach (System.Web.UI.WebControls.WebParts.WebPart webpart in zone.WebParts) 
         if (webpart is Calendar) 
         { 
          _calendarWP = (Calendar)webpart; 
          _calendarWP.EnsureChildControls(); 
          return _calendarWP; 
         } 
      return null; 
     } 
    } 

Ahora puede hacer cosas como ir a buscar algunos datos nuevos y actualizar el calendario por lo que:

  IEnumerable newData = SomeDataProvider.GetNewData(args); 
     CalendarWP.someGridView.DataSource = newData; 
     CalendarWP.someGridView.DataBind(); 

O tal vez dejar que webpart de un lanzamiento de una referencia a sí mismo a Webpart B, así que puede utilizar webpart de propiedades públicas/interno de una a ir a buscar los datos por sí mismo:

CalendarWP.UseWPAToFetchData(this);