OnePage mit jQuery [abgetrennt von OP-Template "OP_IHave a

[Holger]

Bezüglich der $sn Sache bin ich gerade auf eine entsprechende Anfrage von manu gestoßen. Ganz interessant: ursprünglich hatte ich $sn drin, dann hatte Ludwig angemerkt, dass das $sn wohl unnötig ist, so dass ich es entfernt habe. Daraufhin hat Knollsen bemängelt, dass nach dem Logout erst mal nichts mehr funktioniert, so dass ich es wieder eingefügt habe. manus Argumente müsste ich mir noch mal genauer anschauen, aber das Problem mit den Formularen wiegt wohl schwerer.

Da sieht man wie schwierig es wird möglichst viele Fälle abzudecken.
Das Problem "Einbahnstraße nach Logout" könnte man ja akzeptieren (oder per verzögertem Refresh lösen). Und ohne $sn funktionieren halt keine Formulare mehr....

Bezüglich des display:none für #onepage_toplink, das Du eingefügt hast: das finde ich nicht so gut, falls kein JS verfügbar ist. Daher habe ich das per JS und zwei zusätzlichen Klassen gelöst.

Bezüglich des (Nicht-)Ladens des JS im Bearbeitungsmodus: da bin ich nicht ganz sicher, da dann zumindest der Toplink immer sichtbar wäre. Vielleicht ist Deine Idee, den Toplink per CSS auszublenden, doch das beste. Vielleicht sollte auch das JS aufgeteilt werden?

Ich habe die andere Variante ja schon als Kommentar im Skript stehen. Aber mir gefällt es so besser. Wer kein JS aktivieren will, hat eben den Komfort nicht. Außerdem kann das Template per <noscript> eine andere Alternative, die nicht den Editor überlagert, anbieten.
[edit] Und, ganz vergessen: sag' mir was genau Du von dem Code in onepage.js sonst überhaupt im Edit-Mode benötigst? IMO nichts. Aber dadurch müssen Links repariert werden, die ohne das JS funktionieren würden. Ich sehe da echt keinen Grund das Skript (mit dieser Funktionalität) in dem Modus zu laden. Anders sieht es aus, wenn noch mehr Funktionalität - besonders für den Edit-Mode - dazu käme. Dann würde ich den Teil aber auslagern, damit das Smooth-Scrolling unabhängig ausgetauscht werden kann.[/edit]

Bezüglich der Beschränkung des smooth Scrolling auf Links mit scrollTo Klasse bin ich mir nicht wirklich sicher. Wenn der Anwender manuell interne Links setzt, dann wäre es eigentlich schön, wenn auch diese weich Scrollen würden, ohne dass manuell die entsprechende Klasse vergeben werden soll. Aber irgendein Problem gab es wohl mit der derzeitigen Variante – ich muss mal suchen, was ich aber auf "Morgen" verschiebe.

Beim Template in meiner Demo würde der Menü-Toggle in der Mobile-Ansicht dann auch vom Smooth-Scrolling erfasst. IMO sieht das da aber unpassend aus - Geschmackssache. Wenn alle Links automatisch erfasst werden, sollte es dann zumindest eine Klasse geben mit der einzelne Links davon ausgeschlossen werden können.

Das Argument, solche Dinge im Plugin per Konfiguration zu ermöglichen, halte ich für nicht optimal. Testet z.B. ein User verschiedene Templates, muss er immer wieder die passenden Einstellungen machen. Bei optionalen Sachen wäre es besser, wenn sie per Konfiguration direkt im Template gemacht werden könnten. Der Designer müsste lediglich ein paar Dinge, die er anpassen möchte, in z.B. Variablen / Konstanten direkt im Template definieren.
Wenn man dann einen Schritt weiter geht wäre es sogar möglich die gewünschte HTML-Struktur der "one_page" (umschließendes Div, zusätzliche Klasse ".container etc") ebenfalls im Template zu definieren. Zur Not vielleicht auch einfach als Variable. Damit würde die Sache ungemein flexibel werden.

Bezüglich der jQuery-Variante: die würde ich, wie schon gesagt, einbauen. Konfigurierbar, aber als Default. Wenn Du nichts dagegen hast, übernehme ich die derzeitige Variante (und passe ggf. an). Okay?

Na klar. Nur ob es in dem Stadium schon etwas bringt?

LG
Holger

[lck]

Habe gestern ein paar OnePage-Templates mit dem zusätzlichen div getestet. Von meiner Seite könnte das festgenagelt werden und zwar folgendermaßen:
Controller.php

Code: Select all

<div id="%s" class="onepage_page">%s</div>

/* ändern zu */
<div id="%s" class="onepage_page"><div class="opp_content">%s</div></div>

Der Name für die Klasse .onepage_page muss auf alle Fälle so belassen werden, zwecks bereits bestehender und verwendeter Templates.
Für die Klasse im 2. div brauchen wir auf alle Fälle einen eindeutigen Namen, mit .container kann es zu Problemen kommen, wenn andere Plugins, Addons usw. auch den selben Klassen-Namen verwenden.
opp_content erscheint mir passend, bin aber für Vorschläge offen.

Für den speziellen Fall von Bootstrap oder auch anderen Frameworks, schlage ich vor, den Klassen-Namen .opp_content oder evtl auch .onepage_page konfigurierbar zu machen. Standard sollten aber die genannten Klasse-Namen sein. Frank, was meinst du?

Das Argument, solche Dinge im Plugin per Konfiguration zu ermöglichen, halte ich für nicht optimal. Testet z.B. ein User verschiedene Templates, muss er immer wieder die passenden Einstellungen machen. Bei optionalen Sachen wäre es besser, wenn sie per Konfiguration direkt im Template gemacht werden könnten. Der Designer müsste lediglich ein paar Dinge, die er anpassen möchte, in z.B. Variablen / Konstanten direkt im Template definieren.
Wenn man dann einen Schritt weiter geht wäre es sogar möglich die gewünschte HTML-Struktur der "one_page" (umschließendes Div, zusätzliche Klasse ".container etc") ebenfalls im Template zu definieren. Zur Not vielleicht auch einfach als Variable. Damit würde die Sache ungemein flexibel werden.

Stimmt, das sollte alles mit dem Template ausgeliefert werden. Sonst wirds zu umständlich für den Anwender.

[Holger]

Habe gestern ein paar OnePage-Templates mit dem zusätzlichen div getestet. Von meiner Seite könnte das festgenagelt werden und zwar folgendermaßen:

Ich stelle mir die Sache mit der Seitenstruktur ganz simpel und vor allen Dingen flexibler vor:

Code: Select all

$contents .= sprintf(
                    $onepage_structure,
                    $url, evaluate_scripting($c[$i])
                ); 

Im Template wird die Struktur der Ausgabe dann definiert (lacht jetzt bitte nicht . Ich hab' nie getestet, ob das per Variable geht -- zur Not muss es halt als Rückgabe einer Funktion oder als eine Art Template definiert werden):

Code: Select all

$onepage_structure = '<div id="%s" class="onepage_page"><div class="opp_content">%s</div></div>';

oder halt

Code: Select all

$onepage_structure = '<div id="%s" class="onepage_page"><div class="opp_content container">%s</div></div>';

Für Dinge wie offsetTop bei fixierten Headern müsste es ähnlich möglich gemacht werden. Nur eben mit einer globalen JS-Variable. Die kann dann auch ihren Wert aus einer Funktion bekommen, was vielleicht bei dynamischen Höhen nötig ist.
So liegt alles in der Hand des Templates...

[cmb]

So langsam frage ich mich ob der Versuch überhaupt Sinn macht, solch eine universelles onpage.js dem Plugin beizulegen. Wie man sieht ist es in der Regel mit ein paar Zeilen im Template-Ordner getan. Und auch für das aktuell in der Demo genommene Template gibt es eine passende Lösung. Aber wirklich universell?

Absolut universell ist nicht sinnvoll bzw. überhaupt machbar, das sehe ich zumindest mittlerweile so. Aber vielleicht kann mit vertretbarem Aufwand ein JS ausgeliefert werden, das für viele Fälle genügt. Wer das nicht nutzen will, wird es aber deaktivieren können (dazu später mehr in diesem Post). Alle anderen hätten aber den Vorteil auf eine hoffentlich fertige und gut ausgetestete Lösung zurückgreifen zu können. Und wenn man die Idee "universell geeignet" einmal weiter denkt, dann betrifft das ja nicht nur das JS, sondern auch das PHP (z.B. $sn Problem). Auch hier kann, denke ich, nur eine Lösung für viele, aber eben nicht für alle Anwendungsfälle vorbereitet werden. Wer da speziellere Wünsche hat, dem stehen ja auch noch manuelle Wege ohne Onepage-Plugin zur Verfügung.

Ein weiterer Grund, doch zumindest eine möglichst universelle Lösung anzubieten, ist die Kompatibilität mit späteren CMSimple_XH Versionen. Wenn sich an der genutzten API etwas ändern wird (und das wird es hoffentlich; viel zu viele globale Variablen), dann müssten die enstprechenden Anpassungen nur einmal im Onepage-Plugin vorgenommen werden, aber die Templates könnten u.U. unverändert erhalten bleiben.

Der nächste Punkt wäre ein Offset für Menüs mit position:fixed, den man vielleicht abhängig des Viewports noch anpassen müsste. Da hilft dann auch keine Konfigurationsvariable mehr. Und was, wenn der User einmal das Template wechselt?

Eventuell ist es möglich hier per JS dynamisch einzugreifen; ansonsten eben doch per Konfiguration (siehe weiter unten).

Bezüglich des display:none für #onepage_toplink, das Du eingefügt hast: das finde ich nicht so gut, falls kein JS verfügbar ist. Daher habe ich das per JS und zwei zusätzlichen Klassen gelöst.

Bezüglich des (Nicht-)Ladens des JS im Bearbeitungsmodus: da bin ich nicht ganz sicher, da dann zumindest der Toplink immer sichtbar wäre. Vielleicht ist Deine Idee, den Toplink per CSS auszublenden, doch das beste. Vielleicht sollte auch das JS aufgeteilt werden?

Ich habe die andere Variante ja schon als Kommentar im Skript stehen. Aber mir gefällt es so besser. Wer kein JS aktivieren will, hat eben den Komfort nicht. Außerdem kann das Template per <noscript> eine andere Alternative, die nicht den Editor überlagert, anbieten.

Ja, Du hast recht. Halten wir es zumindest einigermaßen simple.

[edit] Und, ganz vergessen: sag' mir was genau Du von dem Code in onepage.js sonst überhaupt im Edit-Mode benötigst? IMO nichts. Aber dadurch müssen Links repariert werden, die ohne das JS funktionieren würden. Ich sehe da echt keinen Grund das Skript (mit dieser Funktionalität) in dem Modus zu laden. Anders sieht es aus, wenn noch mehr Funktionalität - besonders für den Edit-Mode - dazu käme. Dann würde ich den Teil aber auslagern, damit das Smooth-Scrolling unabhängig ausgetauscht werden kann.[/edit]

Ich hatte da v.a. an eventuelle später zu entwickelnde JS-Funktionalität gedacht, aber tatsächlich kann es ja dann zwei Scripte geben. Für jetzt sollte aber gelten: YAGNI.

Bezüglich der Beschränkung des smooth Scrolling auf Links mit scrollTo Klasse bin ich mir nicht wirklich sicher. Wenn der Anwender manuell interne Links setzt, dann wäre es eigentlich schön, wenn auch diese weich Scrollen würden, ohne dass manuell die entsprechende Klasse vergeben werden soll. Aber irgendein Problem gab es wohl mit der derzeitigen Variante – ich muss mal suchen, was ich aber auf "Morgen" verschiebe.

Beim Template in meiner Demo würde der Menü-Toggle in der Mobile-Ansicht dann auch vom Smooth-Scrolling erfasst. IMO sieht das da aber unpassend aus - Geschmackssache. Wenn alle Links automatisch erfasst werden, sollte es dann zumindest eine Klasse geben mit der einzelne Links davon ausgeschlossen werden können.

Okay, gute Argumente. Das möchte ich mir aber noch mal in Ruhe durch den Kopf gehen lassen.

Das Argument, solche Dinge im Plugin per Konfiguration zu ermöglichen, halte ich für nicht optimal. Testet z.B. ein User verschiedene Templates, muss er immer wieder die passenden Einstellungen machen. Bei optionalen Sachen wäre es besser, wenn sie per Konfiguration direkt im Template gemacht werden könnten. Der Designer müsste lediglich ein paar Dinge, die er anpassen möchte, in z.B. Variablen / Konstanten direkt im Template definieren.
Wenn man dann einen Schritt weiter geht wäre es sogar möglich die gewünschte HTML-Struktur der "one_page" (umschließendes Div, zusätzliche Klasse ".container etc") ebenfalls im Template zu definieren. Zur Not vielleicht auch einfach als Variable. Damit würde die Sache ungemein flexibel werden.

Ja, Du hast völlig recht, dass die Konfiguration zumindest teilweise/optional per Template gemacht werden muss – sonst artet das in Chaos aus. Was und wie genau das gemacht wird, wird sich noch zeigen müssen. An die Anpassung der Struktur per Template-Konfiguration hatte ich auch schon gedacht, aber das könnte später Probleme mit ein paar JS-Erweiterungen machen. Muss ich mir noch überlegen.

Bezüglich der jQuery-Variante: die würde ich, wie schon gesagt, einbauen. Konfigurierbar, aber als Default. Wenn Du nichts dagegen hast, übernehme ich die derzeitige Variante (und passe ggf. an). Okay?

Na klar. Nur ob es in dem Stadium schon etwas bringt?

Der Vorteil wäre, dass zunächst mal alles in einem Repo verfügbar ist, was das Testen erleichtern sollte[1]. Ich werde die jQuery-Variante also mal einbinden.

Zu den inzwischen eingetroffenen Posts dann später mehr.

[1] <Träumermodus>Nicht nur das manuelle Testen, sondern eben auch das automatisierte Testen.</Träumermodus>

[frase]

Controller.php

Code: Select all

<div id="%s" class="onepage_page">%s</div>

/* ändern zu */
<div id="%s" class="onepage_page"><div class="opp_content">%s</div></div>

Der Name für die Klasse .onepage_page muss auf alle Fälle so belassen werden, zwecks bereits bestehender und verwendeter Templates.
Für die Klasse im 2. div brauchen wir auf alle Fälle einen eindeutigen Namen, mit .container kann es zu Problemen kommen, wenn andere Plugins, Addons usw. auch den selben Klassen-Namen verwenden.
opp_content erscheint mir passend, bin aber für Vorschläge offen.

Für den speziellen Fall von Bootstrap oder auch anderen Frameworks, schlage ich vor, den Klassen-Namen .opp_content oder evtl auch .onepage_page konfigurierbar zu machen. Standard sollten aber die genannten Klasse-Namen sein. Frank, was meinst du?

Lasst euch durch spezial-Fälle (wie z.B. meinem) nicht vom rechten Weg abbringen. Das oben Geschriebene ist völlig OK. Das Plugin muss allgemeingültig werden. Und die bereits laufenden Templates müssen unbedingt weiter funktionieren.
Bootstrap ist nun schon wieder so speziell, dass es in CMSimple_XH sowieso nie allgemein verwendet werden kann. Ist aber trotzdem sehr hifreich, was Responsibilität betrifft. Habe schon beinahe 10% der Funktionen begriffen

Ich werde mal meine spezial-Probleme etwas zurückstellen, damit ihr vorankommt.

[cmb]

Zur Seitenstruktur:

Von meiner Seite könnte das festgenagelt werden und zwar folgendermaßen:
Controller.php

Code: Select all

<div id="%s" class="onepage_page">%s</div>

/* ändern zu */
<div id="%s" class="onepage_page"><div class="opp_content">%s</div></div>

Der Name für die Klasse .onepage_page muss auf alle Fälle so belassen werden, zwecks bereits bestehender und verwendeter Templates.
Für die Klasse im 2. div brauchen wir auf alle Fälle einen eindeutigen Namen, mit .container kann es zu Problemen kommen, wenn andere Plugins, Addons usw. auch den selben Klassen-Namen verwenden.
opp_content erscheint mir passend, bin aber für Vorschläge offen.

Für den speziellen Fall von Bootstrap oder auch anderen Frameworks, schlage ich vor, den Klassen-Namen .opp_content oder evtl auch .onepage_page konfigurierbar zu machen. Standard sollten aber die genannten Klasse-Namen sein.

Das habe ich bisher so gemacht im Controler geändert:

Code: Select all

<div id="%s" class="onepage_page">
<div class="container">%s</div>
</div>

[…]
So liegt alles in der Hand des Templates...

Das ist elegant, kann aber auch ein Stich ins Wespennest sein: wer kann schon vorhersehen, was ein Templatedesigner dann alles vorbereitet, und wie das mit zukünftigen Erweiterungen von Onepage_XH (das Plugin ist schließlich noch in der Beta-Phase!) zusammen spielt. Da möchte ich mich zumindest noch nicht allzu sehr festlegen lassen.

Daher finde ich, dass der oben zitierte Vorschlag von Ludwig sinnvoll ist. Das würde dann auch für Frank passen. Einzig der Name des inneren Divs `opp_content` gefällt mir nicht, weil ich bezüglich des Namespacings am liebsten keine Kompromisse eingehen möchte (wer weiß, ob es nicht irgendwann mal ein Opp-Plugin geben wird). Also auf jeden Fall sollte der Klassenname mit `onepage_` beginnen. Wie wäre es mit `onepage_page_inner` oder kurz `onepage_inner`?

Und wem der Name nicht gefällt, der kann ihn umkonfigurieren (bei Bedarf im Template).

Auf jeden Fall an dieser Stelle vielen Dank an Ludwig, Frank und Holger für die konstruktive Diskussion, die guten Anregungen, das Testen und Ausarbeiten von Code. So macht die Pluginentwicklung deutlich mehr Spaß.

[lck]

Einzig der Name des inneren Divs `opp_content` gefällt mir nicht, weil ich bezüglich des Namespacings am liebsten keine Kompromisse eingehen möchte (wer weiß, ob es nicht irgendwann mal ein Opp-Plugin geben wird). Also auf jeden Fall sollte der Klassenname mit `onepage_` beginnen. Wie wäre es mit `onepage_page_inner` oder kurz `onepage_inner`?

'onepage_page_inner' finde ich passend, das weiß man gleich welcher Bereich gemeint ist.

[Holger]

Das ist elegant, kann aber auch ein Stich ins Wespennest sein: wer kann schon vorhersehen, was ein Templatedesigner dann alles vorbereitet, und wie das mit zukünftigen Erweiterungen von Onepage_XH (das Plugin ist schließlich noch in der Beta-Phase!) zusammen spielt. Da möchte ich mich zumindest noch nicht allzu sehr festlegen lassen.

Gerade mit einer fix vorgegebenen Struktur legst Du dich fest. Und weil es jetzt mal nicht passt, wird die Struktur erweitert. Das finde ich schon in diesem Stadium inkonsequent. Den zusätzlichen Container kann jeder Designer selbst per JS etc. erzeugen. Mit jQuery werden das vermutlich nicht mehr als 5 Zeilen. Und wozu die Anpassung des Namens per Konfiguration? Das würde ich versuchen zu vermeiden.

Sicher muss eine vorgegebene Struktur erst 'mal Standard sein. Aber das sie oft nicht passt, sieht man an den aktuellen Wünschen. Der nächste Designer nutzt das nächste Framework und wünscht sich genau das Gegenteil.

Bei vielen fertigen (jQuery-) Plugins oder sonstigen Frameworks passen die vorgesehenen Seitenstrukturen vom Core oder eines Plugins nicht. Das ist immer wieder ein Problem. Und immer wieder wird dann per JS angepasst oder Code gehackt. So auch bei Franks Projekt (Stichwort ".container").

Ich würde eine feste Struktur als Default-Wert vorgeben. Aber dem Template optional volle Kontrolle geben. Ansonsten bleiben dem Designer nur Bastellösungen -- wie sie in der Praxis ja auch immer wieder angewendet werden. Und warum "stört" das eventuell die zukünftige Erweiterung des Plugins? Im Zweifel wird nur die Standard-Struktur offiziell unterstützt.

EDIT: hmm, zu spät https://github.com/cmb69/onepage_xh/com ... 3ea656ecb6

[cmb]

Ich würde eine feste Struktur als Default-Wert vorgeben. Aber dem Template optional volle Kontrolle geben. Ansonsten bleiben dem Designer nur Bastellösungen -- wie sie in der Praxis ja auch immer wieder angewendet werden. Und warum "stört" das eventuell die zukünftige Erweiterung des Plugins? Im Zweifel wird nur die Standard-Struktur offiziell unterstützt.

Meine Grundidee bei Onepage_XH war und ist, Templatedesignern und Webmastern ein Tool zu geben, mit dem sie relativ leicht einen Onepager erstellen können. Zu so einem Onepager gehört aber irgendwie immer auch JS Unterstützung: das weiche Scrollen, der dynamische Toplink, und, finde ich eigentlich wichtig, auch wenn noch nicht verfügbar, die dynamische Anpassung der Menüstruktur bzgl. sdoc(s). Je fester ich die Seitenstruktur vorgebe, umso weniger Designer können damit was anfangen (bzw. müssen Hacken). Je flexibler die Seitenstruktur anpassbar ist, umso weniger JS-Gimmicks kann ich (mit vertretbarem Aufwand) anbieten, und nicht jeder Designer wird eigenes JS einbringen können und/oder wollen.

Wenn ich Dich richtig verstehe, dann wünschst Du Dir eigentlich ein Onepage_XH, dass völlige Flexibilität bietet, dabei aber ggf. keinerlei eingebaute JS-Features mitbringen muss (also eigentlich reines PHP). Auch manus Wünsche gehen in diese Richtung.

Also Vorschlag, nach Wahl des Designers:

• Simple Variante: weitgehend fest vorgegebene Struktur (so wie derzeit) mit JS out-of-the-box
• Komplexe Variante: flexible Seitenstruktur (und Menüstruktur?) ganz ohne vorgegebenes JS

hmm, zu spät https://github.com/cmb69/onepage_xh/com ... 3ea656ecb6

Nichts, was nicht prinzipiell leicht wieder rückgängig gemacht werden könnte.

[manu]

Hallo miteinander
Ihr legt Euch ja ganz schön ins Zeug. Ich lese artig mit, kann aber aus Zeitgründen der Diskussion nicht immer ganz vollständig folgen. Vor rund einem Jahr hatte ich das Ziel, ein Onepage Template ab der Stange in CMSimple_XH zu integrieren. Ein Bootstrap Template mit all den Gimmicks, die scheints so gefragt sind: onepage.pixolution.ch. So aus dem Kopf heraus habe ich Christoph's onepage Klasse in einem eigenen Plugin erweitert. Den Inhalt bearbeite ich im codeeditor von Christoph. Wenn ich was dazu beitragen kann, mache ich das gerne. Meine Meinung dazu ist: CMSimple_XH sollte den Inhalt so flexibel wie möglich und nur soviel wie nötig ausliefern, damit möglichst universell mit Templates (und deren Frameworks) gearbeitet werden kann, d.h. ein plugin und evtl. ein minimales (Beispiel-)Template.
Gruss an alle
manu