Namespace | Beschreibung |
---|---|
combit.Reporting | Die Hauptkomponente, die alle wichtigen List & Label Basisfunktionen für Druck und Design beinhaltet. Dazu stehen Ihnen komfortable Klassenwrapper zur Verfügung. Hinweise zu deren Verwendung finden Sie in dieser Hilfe. |
combit.Reporting.DataProviders | Der DataProvider Namespace enthält alle verfügbaren Datenprovider von List & Label. Dies erlaubt direkte Verbindungen zu Quellen wie SqlConnection, XML-Dateien oder Objekthierarchien. Die Schnittstellen, die in diesem Namespace enthalten sind, erlauben es außerdem eigene Datenprovider für Verbindungen, die derzeit noch nicht abgedeckt werden, zu schreiben. |
combit.Reporting.DesignerExtensions | Der DesignerExtensions Namespace enthält Klassen und Schnittstellen, die sich mit dem Erweitern des Designers befassen. Diese Klassen können zum Beispiel verwendet werden um mächtige DesignerObjects zu erstellen. |
combit.Reporting.Dom | Um Projektdateien dynamisch zur Laufzeit zu erstellen oder auch um bestehende Projektdateien per Code zu bearbeiten, können Sie mit den List & Label DOM-Funktionen arbeiten. Dazu stehen Ihnen komfortable Klassenwrapper zur Verfügung. Hinweise zu deren Verwendung finden Sie in dieser Hilfe. Um ein Projekt neu anzulegen, benötigen Sie die Open Methode der ProjectBase Klasse. Um bestehende Projekte zu bearbeiten, verwenden Sie die GetFromParent Methode. |
combit.Reporting.Repository | Wenn Berichte in verteilten Anwendungen wie z.B. Webanwendungen verwendet werden sollen, müssen alle benötigten Dateien zwischen den beteiligten Systemen bzw. zwischen Client und Server ausgetauscht und auf demselben Stand gehalten werden. Es bietet sich daher an, die Projektdateien in einer zentralen Datenbank zu speichern, was jedoch spätestens dann komplex wird, wenn ein Projekt Grafiken, Drilldown-Projekte oder weitere externe Dateien über lokale Dateipfade referenziert, die auf einem anderen System ebenfalls gültig sein müssen.
Grundlagen Im Repository-Modus speichert und lädt List & Label die in einem Bericht verwendeten Dateien nicht selbst. Anstelle von Dateipfaden- und namen werden eindeutige Repository-IDs verwendet. Sie müssen selbst die IRepository Schnittstelle implementieren und an das List & Label-Objekt übergeben. Ab diesem Zeitpunkt fragt List & Label Ihr benutzerdefiniertes Repository nach dem Dateiinhalt zu einer Repository-ID, oder übergibt dem Repository eine solche ID samt dem zugehörigen Dateiinhalt zum Speichern. Ob die Dateien im Repository von einer SQL-Datenbank, einem Webservice oder einer anderen Speicherlösung verwaltet werden, hängt ausschließlich von Ihrer IRepository-Implementierung ab. Das Laden und Speichern der Einträge im Repository geschieht dabei ausschließlich über Streams.
Umsetzung Allen Funktionen, denen bisher der Dateipfad des Projekts übergeben wurde, wird stattdessen die Repository-ID übergeben: Aus "Dateien" werden im Repository-Modus "Repository-Items" (Elemente) und aus den Dateinamen werden "Repository-IDs". Jedes Repository-Item (Element) besitzt neben der ID einen Typ, einen Zeitstempel und einen Bezeichner (String mit variabler Länge, der interne Informationen enthält). Ihre Repository-Implementierung muss neben dem Dateiinhalt also mindestens diese vier Informationen für jedes Repository-Item (Element) speichern und abrufen können.
Hier finden Sie eine Anleitung zur genauen Vorgehensweise, um das Repository zu verwenden: Verwenden des Repository-Modes
Sie finden eine vollständige einfache Repository-Implementierung in den ASP.NET-Beispielprojekten (Klasse SQLiteFileRepository), die ein Repository mit einer SQLite-Datenbank als Datenspeicher bereitstellt.
Tipps
Hier finden Sie eine Anleitung zur genauen vorgehensweise, um das Repository zu verwenden: |