JavaScript HTML - Objekte auf Server speichern

[matanceros]

Guten Tag zusammen,

ich habe mir gerade ein kleines Tool mittels JavaScript gebastelt und dieses auch online gestellt. Ich kann problemlos darauf zugreifen und es auch von überall nützen, ich möchte aber nun, dass wenn ich in meinem Tool etwas mache (Ich kann z.B.: Dynamisch bestimmte DIVs erzeugen), dass diese Änderung auch zugänglich sind nachdem das Browserfenster geschlossen wurde , am besten auch für mehrere Benutzer über einen speziellen Link definiert.

Wie stell ich das an? PHP, Datenbank auf dem Server?

Hoffe ihr könnt mir weiterhelfen

LG

 

[TheRepatriate]

Kommt drauf an, was du mit dem Tool genau machst. "Bestimmte Divs erzeugen" kling danach als würdest du nur ein paar HTML-Elemente erzeugen/verändern. Möchtest du denn auch Inhalte speichern? Dann würde man typischerweise eine Datenbank nehmen

 

[matanceros]

@TheRepatriate: Danke für die Antwort. Ja möchte auch Inhalte speichern, vorerst nur in Form von Text. Später eventuell Bilder.

 

[CapFuture]

Wenn alles auf dem Client machen willst, schau dir mal den LocalStorage an.. Dort kannst du recht lange Daten speichern.
Falls du aber richtige Persistenz auf dem Server braucht/willst, musst du dich mit den dazugehörigen PHP-Routinen auseinandersetzen.

 

[Daaron]

Es muss nicht PHP sein, auch Perl, Python, Ruby, ASP.NET, C, C++,... würden den Job erledigen. Es muss auch nicht unbedingt eine SQL-Datenbank sein. Man KÖNNTE auch direkt in Dateien speichern, oder dem Hype folgen und einen NoSQL-Ansatz wählen.
Am Ende läuft es aber darauf hinaus: PHP+SQL (z.B. MySQL), das Duo kann man auf quasi jedes Problem werfen.

Aber was genau hast du eigentlich vor? Willst du einen WYSIWYG - Editor schreiben, dessen Ergebnisse eine Webseite persistent verändern sollen? Dann mach es dir leicht, schau dir die notwendigen Schritte von einem der vielen guten Open Source CMS ab.
TinyMCE + PHP + Datenbank = WYSIWYG mit persistenter Lagerung.

 

[matanceros]

@All: Was ich vorhabe:

Ich möchte für mich eine Art To-Do Liste bzw. CRM schreiben wo ich Kategorien (Arbeit, Schule etc.) anlege, und innerhalb dieser Kategorien kann ich dann Personen anlegen, welche wiederum eine Tabelle beinhalten.

Die Kategorien sind - genauso wie die Personen - im HTML "grafisch" eben Divs, wozu eben meine Frage.

@Daaron:
TinyMCE ist nicht das was ich suche, aber trotzdem eine sehr geile Sache!
Danke!

@CapFuture: Auch dir danke für deine Antwort.

LocalStorage war mir ein Begriff, ich möchte aber die Möglichkeit haben auf die selben Daten von mehren Rechner aus zuzugreifen.

Hab mich jetzt ein bisschen mit PHP und Datenbanken beschäftigt und habe geschafft Daten in einer Tabelle abzuspeichern, diese von Dort aufzurufen und anzuzeigen.

So gesehen müsste es doch möglich sein, dass ich per JavaScript das HTML und die entsprechenden Inhalte dynamisch generiere in der Datenbank abspeichere und von dort aus den HTML Dom dynamisch auslese?

Jeder Benutzer bekommt eine per auto-inkrement vordefinierte ID, seine HTML Seite inklusive den Inhalten wird in der Datenbank abgespeichert und jedes Mal wenn ich mich in der Seite "einlogge" (mittels der ID identifiziere) werden die jeweiligen HTML Tags aus der Datenbank geladen und die Seite dynamisch erstellt.

Kann ich das mit JavaScript, MySQL und PHP vollbringen bzw. ist das der richtige Weg?

Danke für die Antworten!

LG

 

[Daaron]

Ich möchte für mich eine Art To-Do Liste bzw. CRM schreiben wo ich Kategorien (Arbeit, Schule etc.) anlege, und innerhalb dieser Kategorien kann ich dann Personen anlegen, welche wiederum eine Tabelle beinhalten.

Die Kategorien sind - genauso wie die Personen - im HTML "grafisch" eben Divs, wozu eben meine Frage.

Dann ist deine Herangehensweise aber falsch. Was du suchst, ist eine relationale Datenstruktur. Du willst nicht wirklich grafisch HTML-Container herum schubsen, du willst eine Eingabemaske, in der du Kategorien, Personen und Tasks anlege und verknüpfen kannst.

So gesehen müsste es doch möglich sein, dass ich per JavaScript das HTML und die entsprechenden Inhalte dynamisch generiere in der Datenbank abspeichere und von dort aus den HTML Dom dynamisch auslese?

Ja, aber wie schon gesagt: die Herangehensweise ist etwas falsch.
Trenne den Kram auf.
- Du hast eine Backend-Logik, die die Daten verwaltet. Diese Logik schreibt deine Personen, Kategorien und Tasks als Entitäten in eine Datenbank und setzt sie in Relation. Diese Logik stellt auch Funktionen bereit, die Daten zu extrahieren.
- Du hast eine Darstellungsschicht, die Daten zum Schreiben an die BE-Logik übermittelt oder lesend von der BE-Logik anfordert. Aus den Daten bastelt diese SChicht dann HTML-Code zusammen, oder sie schreibt die Werte in einen JSON-String, den du dann per JS auswertest und daraus HTML baust.

Du lagerst nicht deine ganzen <div>-Container und <table>-Elemente direkt in der Datenbank. Das ist Quatsch. Du lagerst nur die entscheidenden Schlüsseldaten in der Datenbank: WER hat WAS zu erledigen, und WELCHE Kategorie hat dieser Task.

The Key, the whole key, and nothing but the key! So help me, Codd!

 

[matanceros]

@Daaron: Danke für die Antwort.
Wenn ich das richtig verstanden habe, besitze ich dann von der Struktur eine Datenbank mit drei Tabellen (Kategorien, Personen und Aufgaben)

Der User erstellt eine neue Kategorie und vergibt einen Kategorienamen.
In der Datenbank wird die entsprechende ID und der Kategoriename in der Tabelle "Kategorien" abgespeichert.
Tabelle Personen enthält alle Personen und ist über PK/FK mit Tabelle "Kategorien" verbunden.
Tabelle Tasks enthält alle Personen und ist über PK/FK mit Tabelle "Kategorien".
[...] Über das Normalisieren muss ich mir noch genauer Gedanken machen, aber wie stelle ich es an, dass das HTML dann dynamisch erstellt wird?

So wie ich es bis jetzt mache über JavaScript mittels "createElement()" und Co.?


Danke !
LG

 

[Daaron]

@Daaron: Danke für die Antwort.
Wenn ich das richtig verstanden habe, besitze ich dann von der Struktur eine Datenbank mit drei Tabellen (Kategorien, Personen und Aufgaben)

Du brauchst zusätzlich unter Umständen noch Kreuztabellen, z.B. wenn eine Aufgabe mehrere Kategorien hat oder eine Aufgabe mehreren Personen zugewiesen ist.

[...] Über das Normalisieren muss ich mir noch genauer Gedanken machen, aber wie stelle ich es an, dass das HTML dann dynamisch erstellt wird?

Die Details bleiben dir überlassen.

Eine gängige Praxis (bzw. die wohl gängigste) ist, dass du in PHP (oder einer anderen Server-Sprache) auf deine Datenbank zugreifst, die nötigen Queries auf sie abfeuerst und aus dem erhaltenen Datenset ein HTML-Dokument zusammen baust, dass eben die erhaltenen Daten "hübsch" präsentiert.
Alternativ könntest du ein recht unabhängiges HTML-Grundgerüst bauen, per AJAX die Anfrage nach spezifischen Daten an dein PHP-Script schicken. Das PHP-SCript erledigt dann wieder die Datenbank-Operationen, gibt aber kein komplettes HTML-Dokument zurück, sondern entweder nur ein Teil-Dokument, dass du direkt einfügen kannst, oder aber, das Script gibt die Daten als JSON-String zurück. Jetzt kannst du diese JSON-Antwort mit JavaScript abarbeiten, um daraus die notwendigen DOM-Elemente zu erstellen.

Der Vorteil an Variante 1 ist, dass es ohne JavaScript funktioniert und du sehr geradlinig arbeiten kannst. Du hast z.B. HTML-Templates, in die du z.B. mit simplen echo-Anweisungen Werte aus PHP einträgst, und der ganze Kram gibt am Ende ein hübsches und semantisch vollständiges HTML-Dokument. Du hast eine einfache aber vollständige Abfolge von Request & Response.
Der Vorteil an Variante 2 ist, dass du die endgültige HTML-Struktur (vor allem mit JSON) vollkommen vom Server loslösen kannst. Außerdem brauchts weniger Bandbreite.

 

[matanceros]

Eine gängige Praxis (bzw. die wohl gängigste) ist, dass du in PHP (oder einer anderen Server-Sprache) auf deine Datenbank zugreifst, die nötigen Queries auf sie abfeuerst und aus dem erhaltenen Datenset ein HTML-Dokument zusammen baust, dass eben die erhaltenen Daten "hübsch" präsentiert.

Ok, so weit habe ich das verstanden, glaube ich.

Eine Verständnisfrage dann noch zum Schluss, da ich mich erst in PHP einlesen muss:
Ich erstelle dann nach diesem Schema (http://php.net/manual/de/domdocument.createelement.php)
quasi die Divs und kann diesen auch mit Klassen die in meinem .css file abgespeichert sind, versehen?

LG und Danke!

 

[Daaron]

Warum solltest du? Kein Aas verwendet die DOM-Schnittstelle dafür, um etwas HTML auszugeben. Die DOM-Schnittstelle ist dafür da, dass du z.B. HTML parsen kannst (beispielsweise als Bot), oder dass du XML-Dokumente (RSS, Sitemap,...) sauber erstellen oder auch auslesen kannst. Für n simples HTML-Dokument als Antwort auf einen Request wäre das doch alles Kanonen vs. Spatzen.

Der PHP-Parser ignoriert alles, was außerhalb von <?php ?> steht (oder, wenn aktiv, <? ?>). Also schreib einfach stink normales HTML, und da, wo du dynamische Inhalte benötigst, setzt du jeweils eine neue PHP-Sequenz an. Oder du arbeitest mit echo. Fortgeschrittene verwenden zusätzlich noch den Output Buffer, um später keine Probleme mit Headern zu bekommen, aber das brauchst du hier nicht.

 

[Solidnerd]

Also, an den themen ersteller, warum verwendest du nicht einfach weiter javascript für's backend. Ich kann dir Node.js + Express empfehlen, dann brauchst du nur noch in deinem client die ajax call's machen und alles klappt wunderbar. Auf der Express Seite kümmerst du dich dann um das persistieren der Daten zum Beispiel mit mongo db(NoSQL) ist auch sehr ähnlich zu javascript anstatt einer normalen relationalen datenbank.

 

[CapFuture]

Ist zwar etwas allgemein, aber worauf dich Daaron letztendlich hinweisen will, ist das "MVC-Muster".
Eine sehr gute Lektüre zu dem Thema Entwurfsmuster ist "Entwurfsmuster von Kopf bis Fuß".

Ich denke mit einer soliden Strukturierung werden sich einige (technische) Fragen von selbst lösen.

 

[Solidnerd]

Ist zwar etwas allgemein, aber worauf dich Daaron letztendlich hinweisen will, ist das "MVC-Muster".
Eine sehr gute Lektüre zu dem Thema Entwurfsmuster ist "Entwurfsmuster von Kopf bis Fuß".

Ich denke mit einer soliden Strukturierung werden sich einige (technische) Fragen von selbst lösen.

Ich denke du meinst nicht das MVC Pattern, sondern eher die 3-Schichten-Architektur .

 

[CapFuture]

Sowohl das MVC-Pattern als auch eine 3-Schichten-Architektur sind letztendlich das selbe Prinzip auf unterenschiedlichen Ebenen...
Nicht umsonst steht in dem Wiki Artikel das MVC-Pattern als Referenz drinnen ^^

 

[trialgod]

Es ist irgendwie sehr lustig anzusehen wie kompliziert das WEB doch geworden ist. Früher wurde einem sowas vorgeschlagen:

<?
mysql_connect(...);
$result = mysql_query("SELECT * FROM Kategorien WHERE Id = " + $_GET["id"] + ";");
$row = mysql_fetch_assoc($result);
?>
<h1>Kategorie &quot;<?= $row["name"]?>&quot;</h1>
<h3>Folgende Personen haben Zugriff:</h3>
<ul>
<?
$result = mysql_query("SELECT * FROM Kategorien AS k INNER JOIN Personen p ON k.Id = p.KategorieId WHERE k.Id = " + $_GET["id"] + ";");
while($row = mysql_fetch_assoc($result)) {
    ?> <li><?= $row["vorname]"?> <?= $row["nachname"] ?></li>
}
</ul>

Man hatte mit ein paar Zeilen ein funktionierendes Ergebnis.

Heute kommen alle gleich mit OOP, Layering, MVC, Frontcontroller, DOM Manipulation, AJAX, und sonstwas an

Keine Garantie auf Richtigkeit und sollte so definitiv auch NICHT übernommen werden!

 

[Daaron]

...Auf der Express Seite kümmerst du dich dann um das persistieren der Daten zum Beispiel mit mongo db(NoSQL) ist auch sehr ähnlich zu javascript anstatt einer normalen relationalen datenbank.

...und ich schreib weiter oben sogar noch was von "folgst dem Hype und nimmst NoSQL". Ja nehmt nur alle MongoDB, "'cause it's webscale!"
Mal ne ganz einfache Frage an dich: Warum sollte man ein offensichtliches relationales Problem (Menschen haben Aufgaben, Aufgaben haben Kategorien) in einer nichtrelationalen Datenbank lagern?

Es ist irgendwie sehr lustig anzusehen wie kompliziert das WEB doch geworden ist. Früher wurde einem sowas vorgeschlagen:
...

Und weil dein Beispiel bereits einerseits in modernen PHP-Versionen schon mit großen DEPRECATED-Meldungen um sich wirft (und in zukünftigen gar nicht mehr geht), andererseits aber auch gleich noch eine riesige SQL Injection Lücke aufreißt, sollte man genau solche undurchdachten Beispiele nicht bringen.

Außerdem: Hat sich nicht letztens erst jemand großspurig negativ über PHP geäußert? Waren da nicht Technologien wie .NET (das keinerlei Ökosystem hat) oder ECMAScript 6 (das nicht existiert) DA SHIT? Hieß es im selben Kontext nicht auch immer wieder, dass PHP ja so unsicher ist und man damit nur Scheiße schreibt?
Woher also der Sinneswandel? Warum schreibst du selbst hier totalen Grützcode, der an allen Ecken udn Enden klappert?

Heute kommen alle gleich mit OOP, Layering, MVC, Frontcontroller, DOM Manipulation, AJAX, und sonstwas an

Wenn du wirklich interaktive Anwendungen willst, dann brauchst du AJAX und DOM Manipulation. Geht einfach nicht anders. Objektorientierung? Die sollte man schon allein deshalb nutzen, weil sie die Übersicht fördert und bei Fehlern eher panisch schreit, statt durch Fehler einfach unkommentiert Lücken zu reißen.
Design Patterns wie MVC? Klar, muss nicht sein. Man muss sich auch nicht faschistoid dran halten. Mach ich selbst nicht, ist manchmal einfach Zeitverschwendung.... Aber gerade, wenn man eh bei Null einsteigt, kann man es doch auch gleich RICHTIG lernen und sich die kompakten, aber vollkommen unübersichtlichen und unflexiblen Hacks später erarbeiten, wenn man weiß wie es sauber geht.

 

[trialgod]

Ich habe doch darunter geschrieben, dass man das so nicht mehr machen sollte.

Ich wollte damit nur verdeutlichen, dass es heutzutage um ein x-faches schwieriger geworden ist sich in die Materie einzuarbeiten. Früher war das halt so, da hat sich für so kleine Aufgaben niemand um SQL Injection, XSS oder sonstwas gekümmert. Darum gab es ja so viele PHP "Entwickler" (zumindest welche, die sich selbst so getauft haben) die x-tausend Zeilen langen Grützcode geschrieben haben.

Ich mach es auch lieber komplizierter als es eigentlich ist. Wollte nur aufzeigen, dass es u.U. auch einfacher gehen kann.

Über die Sicherheit von PHP habe ich übrigens nie was gesagt. Sicherheit ist in fast jeder Sprache mit den gleichen Mitteln zu bewältigen.

Ich bin hier völlig deiner Meinung Daaron, also ganz ruhig bleiben. Zu den anderen Themen schreibe ich jetzt mal nix, weil es hier einfach Offtopic ist ;-)