Aufbau der Programmierung bei "Baukästen-Systemen"

#1
Hallo!
Ich bin noch nicht lange dabei, aber ich kenne von Anfang an diese "Baukästen-Systeme" von Anbietern wie Jimdo, Wix etc.

Wie genau sind diese aufgebaut von der eigenen Programmierung? Letztendlich zieht man ja dann nur eigene Blöcke an die gewünschte Position, aber wie haben die Entwickler bspw. die Oberflächen umgesetzt? Ich würde gerne verstehen, wie man ggf. ähnliche Baukästen aufbauen könnte.

Kennt sich damit jemand aus? Es geht mir nur um die grundlegende Struktur :) Vielleicht hat ja sogar mal jemand von euch soetwas selbst umgesetzt!

Vielen Dank
 
#3
Hi!
Vielen Dank für deine Nachricht - die hilft mir wirklich sehr!
Würdest du sagen, dass man diese Systeme relativ einfach auch umsetzen kann? Der Aufwand nimmt natürlich nach Ausmaß zu, ich meine jedoch nur das Prinzip selbst.

Besten Dank!
 

AGGROStar1991

Well-Known Member
c-b Experte
#4
<rant>
Erstmal vorwort : Die Dinger sind ALLE!!! Trash. Ausnahmslos. Wenn du irgendein Problem damit lösen willst außer "Was könnte ich meinen Studis zeigen als Beispiel für Software die es nie hätte geben dürfen?" ist deine Lösung falsch und dein Problem vermutlich eines das es nicht gibt. Du solltest dich schlecht fühlen sie überhaupt in Erwägung gezogen zu haben und wir alle sollten den Tag verfluchen, an dem der Erste geboren wurde, der so einen vollendet entarteten Verstoß gegen alles das gut und schön ist in der Welt erdacht hat.
</rant>

Ich gehe also im folgenden davon aus dass du dich genauso wie ich nur fragst, wie man mit so etwas Geld verdienen kann ;)

Das hängt von deiner Auffassung von "Aufwand" ab. Was es tun soll, wie großer Müll es sein soll. was du kannst , ob du nur mal mit einer Art html-Tag sowas durchspielen willst als Spaß... angenommen html hätte nur div tags. Dann ist es ja relativ einfach : du schiebst einen div tag rein und im code wird der an der entsprechenden Stelle angefügt. Man nutzt sozusagen im einfachsten Fall aus, dass HTML selbst strukturiert angezeigt wird und aus deinem Clickort auf der Webseite genau auf ein HTML-Element gefolgert werden kann.

mfg
 
Gefällt mir: asc
#5
Haha, zum Glück geht es wirklich um letzteres :D

Vielen Dank für deine hilfreiche Erklärung, wie man sich das, was im Hintergrund geschieht "einfach" vorstellen kann!

Würdest du auch sagen, dass Lodash, React und Zepto erstmal gute Anlaufstellen sind, um in die richtige Richtung zu kommen?

Wie genau kann ich mir dieses "du schiebst ein div tag rein und im Code wird der an der entsprechenden Stelle eingefügt" vorstellen? Ich bin bisher noch nicht dahintergekommen, wie man dieses Verschieben wirklich umsetzen kann :)
Vielleicht kannst du mir ja einen Tipp geben

Beste Grüße!
 

AGGROStar1991

Well-Known Member
c-b Experte
#6
Nicht wirklich. Ich verachte dieses "Wir stopfen einfach noch ein Framework rein"-Ding jenseits deiner Vorstellungskraft. Ich würde mich erstmal fragen, ob man überhaupt eines braucht, ich denke mal nicht(ich habe noch nicht ein Beispiel gefunden, wo diese Dinger irgendwas besser gemacht haben, üblicherweise sorgen sie nur dafür, dass schlechte Webentwickler Kram produzieren den richtig zu machen sie nicht vermögen und damit kommt ultimativ nur noch schneller noch mehr viel zu fetter Müll zu Stande), Frameworkautoren scheinen mir noch so eine Gruppe Wahnsinnige zu sein die als erstes an die Wand gestellt wertden, wenn die Revolution kommt :p
Bei Frameworks in Javascript denk ich immer an einen Typen, der schon bis zum Hals in Gülle steht und zu ertrinken droht, weil ihm schon 10 mal der gleiche Kerl ein "Seil" verkauft hat das sich aber als noch mehr Gülle heraus gestellt hat. Und der Ertrinkende ruft "Hilfe Verkauf mir doch noch mehr Seil!"^^

Stell dir vor : wir haben jetzt einfach mal zwei HTML-Dokumente. Eines wird in deinem Browser angezeigt als Teil deines Views. Eines liegt im Backend. Nun definieren wir für JEDES Element des ersten ein Onclick-Event das in diesem Element ein leeres <div/> anlegt und das danach in das HTML im Backend(das wird deine geklickte Webseite) überträgt, dann können wir über einfaches klicken divs hinzufügen deren Position über das gewählte Element eindeutig bestimmt ist. Das ist nun aber sehr langweilig. also gibt es als zweites eine Auswahlbox dazu und die onclick-funktion fragt dann beispielsweise ab ob es ein <div> oder eine Tabelle sein soll. Das ist immernoch ein bisschen leer. Also gibts als nächstes eine Textbox mit der wir ein Element auch modifizieren und ihm Inhalt außer Children geben können oder vielleicht Attribute setzen. Und das ist es im Grunde.
 
#8
Ich möchte doch noch etwas aufs Thema Frameworks eingehen. Es kommt fast darauf an, wie man den Baukasten bedienen können soll und wie umfangreich die Bedienbarkeit sein soll und wie die Kommunikation mit dem Server abläuft.

Das Ausgabe-HTML (die Webseite) wird fürs Bearbeiten weiterverwendet und die Editor-GUI wird quasi drübergebügelt. Wenn der Editor-Part eine recht komplexe GUI hat (z. B. eine Sidebar mit vielen Tabs, Bäumen, Listen, Dialogfenstern, viel Kommunikation mit dem Server), würde sich ein Framework wahrscheinlich lohnen, aber nur für diesen speziellen Part. Das ganze ist dann quasi zweigeteilt. Die Kommunikation mit der "Außenwelt" (der tatsächlichen Webseite) wird dann aber etwas tricky, da sowas von Frameworks üblicherweise nicht angedacht ist, denn: Die meisten Frameworks können nur mit HTML arbeiten, das sie selbst erstellt haben.

Wenn der Editor eine tiefe Integration mit der Webseite hat, wird es schon schwieriger. Also du klickst z. B. auf einen Bereich und dann erscheint eine kleine Toolbar, in der du Elemente auswählen kannst, die an dieser Stelle eingefügt werden sollen. Ein kontextsensitiver Editor quasi. Dann musst du dir wirklich was eigenes ausdenken, da hier Frameworks anfangen sich wie Fremdkörper anzufühlen.

Was diese tun, ist HTML erzeugen und dieses ggf. nachträglich noch manipulieren. Wenn noch HTML von außen hinzukommt, gibt es eine Art Interessenkonflikt.

Um auf die genannten Beispiele einzugehen:
React wäre ein solches Framework. Die bekanntesten Alternativen dazu sind - ich nenne mal - Vue, Angular und Svelte. Je nach Details der Implementierung sind einige besser geeignet als andere. Aber wie gesagt: speziell hier sehe ich den Sinn etwas auf der Kante wackeln.
Lodash dagegen ist eine Sammlung von simplen Funktionen zur Arbeit mit Objekten, Arrays. Man kann es überall verwenden oder nirgendwo. Ich hoffe, dass es mit der Zeit verschwinden wird, da viele dieser Funktionen nach und nach im Sprachkern von JavaScript landen.
Zepto ist jetzt interessant. Das ist ein Drop-in-Ersatz für jQuery. Beides halte ich inzwischen wirklich für überflüssig. Ähnlicher Grund wie bei Lodash. Die Kombination mit React ist auch etwas seltsam, da hier zwei gegensätzliche Paradigmen aufeinander stoßen. Meine Vermutungen für den Einsatz sind entweder a) oben genanntes Problem mit der Kommunikation zur "Außenwelt" oder b) es wird ein jQuery-Plugin verwendet, welches jQuery/Zepto natürlich auch voraussetzt. Oder beides.

Und zur Frage: Warum Frameworks?
Wie bei jedem externen Code geht's darum, den Entwicklern Arbeit abzunehmen, also Boilerplate-Code zu reduzieren. Um auch ein bisschen auf die Kritik von @AGGROStar1991 einzugehen: Man kann vieles durchaus ohne Framework machen. Ich zieh da einen dicken Strich zwischen Webseiten (Backend generiert HTML) und JS-Anwendungen (Backend ist ein API-Server oder es ist kein Backend vorhanden).

Bei ersterem ist es definitiv möglich, aber je nach Komplexität der Seite wird es doch schwieriger. Frontend-Frameworks können hier aber nicht viel tun. (Das ist ein Thema, das mich derzeit stark interessiert)
Bei letzterem halte ich es nicht für sinnvoll, ohne Framework zu arbeiten. Ich denk mir hier: Verwende ein Framework oder schreib dein eigenes (und genau so sind die Öffentlichen auch entstanden). Wenn du ein Vorhandenes verwendest, sparst du dir Arbeit und andere Entwickler finden sich schneller zurecht.
 
Oben