Zeilenweises lesen einer (Text?)Datei in HTML

[Don]

Hi. Bin HTML Neuling und habe ein wenig Probleme bei einer HTML-Aufgabe. Will mehrere Textstrings, welche mit einer ID (Nummerisch oder auch Textstring) versehen sind, in einer Datei (denke an eine Textdatei, kann aber auch was anderes sein) hinterlegen und dann je nach Bedarf die richtige Zeile mit Hilfe der ID in einer HTML auslesen und in einem Popupfenster ausgeben. Brauche dafür quasi eine Tabelle mit 2 Spalten die ich in einer externen Datei hinterlege. Eine Spalte mit einem "Zuordnungsparameter", die Zweite mit wiegesagt Fliesstext.

             ID     ||     Text
             -------------------
             ID1    || "BLABLABLA1"    
             ID2    || "BlaBLUBB2"         usw.

Kann man das mit Hilfe von Javascript und HTML umsetzen? Und wenn ja, wie?

dank euch schonmal für die eventuelle Hilfe ;), Don

[j4nk3y]

Guten Morgen,

Kann man das mit Hilfe von Javascript und HTML umsetzen? Und wenn ja, wie?

Wie wäre es mit PHP und einer MYSQL Datenbank?

Gruß
Jo

[Don]

Hi. Hab auch schon daran gedacht. Ist denke ich die elegantere und bessere Lösung. Jedoch habe ich keine Ahnung von PHP und auch bei MYSQL bin ich schon ewig raus. Wüsste nichtmal was ich f+r beides installieren müsste und auch nicht wie ich umsetzen soll. Mich da bis morgen einzulesen ist denke ich ein wenig knapp. Java bin ich ein wenig fitter drin und die Daten irgendwie aus einer Textdatei rauszuholen hab ich mir ein wenig einfacher vorgestellt als die PHP Variante. TxT-Inhalt mit JavaScript in ne Variable knallen und dann mit n paar Schleifchen und der übermittelten Id den richtigen Teil aus dem String rausholen, in ne Variable knallen und wieder ans HTML übermitteln... oder sowas in der Art. Naja, ich schau gleich mal weiter

[Gunnar Bittersmann]

@@Don

Will mehrere Textstrings, welche mit einer ID (Nummerisch oder auch Textstring) versehen sind, in einer Datei (denke an eine Textdatei, kann aber auch was anderes sein) hinterlegen und dann je nach Bedarf die richtige Zeile mit Hilfe der ID in einer HTML auslesen und in einem Popupfenster ausgeben.

1. Was heißt „je nach Bedarf“?
   a) Steht der Bedarf beim Laden der Seite schon fest (d.h. die Strings können schon serverseitig in HTML geschrieben werden) oder
   b) ergibt sich der Bedarf erst während der Interaktion?

2. Was heißt „mehrere“? Wie viele?
   a) Sind es so viele, dass es sich verbietet, die Datei mit den Strings komplett zum Nutzer zu schicken, wenn doch nur einige wenige davon benötigt werden?
   b) Oder sind es nur ein paar Strings, deren Größe kaum ins Gewicht fällt?

Kann man das mit Hilfe von Javascript und HTML umsetzen?

Wenn die Antwort auf 1. und 2. jeweils b) ist, dann ja.

Du könntest die Texte in eine JavaScript-Datei tun, die du einbindest, bevor du auf die Strings zugreifst:

var texte = {
	"1": "Am Anfang war das Wort.",
	"Prediger": "Jegliches braucht seine Zeit."
}

Zugriff dann per texte['1'] bzw. texte['Prediger'].

Oder ohne var texte = als JSON-Datei:

{
	"1": "Am Anfang war das Wort.",
	"Prediger": "Jegliches braucht seine Zeit."
}

Diese dann per AJAX laden, JSON parsen.

Wenn die Antwort auf 2. a) ist, dann brauchst du ein API, dass dir auf Abfrage einen String zurückgibt; bspw. https://example.com/text/1 liefert "Am Anfang war das Wort."; https://example.com/text/Prediger liefert "Jegliches braucht seine Zeit.".

Im Backend hast du die entsprechende Textdatei in bspw. in PHP – oder genauso als JSON. Oder du verwendest – wie j4nk3y sagte – ein Datenbanksystem. Das wäre hier aber vermutlich Overkill.

Gleiches auch bei 1. a), nur dass du die Texte mit PHP (o.a.) gleich ins generierte HTML schreibst.

LLAP 🖖

[Don]

also zu 1: der Bedarf steht am Anfang noch nicht fest. Der Anwender sucht sich in dem Fall ein Themengebiet aus einer Liste aus und klickt auf einen Link. Zu dem gewählten Themengebiet soll dann aus der Datei der passende Erklärungstext oder themenbezogene Sourcebeispiele mittels der ID, welche hinter dem Link steckt ausgelesen werden und dann in einem neuen (Popup)Fenster im HTML ausgegeben werden.

zu 2.: Die Menge (der auswählbaren Themen) ist mir überlassen. Kann 10, aber auch 200 Erklärungstexte beinhalten. Das Projekt ist nur zu Übungszwecken. Habe in dem Fall an eine überschaubare Menge von 20-30 gedacht. Jeder Text soll dann so um die 6-8 Zeilen umfassen.

[Gunnar Bittersmann]

@@Don

also zu 1: der Bedarf steht am Anfang noch nicht fest.

Doch, das steht fest. Bei 1 geht es darum, wie die Anwendung funktioniert. Ob bei Nutzeraktion eine neue serverseitig gerenderte Seite aufgerufen wird oder ob es sich um eine single page app handelt, wo alles clientseitig läuft.

zu 2.: Die Menge (der auswählbaren Themen) ist mir überlassen. Kann 10, aber auch 200 Erklärungstexte beinhalten.

Das sollte man sich schon vorher überlegen, da davon abhängt, wie man das implementiert.

Habe in dem Fall an eine überschaubare Menge von 20-30 gedacht. Jeder Text soll dann so um die 6-8 Zeilen umfassen.

Macht dann so in etwa 200 Zeilen, so in etwa 1500 Zeichen. Überschaubar.

LLAP 🖖

[Rolf b]

Währen die Koryphäen diskutieren, hätte ich noch einen Vorschlag für eine relativ simple Lösung.

Du sagst, Du hättest eine Anzahl von IDs, zu denen Du Erklärungen hinterlegen willst. Ich nehme mal an, dass Du diese IDs selbst wählen kannst (z.B. den verwendeten Zeichenvorrat so begrenzen, dass eine ID eine Datei im Filesystem deines Servers ansprechen kann).

Du könntest nun aus der ID die URL einer Datei zusammenbauen, die die gewünschte Erklärung enthält. Wie Du diese Datei gestaltest, ist Dir überlassen. Du kannst primitiv zeilenweisen Text hineinschreiben, oder auch ein HTML-Fragment daraus machen.

Den Dateiinhalt lädst Du mit einem Ajax-Request in einen passenden Container in deinem Popup. Diesem Container gibst Du mit CSS passende Styles (wenn deine Erklärungsdatei manuell Zeilen umbricht, wäre ein white-space angebracht mit Wert pre oder pre-wrap). Der Ajax-Request ist ein Einzeiler, wenn Du eine Helper-Bibliothek verwendest. Ich bin trotz allen Totredens immer noch ein Fan von jQuery, da wäre es die load Funktion, mit der Du ein einem Rutsch ein Stück Text vom Server holst und in einen Container einsetzt. JQuery hat den Vorteil, fast überall zu funktionieren. Es hat den Nachteil, dafür den entsprechenden Ballast überallhin mitzuschleppen. Es gibt sicherlich Alternativen für Ajax-Requests, hier habe ich einen Vergleich gefunden. fetch() bzw. der Polyfill dazu klingt sehr interessant, weil es in Chrome, Firefox und MS Edge native ist. Ich habe es selbst aber noch nicht verwendet.

Rolf

[pl]

Hi.

Kann man das mit Hilfe von Javascript und HTML umsetzen?

Freilich: Mit der File API z.B. könnte das eine Offline-App werden.

Und wenn ja, wie?

Der Benutzer wählt im Browser die Datei, die lokal vorliegen muss. Nach der Auswahl der Datei wird die Tabelle ins DOM geladen und der Benutzer kann mit Klick auf einen Eintrag das Popup erzeugen.

Wir brauchen: Die Datei, eine JS-Funktion welche aus der Datei (Sequenz) ein Array mit Objekten erstellen kann (de-Serializer) und ein Template, was mit diesem Array gerendert wird.

Willste Beispiel?

PS: JS kann mittlerweile auch mit Binaries umgehen. D.h. dass es auch möglich ist, Multimedia-Dateien zu verwenden mit Video, Grafik, Audio.

[pl]

Hi.

Kann man das mit Hilfe von Javascript und HTML umsetzen?

Freilich: Mit der File API z.B. könnte das eine Offline-App werden.

Und wenn ja, wie?

Der Benutzer wählt im Browser die Datei, die lokal vorliegen muss. Nach der Auswahl der Datei wird die Tabelle ins DOM geladen und der Benutzer kann mit Klick auf einen Eintrag das Popup erzeugen.

Wir brauchen: Die Datei, eine JS-Funktion welche aus der Datei (Sequenz) ein Array mit Objekten erstellen kann (de-Serializer) und ein Template, was mit diesem Array gerendert wird.

Willste Beispiel?

Tipp: Erstelle die Datei als JSON (Array mit Objekten). Jedes Objekt enthält die Daten für eine Zeile der Tabelle (Spaltenname => Wert). Fürs Template guckst Du Mustache.

[Don]

dank euch auf jeden fall erstmal. und das Beispiel nehm ich gerne

[Gunnar Bittersmann]

@@pl

Tipp: Erstelle die Datei als JSON (Array mit Objekten). Jedes Objekt enthält die Daten für eine Zeile der Tabelle (Spaltenname => Wert).

Bringt das gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile?

LLAP 🖖

[pl]

@@pl

Tipp: Erstelle die Datei als JSON (Array mit Objekten). Jedes Objekt enthält die Daten für eine Zeile der Tabelle (Spaltenname => Wert).

Bringt das gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile?

Nunja, die Datenstruktur muss ja auch zur Templating-Engine passen. Was ein Array mit Objekten tut, womit die TE eine Tabelle rendert.

MfG

[Gunnar Bittersmann]

@@pl

Tipp: Erstelle die Datei als JSON (Array mit Objekten). Jedes Objekt enthält die Daten für eine Zeile der Tabelle (Spaltenname => Wert).

Bringt das gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile?

Nunja, die Datenstruktur muss ja auch zur Templating-Engine passen. Was ein Array mit Objekten tut, womit die TE eine Tabelle rendert.

Deine Antwort lässt mich zweifeln, ob du die Frage verstanden hast.

Also nochmals: Was hätte ein Array mit Objekten

[
	{
		"1": "Am Anfang war das Wort."
	},
	{
		"Prediger": "Jegliches braucht seine Zeit."
	}
]

für Vorteile gegenüber einem Objekt?

{
	"1": "Am Anfang war das Wort.",
	"Prediger": "Jegliches braucht seine Zeit."
}

LLAP 🖖

[pl]

@@pl

Tipp: Erstelle die Datei als JSON (Array mit Objekten). Jedes Objekt enthält die Daten für eine Zeile der Tabelle (Spaltenname => Wert).

Bringt das gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile?

Nunja, die Datenstruktur muss ja auch zur Templating-Engine passen. Was ein Array mit Objekten tut, womit die TE eine Tabelle rendert.

Deine Antwort lässt mich zweifeln, ob du die Frage verstanden hast.

Du hast weder das Beispiel angeschaut noch die Antwort verstanden, also nochmal: Wenn Du nur ein Objekt hast, wird die TE auch nur eine Zeile darstellen.

[Gunnar Bittersmann]

@@pl

Tipp: Erstelle die Datei als JSON (Array mit Objekten). Jedes Objekt enthält die Daten für eine Zeile der Tabelle (Spaltenname => Wert).

Bringt das gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile?

Nunja, die Datenstruktur muss ja auch zur Templating-Engine passen. Was ein Array mit Objekten tut, womit die TE eine Tabelle rendert.

Deine Antwort lässt mich zweifeln, ob du die Frage verstanden hast.

Du hast weder das Beispiel angeschaut noch die Antwort verstanden

Ich hab mir das Problem des OP angeschaut und so wie ich es verstanden habe, hat deine Antwort nichts damit zu tun.

„Sehr guter Ansatz, Hoëcker. Aber für eine ganz andere Frage.“

also nochmal: Wenn Du nur ein Objekt hast, wird die TE auch nur eine Zeile darstellen.

Außerdem: Warum sollte die TE nicht auch über alle Name/Wert-Paare eines Objekts iterieren können?

LLAP 🖖

[pl]

hi,

Ich hab mir das Problem des OP angeschaut und so wie ich es verstanden habe, hat deine Antwort nichts damit zu tun.

Aha.

„Sehr guter Ansatz, Hoëcker. Aber für eine ganz andere Frage.“

Mit meinem Lösungsvorschlag wäre diese Hausaufgabe längst fertig. Und wie das so ist mit Schablonenarbeit: Eine gute Basis für einen Produktivbetrieb ähnlich gelagerter Problemstellungen ;)

also nochmal: Wenn Du nur ein Objekt hast, wird die TE auch nur eine Zeile darstellen.

Außerdem: Warum sollte die TE nicht auch über alle Name/Wert-Paare eines Objekts iterieren können?

Du wirst lachen: Genau das macht eine (jede) TE.

MfG

[Gunnar Bittersmann]

@@pl

also nochmal: Wenn Du nur ein Objekt hast, wird die TE auch nur eine Zeile darstellen.

Außerdem: Warum sollte die TE nicht auch über alle Name/Wert-Paare eines Objekts iterieren können?

Du wirst lachen: Genau das macht eine (jede) TE.

Ich lache schon.

Also nochmal zurück zu: „Wenn Du nur ein Objekt hast, wird die TE auch nur eine Zeile darstellen.“

Du erkennst den Widerspruch?

LLAP 🖖

[pl]

{
	"1": "Am Anfang war das Wort.",
	"Prediger": "Jegliches braucht seine Zeit."
}

Mehrere Zeilen in einem Objekt:

{
 ['col1', 'col2', 'col3'...],
 [...]
}

Ist aber nicht so schön, weil die Spalten anonym sind. Fraglich auch, ob es eine TE gibt, die mit einer solchen Datenstruktur zurecht kommt.

[Gunnar Bittersmann]

@@pl

{
 ['col1', 'col2', 'col3'...],
 [...]
}

Ist aber nicht so schön, weil die Spalten anonym sind. Fraglich auch, ob es eine TE gibt, die mit einer solchen Datenstruktur zurecht kommt.

Von solch einer Datenstruktur war keine Rede.

BTW, du weißt, warum der Syntax-Highlighter deinen ganzen Code als fehlerhaft anmeckert? Tip: Es liegt nicht (nur) an den ....

LLAP 🖖

[pl]

@@pl

{
 ['col1', 'col2', 'col3'...],
 [...]
}

Ist aber nicht so schön, weil die Spalten anonym sind. Fraglich auch, ob es eine TE gibt, die mit einer solchen Datenstruktur zurecht kommt.

Von solch einer Datenstruktur war keine Rede.

Sie trägt jedoch zum Verständnis bei, weil: Platzhalter in einem Template brauchen Namen. Ergo ist obenstehende Datenstruktur für eine TE ungeeignet, weil die Werte keine Namen haben.

Von daher brauchen wir ein Objekt für jede Zeile und wenn es mehrere Zeilen werden sollen, ein Array mit Objekten.

MfG

[Gunnar Bittersmann]

@@pl

Sie trägt jedoch zum Verständnis bei, weil: Platzhalter in einem Template brauchen Namen. Ergo ist obenstehende Datenstruktur für eine TE ungeeignet, weil die Werte keine Namen haben.

Ja.

Von daher brauchen wir ein Objekt für jede Zeile und wenn es mehrere Zeilen werden sollen, ein Array mit Objekten.

Nein.

LLAP 🖖

[pl]

@@pl

Sie trägt jedoch zum Verständnis bei, weil: Platzhalter in einem Template brauchen Namen. Ergo ist obenstehende Datenstruktur für eine TE ungeeignet, weil die Werte keine Namen haben.

Ja.

Es gibt tatsächlich TE's die mit namenlosen Platzhaltern arbeiten wie z.B.:

sprintf("Name: %s\nVorname: %s", $name, $vname);

Von daher brauchen wir ein Objekt für jede Zeile und wenn es mehrere Zeilen werden sollen, ein Array mit Objekten.

Nein.

Freilich würde es auch mit anderen Datenstrukturen funktionieren, bspw. würde es auch ein einfaches Array tun. Aber wie gesagt, es hängt von den verfügbaren TE's ab wie die Datenstruktur aussehen muss. Die TE Mustache die ich hier namentlich genannt hatte, braucht ein Array mit Objekten:

[
  {
    Name    => $name, 
    Vorname => $vname, 
    Ort     => $ort
  },        # 1. Zeile
  {usw.},   # 2. Zeile usw
]

Und so heißen die Platzhalter in jeder <td>{{Name}}</td> so wie die Schlüssel in obenstehender Datenstruktur. Alle TE's die ich kenne, funktionieren auf diese Art und Weise und auch die beiden TE's die ich für Perl bzw, JavaScript selbst entwickelt habe funktionieren mit denselben Datenstrukturen.

Des Weiteren ist es in Perl wie auch in PHP möglich, SQL-Ergebnismengen auf solch eine Datenstruktur -- Array mit Hashreferenzen/Array mit Objekten -- zu lesen (Slice-Option in Perl) und damit unmittelbar eine TE zu füttern. Dabei ist es unerheblich, ob dazwischen ein Transport-Layer eingeschaltet ist, genau dieser wird in dem Augenblick transparent, wenn alle TE's mit denselben Datenstrukturen zurechtkommen.

Vielleicht verstehst Du ja jetzt, dass die Frage der Datenstruktur nicht etwa eine Frage der Willkür ist sondern eine Frage der Zweckmäßigkeit. Eher nebensächlich hingegen ist die Frage der Verpackung für den Transport; das kann ein beliebiger Serializer erledigen und so ist JSON nur eine von vielen Möglichkeiten.

Ebenso ist es abstrakt gesehen auch egal, auf welchem Wege die Daten in die Anwendung kommt, File-API, Ajax-Response oder über Santa Claus ;)

[Gunnar Bittersmann]

@@pl

Vielleicht verstehst Du ja jetzt, dass die Frage der Datenstruktur nicht etwa eine Frage der Willkür ist sondern eine Frage der Zweckmäßigkeit.

Ich verstehe das schon – die ganze Zeit. Deshalb stellte ich ja die Frage: „Bringt das [Array mit Objekten] gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile?“ Du bist seit sechs Postings einer Antwort ausgewichen …

Freilich würde es auch mit anderen Datenstrukturen funktionieren

… und hast dich in Widersprüche verstrickt: Einerseits erkennst du: „Genau das [über alle Name/Wert-Paare eines Objekts iterieren] macht eine (jede) TE.“

Nichtdestotrotz behauptest du: „Von daher brauchen wir ein Objekt für jede Zeile und wenn es mehrere Zeilen werden sollen, ein Array mit Objekten.“

Die TE Mustache die ich hier namentlich genannt hatte, braucht ein Array mit Objekten:

Das ist wohl definitiv falsch.

Der erste Suchtreffer nach „mustache template engine“ führt mich direkt zum Mustache Manual. Und gleich im ersten Beispiel ganz oben wird über alle Name/Wert-Paare eines Objekts iteriert. Nichts mit Array mit Objekten.

Also nochmal meine Frage: Bringt ein Array mit Objekten gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile? (Unterschied im Code)

Und jetzt mal bitte Butter bei die Fische und nicht wirres Zeug quatschen.

LLAP 🖖

[pl]

Die TE Mustache die ich hier namentlich genannt hatte, braucht ein Array mit Objekten:

Das ist wohl definitiv falsch.

Der erste Suchtreffer nach „mustache template engine“ führt mich direkt zum Mustache Manual. Und gleich im ersten Beispiel ganz oben wird über alle Name/Wert-Paare eines Objekts iteriert. Nichts mit Array mit Objekten.

Da hast Du definitiv nicht alles gelesen.

Also nochmal meine Frage: Bringt ein Array mit Objekten gegenüber einem Objekt, das alle Zeilen enthält, irgendwelche Vorteile? (Unterschied im Code)

Und jetzt mal bitte Butter bei die Fische und nicht wirres Zeug quatschen.

Gib Dir mal ein bischen mehr Mühe beim Lesen der Gebrauchsanleitung.

RTFM

[Gunnar Bittersmann]

@@pl

Und jetzt mal bitte Butter bei die Fische und nicht wirres Zeug quatschen.

Gib Dir mal ein bischen mehr Mühe beim Lesen der Gebrauchsanleitung.

Und ich sagte noch „Butter bei die Fische“ … Ich geb’s auf.

LLAP 🖖

[Fischkopp]

moin

Und ich sagte noch „Butter bei die Fische“ … Ich geb’s auf.

Vielleicht konnte @Pl damit einfach nichts anfangen?

tschüss

[pl]

@@pl

Und jetzt mal bitte Butter bei die Fische und nicht wirres Zeug quatschen.

Gib Dir mal ein bischen mehr Mühe beim Lesen der Gebrauchsanleitung.

Und ich sagte noch „Butter bei die Fische“ … Ich geb’s auf.

Wäre ja noch schöner, einfach aufzugeben. Deswegen noch ein Versuch, Dich zum Verständnis der Arbeitsweise einer TE zu bewegen. HTML::Template kriegt zum rendern einer Loop nämlich genau dieselbe Datenstruktur wie Mustache: Ein Array mit Objekten. In Mustache sieht das so aus:

// einfaches Objekt,
// z.B. für Adressetiketten
Mustache.render(template, {key:value});

// Loop f. Tabelle
Mustache.render(template, { loop: [{}, {}, {}] });
//                                ^ Array mit Objekten
//                        ^ Objekt

Das ist halt der Unterschied: Ist nur ein Adressetikett zu rendern, reicht ein Objekt. Ist jedoch eine Tabelle zu rendern, wird für jede Zeile ein Objekt gebraucht und somit ein Array mit Objekten für die gesamte Tabelle.

Deswegen ist es auch kein Zufall oder eine Frage der Willkür, dass alle TE's mit demselben abstrakten Datentyp arbeiten, sondern eben eine Frage der Zweckmäßigkeit: Ein Array mit Objekten ist ideal zum Halten tabellarischer Daten für den wahlfreien Zugriff. Während die Zeile über den Array-Index adressierbar ist, sind die Spalten namentlich ansprechbar. mfg

[Gunnar Bittersmann]

@@pl

Das ist halt der Unterschied: Ist nur ein Adressetikett zu rendern, reicht ein Objekt.

Und das genau ist hier der Fall. Es handelt sich um eine Menge von key/value-Paaren: Bezeichner und zugehöriger Text.

Ist jedoch eine Tabelle zu rendern, wird für jede Zeile ein Objekt gebraucht und somit ein Array mit Objekten für die gesamte Tabelle.

Von einer Tabelle mit mehr als zwei Spalten war beim vorliegenden Problem keine Rede. Die hast du erst ins Spiel gebracht – aus Gründen, die mir vorborgen bleiben. Eine Hotti-Antwort am Problem vorbei.

Die Frage bleibt: Warum eine überdimensionierte Datenstruktur, die hier nicht erforderlich ist?

LLAP 🖖

[Rolf b]

Lokaler Zugriff per File-API? Hab ich da was falsch verstanden? Eine normale Webseite kann doch nicht auf das Filesystem des Browsenden zugreifen - es sei denn, man befindet sich in einem Kontext mit Sonderrechten. Abgesehen davon muss die Datei (oder die Dateien) dann erstmal auf den PC des Anwenders gelangen. Ich glaube, davon war beim OP keine Rede.

Rolf

[JürgenB]

Hallo,

Lokaler Zugriff per File-API? Hab ich da was falsch verstanden? Eine normale Webseite kann doch nicht auf das Filesystem des Browsenden zugreifen

Doch, per File Reader Api.

Und im FF geht das Lesen lokaler Dateien auch per http-Rquest. Aber da Don die Dateien wohl auf dem Server liegen hat, ist hier http-Rquest das (oder ein) Mittel der Wahl.

Gruß
Jürgen

[Rolf b]

Doch, per File Reader Api.

Sorry, habe mich undeutlich ausgedrückt. Ich meinte eigenständigen und ggf. unbemerkten Zugriff ohne Benutzerinteraktion. Beim File/FileReader API muss der User eine Fileliste per input Element vorgeben oder ein File herbeizerren und droppen.

Dass es nicht das Mittel der Wahl ist, steht bei fast allen außer Frage... Eine Offline-Application, wie von PL in Spiel gebracht, könnte LocalStorage benutzen, muss den dann aber erstmal vom Web downloaden.

Rolf

[JürgenB]

Hallo

Doch, per File Reader Api.

Sorry, habe mich undeutlich ausgedrückt. Ich meinte eigenständigen und ggf. unbemerkten Zugriff ohne Benutzerinteraktion. Beim File/FileReader API muss der User eine Fileliste per input Element vorgeben oder ein File herbeizerren und droppen.

ach so.

Dass es nicht das Mittel der Wahl ist, steht bei fast allen außer Frage... Eine Offline-Application, wie von PL in Spiel gebracht, könnte LocalStorage benutzen, muss den dann aber erstmal vom Web downloaden.

ich habe zwei „Web-Aps“, die ohne File Reader Api kaum realisierbar wären, die ihre Input-Daten lokal vorliegen.

Gruß
Jürgen

[pl]

hi,

ich habe zwei „Web-Aps“, die ohne File Reader Api kaum realisierbar wären, die ihre Input-Daten lokal vorliegen.

Neu ist nur der Begriff App. Hier ein Beispiel für eine On/Off Anwendung, Stichwort Replik.

[JürgenB]

Hallo

Neu ist nur der Begriff App. Hier ein Beispiel für eine On/Off Anwendung, Stichwort Replik.

wo habe ich was von „neu“ geschrieben?

Gruß
Jürgen

[pl]

Lokaler Zugriff per File-API?

Klar doch. Der Aufgabenstellung entsprechend war es doch nicht näher festgelegt, woher die Datei kommt. Die Frage war, ob es mit JavaScript und HTML machbar ist.

Ob die Daten für die Anwendung von der lokalen Festplatte kommen oder per Ajax oder aus der Anwendung selbst, ist letztendlich aber auch sowas von egal. mfg