Tabelle html dynamisch erzeugen

Hallo,


Ich suche nach einer Möglicheit die Ausgaben des heißgeliebten Wasserkochers zu debugging-Zwecken und der Präsentation wegen, übersichtlicher zu gestalten.
Ich lies mir bisher Textdateien dynamisch erstellen (auch als html) doch brauche ich jetzt händeringend eine Tabelle in html.

Bisher lasse ich die Werte im Quelltext vom Heater aus mit Variablen replacen, etwa so:

Heater: WERT1
html-Quelltext: $VARIABLE1

Ich schaffe so eine relativ übersichtliche Textausgabe. In dieser Form oder ähnlich möchte ich jetzt html-Tabellen generieren lassen (also html-Tags um diese Werte herumschreiben) was ich allerdings bisher nicht wirklich gut hinbekommen habe.

Haben Sie sowas wie eine 'best-practice' in petto?


Viele Grüße und vielen Dank

Kurz Vorweg, für den HTML Export wurde der FlowHeater nicht entwickelt, das hier beschriebene stellt nur eine Notlösung dar.

Export Werte können Sie ganz einfach mittels des String Append Heaters mit HTML Tags umschließen. Hier brauchen Sie die Tags lediglich über die optionalen Parameter Präfix und Suffix angeben.

z.B.
Präfix: <td> und Suffix </td>
oder
Präfix: <tr> und Suffix </tr>

Den Rest erledigt der String Append Heater.



Hiermit können Sie schon mal die einzelnen ROWS einer Tabelle schreiben. Das Problem ist jetzt die HTML Kopfzeile bzw. eigentlich die HTML Fußzeile. Die Kopfzeile (Header) könnten wir jetzt über einen IF-THEN-ELSE noch so hinbekommen, dass bei der 1. Zeile zusätzlich noch ein Header geschrieben wird. Die HTML Fußzeile (Footer) bekommen wir so aber nicht hin

Das Problem dabei ist wir wissen nicht wann, bzw. bei welchem Datensatz die Fußzeile geschrieben werden soll.

Workaround
Da es sich bei HTML Dateien meistens nicht um sehr große Dateien handelt könnten wir pro Datensatz jeweils eine komplette HTML Datei mittels des File Heaters schreiben. Die alte Datei wird dann mit der neuen wieder überschrieben. Am Ende haben wir eine HTML Datei die den kompletten Export enthält.
Schauen Sie sich hierzu mal das Beispiel "HTML Export" im Anhang an. Das Beispiel verwendet folgendes Skript um sich die einzelnen Daten/Rows zu merken und die HTML Kopf bzw. Fußzeile zu schrieben.

Hinweis: Der HTML Export bzw. das Schreiben der HTML Datei befindet sich auf dem Layer „HTML Ausgabe“.

Achtung: Es wird pro Datensatz eine Komplette HTML Datei geschrieben. Dieses Vorgehen ist nicht sonderlich schnell!

Vielen Dank dafür Herr Stark und sorry das ich mich erst heute rückmelde, es war eine harte Woche :S

Der Workaround hat funktioniert, ich habe es fast ähnlich lösen müssen. Ich hatte dort wo ich es brauchte keinen Zugriff auf das Inet(nicht weil man dort noch in Höhlen schläft, sondern aus reinen Sicherheitsaspekten) und konnte leider erst später Ihre Lösung sehen.

Meine unterscheidet sich zwar nicht grundlegend, jedoch bin ich (wiedermal) aufwändiger verfahren und habe den Appender rausgelsssen, den ich jetzt aber nachrüsten werde.

Mein Kunde hatte mir eine nicht unwesentliche Kleinigkeit ebenfalls verschwiegen, was zu meiner nächsten Frage überleitet:

nämlich ob es FH auch für Unix-Systeme (NET/Mono) geben wird bzw. ob da generell mal was geplant ist?


Werden alle Heater compiliert?
Auf nachfolgendem Screenshot sieht man, dass ich mehrere Net Heater am oberen Rand eines Layers geparkt habe. Ich schreibe bewusst geparkt, da ich das Gefühl habe, das diese ebenfalls jedesmal mit compilliert werden, obwohl diese nicht verbunden sind und keine produktive Funktionalität haben (womit eine Compilation überflüssig wäre)

In der heutigen Zeit knausere ich nicht mit Rechenleistung wenn das nicht zwingend erforderlich ist, doch aufgrund der Größe meiner FH-Projekte geht beim Debugging schon einiges an Vorlaufzeit durch Compilation verloren. Derzeit sind es 55 bis 65 Sekunden (und in dieser Zeit zünde ich mir fast immer eine neue Zigarette an, das macht mich ganz fertig )


Da kam mir der Verbesserungsvorschlag bezüglich eines Parkingsystems für Net-Heater oder man regelt das über eine Codesnippet-Verwaltung.
Man könnte somit austauschbare Net-Heater für unterschiedliche Aufgaben parken und bei Bedarf einfach austauschen bzw. reinziehen

Die vier zeitweise funktionslosen NET-Heater am linken oberen Rand enthalten teilweise mehr als 2 Seiten Code und ich bin nicht sicher in wie weit der Layer noch unübersichtlicher würde, sollte ich dessen Funktionalität von den Standardheatern ausführen lassen.

Gruß Tim



Von diesen unverbundenen Net-Heatern tummeln sich noch weitere auf dem unteren Teil dieses und den 5 weiteren Layern des Projects.

Natürlich habe ich zwischenzeitlich erwogen, für jede einzelnen Anwendungsfall eine eigene .fhd zu schreiben, doch sind die Unterschiede innerhalb der NET Heater nicht so gravierend, das ein schneller Austausch bequemer und zeitsparender erscheint, als ein neues Definitionsfile einzuhängen.

Sie wissen doch wie das ist, es ändern sich zwei Feldnamen oder Datentypen, just wird mal eben ein anderer Heater eingehängt, der diese Anpassungen beinhaltet.
Im Produktivbetrieb allerdings geht das natürlich nicht, das ist mir klar. Aber während der Entwicklungsphase, wäre die Snippetverwaltung oder ein Parkingsystem der NET-Heater eine tolle Hilfe denke ich.

Hallo Tim,

nämlich ob es FH auch für Unix-Systeme (NET/Mono) geben wird bzw. ob da generell mal was geplant ist?

Ich bin zwar ein Linux/UNIX Freund, aber den FlowHeater wird es leider vorerst nicht für .NET / Mono geben. Auch wenn es auf den ersten Blick einfach erscheint hier was umzustellen, der erforderliche zusätzliche Testaufwand steht in keinem Verhältnis zum möglichen Ertrag.

Werden alle Heater compiliert?

Ja, es werden immer alle .NET Script Heater kompiliert die auf der Definition vorhanden sind. Es ist aber eine Art Script Bibliothek geplant. Hier können Sie sich im.NET Script Heater vorhandene Skripts einfach auswählen und verwenden.

Zu Ihrer Definition) Respekt! Die ist echt sehenswert. Ziel ist es so wenig wie möglich Heater zu verwenden, deshalb werden die einzelnen Heater stetig um weitere Funktionalitäten erweitert. Siehe aktuell String Append Heater bzw. String Replace Heater . Momentan werden die Rechenoperationen (plus, minus, mal, geteilt) um eine Konfigurationsdialog erweitert, so dass ein evtl. statischer Operand nicht mühsam über einen zusätzlichen X-Value Heater angegeben werden muss. Der GroupBy Heater wird ebenfalls erweitert, so dass nicht nur gleich einlaufenden Eingangswerte z u einem Datensatz gruppiert werden können sondern eine Datengruppe anhand eines Wertes im Eingangswert bestimmt werden kann. Dies musste bisher über ein zusätzliches Skript realisiert werden.
Hinweis: Die letzten beiden Funktionen werden mit Version 2.0.8 in den FlowHeater einfließen, ca. Anfang August.

z.B.
From: info [ät] test.com = 1. Gruppe
Name: Test1
Datum: 2011-07-11
Grund: Infomaterial
From: info [ät] 123.com = 2. Gruppe
Name: Test2
Datum: 2011-07-11
Grund: Weitere Bestellung

Moin Robert, vielen Dank für dein Posting,

Das ist mir absolut verständlich, ich kenne die Linuxsparte was Software angeht mittlerweile gut, einen Blumentopf (jedenfalls einen voll mit Geld) kann man da nicht wirklich mehr gewinnen.

Was meine Definition angeht:
Na dann solltet ihr mal die anderen Layer sehen
Nein ernsthaft, auch mein Ziel ist es natürlich mit so wenig Aufwand wie nur möglich, zum Ziel zu kommen, doch manchmal sind während des Debugging kleinere Änderungen vorzunehmen und wenn sich die, realisiert mit den Funktionsheatern summieren, gehe ich gerne zu einem NET-Heater über und packe schonmal 10 Pfund Code in eine 2 Pfund-Tüte.

Ich mag es ebenfalls übersichtlich und bin sehr froh darüber das uns mittlerweile Werkzeuge wie der Replace-Heater verfügbar sind, mit denen ich einen Großteil meiner fhd's großzügig abspecken konnte.

Das es auf dem Sektor Flowheater noch so einiges zu erwarten gibt, hatte bereits einer unserer Fortbildungsdozenten, auf den ich mind. 2x jährlich treffe, verlauten lassen.
Der ist übrigens Schuld daran, daß Sie mich (und ein paar Kollegen) hier an der Backe haben.
Als der den FH erstmals auf seinem Beamer zeigte, waren etwa 70% meiner damaligen Datenprobleme schlagartig gelöst. Der FH hat sich innerhalb kurzer Zeit zu einem meiner Lieblingstools in Sachen Im/Export von Daten entwickelt, als Entwickler kennt man das doch, man hat immer einen Pool mit Tools, die man nicht missen möchte, weil sie einem unliebsame Aufgaben erleichtern oder einfach gut zu bedienen sind.
Mittlerweile ist es so, das egal bei welcher Weiterbildung, erstmal eine kleine FH-Plauderei bezüglich Neuigkeiten usw.losgetreten wird, weil viele dort den FH haben.
Das ich damit allerdings mal solche Konstrukte baue, war damals nicht abzusehen.
Der Layer der auf dem IMG zu sehen ist, ist lediglich der obere Teil des Layers 1 von weiteren und für mich noch relativ gut zu überschauen. Jetzt erklären sich Ihnen vermutlich auch die von mir beschriebenen Compiler-Vorlaufzeiten :blush:

Aud die Compilation aller NET-Heater bin ich gestoßen, als mit Visual Studio Code debuggte und dabei jedesmal die FH Layer neu gezeichnet wurde.
Derzeit verwende ich das VS auch noch dazu, meine NET-Heater zu debuggen und paste den Code dann in den NET-Heater rüber und passe ihn der FH-Umgebung an.

So, genug smaltalk, ich habe eine heftige Auslandswoche vor mir und mein Flieger geht früh.

Bis bald, Tim