Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.javascript > #5255 > unrolled thread

Generelles: per JS neue Seite Aufbauen

Back to article view | Back to de.comp.lang.javascript

Contents

  Generelles: per JS neue Seite Aufbauen Jan Novak <repcom@gmail.com> - 2021-03-22 15:25 +0100
    Re: Generelles: per JS neue Seite Aufbauen Arno Welzel <usenet@arnowelzel.de> - 2021-03-22 19:04 +0100
      Re: Generelles: per JS neue Seite Aufbauen Jan Novak <repcom@gmail.com> - 2021-03-23 07:06 +0100
        Re: Generelles: per JS neue Seite Aufbauen Maik Koenig <usenetspam@maikkoenig.de> - 2021-03-23 11:10 +0100
          Re: Generelles: per JS neue Seite Aufbauen Stefan Reuther <stefan.news@arcor.de> - 2021-03-23 17:36 +0100
            Re: Generelles: per JS neue Seite Aufbauen Arno Welzel <usenet@arnowelzel.de> - 2021-03-23 18:15 +0100
            Re: Generelles: per JS neue Seite Aufbauen Maik Koenig <usenetspam@maikkoenig.de> - 2021-03-23 19:19 +0100
              Re: Generelles: per JS neue Seite Aufbauen Stefan Reuther <stefan.news@arcor.de> - 2021-03-24 17:35 +0100
            Re: Generelles: per JS neue Seite Aufbauen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-26 20:04 +0100
        Re: Generelles: per JS neue Seite Aufbauen Arno Welzel <usenet@arnowelzel.de> - 2021-03-23 14:29 +0100
          Re: Generelles: per JS neue Seite Aufbauen Jan Novak <repcom@gmail.com> - 2021-03-24 07:09 +0100

#5255 — Generelles: per JS neue Seite Aufbauen

Hallo,

ich habe eine generelle Frage zum Vorgehen von Seitenabläufen mit 
Javascript.

Ich habe eine Tabble mit Werten, welche per JS aufgebaut wurde. Nach 
einem Klick auf einen Wert in der Tabelle, soll eine neue Seite 
angezeigt werden, wo ich den angeklickten Datensatz editieren kann. Der 
Klick auf die Tabelle löst ein JS Event aus, das wiederrum lädt den 
Datensatz per Ajax, dieser steht nun in einem objekt zur Verfügung. 
Soweit so gut.

Ich möchte nicht auf der aktuellen Seite (die mit der Tabelle) bleiben 
und mir diese dann ausblenden und alle Elemente per JS erstellen, 
sondern möglichst eine HTML Vorlage verwenden, in die dann der Datensatz 
nur übergeben wird.

Wie wäre ein korrektes Vorgehen?

Mit "window.location.replace" oder "href" könnte ich auf eine ganz neue 
Seite verzweigen, aber das wäre ja ein kompletter Neuaufbau. 
Andererseits: wie übergebe ich dann die Daten dorthin?


Jan

[toc] | [next] | [standalone]

#5256

Jan Novak:

> ich habe eine generelle Frage zum Vorgehen von Seitenabläufen mit 
> Javascript.
> 
> Ich habe eine Tabble mit Werten, welche per JS aufgebaut wurde. Nach 
> einem Klick auf einen Wert in der Tabelle, soll eine neue Seite 
> angezeigt werden, wo ich den angeklickten Datensatz editieren kann. Der 
> Klick auf die Tabelle löst ein JS Event aus, das wiederrum lädt den 
> Datensatz per Ajax, dieser steht nun in einem objekt zur Verfügung. 
> Soweit so gut.
> 
> Ich möchte nicht auf der aktuellen Seite (die mit der Tabelle) bleiben 
> und mir diese dann ausblenden und alle Elemente per JS erstellen, 
> sondern möglichst eine HTML Vorlage verwenden, in die dann der Datensatz 
> nur übergeben wird.

An die "HTML-Vorlage" wird der Datensatz sicher nicht übergeben, sondern
die Angabe, um welchen Datensatz es sich handelt, an ein Script, was
dann die Bearbeitung ermöglichen soll.

> Wie wäre ein korrektes Vorgehen?

Nicht den kompletten Datensatz per XHR abrufen, sondern dem Server
sagen, dass er eine Seite erzeugen soll, auf der man den angeklickten
Datensatz bearbeiten kann.

> Mit "window.location.replace" oder "href" könnte ich auf eine ganz neue 
> Seite verzweigen, aber das wäre ja ein kompletter Neuaufbau. 
> Andererseits: wie übergebe ich dann die Daten dorthin?

In der URL. Die übliche Lösung wäre, dass jede Zeile in der Tabelle ein
eindeutige ID hat, die man als Parameter übergeben kann:

window.location.href="http://server.example/edit-record?id=<ID>

Wobei <ID> eben die ID des Datensatzes ist, den man bearbeiten will.

Den kompletten Datensatz per XHR zu laden egibt nur dann Sinn, wenn auch
die Bearbeitung *ohne* Server-Seite im Client passieren soll, *ohne*
eine andere Seite dafür anzuzeigen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5257

Am 22.03.21 um 19:04 schrieb Arno Welzel:
>> Wie wäre ein korrektes Vorgehen?
> 
>> Mit "window.location.replace" oder "href" könnte ich auf eine ganz neue
>> Seite verzweigen, aber das wäre ja ein kompletter Neuaufbau.
>> Andererseits: wie übergebe ich dann die Daten dorthin?
> 
> In der URL. Die übliche Lösung wäre, dass jede Zeile in der Tabelle ein
> eindeutige ID hat, die man als Parameter übergeben kann:
> 
> window.location.href="http://server.example/edit-record?id=<ID>

Ah, ok, natürlich ... das wäre eine Lösung meines Problems
Zur Info: ... wie machen "großen" Applikation so etwas, welche keinen 
Seitenwechsel haben? Die übergeben das doch nicht auf diese Weise?


> Wobei <ID> eben die ID des Datensatzes ist, den man bearbeiten will.

Klar.

> Den kompletten Datensatz per XHR zu laden egibt nur dann Sinn, wenn auch
> die Bearbeitung *ohne* Server-Seite im Client passieren soll, *ohne*
> eine andere Seite dafür anzuzeigen.

Verstehe, dann war das mein Denkfehler. Hatte zu sehr in php/html 
"gedacht". Danke für den Tip. Manchmal Wald und Bäume und so ;-)


Jan

[toc] | [prev] | [next] | [standalone]

#5258

Am 23.03.2021 um 07:06 schrieb Jan Novak:

> Ah, ok, natürlich ... das wäre eine Lösung meines Problems
> Zur Info: ... wie machen "großen" Applikation so etwas, welche keinen 
> Seitenwechsel haben? Die übergeben das doch nicht auf diese Weise?

https://de.wikipedia.org/wiki/Ajax_(Programmierung)

User löst einen event aus, Javascript erzeugt daraus einen
XMLHttpRequest und wartet dann auf die Antwort des Servers. Die Antwort
wird dann benutzt um die Seite entsprechend anzupassen. Das
Endlosscrolling bei Youtube und Co wird z.B. so gemacht. Diese
Möglichkeit ist ja gerade der Witz bei Ajax.

Als Nutzer ist das deutlich angenehmer als eine neue Seite. Ich frage
mich auch, warum dein Editor unbedingt in einer neuen Seite geladen
werden soll, ich als Nutzer fände ein Overlay für den Editor in 90% der
Fälle deutlich angenehmer.

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
Ich lese die Gruppen in denen ich schreibe: KEINE Mailkopie.

[toc] | [prev] | [next] | [standalone]

#5260

Am 23.03.2021 um 11:10 schrieb Maik Koenig:
> Am 23.03.2021 um 07:06 schrieb Jan Novak:
>> Ah, ok, natürlich ... das wäre eine Lösung meines Problems
>> Zur Info: ... wie machen "großen" Applikation so etwas, welche keinen 
>> Seitenwechsel haben? Die übergeben das doch nicht auf diese Weise?
> 
> https://de.wikipedia.org/wiki/Ajax_(Programmierung)
> 
> User löst einen event aus, Javascript erzeugt daraus einen
> XMLHttpRequest und wartet dann auf die Antwort des Servers. Die Antwort
> wird dann benutzt um die Seite entsprechend anzupassen. Das
> Endlosscrolling bei Youtube und Co wird z.B. so gemacht. Diese
> Möglichkeit ist ja gerade der Witz bei Ajax.
> 
> Als Nutzer ist das deutlich angenehmer als eine neue Seite. Ich frage
> mich auch, warum dein Editor unbedingt in einer neuen Seite geladen
> werden soll, ich als Nutzer fände ein Overlay für den Editor in 90% der
> Fälle deutlich angenehmer.

Es kommt wie immer drauf an. Man darf nicht vergessen: wenn die
komplette Seite neu geladen wird, hat man einen neuen Kontext, auf den
man ein Bookmark setzen kann. In einem Ticketsystem würde mir das
ziemlich auf den Zünder gehen, wenn ich auf ein Ticket, das ich aus
einer Ticketliste geöffnet habe, kein Bookmark setzen kann. Eine
Ein-Seiten-Lösung müsste sowas simulieren (z.B. per Fragment Identifier).

Und Stichwort Endlosscrolling: sehr schön, wenn man nach unten scrollt,
um den Kontakt/AGB-Link zu finden, und das Javascript Inhalte nachlädt
und das weiter runter schiebt. Oder man klickt einen Link, geht zurück
und steht wieder ganz oben.

Vorteil der Ein-Seiten-Lösung ist, dass sie höhere Schwuppdizität bieten
kann und relativ simpel Dinge von einem Kontext in den nächsten
übernehmen kann; wenn du das zweite Ticket anklickst also z.B. gleich
Inhalte aus dem ersten vorschlagen. Wenn man sowas richtig machen will,
ist das aber eben eine riesige Menge Arbeit (die auch noch eine riesige
Menge Code fabriziert, der bei jedem Seitenaufruf auf Vorrat geladen wird).


  Stefan

[toc] | [prev] | [next] | [standalone]

#5261

Stefan Reuther:

> Am 23.03.2021 um 11:10 schrieb Maik Koenig:
[...]
>> Als Nutzer ist das deutlich angenehmer als eine neue Seite. Ich frage
>> mich auch, warum dein Editor unbedingt in einer neuen Seite geladen
>> werden soll, ich als Nutzer fände ein Overlay für den Editor in 90% der
>> Fälle deutlich angenehmer.
> 
> Es kommt wie immer drauf an. Man darf nicht vergessen: wenn die
> komplette Seite neu geladen wird, hat man einen neuen Kontext, auf den
> man ein Bookmark setzen kann. In einem Ticketsystem würde mir das
> ziemlich auf den Zünder gehen, wenn ich auf ein Ticket, das ich aus
> einer Ticketliste geöffnet habe, kein Bookmark setzen kann. Eine
> Ein-Seiten-Lösung müsste sowas simulieren (z.B. per Fragment Identifier).

React.js ändert die komplette URL im Browser ohne dass dazu eine neue
Seite geladen werden muss und man kann solche URLs auch direkt aufrufen.
Dass sich die URL ändert bedeutet also nicht zwangsläufig, dass eine
neue Seite geladen wurde.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5262

Am 23.03.2021 um 17:36 schrieb Stefan Reuther:
> Am 23.03.2021 um 11:10 schrieb Maik Koenig:

>> Als Nutzer ist das deutlich angenehmer als eine neue Seite. Ich frage
>> mich auch, warum dein Editor unbedingt in einer neuen Seite geladen
>> werden soll, ich als Nutzer fände ein Overlay für den Editor in 90% der
>> Fälle deutlich angenehmer.
> 
> Es kommt wie immer drauf an. Man darf nicht vergessen: wenn die
> komplette Seite neu geladen wird, hat man einen neuen Kontext, auf den
> man ein Bookmark setzen kann. 

Du weisst was Sessions sind? Da hilft dir dann das beste Lesezeichen
nichts... Abgesehen davon spricht ja nichts dagegen, bei entsprechenden
Aktionen die Adresszeile des Browsers gleich mit anzupassen. Dazu muss
man nicht zwingend die Seite neu laden.

> Und Stichwort Endlosscrolling: sehr schön, wenn man nach unten scrollt,
> um den Kontakt/AGB-Link zu finden, und das Javascript Inhalte nachlädt
> und das weiter runter schiebt. Oder man klickt einen Link, geht zurück
> und steht wieder ganz oben.

Was den Impressum/AGB-Link betrifft: Ich kenne keine Seite, bei der
entsprechende vorgeschriebene Dokumente aus solchen Gründen nicht
erreichbar sind.
Was das mit dem mangelhaften Rückweg angeht: Das ist Sache derjenigen
die das bauen. Man kann sehr wohl entsprechende Infos zwischenspeichern
und beim Gang zurück wieder laden.

> Vorteil der Ein-Seiten-Lösung ist, dass sie höhere Schwuppdizität bieten
> kann und relativ simpel Dinge von einem Kontext in den nächsten
> übernehmen kann; wenn du das zweite Ticket anklickst also z.B. gleich
> Inhalte aus dem ersten vorschlagen. Wenn man sowas richtig machen will,
> ist das aber eben eine riesige Menge Arbeit (die auch noch eine riesige
> Menge Code fabriziert, der bei jedem Seitenaufruf auf Vorrat geladen wird).

Niemand hat behauptet, Usability wäre schnell zu bauen ;).

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
Ich lese die Gruppen in denen ich schreibe: KEINE Mailkopie.

[toc] | [prev] | [next] | [standalone]

#5264

Am 23.03.2021 um 19:19 schrieb Maik Koenig:
> Am 23.03.2021 um 17:36 schrieb Stefan Reuther:
>> Und Stichwort Endlosscrolling: sehr schön, wenn man nach unten scrollt,
>> um den Kontakt/AGB-Link zu finden, und das Javascript Inhalte nachlädt
>> und das weiter runter schiebt. Oder man klickt einen Link, geht zurück
>> und steht wieder ganz oben.
> 
> Was den Impressum/AGB-Link betrifft: Ich kenne keine Seite, bei der
> entsprechende vorgeschriebene Dokumente aus solchen Gründen nicht
> erreichbar sind.

Wie gesagt, hatte ich schon, weiß aber nicht mehr wo. (Könnte Reddit zu
den Anfangszeiten des "new" Skins gewesen sein?)

Meistens sind das die Seiten, wo ich dann relativ schnell beschließe,
dass die wohl doch nicht so interessant für mich zu sein scheinen wie
ich dachte, als ich den Link anklickte.

> Was das mit dem mangelhaften Rückweg angeht: Das ist Sache derjenigen
> die das bauen. Man kann sehr wohl entsprechende Infos zwischenspeichern
> und beim Gang zurück wieder laden.

Tja, man muss es aber eben machen. Man muss Features nachbauen, die der
Browser einem eigentlich schon gratis gibt. Das klingt jetzt nicht nach
sonderlich kleverem Einsatz von Manpower.

Unpopuläre Meinung: Eine Website bekommt auch gute Schwuppdizität, wenn
man nicht 150 Tracker nachlädt.


  Stefan

[toc] | [prev] | [next] | [standalone]

#5265

Stefan Reuther wrote:

> Am 23.03.2021 um 11:10 schrieb Maik Koenig:
>> Am 23.03.2021 um 07:06 schrieb Jan Novak:
>>> Ah, ok, natürlich ... das wäre eine Lösung meines Problems
>>> Zur Info: ... wie machen "großen" Applikation so etwas, welche keinen
>>> Seitenwechsel haben? Die übergeben das doch nicht auf diese Weise?
>> 
>> https://de.wikipedia.org/wiki/Ajax_(Programmierung)

Veraltet.  Insbesondere Prototype.js wird heute nicht mehr für 
professionelle Anwendungen benutzt: die letzte Version wurde 2015 
veröffentlicht, ist damit hoffnungslos veraltet und mit an Sicherheit 
grenzender Wahrscheinlichkeit nicht nur voller Sicherheitslücken, sondern 
auch inkompatibel zu aktuellen Laufzeitumgebungen.

>> User löst einen event aus, Javascript erzeugt daraus einen
>> XMLHttpRequest und wartet dann auf die Antwort des Servers. Die Antwort
>> wird dann benutzt um die Seite entsprechend anzupassen. Das
>> Endlosscrolling bei Youtube und Co wird z.B. so gemacht. Diese
>> Möglichkeit ist ja gerade der Witz bei Ajax.

Das *war* der Witz.  Seit mehr als 10 Jahren spricht jedenfalls der Profi 
nicht mehr von „Ajax“; nicht zuletzt weil es in jeder Hinsicht eine 
Fehlbezeichnung ist: es muss weder asynchron sein (auch wenn das empfohlen 
wird), es muss nicht JavaScript sein, und übertragen werden in der Regel 
nicht mehr XML-Dokumente, sondern Daten in JSON.

Inzwischen wird XMLHttpRequest(2) auch schrittweise durch das Fetch API 
abgelöst:

<https://developer.mozilla.org/en-US/docs/Glossary/AJAX>

>> Als Nutzer ist das deutlich angenehmer als eine neue Seite. Ich frage
>> mich auch, warum dein Editor unbedingt in einer neuen Seite geladen
>> werden soll, ich als Nutzer fände ein Overlay für den Editor in 90% der
>> Fälle deutlich angenehmer.
> 
> Es kommt wie immer drauf an. Man darf nicht vergessen: wenn die
> komplette Seite neu geladen wird, hat man einen neuen Kontext, auf den
> man ein Bookmark setzen kann. In einem Ticketsystem würde mir das
> ziemlich auf den Zünder gehen, wenn ich auf ein Ticket, das ich aus
> einer Ticketliste geöffnet habe, kein Bookmark setzen kann. Eine
> Ein-Seiten-Lösung müsste sowas simulieren (z.B. per Fragment Identifier).

Deshalb gibt es die Möglichkeit, die auch genutzt wird, dann 
window.location.hash zu setzen bzw. "neu" (das Feature gibt es mindestens 
seit 2011) mit window.history.pushState(…) einen neuen Zustand der 
Applikation zu erzeugen.

<https://developer.mozilla.org/en-US/docs/Web/API/History/pushState>

Die Web-Applikation sollte dann beim Laden des Dokuments 
window.location.hash lesen, um den alten Zustand wiederherzustellen.

Ein bekanntes Beispiel dafür ist Google Maps:

<https://www.google.com/maps/place/London,
+UK/@51.5456632,-0.765196,176645m/data=!3m1!1e3!4m5!3m4!
1s0x47d8a00baf21de75:0x52963a5addd52a99!8m2!3d51.5073509!4d-0.1277583>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#5259

Jan Novak:

> Am 22.03.21 um 19:04 schrieb Arno Welzel:
>>> Wie wäre ein korrektes Vorgehen?
>>
>>> Mit "window.location.replace" oder "href" könnte ich auf eine ganz neue
>>> Seite verzweigen, aber das wäre ja ein kompletter Neuaufbau.
>>> Andererseits: wie übergebe ich dann die Daten dorthin?
>>
>> In der URL. Die übliche Lösung wäre, dass jede Zeile in der Tabelle ein
>> eindeutige ID hat, die man als Parameter übergeben kann:
>>
>> window.location.href="http://server.example/edit-record?id=<ID>
> 
> Ah, ok, natürlich ... das wäre eine Lösung meines Problems
> Zur Info: ... wie machen "großen" Applikation so etwas, welche keinen 
> Seitenwechsel haben? Die übergeben das doch nicht auf diese Weise?

Doch, tun sie ebenso.

Ob man eine neue URL aufruft mit der ID als Parameter oder ob man in der
selben Seite per XHR einen Request mit der ID abschickt, um dann ein
Fragment zur Bearbeitung zurückzubekommen, was man in eine bestehende
Seite einfügt, macht technisch erstmal keinen grundlegende Unterschied.

Du kannst halt entweder eine neue Seite aufbauen, wo man den Datensatz
bearbeitet oder Du änderst den Inhalt der bereits geladenen Seite im
Browser, indem Du dort ein Bearbeitungsformular erzeugst, dessen
Eingaben dann wiederum per XHR an den Server geschickt werden.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5263

Am 23.03.21 um 14:29 schrieb Arno Welzel:
> Jan Novak:
>>> window.location.href="http://server.example/edit-record?id=<ID>
>>
>> Ah, ok, natürlich ... das wäre eine Lösung meines Problems
>> Zur Info: ... wie machen "großen" Applikation so etwas, welche keinen
>> Seitenwechsel haben? Die übergeben das doch nicht auf diese Weise?
> 
> Doch, tun sie ebenso.
> 
> Ob man eine neue URL aufruft mit der ID als Parameter oder ob man in der
> selben Seite per XHR einen Request mit der ID abschickt, um dann ein
> Fragment zur Bearbeitung zurückzubekommen, was man in eine bestehende
> Seite einfügt, macht technisch erstmal keinen grundlegende Unterschied.

OK.


> Du kannst halt entweder eine neue Seite aufbauen, wo man den Datensatz
> bearbeitet oder Du änderst den Inhalt der bereits geladenen Seite im
> Browser, indem Du dort ein Bearbeitungsformular erzeugst, dessen
> Eingaben dann wiederum per XHR an den Server geschickt werden.

Nun, ich denke eine neue Seite aufbauen ist dann doch einfachr, weil ich 
dann andere Templates nutzen kann. Ansonsten würde ja sonst alles immer 
in die gleiche Seite geladen werden. Das wheisst, diese muss jedesmal 
komplett (mehr oder weniger) geleert und wieder aufgebaut werden (mit js).

Ich werde letztendlich eine Mischung aus beiden Möglichkeiten nutzen.
Danke für die Anregungen.

Jan

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.javascript

csiph-web