WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Frontend-Edit Überlegungen

<< < (6/11) > >>

chio:
Naja - dann ist dieser Teil ja einfacher als ich gedacht habe.

Ein Modul muss es trotzdem werden, weil es weitere Dateien gibt, die an einem festen Ort sein müssen.
Header, Footer, Bildchen zb.
Außerdem sollte es möglich sein, die Dinger auszutauschen.

escpro:
Mir und ein_paar_anderen reichts  :-P
aber vorsicht: wer einmal drinsteckt kommt aus der Frontend-Sucht nicht so schnell wieder raus!

--- Quote from: chio on July 29, 2010, 10:24:06 AM ---Naja - dann ist dieser Teil ja einfacher als ich gedacht habe.
--- End quote ---

Ich versuchs mal anders...
Wo sollen sich denn die "Bildchen" bei dir befinden ? /modules/deinirgendwas/ ?
Evtl ist es sinnvoll mal zu überdenken was wirklich der user anstellt und wer der user ist. denn da steckt ansich der Wurm in allem.

--- Quote from: chio on July 29, 2010, 10:24:06 AM ---Ein Modul muss es trotzdem werden, weil es weitere Dateien gibt, die an einem festen Ort sein müssen.
Header, Footer, Bildchen zb.

--- End quote ---

Waldschwein:

--- Quote from: escpro on July 29, 2010, 10:33:12 AM ---Mir und ein_paar_anderen reichts  :-P

--- End quote ---
In welchem Bezug und was reicht?

Naja, eigentlich haben wir doch schon das Backend im Frontend - ich sage ja nur der ominöse "account" Ordner.
Wenn ich mir den Account so ansehe, ist er ziemlich losgelöst vom Core - mehr oder weniger komplett.
Würde man also "account" als Modul erstellen, hat man eine vollständige Backend-Funktionalität komplett im Frontend.
Daher kann es eigentlich gar nicht so schwer sein, bzw. müsste sogar ohne jegliche WB Coreänderung es geschehen. Ich meine, man kann per Modul show_menu(2), PHPlib, Einstellungen usw. "umgehen", also sollte es wirklich kein Problem darstellen, Frontend-Edit echt & ernsthaft zu ermöglichen.

Wo Bildchen usw. sind, kann man doch alles definieren. Natürlich wäre zu überlegen, nicht einfach ein Frontend-Edit Modul als mehr oder weniger eierlegende Wollmilchsau zu erstellen - wobei wohl für so etwas manche kein Verständnis haben und mir dann doch irgendwo das Handwerkszeug, respektive die Entwicklererfahrung fehlt.

JavaScript (also auch jQuery) ist ein sehr weites Feld. JavaScript kann genauso kompliziert und umfangreich sein wie PHP (man sehe sich einmal die YUI Dateien in /includes an), aber auch sehr mächtig.

Was sollte ein Frontend Edit Modul können?

Auswahl & Abschnittsweises Konfigurieren des Editors.
Geht alles - gucke z.B. hier http://ckeditor.com/demo
Problem:
Wer hat welchen Editor installiert? Das Frontend Edit Modul müsste einen Editor mitliefern.

Hier wäre der von Willy Wonka vorgeschlagene Aloha http://aloha-editor.com/index.html nicht so schlecht. Alternativ sollte es evtl. noch eine Schnittstelle zum FCKEditor geben - auch den kann man ohne Probleme angepasst aufrufen.
Eigentlich alle Editoren haben dasselbe System - man ruft den Editor auf, passt einiges an usw.
Übrigens wären hier Presets zu empfehlen - man erstellt sich verschiedene Presets und ruft dann nur noch dieses auf.
Ich habe das alles schon einmal hier https://forum.WebsiteBaker.org/index.php/topic,18593.0.html aufgegriffen, allerdings nicht nur in Bezug auf Frontend.
Wichtig ist nur, dass man sich nicht auf einen einzelnen Editoren versteift, was aber wegen Presets kein Problem darstellen sollte. Dann kann man sogar für Modul X Editor Y und für WYSIWYG einen anderen nehmen. Groß sind die kleineren Editoren alle nicht - zumindest kleiner als das langweilige Editarea allemal (50-80kb).

Anpassung vom Design & Funktionalität
Ist ja logisch eigentlich. Man muss ja nicht alles zusammenklicken, aber zumindest rudimentär sollte man eine Möglichkeit bekommen, ohne großartige externe Module, die wieder Module, die wieder... Also einfach eine x-beliebige Datei und / oder Datenbankeintrag mit den Anweisungen: "Frontend Edit soll dies und jenes von jQuery nehmen, und daraus dann einen Overlay mit den und jenen Eigenschaften machen". Im Prinzip kann man das Ganze analog zu den Editoren machen - der Unterschied ist praktisch nicht vorhanden, gerade weil heutzutage das JavaScript alles ein wenig nach jQuery aussieht - auch das der Editoren. Ob Presets - nun, schön wäre es ebenfalls.

Wer darf was machen?
Problem:
WebsiteBaker hat (noch) keine Möglichkeit, dass registrierte Module selbstständig Zugänge erteilen können. Gleichzeitig kann man ja aber festlegen, wer welche Seite wie ansehen / editieren darf. Hier muss darauf geachtet werden, dass die ganzen Einstellungen wer was machen darf im Backend-Seitenbaum auch übernommen werden und ohne Herumtricksen laufen.

Soweit mal erste Überlegungen.

Gruß Michael

Stefek:

--- Quote from: Waldschwein on July 29, 2010, 11:25:19 AM ---Naja, eigentlich haben wir doch schon das Backend im Frontend - ich sage ja nur der ominöse "account" Ordner.
--- End quote ---

Nee... das ist nich Backend im Frontend - das ist doppelter Code.


--- Quote from: Waldschwein on July 29, 2010, 11:25:19 AM ---
Wer darf was machen?
Problem:
WebsiteBaker hat (noch) keine Möglichkeit, dass registrierte Module selbstständig Zugänge erteilen können. Gleichzeitig kann man ja aber festlegen, wer welche Seite wie ansehen / editieren darf. Hier muss darauf geachtet werden, dass die ganzen Einstellungen wer was machen darf im Backend-Seitenbaum auch übernommen werden und ohne Herumtricksen laufen.

--- End quote ---
Im Baum wird das nicht reichen. Und abgesehen davon, sieht man im PageTree nicht einmal die Sections und deren verwendeten Module.

Es sollte im Modul selbst definiert werden können.
Sprich -> das Modul sollte bei der Installation ein Feld mit installieren, wo ein Array der Rechte als String gespeichert wird.

Zumindest solange es keine zentralisierte Stelle gibt, wo Rechte an Sectionen gespeichert werden.

Gruß,
Stefek

Waldschwein:

--- Quote from: Stefek on July 29, 2010, 11:35:44 AM ---Im Baum wird das nicht reichen. Und abgesehen davon, sieht man im PageTree nicht einmal die Sections und deren verwendeten Module.

Es sollte im Modul selbst definiert werden können.
Sprich -> das Modul sollte bei der Installation ein Feld mit installieren, wo ein Array der Rechte als String gespeichert wird.

Zumindest solange es keine zentralisierte Stelle gibt, wo Rechte an Sectionen gespeichert werden.

Gruß,
Stefek

--- End quote ---

Also das Modul sollte nicht selbstständig Rechte verteilen - natürlich kann ich über einen Array zu String (Hrm... ich mag kein implode) jetzt lustig herumfurwerken - aber das wäre dann eine Insellösung, die keinen Sinn macht.
Was passiert, wenn man eine neue Seite erstellt?
Wenn man Abschnitten selbst übe WB keine Rechte zuordnen kann, sollte man das aus meiner Sicht vorerst auch lassen. Man kann ja trotzdem ein Modul erstellen - das frägt halt vorerst nur die Seiten- und Modulberechtigung ab und fügt nicht irgendwas selbst hinzu. Das ist nicht tragbar, gerade in Hinsicht auf Upgrades.

Gruß Michael

Navigation

[0] Message Index

[#] Next page

[*] Previous page