2008-10-01 5 views
5

Angenommen, Sie haben mehrere Webparts, einen als Controller und mehrere, die Informationen vom Controller übernehmen und darauf reagieren. Dies ist mit der in ASP 2.0 eingeführten Consumer/Producer-Schnittstelle relativ einfach zu modellieren.Sharepoint WebParts

Wie würden Sie Interaktionen andersherum hinzufügen und trotzdem die oben genannten beibehalten?

Ein einfaches Beispiel wäre: Der Benutzer gibt Informationen in Webpart A ein, der eine Suche durchführt, und die Ergebnisse werden auf Webpart B angezeigt. Mit Webpart C können Sie die Ergebnisse filtern, die Webpart A dazu veranlassen sollen, die Abfrage erneut zu senden und aktualisieren Sie daher die Ergebnisse in B.

Es scheint nicht möglich, in WSS 3.0 zu tun, weil Sie nur 1 Schnittstelle in allen Verbindungen gleichzeitig verwendet werden dürfen.

Macht das überhaupt Sinn? :-)

Antwort

2

Eine schnelle und schmutzige Lösung, um willkürliche Kontrollkommunikation zu ermöglichen, ist die Verwendung rekursiver Suchsteuerung und Ereignisse. Lassen Sie die Steuerelemente den Steuerelementbaum nach Steuerelementtyp durchsuchen, was sie benötigen, und abonnieren Sie anschließend öffentlich belichtete Ereignisse im Veröffentlichungssteuerelement.

Ich habe zuvor den Trick verwendet, um Standard-Server-Kontrollen zu ermöglichen, einander zu finden, wenn in CMS-Systeme von verschiedenen Herstellern eingebettet, um eine bestimmte Kommunikations-API vollständig zu vermeiden.

+0

das ist ein bisschen eklig: D –

1

Ich sehe nichts falsch mit Webpart A bekommen einen Verweis auf Webpart B und Aufruf öffentliche/interne Methoden/Eigenschaften oder Subskribenten Handler zu öffentlichen/internen Ereignissen. Ein Punkt, der dabei erwähnt wird: EnsureChildControls. Ich habe mit eigenen Augen gesehen, dass ein Webpart für PreRender freigegeben wurde, während ein anderer Webpart nicht einmal CreateChildControls ausgeführt hat.

Von webpart A, holen Ihre Referenz B (in diesem Fall webpart B Kalender ist vom Typ) webpart etwa so:

 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; 
     } 
    } 

Jetzt können Sie Dinge tun, wie einige neue Daten holen und den Kalender aktualisieren, wie so:

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

Oder vielleicht lassen webpart A werfen einen Verweis auf sich selbst über webpart B, so dass es webpart A öffentlichen/interne Eigenschaften verwenden können, gehen Daten holen für sich:

CalendarWP.UseWPAToFetchData(this);