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

Frontend-Edit Überlegungen

<< < (7/11) > >>

Stefek:

--- Quote from: Waldschwein on July 29, 2010, 11:42:45 AM ---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

--- End quote ---
Es gibt bessere Funktionen als implode, um Arrays in der DB serialisiert zu speichern.

Natürlich könnte man das lassen, will aber grade verwendet werden, dann muss man das Modulabhängig machen.
Und ähnliche Verfahren werden bereits verwendet, um zu bestimmen, wer welche Rechte am Modul hat (Bsp. Bakery).

So lange sich am Core nichts ändert, muss drumherum gewerkelt werden, ob es jemandem gefällt oder nicht.

Chios FE Edit ist ja auch "drumherum" gebaut, weil das Core nichts bereithält und das Core-Team sich nicht darum bemüht (nicht in der "zweier Reihe" - kannst Du weiter oben lesen).

Und was soll sein, wenn man eine neue Seite erstellt?
Man kann dem Modul "Standardwerte" einstellen, die bei jeder neuen Section übernommen werden und dann in den Sections section-individuelle Werte einstellen.
Du weißt doch, wei eine Datenbanktabelle aussieht, oder nicht?

Stefek

Waldschwein:
Stefek, wir müssen jetzt nicht zeigen wer besser programmieren / coden / was auch immer kann.
Es geht hier darum, eine gemeinsame Linie zu finden - ich bin auf jeden Fall daran interessiert und würde auch mit vielen Kompromissen meinerseits mich daran beteiligen.
Ich habe nur Probleme damit, dass es ein Modul gibt, das eigenständig um das CMS herum das Rechtesystem mehr oder weniger aushebelt (ja, wenn es Bakery macht kann sein, ich kenne das Modul nicht).
Man muss eben nur bedenken, dass man es hier mit einem weiteren "God-mode" Modul zu tun hat, das prinzipiell alles aushebeln könnte. Und da muss man in technischer Hinsicht schon recht sensibel sein, nicht dass man dann über nicht bekannte Umwege jegliche Berechtigungen umgehen kann - es wäre halt schade.
Aber nur zum Nachvollziehen - ich erstelle eine neue Seite im Seitenbaum und setze diese auf Privat, drei Gruppen dürfen sie sehen und zwei bearbeiten (oder soll das Frontend Edit Modul auch Seiten erstellen dürfen?)
Meine Frage: Wie übernimmt das Frontend Edit Modul diese Werte - direkt aus der Datenbank oder schert es sich nicht drum und ich habe die doppelte Arbeit, weil ich alles noch einmal konfigurieren muss im Modul?

Gruß Michael

Stefek:
Wenn ich richtig verstehe, willst Du die Rechte pro Seite vergeben?
Falls ja, dann ist es sinnfrei.
Jede Section sollte die Möglichkeit bekommen, bearbeitbar zu sein oder eben nicht.
Zu Deutsch: man sollte bei jeder Section angeben können, welche Gruppe sie editieren kann.

Der Bereich "Sections" /sections.php
wäre dafür also eigentlich der richtige Ort.
Aber merk mal auf, wieviel Arbeit es wäre, ein solches System zu programmieren und die Module müßten ebenfalls dadrauf abgestimmt werden.

Also bleibt - zumindest im Moment - nichts anderes übrig, als es vom Modul abhängig zu machen.
In den Einstellungen des Modules selbst.

Anders wird es nicht funktionieren.
Und Bakery ist nicht das einzige Modul, welches es hat/tut.
Viele andere Module bedienen sich ähnlichen Verfahrens, um z.B. den Button "Settings" nur der 0-Gruppe (Admins) zu zeigen.

Es geht nur von Modul zu Modul.

Eine andere Herangehensweise könnte sein:
- eine Liste von Modul-Kandidaten, für die man FE Edit haben will aufzustellen
- sich diese Module anzuschauen, welche Bereiche im FE Sinn machen würden und für wen
- zu schauen, ob man einheitliche Verfahren etablieren kann, die sie alle gemeinsam haben (sollten)
- eine übergeordnete Lib/Framework etablieren, welches mit diesen Modulen korrespondiert und die nötigen FE Dateien, samt Scripte etc. mitliefert

(solange das nicht im Core ist, muss eine Lib/Zusatzframework herhalten - anders wird es NICHT gehen)

Man sollte aber zuerst überlegen, welche Module so ein FE Edit haben sollten (mit den erweiterten Einstellungen, Freigabe zum Editieren je nach User und Section).

Was wären die Kandidaten?
Und in wie fern ähneln sich diese Kandidaten und wie könnte man das vereinheitlichen?
Wie oben schon erwähnt - das Guestbook Modul könnte locker mit "Edit-in-Place" arbeiten, somit gibt es auch einige unterschiedliche Herangehensweisen bei den verschiedenen Modulen.

Man plant am besten vom Endprodukt zurück, bis man auf die richtige Technik kommt.
Und die Module selbst, sind hier die Endprodukte.
Module sind unterschiedlich, weisen aber untereinander ähnliche Charakteristika auf.
Es würde möglicherweise 3 Gruppen von Modulen geben:
solche, die mit Edit-In-Place umgehen können,
solche, wo man die modify.php reinlädt und
solche, wo man (wie bei News z.B.) die view_(item).php reinzieht, wo der Inhalt des Items bearbeitet wird. (wobei das nach einer Mischtechnik schreit, sodass sowohl die einzelnen Items/News editierbar sind, als auch die modify.php selbst)

Ganz schön umfangreich und abenteuerlich das ganze.
Aber ohne eine Liste von Kadidaten kommt man nicht dadrauf.

Ein Projekt von " Frontend Editable Modules for WebsiteBaker " könnte der ganzen Problematik auf den Grund gehen.
Mit ein paar Leuten, die Lust haben, dadran zu werkeln.

Wäre aber momentan natürlich ein "am Core vorbei"....

Schlimm?

chio:
Wir sollten die Kirche im Dorf lassen.
Frontend Edit soll eine Erleichterung sein, kein Ersatz fürs Backend.

Für FE-Edit gilt das gleiche wie fürs Backend. Vom Core her soll das Berechtigungssystem geregelt werden und fertig.

Es ist letztliche nur eine andere Darstellungsform der selben Dateien. Es ist den Modulautoren überlassen, wie sie das im Detail handhaben.
In Topics wird einfach ein Flag gesetzt und dann sind Kleinigkeiten anders. Aber es ist keine Datei doppelt (BE und FE) vorhanden. Wo kämen wir denn da auch hin, wenns eine move_up_fe.php usw geben müsste.

Natürlich verwendet man den selben Editor, da käme man ja in Teufels Küche: Der eine macht <p> bei Return, der andere <br/>, der dritte <div>... ganz zu schweigen vom Umgang mit <embed> usw.

Fürs erste muss man mal die Rahmenbedingungen definieren.
Dann kann nach und nach jeder Modulautor hergehen und (sein) Modul anpassen. Oder jemand anders - auch das geht ;-)
Letztlich macht ja das Modul selbst den Schalter rein, und der ist eben erst da, wenns wohl auch funkioniert. Bei WYSIWYG ist das ein Kinderspiel, bei News etwas mehr arbeit (viele Dateien betroffen). Bei Code wird mans wohl nie machen. Wozu auch.

Mit ein Grund, warum ich für die Bereitstellung von frontend-edit ein eigenes Modul nehmen würde: Das ist viel flexibler. Es kann sogar verschiedene geben. Solange sich alle an die Rahmenbedingungen halten.

Das kann sogar soweit gehen, dass es ein neues Modul geben könnte, mit dem zb Seiteneinstellungen im Frontend geändert werden können. Da braucht man nicht unbedingt die Core-Dateien dazu.

Stefek:
Hi Chio,


--- Quote from: chio on July 29, 2010, 01:51:14 PM ---Für FE-Edit gilt das gleiche wie fürs Backend. Vom Core her soll das Berechtigungssystem geregelt werden und fertig.

--- End quote ---
Ist natürlich eine Frage dessen, WAS man alles im FE laden will.
Was ich da beschrieben habe, zielt nicht direkt auf FE-Edit ab, sondern auf die momentan mangelnde Rechtevergabe an so wichtigen "Ecken" wie den Settings der Module.



--- Quote from: chio on July 29, 2010, 01:51:14 PM ---Es ist letztliche nur eine andere Darstellungsform der selben Dateien. Es ist den Modulautoren überlassen, wie sie das im Detail handhaben.

--- End quote ---
Ja, aber wenn es auch dafür eine gut regulierte Vorlage gäbe, warum nicht.
Was hat das jetzt mit einer Kirche im Dorf zu tun?
Natürlich macht das der Entwickler rein oder auch nicht.


--- Quote from: chio on July 29, 2010, 01:51:14 PM ---Mit ein Grund, warum ich für die Bereitstellung von frontend-edit ein eigenes Modul nehmen würde: Das ist viel flexibler. Es kann sogar verschiedene geben. Solange sich alle an die Rahmenbedingungen halten.
--- End quote ---
Klar, ohne Lib wird's nicht gehen.
Nicht so lange nichts fest ins Core kommt.


--- Quote from: chio on July 29, 2010, 01:51:14 PM ---Das kann sogar soweit gehen, dass es ein neues Modul geben könnte, mit dem zb Seiteneinstellungen im Frontend geändert werden können. Da braucht man nicht unbedingt die Core-Dateien dazu.

--- End quote ---
Genau deswegen meine ich, dass das besser geregelt werden sollte - nicht jedem, der Inhalte Editieren kann, will ich auch Rechte zum Setzen der Einstellungen geben.

Ich denke einfach einen Schritt weiter (auch wenn ich die Kirche dafür in meinen Garten stellen müßte).

Stefek

Navigation

[0] Message Index

[#] Next page

[*] Previous page