WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

Du bist nicht angemeldet.

#1 30.06.2017 19:49:26

grindmobil
Gast

WBCE + AJAX

Es werden wohl immer mehr Module AJAX nutzen.

Das Problem dabei ist, dass die Outputfilter recht undurchsichtig sind.

Wenn ich zb die gesamte view.php eines Moduls per AJAX reinladen will, muss ich die halbe /index.php mit dazugeben und kann nur hoffen, dass das in der nächsten Version noch funktioniert.

Ist es nicht möglich, den ganzen Plunder in bestehende Core-Funktionen zu integrieren, die unabhängig vom Modul laufen?

AM liebsten wäre es mir überhaupt, wenn es irgendwo im Core ein Standard-Include gibt, das ich einfach reinhängen kann und das alles schon mal so herrichtet, wie man es braucht. Also quasi eine index.php ohne Template.

Beitrag geändert von grindmobil (30.06.2017 19:52:00)

#2 30.06.2017 20:31:36

florian
Administrator

Re: WBCE + AJAX

Kannst Du etwas genauer definieren, was Du mit "den ganzen Plunder" und "so herrichtet, wie man es braucht" meinst bzw. einen konkreten Anwendungsfall/Beispiel nennen?
Grundsätzlich denke ich aber, dass das eher schwierig ist, weil ja jede view.php ihr eigenes Ding macht.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#3 30.06.2017 20:53:43

colinax
Developer

Re: WBCE + AJAX

grindmobil schrieb:

AM liebsten wäre es mir überhaupt, wenn es irgendwo im Core ein Standard-Include gibt, das ich einfach reinhängen kann und das alles schon mal so herrichtet, wie man es braucht. Also quasi eine index.php ohne Template.

Norbert hat in dieser Richtung schon was für/in 1.3 gemacht.

Offline

#4 30.06.2017 20:53:57

grindmobil
Gast

Re: WBCE + AJAX

In der /index.php wird ja allerhand geladen, bevor mal das Template - und damit die ganzen view.php - geladen werden.
Danach kommen noch die Output-Filter.

Wenn es jetzt nur darum geht, eine einzige view.php ohne Template zu auszugeben, aber bitte mit Output-Filter, dann ist für mich recht undurchsichtig, was ich tatsächlich brauche.
Und weil sich die /index.php auch ändern kann, kann ich mich (vom Modul aus gesehen) nicht darauf verlassen, dass das auch bei der nächsten Version noch so sein wird.

Wenn man das so sieht, wäre es vielleicht auch kein Fehler, wenn die /index.php etwas verschlankt wird und stattdessen das, was auch ein Modul braucht, zusammenkommt. Das meinte ich mit "Plunder" (Plunder ist alles, was ich nicht so genau wissen will ;-)

EDIT Parallel-Post zu Colinax

Beitrag geändert von grindmobil (30.06.2017 20:56:10)

#5 30.06.2017 20:57:45

florian
Administrator

Re: WBCE + AJAX

Norbert hat in dieser Richtung schon was für/in 1.3 gemacht.

Was genau meinst Du da? Diese i:: insert-Klassen? Gibts die nicht erst in 2.0?


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#6 30.06.2017 21:08:00

colinax
Developer

Re: WBCE + AJAX

Ich weis zwar nicht ob Norbert da schon fertig ist, aber in der 1.3 läd der Core die functions.php schon automaitsch (immer) mit.

Offline

#7 30.06.2017 21:13:37

florian
Administrator

Re: WBCE + AJAX

Na, ich glaube, das ist etwas anderes, als Chio meinte.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#8 03.07.2017 10:39:36

stefanek
Developer

Re: WBCE + AJAX

grindmobil schrieb:

Es werden wohl immer mehr Module AJAX nutzen.

Das Problem dabei ist, dass die Outputfilter recht undurchsichtig sind.

Wenn ich zb die gesamte view.php eines Moduls per AJAX reinladen will, muss ich die halbe /index.php mit dazugeben und kann nur hoffen, dass das in der nächsten Version noch funktioniert.

Ich wunder mich ein wenig, welche Module Du meinst, von denen immer mehr Ajax nutzen werden.
(und wo? im Backend, Frontend?)

Noch mehr wunder ich mich, wo Du die view.php eines Moduls über Ajax einbinden willst und warum.

Was ich verstehe, ist, dass Du den Inhalt, den die view.php ausgeben soll, bereits "gefiltert" bereit haben willst.
Das allerdings wird schwer, weil die Filter und Droplets erst den Inhalt aller Sections plus Template als einzelnen String verarbeiten.

Ein möglicher Ansatz wäre für Dich, eine eigene Funktion zu schreiben, z.B. mit dem Namen get_filtered_section($section_id).
In dieser Funktion dann den Inhalt der index.php ohne dem "Plunder" (wie Du ihn nennst) auf den Content der view.php anwenden. Also alle Filter + Droplets. Dann als String zurückgeben.

(Sorry, kein Code.)

Christian


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#9 03.07.2017 10:43:24

stefanek
Developer

Re: WBCE + AJAX

Was mir noch dazu einfällt:
es wird etwas problematisch sein, die richtigen CSS/JS Dateien zuzuweisen für die Ausgabe der Section (es sei denn, Du willst die frontend.css|js mit reinladen).
Das wird eleganter mit der I::Insert Klasse (was mit ein Grund ist, warum ich mich für diese Metode eingesetzt habe).

Christian


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#10 03.07.2017 12:11:16

grindbatzn
Gast

Re: WBCE + AJAX

Ein typisches Beispiel wäre zb das hier:

http://www.aromainstitut.at/ -> rechte Spalte mitte, der Kalender.

Der wird einfach per jQuery load reingeladen, ganz simpel, da waren kaum Änderungen am Script nötig dafür. Vor allem, weil nicht sicherheitskritisch. Den Kalender kann jeder ansehen.

Wenn der nicht mit AJAX gemacht wäre, würde beim Blättern durch die Monate die Startseite jedesmal neu geladen werden und man müsste wieder runterscrollen (oder ich mach einen Anker, aber der verschiebt auch die Scroll-Position)

Ähnliches gilt für Kontaktformulare, oder zb GlobalComments.

Um das CSS oder JS muss ich mich dabei nicht kümmern, das ist ja ohnehin schon da.

#11 03.07.2017 12:56:31

stefanek
Developer

Re: WBCE + AJAX

Ich verstehe, was Du meinst.

Allerdings frage ich mich, ob man für solche Anwendungen nicht eher einen anderen Weg gehen sollte/könnte, statt die view.php dafür zu nehmen.
Also stattdessen mit einem zusätzlichen Snippet arbeiten (siehe die Möglichkeit von Hybriden Modulen ab v. 2.0) oder einer widget.php analog zur view.php

Das zusätzlich zur view.php in ein Snippet (include.php) zu packen würde vielleicht (vielleicht aber auch nicht, je nachdem wie man arbeitet) etwas mehr Code benötigen, bzw. eine Code-Widerholung (Redundanz) bedeuten.
Ich arbeite aber etwas anders in Modulen, grade deswegen, weil ich bestimmten Code in solchen "widgets" wieder verwenden will, arbeite ich meistens mit Funktionen die von der ganzen Ausgabe ein Array bereitstellen und in der view.php / include.php wird die Funktion nur mehr aufgerufen und das Array verarbeitet (=> durch das Template/Layout gezogen).

Die meisten Module gehen aber tatsächlich einen eigenen Weg, deswegen weiß ich nicht, ob das was Du vorhast wirklich übergreifend gelöst werden kann (und auch ob es das müßte/sollte).

Persönlich bin ich eher der "Verfechter" von hybriden Modulen, da sie mehr Möglichkeiten bieten auf lange Sicht und Modulemachern die Freiheit lassen, welchen Weg sie gehen.


Und da hast Du es ja auch in den Beispielen umgesetzt.
Also wunder ich mich, was fehlt lol

Christian


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#12 03.07.2017 13:37:52

webbird
Administrator

Re: WBCE + AJAX

Ist das gleiche Problem wie mit den Droplets. Angefangen bei JS und CSS bis zur SuFu.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#13 03.07.2017 15:13:31

grindbatzn
Gast

Re: WBCE + AJAX

Ist vielleicht etwas zu verkürzt gesagt. Das Problem:

Standardsituation:
WBCE >> view.php >> (include) zeigdas.php

Ajax:
PseudoWBCE >> zeigdas.php

In diesem Fall stellt die view.php nur einen Wrapper für zeigdas.php bereit, also ein <div id="dings123">, in den ich den Inhalt von zeigdas.php entweder per include (wenn kein Parameter)  oder dann später per AJAX (wenn Parameter) reinlade.

Was mir fehlt ist: PseudoWBCE
Wieviel WBCE brauche ich, um ein Script (mit DB-Zugriff und eventuell Nutzerrechten) zu laden?
Was mit AJAX geladen wird, ist prinzipiell von außen zugänglich, auch wenn man das so nicht sieht. Darf der aktuelle Nutzer das?

Bei obigem Beispiel (Kalender):
Wenn der Kalender auf einer privaten Seite wäre, könnte ihn trotzdem JEDER ansehen, wenn er weiß wie.

In diesem Fall ist das egal (es kann - SOLL! jeder sehen). Das ist aber nicht immer so.

#14 03.07.2017 15:15:25

stefanek
Developer

Re: WBCE + AJAX

Die Droplets haben dank der I/Insert Class KEIN Problem mehr mit CSS/JS.

Die Suchfunktion bleibt weiterhin ein Problem.

Christian


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#15 03.07.2017 15:24:47

webbird
Administrator

Re: WBCE + AJAX

Klar, die AJAX-Dinger sollten die Benutzerrechte prüfen. Vor allem die im Backend.

Ich habe jetzt verstanden, dass Du gern eine Art Standard definieren möchtest, der die Nutzung von AJAX zum einen beschreibt, zum anderen erleichtert. Und Du fragst Dich, was es dafür braucht. Korrekt?


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#16 03.07.2017 15:33:23

grindbatzn
Gast

Re: WBCE + AJAX

webbird schrieb:

Klar, die AJAX-Dinger sollten die Benutzerrechte prüfen. Vor allem die im Backend.

Ich habe jetzt verstanden, dass Du gern eine Art Standard definieren möchtest, der die Nutzung von AJAX zum einen beschreibt, zum anderen erleichtert. Und Du fragst Dich, was es dafür braucht. Korrekt?

Jepp!
Genau darum gehts.  Weniger ein Standard, als ein Leitfaden, der bitte auch gerne sehr konkret sein kann.
DIe Nutzung von AJAX selbst ist ja einfach dank jQuery. Aber was muss vorher (per php) passieren?

Momentan bastelt da noch jeder irgendein Süppchen (und ich will gar nicht so genau wissen, was da so für Leichen im Modul-Keller liegen)

Beitrag geändert von grindbatzn (03.07.2017 15:35:06)

#17 03.07.2017 15:33:37

webbird
Administrator

Re: WBCE + AJAX

Also für Seiten gibt es in der class.wb.php eine Funktion page_is_visible($page), wobei $page (leider) ein Hash mit den Eigenschaften der Seite ist. Also nicht die SeitenID, sondern schon alle Eigenschaften der Seite. Um zu prüfen, ob eine Seite aktiv ist, gibt es analog page_is_active($page). Ein AJAX-Script müßte also wissen:

* In welcher Sektion bzw. auf welcher Seite befinde ich mich?
* Eigenschaften der Seite (über die SectionID oder die PageID zu ermitteln)
* Abfrage page_is_visible() um zu ermitteln, ob der aktuelle Besucher die Seite sehen darf

Ich sehe da also durchaus noch Erweiterungsbedarf, ich erinnere aber daran, dass mir die Funktionen in WBCE nicht mehr so im Detail präsent sind. Schon gar nicht von 1.3 oder gar 2.0.  smile


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#18 03.07.2017 18:16:56

grindmobil
Gast

Re: WBCE + AJAX

Bei einer typischen Frontend-Edit > Save - Situation ist das zunächst noch relativ einfach:
Bei Save verwende ich $admin (ohne Header), das sollte reichen.

Schwieriger ist das Frontend: Wie stelle ich fest, ob der aktuelle User das wirklich darf?
Nun: Es wäre hier kein schlimmes Drama, wenn jemand aufgrund eines Fehlers oder besonderer Kenntnisse im Frondend die Edit-Felder sieht, solange ihm dann von der save.php ein "No Permission" mitgeteilt wird.

Noch schwieriger: Wie bringe ich Droplets oder WBLinks zum Laufen? - wenn der Frontend-Inhalt von der save.php zurückgeliefert wird?
Wenn die save.php also nicht zum Backend gehören kann (also $admin), sondern zum Frontend ($wb)
Dann muss ich wirklich genau aufpassen und kann mich nicht auf $admin verlassen.

Oder kann ich $admin dazu bringen, Droplets und WBLinks aufzulösen? Also die Frontend-Filter.

Da stehe ich echt an.

Also:
view.php: Hat der aktuelle User hier die Berechtigung (Seite, Module)? Wie stelle ich das fest?

save.php (das kann auch wieder die view.php sein, weil sie ja fast das gleiche macht. Der Schreiben-Teil ist meist nur klein):
Rechte überprüfen (wie view.php)
ggf in die DB schreiben
Zeug aus der DB holen und aufbereiten
Frontendfilter drüber
Zurückliefern

#19 04.07.2017 10:16:47

webbird
Administrator

Re: WBCE + AJAX

Man muß die AJAX-Anfragen prinzipiell so stricken, dass die erforderlichen Infos mitgeliefert werden. Also z.B. die SeitenID. Keine SeitenID, keine Sicherheitsprüfung.

Frontend-Filter würde ich persönlich von AJAX trennen.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

Fußzeile des Forums

up