Das ist ein guter Punkt, und ich wünsche gerne auch Kritik zu individuellen Punkten. Ist aber auch zu bedenken, dass im Lauf der Zeit immer mehr gefordert wird. Wo man in den 90ern noch mit statischen Websites punkten konnte, geht seit Jahren ohne ausschweifendes CSS und JS eigentlich nichts mehr.
neues Onepage-Template: fhs-sectionsOP - Tester?
Re: neues Onepage-Template: fhs-sectionsOP - Tester?
Christoph M. Becker – Plugins for CMSimple_XH
Re: neues Onepage-Template: fhs-sectionsOP - Tester?
Nachdem ich den ganyen Tag versucht habe das Template verstehen, hier sind einige meiner Bemerkungen:
1. template.htm
Es ist sehr viel drinn, das macht das Template eben auch mit den Kommentaren kaum übersichtlich. Wenn es möglich wäre, die Konfiguration in eine externe Datei auszulagern, so dass drinn wirklich nur das nötigste bleiben würde, wäre es nach meiner Meinung auch einfacher, mit dem Template zu arbeiten. Es ist zwar klar, daß es am Server mehrere Requests verlangen würde, aber bei heutigen Processoren und algemein erhöhten Geschwindigkeiten würde es nur kleine Rolle spielen. Für den Templateautor ist alles klar und er kennt sich gut aus. Würde aber jemand wollen, das Template irgendwie anzupassen, der hilft sich wohl nur sehr schwer durch. Gute Lösung wäre z.B. eine template.php Datei zu haben, die ähnlich wie z.B. config.php vom Backend Zugriff ermöglichen würde.
2. stylesheet.css
Die :root Variablen finde ich bißchen unpraktisch, sogar verwirrend. Besonders, wenn im stylesheet.css gibt z.B.
(hier ist die Nutzung OK)
aber hier schon etwa verwirrend
oder
Ich habe keinen Vorteil in dieser Form gefunden. Mehr flexible, logisch, sicherer und praktischer finde ich die Werte an den Stellen, wo sie logisch gehören, auch zu definieren. Wenigstens finde ich es "Platzsparend"
Wenn ich imm stylesheet.css auf z.B. schaue, brauche ich nicht am Anfang suchen, welche farbe im ":root" für die Klasse eingestellt ist, um sie dann zu ändern. Also, wenn ich im stylesheet.css die "--mainBackgroundColor" ändere, äanderst sich automatisch auch die Farbe im "span.sticker", was ich nicht brauche. Würden die Farben separat definiert, kaönnte ich mit einer oder zweiter beliebig spielen.
3. Swiper
Es würde Einstellungen für die Bilder im stylesheet.css verlangen, aber ich finde es mehr Nutzerfreundlich, die "Sliderseiten" im Backend zu bearbeiten und Swiper sie nutzen lassen, als sie als leere erstellen und den Rest im swiper-set/include.php und swiper-set/stylesheet.php zu definieren. Eine Sache auf 2-3 verschiedenen Stellen definieren, einstellen usw. zu müssen, finde ich nicht besonders "simple". Obwohl das fhs-sectionsOP einfach fabelhaft ist.
Nach habe ich nicht geschafft:
Den Header transparent zu machen und gleichzeitig die Swipers als "vollHintergrund".
1. template.htm
Es ist sehr viel drinn, das macht das Template eben auch mit den Kommentaren kaum übersichtlich. Wenn es möglich wäre, die Konfiguration in eine externe Datei auszulagern, so dass drinn wirklich nur das nötigste bleiben würde, wäre es nach meiner Meinung auch einfacher, mit dem Template zu arbeiten. Es ist zwar klar, daß es am Server mehrere Requests verlangen würde, aber bei heutigen Processoren und algemein erhöhten Geschwindigkeiten würde es nur kleine Rolle spielen. Für den Templateautor ist alles klar und er kennt sich gut aus. Würde aber jemand wollen, das Template irgendwie anzupassen, der hilft sich wohl nur sehr schwer durch. Gute Lösung wäre z.B. eine template.php Datei zu haben, die ähnlich wie z.B. config.php vom Backend Zugriff ermöglichen würde.
2. stylesheet.css
Die :root Variablen finde ich bißchen unpraktisch, sogar verwirrend. Besonders, wenn im stylesheet.css gibt z.B.
Code: Select all
--mainBackgroundColor: 255, 255, 255;
Code: Select all
body {
background: rgba(var(--mainBackgroundColor), 1);
Code: Select all
span.sticker {
...
color: rgba(var(--mainBackgroundColor), 1);
...
}
Code: Select all
border-bottom: 1px dotted rgba(var(--mainBackgroundColor), .5);
Code: Select all
color: rgba(255,255,255,.5)
vs.
color: rgba(var(--mainBackgroundColor), .5);
Code: Select all
.important{color: #f00; background: #0f0; border: 2px solid #f00;}
3. Swiper
Es würde Einstellungen für die Bilder im stylesheet.css verlangen, aber ich finde es mehr Nutzerfreundlich, die "Sliderseiten" im Backend zu bearbeiten und Swiper sie nutzen lassen, als sie als leere erstellen und den Rest im swiper-set/include.php und swiper-set/stylesheet.php zu definieren. Eine Sache auf 2-3 verschiedenen Stellen definieren, einstellen usw. zu müssen, finde ich nicht besonders "simple". Obwohl das fhs-sectionsOP einfach fabelhaft ist.
Nach habe ich nicht geschafft:
Den Header transparent zu machen und gleichzeitig die Swipers als "vollHintergrund".
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
Re: neues Onepage-Template: fhs-sectionsOP - Tester?
Richtig.
Aber genau das ist ja auch das Ziel bei der Template-Konfiguration über das Backend.
Beispiel: Logo im Header
Eine Firma wird ein Logo haben und es an dieser Stelle verwenden können.
Eine Privatperson hat möglicherweise gar kein eigenes Logo. Sie müsste in der Template-Datei händisch den entsprechenden Code-Part finden und entfernen. Dabei kann vieles schiefgehen.
Da ist es doch wesentlich simpler, wenn man in der Template-Konfiguration nur einen Haken setzen muss - oder nicht?
Und es geht noch viel weiter.
Will man Animationen, wird mit einem Haken (bzw. zurzeit noch mit "true") das entsprechende CSS und JS eingebunden.
Will man sie nicht, werden diese Dateien gar nicht mit ausgeliefert.
Dazu muss niemand Programmierer sein
Re: neues Onepage-Template: fhs-sectionsOP - Tester?
Lieber Martin,
grundsätzlich verstehe ich deine Bemerkungen gut - aber:
Ich baue diese Templates, damit Anwender sie möglichst so benutzen können wie sie sind.
Eventuell Farben ändern, das eine oder andere Element ein- oder ausschalten - das war's dann.
Du hast die besondere Gabe, die Templates immer sofort komplett umbauen zu wollen
Header weg, Bildgrößen ändern, einzelen Elemente umfärben ... usw.
Am Ende kommt fast immer ein "anderes" Template heraus.
Ich finde diese Aktivitäten zwar gut und auch technisch interessant - das war aber eigentlich nicht mein Ziel.
Trotzdem werde ich versuchen, auf deine Bemerkungen zu antworten.
Ich sehe (im Moment!) keinen Nutzen darin, die Einstellmöglichkeiten in eine andere Datei auszulagern. Man kann alles im Backend konfigurieren, indem man die entsprechenden Dateien über "Einstellungen" aufruft. Dazu braucht man nicht einmal einen externen Editor.Tata wrote: ↑Tue Oct 12, 2021 10:07 pm1. template.htm
Es ist sehr viel drinn, das macht das Template eben auch mit den Kommentaren kaum übersichtlich. Wenn es möglich wäre, die Konfiguration in eine externe Datei auszulagern, so dass drinn wirklich nur das nötigste bleiben würde, wäre es nach meiner Meinung auch einfacher, mit dem Template zu arbeiten. Es ist zwar klar, daß es am Server mehrere Requests verlangen würde, aber bei heutigen Processoren und algemein erhöhten Geschwindigkeiten würde es nur kleine Rolle spielen. Für den Templateautor ist alles klar und er kennt sich gut aus. Würde aber jemand wollen, das Template irgendwie anzupassen, der hilft sich wohl nur sehr schwer durch. Gute Lösung wäre z.B. eine template.php Datei zu haben, die ähnlich wie z.B. config.php vom Backend Zugriff ermöglichen würde.
Dass es etwas unübersichtlich wird, liegt in der Natur der Sache. Das wird auch in einer extra-Datei nicht anders.
Wenn wir später die Möglichkeit haben werden, Templates über das Backend zu konfigurieren und sprachabhängige Texte zu verwenden, dann wird die Bedienung wesentlich leichter und die Hilfetexte (Kommentare) werden wie bei Plugins mit dem blauen (?) erscheinen.
Das Umbauen von Templates - so wie du es jetzt vorhast - wird aber schwieriger. Da muss dann an noch viel mehr Stellen geändert werden.
Die meisten Benutzer werden aber alles so verwenden können - wie es ist.
Die :root-Variablen haben den Vorteil, dass im gesamten Template (auf der gesamten Website) mit einer Farbangabe mehrere Elemente mit verschiedenen Abstufungen eingefärbt werden können. Das dient u.a. auch dazu, die Seite nicht "kunterbunt" zu machen. Ich finde das gut und simple.Tata wrote: ↑Tue Oct 12, 2021 10:07 pm2. stylesheet.css
Die :root Variablen finde ich bißchen unpraktisch, sogar verwirrend. Besonders, wenn im stylesheet.css gibt z.B.
...
(hier ist die Nutzung OK)
...
aber hier schon etwa verwirrend
...
oder
...
Ich habe keinen Vorteil in dieser Form gefunden. Mehr flexible, logisch, sicherer und praktischer finde ich die Werte an den Stellen, wo sie logisch gehören, auch zu definieren. Wenigstens finde ich es "Platzsparend"
...
Wenn ich imm stylesheet.css auf z.B.
...
schaue, brauche ich nicht am Anfang suchen, welche farbe im ":root" für die Klasse eingestellt ist, um sie dann zu ändern. Also, wenn ich im stylesheet.css die "--mainBackgroundColor" ändere, äanderst sich automatisch auch die Farbe im "span.sticker", was ich nicht brauche. Würden die Farben separat definiert, kaönnte ich mit einer oder zweiter beliebig spielen.
Wenn du einzelne Elemente umfärben möchtest, dann ist das überhaupt kein Problem.
Beispiel Sticker:
Du musst ja bei solchen Elementen nicht die :root-Variablen verwenden. Niemand hält dich davon ab, es zum Beispiel so zu tun:
Code: Select all
span.sticker {
...
background: #f00;
...
color: #fff;
...
}
Der Swiper ist nun wieder ein ganz anderes Thema.Tata wrote: ↑Tue Oct 12, 2021 10:07 pm3. Swiper
Es würde Einstellungen für die Bilder im stylesheet.css verlangen, aber ich finde es mehr Nutzerfreundlich, die "Sliderseiten" im Backend zu bearbeiten und Swiper sie nutzen lassen, als sie als leere erstellen und den Rest im swiper-set/include.php und swiper-set/stylesheet.php zu definieren. Eine Sache auf 2-3 verschiedenen Stellen definieren, einstellen usw. zu müssen, finde ich nicht besonders "simple". Obwohl das fhs-sectionsOP einfach fabelhaft ist.
Die HIntergrundbilder kannst du auch über den Tab "Swiper" auf den Seiten Slider1, Slider2 und Slider 3 festlegen.
Ich habe mich dazu entschieden, es in der stylesheet.php zu tun. Mir schien das einfacher.
Niemand hindert dich, das anders zu realisieren.
Dazu schrieb ich schon weiter oben.
Wenn du hier etwas änderst, dann musst du das gesamte Template und auch das JS bearbeiten.
Re: neues Onepage-Template: fhs-sectionsOP - Tester?
Alles klar, alles machbar. Es waren nur meine Bemerkungen. Das Template gefällt mir doch besonders. Nur muss ich finden, wie einzelne Kleinigkeiten meinen Vorstellungen anzupassen. Und das ist auch nur ein persöńiches “Challenge”.
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.