Hallo,
ich habe eine html mit einem script welches mir eine Tabelle mit daten
aus einer .csv-Datei darstellt.
In jeder Reihe dieser .csv gibt es eine Zelle mit einem pfad zu einem
Bild. Diese sollte in der HTML dargestellt werden.
Aber ich habe leider Absolut keine Ahnung, wie das gemacht wird.
Später möchte ich dann noch ein Suchfeld haben, wo ich etwas eingeben
kann und mir nur dann die Zeilen dargestellt werden, die das gesuchte
beinhalten
Chandler B. schrieb:> row.append($('<td>'+cellData+'</td>'));
Da wird ein Tabellendatenfeld angelegt.
Wenn du da ein Bild anzeigen willst, muss "cellData" einen Bilder-Tag
enthalten.
Ergo: Wenn deine cellData einen Link enthalten, muss cellData um das
HTML-Element zum Anzeigen eines Bildes erweitert werden.
Chandler B. schrieb:> ich habe eine html mit einem script welches mir eine Tabelle mit daten> aus einer .csv-Datei darstellt.> In jeder Reihe dieser .csv gibt es eine Zelle mit einem pfad zu einem> Bild. Diese sollte in der HTML dargestellt werden.> Aber ich habe leider Absolut keine Ahnung, wie das gemacht wird.
Während die Antwort von Rahul D. technisch vollkommen korrekt ist, ist
sie leider noch ein bisschen unvollständig. Denn abgesehen davon, daß
für die Grafiken natürlich ein Image-Tag:
1
<img src="</pfad/zum/bild.webp>">
eingefügt werden muß, gibt es noch eine zweite Anforderung: die
Image-URL muß natürlich obendrein auch vom Client abgerufen werden
können. Dazu gibt es ein paar gebräuchliche Methoden, häufig eine
/static/-Route oder -Subdomain, die im Webserver entsprechend
konfiguriert oder im Falle einer Subdomain mitunter sogar von einem
eigenen Webserver bedient wird.
> Später möchte ich dann noch ein Suchfeld haben, wo ich etwas eingeben> kann und mir nur dann die Zeilen dargestellt werden, die das gesuchte> beinhalten
Das kann man mit jQuery machen, und ich habe schon entsprechende
Techniken benutzt. Heutzutage würde ich das aber eher mit Svelte machen;
das ist zwar deutlich mehr Einarbeitungsaufwand, aber auch wesentlich
leistungsfähiger, flexibler und nach meinen Erfahrungen meistens auch
schneller.
Ein T. schrieb:> ist> sie leider noch ein bisschen unvollständig. Denn abgesehen davon, daß> für die Grafiken natürlich ein Image-Tag:
Ich wollte die Eigeninitiative etwas förden... ;)
Ginge das nicht viel einfacher, wenn der Webserver statt "data.csv"
direkt die fertige HTML-Seite liefern würde? HTML ist doch genauso
einfacher Text wie CSV, nur mit ein paar spitzen Klammern verziert. Ja,
das ist Technik aus dem vorigen Jahrtausend, eure Vorschläge sind modern
und flexibel, aber für eine einfache Tabelle doch totaler Overkill.
Wahrscheinlich wird auch die Suchfunktion auf dem Server etwas
übersichtlicher als in einem Client-seitigen Script.
Bauform B. schrieb:> Ginge das nicht viel einfacher, wenn der Webserver statt "data.csv"> direkt die fertige HTML-Seite liefern würde?
Tut er doch. Bloß als Ajax- / JS-Script.
Die CSV-Daten kommen wohl von woanders (z.B. Messdaten, die mit Bildern
kombiniert sind).
Bauform B. schrieb:> Wahrscheinlich wird auch die Suchfunktion auf dem Server etwas> übersichtlicher als in einem Client-seitigen Script.
Jede Tabellenzeile mit einer Id oder Class versehen, und man kann per JS
und CSS den Spaß ein- und ausblenden.
Chandler B. schrieb:> Aber ich habe leider absolut keine Ahnung, wie das gemacht wird.
Also lieber in einem Forum nach einer fertigen Lösung fragen?!
Für HTML gibt es beispielsweise SELFHTML.org mit vielen Tutorien zu den
einzelnen HTML-Elementen und Themen.
https://www.w3schools.com/html/default.asp hat auch schöne Beispiele.
Bauform B. schrieb:> Wahrscheinlich wird auch die Suchfunktion auf dem Server etwas> übersichtlicher als in einem Client-seitigen Script.
Man versucht doch so viel Last wie möglich vom Server auf den Client
umzulagern. Wenn eine Suchfunktion auf dem Client ausgeführt werden
kann, dann mach ich das auch. Wenn es sich auch bloß um ein paar
Promille Last handelt - aber in Masse kann sowas schon erheblich sein.
Bauform B. schrieb:> Ginge das nicht viel einfacher, wenn der Webserver statt "data.csv"> direkt die fertige HTML-Seite liefern würde? HTML ist doch genauso> einfacher Text wie CSV, nur mit ein paar spitzen Klammern verziert. Ja,> das ist Technik aus dem vorigen Jahrtausend, eure Vorschläge sind modern> und flexibel, aber für eine einfache Tabelle doch totaler Overkill.
Dann brauchst Du eine serverseitige Prozessierung der CSV-Datei. Mit dem
Ansatz des TO wird die Datei hingegen clientseitig prozessiert und sein
Webserver beschränkt sich auf die reine Auslieferung der Dat(ei)en.
> Wahrscheinlich wird auch die Suchfunktion auf dem Server etwas> übersichtlicher als in einem Client-seitigen Script.
Das hängt im Wesentlichen vom Umfang der Daten, der gewünschten Funktion
der Suche, und der Anzahl der gleichzeitigen Clients ab. Und es benötigt
wieder eine serverseitige Prozessierung, die den Server belastet. Wenn
der Server zum Beispiel ein Raspberry Pi ist, insbesondere ein älteres
Modell oder eines mit nur wenig Arbeitsspeicher, dann hat der Client
womöglich viel mehr Ressourcen.
Die clientseitige Suche hat den Vorzug, daß sie weniger Datentraffic und
eine geringere Last auf dem Server verursacht. Nachteil ist, daß viele
komplexere Suchfunktionen äußerst aufwändig sind. Sowas ist serverseitig
mit einer echten Suchmaschine wie Apache Solr, Elastic- oder OpenSearch,
oder mit einer Library wie Bleve für Golang oder Woosh für Python viel
einfacher zu realisieren.
Ein T. schrieb:> Mir ist nicht ganz klar, wie ein deutlich veralteter Leitfaden für HTML4> da helfen sollte.
Grundlagen halt.
Ein T. schrieb:> ...inwieweit WYSIWIG-Editoren dem TO helfen sollen... keine Ahnung,> magst Du dazu vielleicht etwas genauer ausführen?
Nö. Du wunderst hier nur herum. Schau dir die Programme selber an, dann
verstehst du es vielleicht besser, als nur von von Oben draufzuschauen.
Oder bist du dir etwa zu schade dafür oder einfach zu faul trotz der
Neugier?
Rbx schrieb:> Ein T. schrieb:>> Mir ist nicht ganz klar, wie ein deutlich veralteter Leitfaden für HTML4>> da helfen sollte.>> Grundlagen halt.
Hm, der TO hat IMHO recht anständigen HTML-Code gepostet, sogar mit
Doctype, Charset und Viewport. Der TO scheint die Grundlagen also zu
kennen, weswegen unterstellst Du ihm etwas anderes?
Darüber hinaus vermute ich, daß eine Einführung in HTML5 wie das hier im
Thread bereits erwähnte SelfHTML beim Erwerb von Grundlagenwissen besser
vermitteln würde als eine Einführung in HTML4 vom Mai 2005 -- wenn
dieser Erwerb denn überhaupt notwendig sein sollte, natürlich.
> Ein T. schrieb:>> ...inwieweit WYSIWIG-Editoren dem TO helfen sollen... keine Ahnung,>> magst Du dazu vielleicht etwas genauer ausführen?>> Nö. Du wunderst hier nur herum. Schau dir die Programme selber an, dann> verstehst du es vielleicht besser, als nur von von Oben draufzuschauen.> Oder bist du dir etwa zu schade dafür oder einfach zu faul trotz der> Neugier?
Nvu wurde bereits 2005 aufgegeben, dessen Nachfolger KompoZer 2010, und
bei BlueGriffon wurde seit 2017 nichts mehr veröffentlicht. Zudem gab es
Nvu und die letzten Versionen von BlueGriffon nur für Windows, und...
also, wie sage ich das jetzt... isch 'ahbe gar keine Windows, schon gar
nicht in den uralten Versionen, die die von Dir genannten Programme
voraussetzen. Insofern fürchte ich, daß ich mir diese Programme nicht
anschauen werde.
Außerdem gibt es gute Gründe, warum ich meinen HTML-, CSS- und JS-Code
von Hand schreibe. Ich habe noch keinen WYSIWIG-Editor gesehen, der
halbwegs anständigen Code erzeugt hätte.
Allerdings fällt mir auf, daß Du häufig Du von uralter Software
sprichst, und hier empfiehlst Du sogar eine völlig veraltete
Dokumentation. Warum?
Ein T. schrieb:> Der TO scheint die Grundlagen also zu> kennen, weswegen unterstellst Du ihm etwas anderes?
Den er irgendwo kopiert hat.
Wenn man nicht weiß, welche Funktion "<td>" hat, lässt das auf ziemlich
viel (bzw. wenig Grundlagenwissen) schließen.
AJAX ist kein HTML...
Ein T. schrieb:> Außerdem gibt es gute Gründe, warum ich meinen HTML-, CSS- und JS-Code> von Hand schreibe. Ich habe noch keinen WYSIWIG-Editor gesehen, der> halbwegs anständigen Code erzeugt hätte.
WYSIWG ist doch bei diversen GUI-Programmierungen Standard.
Man kann dann den HTML-Code betrachten und hat was funktionierendes -
egal, ob anständig oder nicht.
Heute käme wohl auch niemand mehr auf die Idee, den G-Code für
CNC-Maschinen von Hand zu erzeugen (außer die Maschine erfordert das,
oder es ist eine Übung).
Rahul D. schrieb:> Ein T. schrieb:>> Der TO scheint die Grundlagen also zu>> kennen, weswegen unterstellst Du ihm etwas anderes?> Den er irgendwo kopiert hat.> Wenn man nicht weiß, welche Funktion "<td>" hat, lässt das auf ziemlich> viel (bzw. wenig Grundlagenwissen) schließen.
Bisher habe ich kein Indiz dafür gesehen, daß diese Unterstellungen
zutreffen.
> AJAX ist kein HTML...
<Loriot>Ach.</Loriot> ;-)
> Ein T. schrieb:>> Außerdem gibt es gute Gründe, warum ich meinen HTML-, CSS- und JS-Code>> von Hand schreibe. Ich habe noch keinen WYSIWIG-Editor gesehen, der>> halbwegs anständigen Code erzeugt hätte.>> WYSIWG ist doch bei diversen GUI-Programmierungen Standard.> Man kann dann den HTML-Code betrachten und hat was funktionierendes -> egal, ob anständig oder nicht.>> Heute käme wohl auch niemand mehr auf die Idee, den G-Code für> CNC-Maschinen von Hand zu erzeugen (außer die Maschine erfordert das,> oder es ist eine Übung).
Die Kombination aus HTML, CSS und gegebenenfalls ECMAScript ist
allerdings wesentlich komplexer als handelsübliche GUIs oder die G-Codes
für CNC. Vor allem, wenn auch noch Features wie Templates mit
Inheritance (think Jinja2 oder Golang HTML Templates) oder Compiler wie
Svelte dazu kommen...
Wie gesagt: ich habe sehr gute Gründe dafür, warum ich so etwas von Hand
schreibe. Ausnahmen davon (think interaktive Datenvisualisierung etwa
mit Bokeh oder seaborn) sind rar -- und bestätigen die Regel.
Ein T. schrieb:> Bisher habe ich kein Indiz dafür gesehen, daß diese Unterstellungen> zutreffen.Chandler B. schrieb:> Aber ich habe leider Absolut keine Ahnung, wie das gemacht wird.
Ist für mich Indiz genug.
Dann auch noch der Quellcode in dem "<td>" auftaucht.
Sowas kann man alles googlen.
Ein T. schrieb:> Die Kombination aus HTML, CSS und gegebenenfalls ECMAScript ist> allerdings wesentlich komplexer als handelsübliche GUIs oder die G-Codes> für CNC. Vor allem, wenn auch noch Features wie Templates mit> Inheritance (think Jinja2 oder Golang HTML Templates) oder Compiler wie> Svelte dazu kommen.
Viel Spaß, wenn du ein komplexes STL-Modell in CNC-Code für 3D-Drucker
umwandeln willst. Aber das willst du ja ga nicht.
Da der TO sich sowieso nicht mehr meldet (weil er entweder vor Lachenn
geplatzt ist, oder in seinem stillen Kämerlein Grundlagen lernt), ist
dieser Thread doch eher was für /dev/null.
Ein T. schrieb:> Ich habe noch keinen WYSIWIG-Editor gesehen, der> halbwegs anständigen Code erzeugt hätte.
Ich hatte schon geschrieben, du sollst dir Nvu ansehen. Solange du das
nicht machst, bist du für mich ein fauler arroganter Sack.
Das ist übrigens auch nichts neues (also das Verweigern von
Überprüfungen) - beim nächsten Mal schreibe ich eine Mail an den
Administrator, ob der dich nicht sperren kann - wegen dieser ständigen
Einseitigkeit mit auf die Füsse treten, beleidigen - oder einfach
Mitarbeit zu verweigern um auf dieser Schiene weiterzumachen und sich
dabei selber in den Himmel loben. Eigenlob stinkt, schon mal gehört den
Spruch?
Chandler B. schrieb:> Aber ich habe leider Absolut keine Ahnung, wie das gemacht wird.
Dann frag doch ne KI wie die 10000000 anderen Nixblicker die davon ganz
begeistert sind.
Rbx schrieb:> Ein T. schrieb:>> Ich habe noch keinen WYSIWIG-Editor gesehen, der>> halbwegs anständigen Code erzeugt hätte.>> Ich hatte schon geschrieben, du sollst dir Nvu ansehen.
s/du sollst dir/Du möchtest Dir bitte/; # Tonfall?
> Solange du das> nicht machst, bist du für mich ein fauler arroganter Sack.
Schreibe ich in einer Sprache, die Du nicht verstehst? Ich würde mir das
ja anschauen -- und sei es nur, um Dir am lebenden Objekt zu beweisen,
was das Wunderding alles nicht kann, von mir aber benötigt wird -- aber
auf der von Dir selbst verlinkten Seite steht, daß es NVU nur für
Windows gibt, und ich (erfreulicherweise) kein Windows habe.
Allerdings habe ich jetzt extra Dir zuliebe ein wenig recherchiert, und
muß feststellen: auf der Seite des ehemaligen Entwicklers gibt es
Binaries für Linux in der Version 0.20 [1] zum Herunterladen. Aber wenn
ich dort auf die Download-Links klicke, bekomme ich einen HTTP-Fehler
404 "Not Found". Kein Wunder, das betreffende Verzeichnis auf dem Server
ist: leer [2].
Auf der von Dir verlinkten Download-Seite des Heise-Verlages gibt es nur
das Binary für Windows, mit dem ich nichts anfangen kann, und auf der
Seite des Projekts [3] gibt es wiederum nur je ein Binary für Windows,
mit dem ich aus oben genannten Gründen nichts anfangen kann, und eines
für MacOS, mit dem ich in Ermangelung eines Mac(OS) ebensowenig anfangen
kann.
[1] http://www.glazman.org/whyNvu/nvu.html#binaries02
[2] http://glazman.org/nvu/releases/
[3] https://www.nvu.com/> Das ist übrigens auch nichts neues (also das Verweigern von> Überprüfungen) -
Es gibt schlicht und ergreifend nichts zu überprüfen: die Software gibt
es nicht für mein Betriebssystem und ich werde mir weder eine
Windows-Lizenz, noch einen Macintosh kaufen, um eine Software
auszuprobieren, welche schon seit zwanzig Jahren tot ist.
Davon abgesehen besteht der größte Teil dessen, was ich mit HTML & Co.
mache, aus Jinja2- [4] oder Golang-Templates [5]. Beide Template-Engines
arbeiten mit etwas, das sie "Inheritance" (Jinja2) oder "Nested
Templates" (Golang) nennen, das heißt: es gibt ein großes
"Eltern-Template" und ein (oder mehrere) Kinder, deren gerenderte
Inhalte dann an den mit Platzhaltern bezeichneten Stellen in das
"Eltern-Template" eingefügt werden. Das kann man vermutlich noch mit
etwas gutem Willen in einen WYSIWIG-Editor einbauen, aber ob sich da der
angebliche Produktivitätsvorteil einstellt, den WYSIWIG für sich
reklamiert, wage ich zu bezweifeln. Ähnliches gilt für das
Frontend-Framework Svelte, welches ich in verschiedenen Projekten
benutze -- bei jeder Änderung müßte das neu übersetzt, und mit
Beispieldaten gefüllt und neu geladen werden. Bei allen Änderungen im
WYSIWIG-Modus müßten diese Änderungen in die Template- oder die
Svelte-Sourcen zurückportiert und dann... you get the idea, Katze beißt
Schwanz.
Wie das mit WYSIWIG und modernen responsiven Webseiten funktionieren
soll, kann ich mir ohne Verrenkungen irgendwie auch nicht vorstellen --
schon gar nicht mit einer Software, die bei der Erfindung des Begriffs
"Responsive Web Design" schon seit fünf Jahren tot war...
[4] https://jinja.palletsprojects.com/en/stable/
[5] https://pkg.go.dev/html/template> beim nächsten Mal schreibe ich eine Mail an den> Administrator, ob der dich nicht sperren kann - wegen dieser ständigen> Einseitigkeit mit auf die Füsse treten, beleidigen -
In letzter Zeit hat es sich hier im Forum eingebürgert, in solchen
Fällen nicht mehr die armen Moderatoren zu belästigen, sondern gleich
einen neuen Thread im Forum zu eröffnen. Andererseits wüßte ich nicht,
womit ich Dich beleidigt haben oder Dir auf die Füße getreten sein
sollte. Das würde ich wirklich zu gerne wissen, kannst Du mir das bitte
kurz erklären?
> oder einfach> Mitarbeit zu verweigern um auf dieser Schiene weiterzumachen und sich> dabei selber in den Himmel loben. Eigenlob stinkt, schon mal gehört den> Spruch?
Ach, ich höre so viel, wenn der Tag lang ist, und merke mir nicht alles.
Ich wüßte auch nicht, wo ich mich selbst gelobt haben sollte, und bitte
Dich nun darum, mich diesbezüglich zu erhellen.
Abschließend möchte ich kurz noch auf einige Dinge hinweisen.
Erstens erscheint es mir ein bisschen... merkwürdig, daß dieselben
Leute, die das Herunterladen von fertigem Quellcode kritisieren und
stattdessen eigene Handarbeit empfehlen, hier genau dies ablehnen. Aus
meiner persönlichen Sicht ist es nur ein marginaler Unterschied, ob man
seinen Code herunterlädt oder mit einem WYSIWIG-Ding erzeugt, das
Ergebnis bleibt dasselbe: jemand anderes schreibt den Code, man selbst
hat wenig bis keine Kontrolle darüber, und am Ende weiß man dabei nicht,
was man tut und was dabei herauskommt. Das ist ja genau das, weswegen
die StackOverflow-Kopierer und die ChatGPTler aber doch hier so gerne
angefeindet werden, oder?
Zweitens hatte ich eine Reihe solcher WYSIWIG-Editoren ausprobiert,
schon um andere Projektbeteiligte ohne HTML-Kenntnisse besser einbinden
zu können. Daß kein einziger davon imstande war, halbwegs guten Code zu
produzieren, ist nun nicht meine Schuld, ich bin nur Überbringer dieser
schlechten Nachricht. Und das betraf wirklich alle WYSIWIG-Editoren, die
ich im Laufe der Jahre gesehen habe, von Macromedia Dreamweaver (heute
Adobe) über MS Frontpage bis hin zum Mozilla Composer (später SeaMonkey)
und etliche weitere -- ich glaube, sogar NVU und KompoZer habe ich
einmal ausprobiert, als sie noch gelebt haben, aber die sind ja beide
schon so lange tot, daß ich mich nicht genau erinnere.
Ein T. schrieb:> Es gibt schlicht und ergreifend nichts zu überprüfen: die Software gibt> es nicht für mein Betriebssystem und ich werde mir weder eine> Windows-Lizenz, noch einen Macintosh kaufen, um eine Software> auszuprobieren, welche schon seit zwanzig Jahren tot ist.
Hast du keine VM ?
(https://www.chip.de/downloads/Windows-Server-2008_31767145.html)
Solange du dir keine Mühe gibst, und stattdessen lieber heiße Luft
produzierst, solltest du dich mit dem Urteil über Nvu zurückhalten.
Rbx schrieb:> Hast du keine VM ?> (https://www.chip.de/downloads/Windows-Server-2008_31767145.html)
Ich habe ein paar, aber keine mit Windows. Wenn ich eine mit Windows
hätte, würde ich ja nicht schreiben, daß ich kein Windows habe. Und
irgendwie... widerstrebt es mir auch, mir dieses 1,9 GB-Image
herunterzuladen, um damit eine Windows-VM zu installieren, nur um wieder
einmal zu lernen, daß ich überaus gute Gründe dafür habe, daß es hier
kein Windows gibt.
> Solange du dir keine Mühe gibst, und stattdessen lieber heiße Luft> produzierst, solltest du dich mit dem Urteil über Nvu zurückhalten.
Okay, jetzt habe ich mir Mühe gegeben und nach Screenshots gesucht, und
hier [1] den anhängenden Screenshot mit Sourcecode von NVU gefunden.
Dieser hier ist kein Einzelfall, reicht mir aber schon.
1
<!DOCTYPE html ... HTML 4.01 Transitional
HTML Version 4.01, also ohne die ganzen schicken Errungenschaften von
HTML5, und dann auch noch im Kompatibilitätsmodus "Transitional" statt
"Strict".
Die Meta-Angaben sind auch für den Allerwertesten -- standardmäßig ist
da anscheinend ISO 8859-1 eingestellt, denn meine Systeme, Seiten, Texte
und natürlich auch HTML5 laufen alle mit UTF-8.
Und dann der Oberhammer:
Für fetten und / oder unterstrichenen Text gibt es die HTML-Tags "<b>"
und "<u>", meine Güte, und anstelle eines "<br>" für den Zeilenumbruch
wäre es wesentlich schicker gewesen, den ganzen Abschnitt in einen
"<p>"(aragraph), eine "<section>" oder meinetwegen einen "<article>" zu
packen. Ach nee, die letztgenannten gehen ja nicht, ist ja kein HTML5
und deswegen haben wir ja leider gar keine semantischen Tags, wie
schade.
Und siehst Du, mit UTF-8 und ein bisschen Knowledge werden aus den
unlesbaren 131 Zeichen langen Textwüste von NVU das hier:
1
<p>Hola <b>gente</b>, <u>cómo</u> estáis?</p>
Das sind 47 Zeichen, 64% weniger nur für dieses winzige Beispiel, und
ich finde das auch sehr viel besser lesbar. Zudem weniger Traffic -- das
spart Kosten und Ladezeiten bei den Aufrufern!
Jetzt kannst Du natürlich etwas besonders "Kluges" einwerfen wie, daß
ich ja jederzeit in die Quellcodeansicht von NVU gehen und solche Dinge
reparieren könnte. Aber ein Werkzeug, dem ich ständig hinterherlaufen
und auf die Finger gucken muß, ist für mich völlig unbrauchbar. Denn das
kostet mich mindestens dieselbe Arbeitszeit, wie wenn ich es gleich
sauber von Hand schreibe -- und zusätzlich dazu kostet es mich auch noch
Nerven, auf deren Schonung ich mit zunehmendem Alter immer größeren Wert
lege. Deswegen benutze ich prinzipiell keine Tools mehr, für die ich
dann Nanny geben muß.
Darüber hinaus möchte ich Dich gerne kurz daran erinnern, daß die
Diskussion unter Erwachsenen ein bisschen anders läuft, als Du sie
gerade praktizierst. Kurz gesagt ist es nicht meine Aufgabe, Deine
Behauptungen der fehlerlosen Großartigkeit von NVU zu widerlegen --
sondern es ist Deine Aufgabe, Deine Behauptungen zu belegen, daß NVU
ebenso sauberen, kompakten, lesbaren Code schreiben kann wie ich. Wenn
Du schon dabei bist, dann bitte auch für meine genannten Anwendungsfälle
mit Templates. Viel Glück, Spaß und Erfolg! :-)
[1] https://www.usitility.com/nvu/
Thread beobachten
Seitenaufteilung abschalten