WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

You are not logged in.

#1 07.06.2016 19:01:20

norhei
Developer

Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Also persönlich würde ich sagen , wenn wir das So hinbekommen das Die Module in allen Themes funktionieren (nach möglichen kleineren umbau Arbeiten) soll mir das recht sein das Template mit in das Core Packet zu packen. Wenn aber bei Aktivierung des Templates  erst die Module gepatcht werden müssen würde ich meinen , das es noch nicht Reif ist. Dann würde ichs auf 2.0 verschieben , da wir dann Zeit haben das mit den Modulen zu regeln.
(Solange wäre es dann einfach ein installierbares Theme)

Genauso wie einige der BE Features noch keinen Sinn gemacht haben gilt auch hier , den (neuen)Nutzer keine Steine in den Weg.

Offline

#2 07.06.2016 19:23:41

florian
Administrator

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

das Template mit in das Core Packet zu packen

(Zur Klärung: bezieht sich auf Fraggy, nicht auf mögliche auf Responsee basierende Templates)

Ich habe heute ich weiß nicht wie lange, bestimmt 3, 4 Stunden damit verbracht, die Backends von Topics, Miniform und MiniGal zu patchen. Insbesondere MiniGal war ein Alptraum. Hätte wirklich nicht gedacht, dass ausgerechnet Ruud auch 2015/2016 noch solchen furchtbaren quick&dirty-Tabellencode produziert.
Also insofern sehe ich schwarz, da auch nur halbwegs zeitnah besonders viele Patches zur Verfügung zu stellen, zumal das, was ich produziere, meist nur Zuckerguss für Scheiße ist. Sprich, es sieht zwar nicht mehr so schlimm aus, aber man sollte besser nicht daran kratzen.
Wäre also gut, wenn sich noch ein paar weitere Mitstreiter_innen finden würden.

Offline

#3 07.06.2016 21:17:16

stefanek
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Dieses Responsee Framework gefällt mir sehr gut. Schlank und für ein BackendTheme absolut ausreichend.

thumb_up

~Chris


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#4 07.06.2016 21:33:41

norhei
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Persönlich klingt das genauso wie die Umstellung der Admintools nach einer Kandidatur für 2.0 , also Anfang 2017. Das bietet Zeit sich Module vorzunehmen und da misch ich dann auch mit , nach diesem Release wollte ich ja sowieso mich mal vermehrt  an die Module machen. 

Leider sind viele Module einfach nur so irgendwie zusammengebaut(Das Problem gibt es wohl in allen CMS), offt ließe sich das viel einfacher und eleganter lösen.

Offline

#5 07.06.2016 22:28:37

stefanek
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

norhei wrote:

Leider sind viele Module einfach nur so irgendwie zusammengebaut(Das Problem gibt es wohl in allen CMS), offt ließe sich das viel einfacher und eleganter lösen.

Nun, das stimmt.
Viele Module sind einfach Module, die auf der Grundlage von anderen Modulen zusammengeschustert wurden, die dann wieder weiter geschustert wurden.
Unser mpForm das wir nach FrankH geschustert haben das er vom Form geschustert hat und an dem Martin jetzt schustert ist auch so eins :-D


Es gibt Wenige, die Module komplett "from scratch" bauen.
Ruud und cwSoft, Bianka auch. Ich ein paar. Vielleicht noch andere, die mir jetzt nicht einfallen.

Vielleicht gibts demnächst mehr.
Ich habe einige, die ich für die 2.8.4. ausgearbeitet habe.
Sobald aber die I/Insert Class drin ist und wir den PageTree fit haben, werde ich die dann auf WBCE nach und nach, so ich Zeit finde, umbauen.

Gruß,
Chris

Last edited by stefanek (07.06.2016 22:29:07)


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#6 08.06.2016 09:51:32

webbird
Administrator

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Naja, die DLG 3 ist auch teilweise noch geschustert, obwohl ich auch viel Code weggeworfen oder "optimiert" habe. Manchmal weiß man einfach nicht, was sich der Autor dabei gedacht hat, und läßt es deshalb lieber drin - wie das strtolower() bei der DLG. Bis man dann feststellt, daß es doch irgendwie sinnfrei ist. big_smile (Was nicht heißt, daß es keine guten Gründe dafür gab, nur sind die dann entweder nie zum tragen gekommen oder zwischenzeitlich rausgeflogen. Ist nicht so als gäb's in meinen Modulen nicht auch solche Leichen.)

Was Ruuds Module angeht: Die funktionieren und sehen im Browser gut aus, wenn ich den Code lese (oder einfach nur XDebug einschalte) gruselt's mich aber meistens. Er benutzt z.B. ungeprüft Einträge aus dem $_SERVER Global (wbstats) und ähnliches, wo sich mir die Fußnägel aufrollen. Das ist auch bei vielen anderen Modulen so, aber gerade bei Ruud finde ich das irgendwie erschreckend. Im Vergleich zu manch anderem ist er - oder sollte er sein - ein Profi...

Wie auch immer, der eigentliche Punkt ist, was einen höheren Rang hat, das BE Theme oder die Module, die damit laufen sollen. Optimalerweise ist ein Modul eine Art "Sandbox", das heißt es stört weder das BE Theme, noch zerstört das BE Theme (z.B. durch sein CSS oder JS) die Funktion des Moduls. Meine Empfehlung wäre, so früh wie möglich - sprich jetzt - Regeln aufzustellen, wie das erreicht werden kann. Das fängt mit der Benennung der CSS Klassen und JavaScript-Funktionen an. Irgendwann gab es irgendwo in der WB Doku mal die Anweisung, daß die CSS Klassen von Modulen das Präfix "mod_<Modulname>" haben sollten, was eine Möglichkeit wäre. Wobei es bei CSS auch noch andere Methoden gäbe, aber es ist und bleibt eben ein Problem, wenn etwa ein verwendetes CSS Framework a la Bootstrap eine Klasse "content" definiert - auf den naheliegenden Gedanken kommen andere nämlich auch. (Das ist auch eine Kernkritik, die ich bei Bootstrap sehe. Schon ein einfaches Präfix wie "b_" könnte viele Probleme vermeiden. Aber da sieht sich so ein Framework eben als maßgeblich, alle anderen haben sich anzupassen. Das macht das nachträgliche Umstellen allerdings extrem schwierig.)

Da Modulnamen schon mal ziemlich sperrig sind, kann man die Präfix-Regel natürlich auch etwas weicher formulieren. (Z.B. "mod_dlg3_" statt "mod_download_gallery_3_".) Man könnte sogar so weit gehen, die Leute den Modulnamen samt Präfix registrieren zu lassen - manche Projekte mit Modulschnittstelle machen das so. Das mag auf den ersten Blick aufwendig erscheinen, manche mögen auch kritisieren, sie fühlten sich in ihrer Freiheit eingeschränkt, aber auf der anderen Seite löst das viele potentielle Probleme. Ich denke schon länger über eine solche Regelung bei BC nach, aber so lange wir wenig eigene Module haben, ist das nicht so wichtig, zumal alle für BC geschriebenen Module bisher von mir und Matthias kommen und wir das ohnehin so halten. Das ist bei WBCE aber nicht so. Daher könnte es sich lohnen, solche Regeln zu definieren und auch durchzusetzen.


Ich habe eine Amazon-Wishlist. wink
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#7 08.06.2016 10:03:55

webbird
Administrator

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Hier mal ein paar Anregungen, wie eine Regelung für CSS aussehen könnte.

* Module dürfen keine globalen Typselektoren (body, h1 etc.) verwenden. Das ist nur erlaubt, wenn sie durch Kombination mit Klassen- oder ID-Selektoren so eingeschränkt wurden, daß sie sich nicht mehr global auswirken. Also z.B. erlaubt: div.mod_dlg3 h1; nicht erlaubt: h1

* Klassennamen müssen ein eindeutiges Präfix haben. Empfohlen: mod_<Modulname> oder mod_<Modulkürzel>. Also z.B. erlaubt: mod_dlg3_content; nicht erlaubt: content

* Templates und Themes dürfen globale Typselektoren verwenden, müssen aber ebenfalls eindeutige Präfixe bei Klassennamen verwenden. Statt mod_ kann z.B. theme_ bzw. tpl_ plus Templatename oder -kürzel verwendet werden.

* Bei Modulen sollte nach Möglichkeit auf ID-Selektoren verzichtet werden, da diese bei mehrfacher Verwendung eines Moduls auf einer Seite nicht mehr eindeutig sind. (Womit der Quellcode auch nicht mehr valide ist.) Ausnahme: Admin Tools.


Ich habe eine Amazon-Wishlist. wink
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#8 08.06.2016 11:22:33

stefanek
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Ergänzend zu dem, was Bianka oben geschrieben hat, hier einige
meiner Beobachtungen und Empfehlungen, für die Gestaltung der Modul-Backends:

  1. Die meisten Module in den Backends haben eine Settings Eingabemaske, die eine Art "Tabelle" mit Input-Feldern ist (früher waren das richtige <table> Tabellen, heute sind sie tabellenlos.
    Um alles einheitlich mit dem Admin-Theme zu gestalten, könnte man folgendermaßen vorgehen:

    1. Es wird ein Muster verwendet in Backend/Grundeinstellungen/Grundeinstellungen (in der aktuellen GitHub-Version ist es: admin/settings/tool.php?tool=settings_defaults)

    2. Dieses Muster würde dann in sämtlichen Core-Modulen im Backend verwendet werden, was eine Einheitlichkeit gewährleistet.

    3. Die Modul-Autoren können dann sehr einfach dieses Muster übernehmen, ohne eigene backend.css für diese Stanard-Formatierungen zu schreiben, ohne das Rad neu erfinden zu müßen.
      Natürlich bei Anspruchsvolleren Backends (oder bei sehr individuellen Autoren) wird man auf die backend.css zurückgreifen müßen.

  2. Eine andere, häufig auftauchende Sache sind Listen und Drag/Drop Listen mit Items (News, Gallerienmodule, Members...)
    Auch hierzu könnte man sich am Beispiel von pages/manage_sections orientieren, indem ein sauberes Muster erstellt wird, worauf dann in den Modulen und dann bei individuellen Modulen von Modul-Autoren zurückgegriffen werden kann.

Das ganze müßte für die Autoren natürlich nur eine Empfehlung darstellen, kein Klotz am Bein, an das man sich unbedingt halten muss.

Der Vorteil wäre dann aber der, dass selbst sehr ausgefallene Admin-Themes gleich einen Großteil der Module berücksichtigen würden, da diese Module zum großen Teil auf das gleiche CSS zurückgreifen würden.

Es wäre dann auch egal, ob jemandes privates, nachinstalliertes Theme auf Bootstrap aufgebaut ist, einem anderen CSS-Framework oder komplett ohne Frameworks, denn das Vorlage Admin-Theme würde ein eigenes kleines Framework für die Hauptinhalte bereitstellen.

Gruß,
Chris

Last edited by stefanek (08.06.2016 12:31:25)


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#9 08.06.2016 14:48:13

grindbatzn
Guest

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Tabellen:
Tabellen sind weder verboten noch irgendwie böse. In vielen Modulen gibt es eine tabellenartige Darstellung von Elementen und es gibt aus meiner Sicht keinen Grund, das mit Gewalt zu ändern. Klar muss man nicht 7 Tabellen ineinander haben, aber jetzt alles rauszuschmeißen? Ne, wirklich nicht.

Backend-Themes:
Mag sein, dass ich alt werde, aber: Ein Backend Theme sollte einfach und übersichtlich sein. Riesige (sinnbefreite) Bilder, dafür unerkennbare Links, monoton aufgelistete Felder (egal ob Title oder max 2-stellige Zahl - alles gleich)..
Einem Kunden würde ich das nie raufladen, der ist völlig überfordert. Wen interessiert riesengroß, welche WB-Version das jetzt ist? Dafür muss er ewig suchen, was man jetzt anklicken kann und was nicht.

OK - das mag Geschmackssache sein, aber die Geschmackssache hört bei mir auf, wenn Module umgebaut werden, weil sie in Backend-Theme 4967 komplett gaga aussehen, und dann sehen sie dafür in Backend-Theme  2612 bescheuert aus.

So generell finde ich es nicht schlimm, wenn Module im Backend ein etwas eigenes Aussehen haben. Dann sieht man wenigstens sofort, dass das jetzt eben dieses Modul ist. Soll man natürlich nicht übertreiben, aber die totale Vereinheitlichung macht nichts besser.

#10 08.06.2016 15:09:56

stefanek
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

grindbatzn wrote:

Backend-Themes:
Mag sein, dass ich alt werde, aber: Ein Backend Theme sollte einfach und übersichtlich sein. Riesige (sinnbefreite) Bilder, dafür unerkennbare Links, monoton aufgelistete Felder (egal ob Title oder max 2-stellige Zahl - alles gleich)..
Einem Kunden würde ich das nie raufladen, der ist völlig überfordert. Wen interessiert riesengroß, welche WB-Version das jetzt ist? Dafür muss er ewig suchen, was man jetzt anklicken kann und was nicht.

OK - das mag Geschmackssache sein, aber die Geschmackssache hört bei mir auf, wenn Module umgebaut werden, weil sie in Backend-Theme 4967 komplett gaga aussehen, und dann sehen sie dafür in Backend-Theme  2612 bescheuert aus.

Ja, stimme ich total überein.
Die Übersichtlichkeit sollte das A und O sein.

Und wie erwähnt, Originalität und gestalterische Freiheiten sollten nicht verwehrt werden. (Kann man eigentlich ja auch nicht, da die backend.css ja nicht wegkommen.)

Ich habe in meinen eigenen Modulen immer eigene backend.css mitgebracht, aber die war ungünstig überladen und dann passte es mit anderen Themes nicht.
Die gestalterische Freiheit bei den alten Themes hat sich auf
<table class="row_a"> beschränkt, falls das jemand noch in Erinnerung hat :-D

Ansonsten: Tabellen: ja, es gibt sogar noch im Core einige Tabellen für Settings (unterm Seitenbaum z.B. AddPage). Doch wenn es auch in Modulen super ist, im Core sollte das dann komplett vereinheitlicht werden.

Gruß,
Chris

Last edited by stefanek (08.06.2016 15:11:28)


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#11 08.06.2016 15:40:25

florian
Administrator

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Tabellen:
Tabellen sind weder verboten noch irgendwie böse. In vielen Modulen gibt es eine tabellenartige Darstellung von Elementen und es gibt aus meiner Sicht keinen Grund, das mit Gewalt zu ändern. Klar muss man nicht 7 Tabellen ineinander haben, aber jetzt alles rauszuschmeißen? Ne, wirklich nicht.

Tabellen sind böse, wenn man den Anspruch hat, ein responsives Design zu haben. Auch im Backend. Versuch mal, zwei per Layouttabellenzellen nebeneinander gesetzte Bereiche untereinander anzuordnen, wenn der Platz zu knapp wird.

Backend-Themes:
Mag sein, dass ich alt werde, aber: Ein Backend Theme sollte einfach und übersichtlich sein. Riesige (sinnbefreite) Bilder, dafür unerkennbare Links, monoton aufgelistete Felder (egal ob Title oder max 2-stellige Zahl - alles gleich)..

Anstatt jetzt zu sagen "bäh, unzumutbar" hättest Du Dich an der Diskussion zum neuen BE-Theme beteiligen können und Verbesserungsvorschläge einbringen.  Niemand schreibt irgendwem vor, was er gut oder schlecht zu finden hat oder welches BE-Theme zu verwenden ist, aber dieser dogmatische Tonfall hier gefällt mir ganz und gar nicht.
Anstatt über sinnbefreite Bilder zu fluchen schreib doch einfach, dass Du es besser fändest, wenn die großen Icons auch anklickbar wären - da wären wir nämlich sogar einer Meinung.


Einem Kunden würde ich das nie raufladen, der ist völlig überfordert.

Das stimmt meines ERachtens so nicht. Erstens kann man in Maßen auch von Kunden Lernbereitschaft verlangen. Zweitens sind alle BE-Templates meinem Dafürhalten nach aufgeräumt und übersichtlich und überfordern niemanden.

Wen interessiert riesengroß, welche WB-Version das jetzt ist? Dafür muss er ewig suchen, was man jetzt anklicken kann und was nicht.

Die WB-Version interessiert niemanden, die WBCE-Version interessiert mich um so mehr. Ich habe sogar angeregt, auch die PHP-Version anzuzeigen. Warum? Ganz einfach, um so besser und zielgerichtet Support leisten zu können, ohne den Kunden erst Sysinfo installieren zu lassen oder selbst auf den Server schauen zu müssen.

OK - das mag Geschmackssache sein, aber die Geschmackssache hört bei mir auf, wenn Module umgebaut werden, weil sie in Backend-Theme 4967 komplett gaga aussehen, und dann sehen sie dafür in Backend-Theme  2612 bescheuert aus.

Was soll diese Polemik?

So generell finde ich es nicht schlimm, wenn Module im Backend ein etwas eigenes Aussehen haben. Dann sieht man wenigstens sofort, dass das jetzt eben dieses Modul ist. Soll man natürlich nicht übertreiben, aber die totale Vereinheitlichung macht nichts besser.

Auch dem muss ich widersprechen. Ich bin auch kein Freund von übermäßiger Standardisierung und Gängelung. Aber schön wäre es schon, wenn es einen Baukasten gäbe, auf dem zukünftige Module aufbauen und für die gleichen Funktionen die gleichen Begriffe und Symbole verwendet würden und bestimmte Elemente immer an derselben Stelle zu finden wären. Das würde die Lernkurve für Anwender nämlich erheblich verflachen.

Eine typische Kombination von Inhaltstypen eines Webauftritts ist: Fließtext, News/Blog, Bildergalerie, Formular, Downloadbereich.
Momentan sieht jedes dafür verwendete Modul im Backend anders aus.
DA sehe ich die wirklichen Probleme für Kunden und nicht in meinetwegen funktionslosen, aber hübsch anzusehenden Icons.

Das ist auch nicht besonders professionell, wenn jedes Modul anders aussieht.
Es gab in den 90ern mal einen VW Polo Harlekin. Genau so kommt derzeit das Backend daher, wenn man mehr Module als nur WYSIWYG, News und Form verwendet.
Würdest Du mit so etwas bei einem Großkunden vorfahren wollen? Oder doch lieber mit einem etwas seriöseren Auto?

Last edited by florian (08.06.2016 15:42:36)

Offline

#12 08.06.2016 16:02:24

stefanek
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

florian wrote:

Ich habe sogar angeregt, auch die PHP-Version anzuzeigen. Warum? Ganz einfach, um so besser und zielgerichtet Support leisten zu können, ohne den Kunden erst Sysinfo installieren zu lassen oder selbst auf den Server schauen zu müssen.

Hey, das ist tatsächlich eine gute Idee.

Ansonsten, wie ich oben schrieb, eine gewisse Vereinheitlichung bei den Standardbereichen sollte tatsächlich gegeben sein, auch wenn sich nicht alle Autoren dran halten wollen; und sicher würde nicht jeder eine sofortige Adaption dieses Framewok-Baukasten einfordern.

Ich persönlich bevorzuge eine Einheitlichkeit.
Dass meine Module dann doch immer irgendwie alles selbst mitgebracht haben, lag daran, dass das Haupt-Theme immer zu karg daher kam.

Deswegen denke ich auch, dass wenn man die Bereiche Core-Settings, Manage-Sections und noch einige weitere gut vorbereitet, kann man da wirklich etwas bereitstellen, worauf Themes ihr eigenes CSS anwenden können und Module als Vorlage nehmen können.

Gruß,
Chris


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#13 08.06.2016 16:22:04

stefanek
Developer

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Ich denke nach wie vor, dass http://www.csszengarden.com/ die beste Referenz dafür ist, wie das Aussehen von Themes/Templates bei gleicher HTML Struktur nur mittels CSS komplett anders aussieht.
Und das geht natürlich nur bei vernünftiger HTML Struktur.

thumb_up

~Chris


"All the knowledge I possess everyone else can acquire, but my heart is all my own."
Johann Wolfgang von Goethe

Offline

#14 09.06.2016 08:32:34

grindbatzn
Guest

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Zu oben von Florian
>>Tabellen sind böse, wenn man den Anspruch hat, ein responsives Design zu haben.

[== CSS ==]
@media screen and (max-width: 600px) {
	.modifytopic-toptable td {display:block; }
}

(Aus Topics 0.912, meiner Arbeitsversion)
Klappt wunderbar. Am Desktop die Vorteile der Tabelle, am Handy ein ganz normaler div.

Bei Fraggy kommt als Problem dazu, dass die linke Menüspalte erst sehr spät verschwindet. Die sollte eigentlich schon bei <= 1024 px verschwinden, dann gibt es am Tablet keine Probleme mit Modulen.
Ein Modul kann ja nicht wissen, dass es nicht ca den Viewport an Breite zur Verfügung hat, sondern dass da noch 250px Menü sind.

Und dass ich über Fraggy oder WBCE Flat bisher nix gesagt habe: Ich nutze sie nicht, also sage ich nix dazu. Ich sage erst was, wenn Änderungen an Modulen verlangt sind.

#15 09.06.2016 10:52:25

webbird
Administrator

Re: Module: Backend-Codequalität / Anpassungen an Fraggy & Co.

Ich hab die Beiträge zu dem Modulbaukasten ausgelagert. http://forum.wbce.org/viewtopic.php?id=588


Ich habe eine Amazon-Wishlist. wink
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

Board footer

Powered by FluxBB

up