Kommt dies als Alternative in Frage?
|
|||
Antworten: 5
Seite [1] |
|||
 reVerBGeekboy Beiträge: 1237 |
# Thema - 25.07.2017 um 21:03 Uhr
Hallo allerseits, ich habe da mal eine allgemeine Frage/Umfrage. Das Internet und somit auch die Webentwicklung machen einen ständigen Wandel durch und verschmelzen immer mehr mit der Software, die uns täglich begleitet. Vor allem mobile Apps oder Anwendungen, die Informationen aus dem Netz laden, benötigen einen Zugangspunkt. Aber trotzdem soll das Thema Webseite/Homepage nicht zu kurz kommen. Aus dieser Entwicklung resultiert gerne mal der Wunsch, eine App zu programmieren, die einem mit dem Forum der eigenen Webseite oder dem PN System verbinden. Oder man möchte stationären Anwendungen Informationen wie Bestellungen oder Anfragen aus dem eigenen Shopsystem zur Verfügung stellen. Mit aktuellen Webanwendungen ist es daher nötig, manuell eine Schnittstelle für solche Aufgaben zu implementieren. Ajax, Rest und Webseite unter einen Hut zu bekommen, gestaltet sich schwer, da auch an die unterschiedlichen Schnittstellen unterschiedliche Anforderungen haben. Zur Zeit kommt es vermehrt zu dem Trend, das Content-Management-Systeme an einem Punkt abgeschnitten werden und ab diesem Punkt ein Rest-Interface implementiert wird. So etwas nennt sich Headless-CMS. Das Konzept dahinter ist aber meiner Meinung nach Genial. Datenbankzugriff für so viele Arten von Anwendungen wie möglich. Das CMS selbst ähnelt etwas dem Prinzip von Microsoft Access. Man kann im Backend Tabellen anlegen, Zugriffsrechte für diese definieren und mit Daten füllen. Nun können Word, Excel, Power Point, Publisher, aber auch Software anderer Firmen auf die strukturierten Daten dieser Datenbank zugreifen. Der Clou dabei! Das erstellen von Modulen ist über das Backend einfach möglich. Denn ein Großteil der Module, die zum Beispiel Clansphere besitzt, sind nichts weiter als anlegen, bearbeiten, löschen und anzeigen von Daten aus der Datenbank. Die optische Aufbereitung sowie die Zuweisung der Daten an ein Formular fallen in den Aufgabenbereich des Frontends. Das Frontend hingegen ist in einem Headless-CMS nicht definiert und man hat dadurch alle Freiheiten, die man sich vorstellen kann. Wahl der eigenen Template-Engine. Unabhängige Wahl des CSS-Frameworks. Wohl des JS-Frameworks. Freie Wahl des HTML-Standards (HTML 5, HTML 4, XHTML). Man hat die Wahl, ob man das Frontend in PHP, Python oder Node schreiben will oder ob man komplett auf serverseitige Programmierung verzichten möchte (z.B. Interaktion nur per Ajax). Und auch das verarbeiten der Daten im nachhinein ist problemlos möglich. Oder man nutzt die Daten ausschließlich nur für Apps und Desktop-Programmen. Jeder hat also die Möglichkeit, für ein Headless-CMS ein eigenes Frontend zu entwickeln und anderen zur Verfügung zu stellen, ohne sich in riesige Frameworks oder komplizierte API's einarbeiten zu müssen. Jeder Anfänger kann für solch ein CMS Frontends schreiben. Hier einmal ein grobes Schaubild zu dem Thema:  Hier in diesem Thread kann gerne darüber diskutieren. Aktuell arbeite ich an einem Konzept für ein solches CMS, da mir bisherige Vertreter dieser Gattung (z.B. Directus) zu Schwer (Code-Overhead) bei relativ geringen Funktionsumfang sind. Andere sind Hosted-Services wie Firebase oder Contentful und sind daher kostenpflichtig. Ich hätte da gerne etwas leichgewichtigeres zum selber hosten. Hier auch noch ein interessanter Link zu dem Thema: https://pantheon.io/decoupled-cms Zuletzt editiert von reVerB am 26.07.2017 um 10:57 Uhr (3x Editiert)
|
||
Inaktiv |
|
||
| d3rLenz Beginner Herkunft: Tostedt Beiträge: 5 |
# Antwort: 1 - 04.08.2017 um 23:58 Uhr
Hallo, könnt ja den wieder löschen möchte nur gärne was da zu sagen und nicht nur klicken  ?Also im Ganzen Ist das eine gute sache im fordschrit mit zu zihen. doch das Hebt den einfluss den mann so am soure hat doch gut auf.. wie meine ich das ? wen wir den ein fluss den wir haben auf die datein so haben wir die möglichkeit mehr draus zu machen ehrst in der gestaltung.! Ananwendungs CMS andere host.. oder wie sie alle heissen dennen ihr prob.. ist sie haben alle die gleiche php sache ihre sachen sind auf 1 seite und macht anderre sachen überflüsig so auch für den besucher was er nicht sehen tuht wir den gast nicht intressiren... ohne werbung über goggle wir die besucher zahl fallen. Das ClanSphere ist anders da her ist das grund wessen zimlich Robust und standhaft es so zu verendern kann nicht gut sein. mit freundlich grüssen Manuel |
||
Inaktiv |
  |  |
||
sgraewe  Supporter  Beiträge: 6116 |
# Antwort: 2 - 05.08.2017 um 08:59 Uhr
Verstehe leider überhaupt nicht was du uns sagen möchtest? Grundlegend hat man mit dieser Art von CMS einfach nur mehr Freiheiten was das Frontend betrifft, was du/ihr/jeder daraus macht, ist dann nicht die Sache des Backends, genau wie es bei Clansphere der Fall war. |
||
Inaktiv |
| |
||
| reVerB Thread-Ersteller Geekboy Beiträge: 1237 |
# Antwort: 3 - 05.08.2017 um 12:57 Uhr
Bitte nichts durcheinander werfen. ClanSphere ist ein CMS, bei dem sich die Module selbst um die Daten kümmern. In den allermeisten Fällen handelt es sich dabei um Daten aus der Datenbank holen und Daten in die Datenbank schieben. Der Rest ist eigentlich nur Aufbereitung zur Ansicht auf der jeweiligen Unterseite. Genau wie bei jedem anderen Clan-CMS ist der Ablauf wie folgt: Seite aufrufen:
Dieses Verfahren ist extrem starr und bietet einem kaum Möglichkeiten, Daten aus dem System anderweitig zu verwenden oder das Frontend nach eigenen Vorlieben zu gestalten. Gerade beim Front-End macht die Wartung eines solchen Systems extrem viel Arbeit. Als HTML5 zum Standard wurde, war ClanSphere bereits so gut wie tot. Um es nun in HTML5 zu realisieren, müssen über 600 Theme-Dateien geändert werden. Wenn man dies strikt nach HTML5 tut und dessen semantische Elemente sowie die Kaskade (Formatierung an Hand der semantischen Elemente und dessen Verschachtelung) vornimmt, dann fängt das Geheule wieder an. Die einen schreien danach, das die Themes direkt schon die Bootstrap-Klassen enthalten sein sollen. Dann kommt wieder einer aus der Ecke gekrochen, der über Jahre hier nichts gesagt hat und will statt Bootstrap Foundation, Pure.CSS, Skeleton oder sonst was haben. Diese Frameworks haben allerdings so viele unterschiedliche Elemente, das dynamische CSS-Klassen in den Themes kaum bis garnicht so umzusetzen sind, das zumindest ansatzweise alle zufrieden sind. Die meisten Systeme machen es sich einfach und geben entweder eines, oder keines vor und die Leute müssen entweder damit klar kommen oder es sich in einem langen Fummel-Martyrium zurechtbasteln (z.B. mit über 600 Dateien, wie bei ClanSphere). JQuery per default drin, obwohl man eigentlich ein anderes nutzen will? Das wird nichts werden. Ein Headless-CMS reduziert die Software auf genau die Elemente, die sich in Stein meißeln lassen und nicht großartig geändert werden müssen. Session-Management, Daten-Management, Benutzer- und Rollen-Management. Zugriff gibt es über API's, die sich entweder aus der Ferne oder über eine andere PHP-Anwendung auf dem gleichen Server ansprechen lassen. Alles was also vor diesen API's passiert, kann komplett frei gewählt werden oder man verwendet ein fertiges Frontend eines Drittentwicklers oder eines, das parallel zum CMS angeboten wird. So zwingt man niemanden, sich auf ein Javascript- oder CSS-Framework festzusetzen. Jeder kann selbst entscheiden, ob er als Frontend eine Singlepage-Anwendung, mobile Anwendung oder eine statisch geroutete Seite verwendet. Es ist also im Grunde ein großer offener Stein im Baukasten für Webanwendungen. Und wer sich mal mit anderen Systemen und essen Umsetzung auseinandergesetzt hat, der wird feststellen, das die meisten bekannteren Systeme auch nichts anderes als zusammengesteckte Bausteine sind. Oftmals hat man zwischen verschiedenen Systemen fast genau die gleiche Basis und es unterscheidet sich nur das Frontend. |
||
Inaktiv |
| |
||
| Tom08 Supporter  Herkunft: Daheim Beiträge: 2923 |
# Antwort: 4 - 07.08.2017 um 22:49 Uhr
*argh* Warum ist das Login-Timeout so klein und wieso kann ich mich nicht einloggen und dann meinen Beitrag absenden? fu ... Naja, hier nochmal so in grob was ich vorhin schon mal in ausführlich getippt hatte ... Also an sich finde ich die Idee gut. Ist ja das, was die Daten für alles liefern könnte, was heute gerade State of the Art ist ... Angular, Vue, React ... wie auch immer der letzte Schrei von Javascript-Frontend-Framework-Blödsinn gerade heißt. Für die Abfrage der Daten steht eben eine API mit diversen Endpoints bereit, über die ich nach dem REST-Prinzip kommunizieren kann. Die Frage, die ich mir stelle, ist allerdings wie viele am Ende wirklich gegen die API entwickeln werden? Man darf ja hier auch wieder den Aufwand nicht vergessen und auch die Notwendigkeit für alle Erweiterungen, die ich möglicherweise dem hCMS hinzufügen kann, muss ich ja auch wieder einige Endpoints mehr berücksichtigen. Letztendlich sollte es parallel zu der Entwicklung des headless-CMS (hCMS) dann sicherlich auch eine Referenzimplementierung geben, also eine Variante eines Frontends, welches alle aktuellen Features des hCMS abdeckt, z.B. als Angular App mit einem einfachen Bootstrap-Template und Font-Awesome (nur um mal was zu nennen). Sicherlich werden 95% der Nutzer dann einfach das hCMS herunterladen, installieren und dann die Referenz nehmen und diese dann anpassen. Ich denke die wenigsten werden sich die Mühe machen, wirklich selbst da was zu entwickeln. Und hier hat man dann auch wieder die Problematik man muss im Endeffekt wieder Templates bauen für jede einzelne Seite, es sei denn man löst das irgendwie elegant mit den von der API gelieferten Daten ... aber das ist nicht mal eben so ... Ansonsten prinzipiell: So ganz theoretisch könnte man das auch mit Clansphere bauen. Man verzichtet einfach auf die Aufrufe der Template-Engine und gibt in den mods-Dateien am Ende einfach eine Javascript Object Notation (JSON) als String mit entsprechendem Header zurück statt cs_subtemplate() aufzurufen und das Ergebnis zu echoen. Natürlich ist aber die komplette Codebasis nach über 10 Jahren nicht mehr State of the Art und sie hat auch diverse andere Probleme, nur mal angefangen davon, dass man sich andauernd wiederholt, weil man eigentlich immer dasselbe macht (z.B. Sortierungsparameter abfragen, Paginationparameter, Pagination bauen, Sortierung ermöglichen, Daten abfragen, Daten ausgeben). Da ist sehr viel Wiederholung - ist ganz und gar nicht DRY (Don't repeat yourself). In cSphere, was ja nie fertig wurde, war das schon deutlich besser. Da konnte man in 3 Methodenaufrufen eine komplette Create oder View-Aktion durchführen. Hier fehlte es allerdings teils auch verständlicher Benutzerdokumentation neben der Code-Doku, die auch einen allgemeinen Überblickt gibt, wie eigentlich alles zusammenhängt. Aber ansonsten war hier das Prinzip CoC (Convention over Configuration) weit verbreitet - d.h. es gibt ein Default-Verhalten, welches für die meisten Fälle passt und dementsprechend lässt sich viel Code sparen. Muss gut dokumentiert sein, sonst wird es schnell zu abstrakt und es nur noch schwer nachzuvollziehen. Um auf das hCMS an sich zurückzukommen, hier mal so 2-3 Punkte, die mir so vorschweben, wenn ich grob so ein System konstruieren würde/sollte. Es sollte: 1) Eine extrem einfache Definition eigener Endpoints ermöglichen, d.h. wenn ich ein neues Objekt hinzufügen möchte, z.B. Project, dann sollte das so wenig Aktionen wie möglich erfordern, z.B. - Definition des Datenmodells (als Klasse mit Annotations, XML-Datei, ...), aus welchem automatisch eine entsprechende Struktur zur Speicherung in der Datenbank generiert wird (wobei Datenbank hier auch eine beliebige Speichermöglichkeit ist - z.B. PDO, aber auch Datei, ... ) 2) Automatisch für diesen Datentyp die Grundlegende API bereitstellen: GET /projects - Alle Projekte, die in Datenquelle vorhanden sind POST /projects - Das übergebene Projekt ergänzen oder aktualisieren (in Abhängigkeit von dem Objekt, welches gesendet wurde - z.B. wenn eine ID dabei ist, dann aktualisieren) GET /projects/[ID] - Die Details des Projekts mit der ID [ID] PUT /projects//ID] - Das Projekt mit der ID [ID] erstellen oder aktualisieren DELETE /projects/[ID] - Das Projekt entfernen Zu klären ist hierbei: - Berechtigungen - wie festlegen, welche Aktionen erlaubt sind und für welche Nutzer (RBAC?) - Pagination und Sortierung für GET 3) Für die API automatisch eine abrufbare und durchsuchbare Schnittstellenbeschreibung erstellen, welches es Frontend-Entwicklern erleichtert mit der API zu interagieren. Neben der Beschreibung der Möglichkeiten eben auch welche Parameter nötig sind und ggf. Berechtigungen. 4) Das ganze System muss bereits während der Entwicklung dokumentiert werden. Dabei geht es nicht nur um Code-Dokumentation, sondern auch um Entwicklerdokumentation und erste Schritte, um mit dem System zu interagieren. Der Einstieg muss hier leicht gemacht werden, damit das System auch genutzt werden kann. Ich glaube das war so das, was mir so spontan zu dem Thema eingefallen ist. Grüße ------------------ Bei Problemen mit Code von mir bitte eine
 Private Nachricht an mich |
||
Inaktiv |
| |
||
| reVerB Thread-Ersteller Geekboy Beiträge: 1237 |
# Antwort: 5 - 08.08.2017 um 09:55 Uhr
Hm komisch. Ich habe die Probleme mit dem Logout usw. komischerweise garnicht mehr ^^ Im Grunde ist das was du sagst schon richtig. Das Anlegen von Endpoints stellt keine Herausforderung dar, da ein Headless-CMS zumindest meistens eine Benutzeroberfläche zur Datenverwaltung hat. Ich habe da an virtuelle Datentypen gedacht, die gleich mehrere Fliegen mit einer Klappe schlagen könnten: 1. Man hat eine für sich stehende Definition einer kompletten Tabelle. 2. Die eingegebenen Daten lassen sich automatisch validieren. 3. Es lassen sich automatisch Formulare erzeugen. Aber ich muss auch aktuell leider zugeben, das mich momentan einfach SQL ankotzt bis hinten gegen. Klar ich könnte auch fertige Abstraction-Layer verwenden wie Doctrine und Co. Aber mir missfällt einfach dieses ständige aufblasen einer Software. Mit Doctrine fängt es an, geht weiter mit HTMLPurifier, auch Router gibt es zu hauf. Nehmen wir davon auch einen. Und am Ende ist fast jede dieser fertigen Frameworks/Bibliotheken umfangreicher und komplexer als das ganze ClanSphere CMS. Und am Ende kann das Endergebnis viel weniger. Mal ganz abgesehen, was man seinen Servern damit antut. Da wundert es mich nicht, das ständig von Skalarität geredet wird, wenn man so mit Quellcode-Files herumhurt. Ich bin gerade dabei, mich ein wenig mit dokumentorientierter Datenhaltung und dem Flat-File Prinzip auseinander zusetzen. Da CouchDB oder MongoDB nur selten bei Hostingpaketen dabei sind, muss man anderweitig eine Möglichkeit finden. Die Dateiaufrufe, die ich bei einer Eigenimplementierung einspare, kann ich ja dann getrost auch in ein Flatfile-System stecken. Kann ja auch nicht schlimmer werden als die Schwergewichte, die einem heute als Non-Plus-Ultra verkauft werden. Neben der Überlegung, auf REST zu setzen, schwebt mir auch GraphQL vor. Das blöde ist nur, das GraphQL wieder eine eigene Anfragesprache ist. Sie ähnelt zwar stark dem Aufbau von JSON. Ist aber leider nicht wirklich JSON-kompatibel, was am Ende serverseitig einen zusätzlichen Parser vorraussetzt: http://graphql.org/ Oben im Header ist links die Definition der Struktur. In der Mitte ist die Anfrage und rechts die Response. Und nur diese ist JSON-kompatibel. Wenn einem nur ein Headless-CMS ohne Referenzimplementierung vorgesetzt wird, dann hat ein Entwickler natürlich erst einmal etwas Arbeit. Da hast du schon recht. Aber am Ende hat man mit einem solchen System eben auch ein leichtgewichtiges Framework, welches einem die Arbeit erleichtert. Vor allem dann, wenn einem nicht nur die REST bzw. GraphQL API zur verfügung steht, sondern eben auch eine "native", die den Datenaustausch ohne HTTP-Request erledigt:
Das ist jetzt nur ein Beispiel. Aber so eine direkte API bieten die anderen nicht an. Die liefern lieber Anleitungen, wie man mit cURL an die Daten kommt. Völlig unnötig, wenn Frontend und das Headless-CMS auf dem gleichen Server liegen. Und wenn man auch noch zusätzliche Bibliotheken zur Formularerzeugung und Auswertung mitliefert, dann ist der Aufwand eigentlich schon extrem gering. Die Rückgabe aus DATA::Get muss ja nur noch in die Templateengine gegeben werden und dann war es das doch auch schon. Am Ende wird es vielleicht eine Referenz-Implementierung geben und wenn es das einzige ist, was die meisten nutzen werden, soll einem das auch recht sein. Wenn diese das Potenzial verschenken wollen, ist das auch deren Problem. Fertige CMS-Lösungen nach dem altbewerten Prinzip gibt es genug. Aber wenn ich in ein Clan-CMS noch einmal Zeit versenke, dann wird dieses wahrscheinlich aller höchstens 15 Module haben und so ein Käse wie Imprint, History, FAQ, Rules usw. würde es nicht mehr geben. Alles Murks, der sich auch einfach mit statischen Seiten realisieren lässt. Und genau dann kommen auch wieder die Leute aus den Ecken gekrochen und jammern, weil die Module fehlen. Und genau deswegen bin ich der Meinung. Man macht es ihnen so leicht wie möglich und wenn ihnen etwas nicht passt: "Da ist die Doku ... Machs selbst!" 
Zuletzt editiert von reVerB am 08.08.2017 um 10:01 Uhr (1x Editiert) |
||
Inaktiv |
| |
||
Antworten: 5
Seite [1] |
|||
| Sie müssen sich registrieren, um zu antworten. |
