Neues Projekt: Modul Leitfaden

[doc]

Hi,

im Deutschen Forum hat es kürzlich einige Diskussionen über Module gegeben. Hauptpunkt der Diskussion waren fehlende Testkritierien für Website Baker Module.

Ein anderer (meiner Ansicht nach) wichtiger Punkt der bisher noch recht wenig bis gar nicht beachtet wurde, sind die fehlenden Modul-Standards. In der Tat gibt es derzeit keine offiziellen Standards für Module. Die meisten Module für Website Baker sind durch anpassen existierender Module mit allen daraus existierenden Vor- und Nachteilen entstanden. Es gibt ein paar grundlegende Infos zur Modulentwicklung auf der WB Hilfeseite (Rubrik Advanced Dokumentation) oder im "Hello World" Modul. Was aber klar fehlt, ist ein Schritt für Schritt Leitfaden für angehende Website Baker Modulentwickler.

Ich habe daher beschlossen, einen solchen Modul Leitfaden zusammen mit Intersierten zu entwickeln. Wie ich mir das gedacht habe? An diese Post ist ein sehr minimalistisches aber immerhin lauffähiges Modul (Typ: Seite) angehängt. Das Modul enthält die von Website Baker benötigten Dateien, um über das WB Backend installiert und deinstalliert werden zu können. Das Moduls gibt ledigliche eine Englische Textzeile im Frontend und Backend aus - mehr nicht.

In der Zipdatei ist eine README Datei (Englisch) enthalten, welche die absoluten Basics erklärt, wie z.B. das aufsetzen einer Entwicklungsumgebun g (XAMPP), einer WB Testinstallation (WB 2.7), sowie die benötigten Moduldateien und deren Code etwas näher erläutert. Darüber hinaus werden auch Texteditoren für die Bearbeitung von PHP Dateien mit Syntaxhervorhebung vorgestellt um die Beispiele besser nachvollziehen zu können. So weit so gut.

Die nächsten geplanten Schritte sind die hartcodierten CSS Definitionen eine CSS Datei auszulagern (Schritt 2a), die Unterstützung von Mehrsprachigkeit einzuführen (Schritt 2b) und anschliessend HTML und PHP Code mittels der in WB mitgelieferten Templateengine zu trennen (Schritt 2c). Schritt 3 Austausch mit der MySQL Datenbank. Schritt 4 absichern von Moduldateien. Weiter Schritte bei Bedarf (offen für Vorschläge).

Abhängig vom Feedback und der Hilfe von Freiwilligen die an diesem Projekt mitarbeiten möchten, kann der Funktionsumfang dieses Projekts weiter wachsen. Möglich wäre z.B. ein "richtiges Modul" zu entwickeln, die Dokumentation zu verbessern (HTML, PDF oder was immer), Übersetzungen in andere Sprachen zu erstellen usw. Es gibt auch die Möglichkeit, Vorschläge für Coding Standards oder Modulanforderungen zu formulieren ...

Es gibt viele Bereiche, wenn Du an diesem Projekt mitwirken willst wie:
 - einbringen von Programmiererfahrun g (Javascript, PHP oder was auch immer)
 - Übersetzungen des "Module Primer" oder der Modul Sprachdateien (Basisinformation ist in English)
 - Design Erfahrung mit GUIs (CSS, Bedienbarkeit, Zugänglichkeit etc.)
 - Designer, Grafiker, Texter (Dokumentation als Textdateien in English)
 - Modultester usw.

Wenn Du irgendwie an diesem Projekt mitarbeiten willst, schreibe einfach einen Beitrag in diesem Thread.

Und was wenn das Projekt scheitert? Nun dann können wir immer noch so weiter wurschteln wie bisher. Ich denke wir sollten dem ganzen eine Chance geben, zusammen als Community (sprich mit mehreren Leuten zusammen).

Freue mich auf Anregungen, mehr noch aber auf jede Form von aktivem Beitrag zu diesem Projekt.

[quote author"für was dieser Thread nicht gedacht ist"]Was ist dieser Thread nicht? Nun in diesem Thread soll keine Diskussion über PHP4 oder PHP5 geführt werden. Es geht auch nicht darum, ob nun Objektorientierte Programmierung oder der Modulare Ansatz der bessere ist. Wer solche Punkt besprechen will kann dies gerne in einem eigenen Thread tun. Ich würde es sehr begrüssen, wenn dieser Thread mehr für "aktive" Hilfe statt den oft zu beobachtenten "fruchtlosen" Diskussionen ohne daraus resultierende Ergebnise genutzt würde
[/quote]

Wichtiger Hinweis: Der "Modul-Leitfaden", das heisst das Modul selbst sowie Text und Bilder des Leitfaden werden unter der Creative Commons Attribution-NonCommercial-No Derivate 3.0 License veröffentlicht. Das heisst das ganze kann für nicht kommerzielle Zwecke vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, solange das Werk als solches unverändert angeboten wird, die Copyright Hinweise erhalten bleiben und ein Rückverlinkung auf das Website Baker Projekt (http://www.websitebaker.org) erfüllt ist.

Der Englische Thread zu diesem Thema ist unter:
http://www.websitebaker2.org/forum/index.php/topic,13133.msg79986.html#msg79986

Gruss
Christian (ak doc)

Revisionen:
Revision A: "README_module_prime r_step1_Rev-A.txt" (10.03.09; 21:00); vorige Version (9x)

[maverik]

hi

In der Tat gibt es derzeit keine offiziellen Standards für Module.

einen wichtigen standard fände ich das man sich auf ein ein scriptframework, jquery, motools, etc, einigt. derzeit benutzt jeder sein lieblingsframework und so kommt es zu unnötigen konflikten bei den modulen weil sich das eine nicht mit dem anderen verträgt oder teilweise doppelt und dreifach geladen wird.
würde man ein framework wie zb jquery systemweit zur verfügung stellen bräuchten die module nur noch ihre plugins nachladen und alle hätten sich lieb. 

das schreibe ich allerdings als anwender mit einer menge ideen der aber nicht weiß wieviel programmieraufwand dahinter steckt.

ansonsten stürze ich mich gerne auf alles was sich so als dau  im rahmen meiner zeit testen lässt.

gruß vom niederrhein

maverik

[doc]

Hi Maverik,

eine grosse Hilfe wäre es z.B. wenn Du wann immer Du Zeit hast mal den Text überfliegen würdest. Gerade auch das Feedback von Nichtprogrammieren kann bei einem "Leitfaden" nie schaden 

Und zu jQuery und Co. Es war in der Überlegung, jQuery und jQueryUI als Ersatz für die YahooUI zu verwenden (wird für JS Admin benötigt). Dies wird aber wohl nicht mehr mit WB 2.8 kommen, sondern erst später. In einem späteren Stadium des Modulleitfadens könnten auch Überlegungen zu diesem Thema aufgenommen werden.

Gruss Christian

[maverik]

hi doc

mal den Text überfliegen würdest

du meinst die txt datei im anhang? macht es sinn die übersetzen zu lassen um sie dann auch in deutsch zur verfügung zu stellen? hätte da eventuell eine möglichkeit

gruß vom niederrhein

[jrast]

Super Idee!

Aus meiner Sicht das wichtigste: klare Trennung von Code und Layout! Meiner Meinung nach sollten alle Module die Templateengine verwenden. Somit wird es viel einfacher das Design an die eigenen Wünsche anzupassen. In diesem Bereich wäre ich auch bereit etwas dazu zu beizutragen.

Aber auch in den anderen Bereichen macht es Sinn richtung einheitlichkeit zu streben. Dies hilft vorallem den Entwickler, man hat dann viel schneller den durchblick bei einem Projekt.

[doc]

@Maverik: Es macht absolut Sinn die Texte in möglichst viele Sprachen zu übersetzen. Da der deutschsprachige Teil des Forums recht aktiv ist, wäre eine Deutsche Version eines "Modul Leitfadens" sehr sinnvoll. Wenn Du den Text übersetzen kannst, wäre das also super.

@jrast:
Da kann ich Dir nur zustimmen. Die Trennung von HTML und PHP Code ist im Schritt 2c vorgesehen. Die Zwischenschritte 2a (CSS) und 2b (Mehrsprachigkeit) sind gerade in Arbeit. Werde Dich per PM kontaktieren, damit wir uns für Schritt 2c entsprechend absprechen können.

Gruss Christian

[Luisehahne]

Hi,

halte ich für sehr gut, bin dabei. Nur mit den Lizenbestimmung blicke ich nicht immer durch, was nützt mir das beste CMS, wenn ich es nicht auf kommerziellen Seiten einsetzen darf.  Backlink und Hinweis auf den Author ist nie ein Thema. Was haltet ihr von der BSD Lizenz, wie z.B. bei jquery?

Und damit zum thema jquery. Meine wie auch viele andere Module benutzen es und dann auch noch mit unterschiedlichen Versionen. Also eine feste Einbindung ist da wohl nicht verkehrt. Da kommt natürlcih die Frage auf, wo fängt man an und wo hört man auf. Was ist mit updates auf neuere und gefixte jquery.

Probleme, die man auch berücksichtigen sollte. Wer hat schon gerne veraltete Scripte, die nicht richtig laufen. Dazu kommt natürlich auch die Abwärtskompabilität. Siehe swobject.js welches sich laufend verändert und teilweise nicht abwärtskompatibel sind.

Das wars erstmal. Ich hoffe, dass ich nicht mal wieder zu umständlich geschrieben habe.

Gruss
Luisehahne

[chio]

Ich fände es gut, wenn dabei ein einfaches, aber konkretes Modul entstehen würde, das man als Basis für weitere verwenden kann.

zb (scheint es nicht zu geben, weil es auch mit SM2 geht):
Auflisten von Unterseiten und/oder Geschwistern dieser bestimmten Seite, je Title, Meta-Description. Natürlich mit Options. (Header, Loop, Footer)
Vor dem Header einen WYSIWYG-Teil als "Anreißer". (Damit auch WYSIWYG vorkommt und man was zum Suchen hat)
Und Hilfe, klar. Und: integriertes Frontend-Edit, mit dem man gleich zu den Seiteneinstellungen der Seiten kommt.

Das wäre zwar ein einfaches Modulchen, kommt aber alles drin vor.

Oder: Man nimmt sich ein existierendes Modul, das nicht mehr gepflegt wird, aber nützlich wäre und richtet es "mustergültig" her.

[doc]

@Chio:
Im ersten Schritt des Projektes schwebt mir eine Art "Modulschablone" vor, welche die notwendigen Basics enthält (Trennung von HTML, PHP, CSS, Javascript, Mehrsprachigkeit, Sicherheit, Standards), aber ansonsten keinen wirklichen Zweck erfüllt. Diese "Schablone" kann man dann als Grundlage für die Entwicklung eigener neuer Module verwenden und an die eigenen Bedürfnisse anpassen.

Im zweiten Schritt ist dann ein "richtiges" Modul mit Features vorgesehen. Ob Schritt 2 umgesetzt wird oder nicht, hängt vor allem davon ab, wer sich aus der Community an diesem Projekt beteiligen will, ob sich Leute finden, die das ganze in ein PDF oder HTML (z.B. Hilfeseiten) überführen etc.

@Luisehahne:
Da habe ich mich wohl etwas unglücklich ausgedrückt.
Mir geht es darum, dass der aus dem Projekt resultierende Modulleitfaden (sprich der Text und die Bilder) under Creative Commons gestellt werden, ein Backlink auf das WB Projekt erfolgt und das ganze nur ohne weitere Änderungen und für nicht kommerzielle Zwecke veröffentlicht werden darf.

Das daraus resultierende Modul sollte in der Tat unter GNU GPL veröffentlicht werden. Ich werde die Copyright Hinweise im Modul mit Step 2a dahingehend ändern.

Gruss Christian

[lousou76]

Hi,

Although I don;t speak German I managed to understand what this thread was saying using the google translator 

I think it's a great idea to make a nice module base so we all can use to create new stuff.
HTML and PHP code seperation is the most important step I think. This way even ppl who don't programm will still be able to improve module layouts and use them.

I usually write a lot of mixed code because I want it done fast and I can't bother messing with css so I use tables.
It would be really helpfull to have a nice working base module.

I ll try to participate.
Regards,
LS

[doc]

@lousou76:
There is a German (this thread) and an English thread for the "Module Primer" topic. Forgot to cross link both in my first post, which is fixed now - thanks for the notice.

Regards Christian

Bitte beachten: Die im ersten Post angehängte Readme Datei des "Modulleitfadens" wurde auf Revision A upgedated.

[Stefek]

Also ich finde die Idee gut,wenn man den Code vom Design trennt, wie oben schon angesprochen und wie z.B. im Modul "Guestbook" zu sehen.
Ich habe ein paar Schritte im Voraus gedacht, vielleicht - es gibt nämlich mitlerweile einen recht guten WB Addon Editor. Ich finde, dieser Sollte fest in WB integriert werden. Auf diese Weise könnte man von Modulen heraus bestimmte Moduldateien bearbeiten (nicht nur frontend./backend.css).

Darüber hinaus ist es momentan wichtig zu schauen, wie man das zukünftige Feature "Skinable Backend Interface" richtig berücksichtigt - falls es mit 2.8 rauskommt, wird es noch ziemlich krückenhaft und verbesserungswürdig sein.
Das Layout der Module selbst sollte einem bestimmten Schema folgen, damit die CSS Styles sich richtig auf die Module auswirken können und auch das CSS File des Backends selbst müsste um einige Styles erweitert werden, um einen guten Überblick zu schaffen.

Beispiele:
- die meisten Module verwenden in der [module]_settings.php für die Tabelle die Class "row_a".
- für die linke Spalte hat sich die Klasse "setting_name" eingebürgert, wird aber nicht konsequent eingesetzt (auch innerhalb der Module, die diese Klasse benutzen) - Auswirkung: Bearbeitet man die globale backend css und gibt der Klasse "setting_name" die Schriftstärke "bold", ist sie nicht durchgängig vorhanden.
Das sind kleinigkeiten, auf die aber geachtet werden sollte.
Und es geht.

Ich bin also an der Erarbeitung von Schritt 2a am meisten interessiert - als natürliche Folge meiner Fertigkeiten 

Gruß,
Stefek

EDIT//
Finde dieses Projekt sehr fortschrittlich, Christian.
Sehr gute Initiative.

[doc]

Hi,

anbei der Schritt 2a des "Modul Leitfadens". In Schritt 2a werden Techniken vorgestellt, um Konflikte mit CSS Definitionen aus verschiedenen Modulen zu vermeiden. Es wird erklärt, wie die Moduldateien "frontend.css" und "backend.css" am sinnvollsten eingesetzt und konfiguriert werden.

Weiterhin wird erklärt, wie man die die Möglichkeit zum Bearbeiten der Moduldateien "frontend.css" und "backend.css" vom Backend heraus ermöglichen kann.

Viel Spass.
Christian

P.S.: Zur Erinnerung. Der "Modul Leitfaden" ist ein "offenes Projekt" und jeder der mag, kann sich daran beteiligen

[Stefek]

Hi Doc,
mal geklugscheißert:
+++ B2: Create file: "backend.css" +++

sollte wohl "B4" heißen?

Gruß,
Stefek

[doc]

Hi,

anbei der Schritt 2b des "Modul-Leitfadens". Dieser Schritt erklärt warum Textausgaben von Modulen in Sprachdateien organisiert werden sollten und wie man Unterstützung für mehrer Sprachen in eigene Website Baker Module integriert. Das Modul enthält eine "Deutsche" und "Englische" Sprachdatei.

Viel Spass
Christian

[doc]

Hi,

anbei Schritt 2c des "Modul-Leitfadens". Dieser Schritt zeigt wie die in Website Baker mitgelieferte Template Engine dazu verwendet werden kann, PHP Code und HTML Markup voneinander zu trennen und in separaten Dateien zu verwalten.

Angehängt sind 3 Dateien. Die README Datei und die zugehörigen Template Engine Beispiele (Dateien ins WB Wurzelverzeichnis kopieren, diese Datei ist keine WB Moduldatei).

Die dritte Datei (module_primer_step2 c.zip) enthält das ausgearbeitete Beispielmodule des "Modul-Leiftadens" mit Unterstützung der PHPLib Template Engine.

Viel Spass.
Christian

[doc]

Hi,

da ich nun fast alle meine Webseiten auf ein anderes Open Source CMS umgestellt habe, werde ich den "Modul Leitfaden" für Website Baker wohl nicht mehr weiterentwickeln.

Sollte es "Freiwillige" geben, die das ganze weiterführen wollen, nur zu. Da das ganze ein Projekt für jedermann ist, können Inhalt und Ausrichtung nach belieben neu gesetzt oder geändert werden. Auch die Lizenz kann nach belieben geändert werden, sollte dies für die Fortführung des Projektes irgendwie notwendig sein.

Gruss Christian

[Luisehahne]

Hallo Christian,

jetzt bin ich aber doch mal neugierig warum du auf ein anderes CMS umgestiegen bist. Wenn du das nicht öffentlich erläutern möchtest, dann bitte über die Privat messages.

Auch ich hatte mal mit SMARTY CMS beschäftigt. Bin aber wegen der FLexibilität und Aktivitäten bei WB gelandet.

Ich hoffe das WB nicht sterben wird.

Gruss
Dietmar

[doc]

Hi,

gehört eigenlicht nicht in diesen Thread, aber nun gut.

Der Ausschlag für Website Baker war und ist das einfach zu bedienende Backend. Allerdings verwende ich fast auf allen Seiten eigens programmierte Module oder Coreänderungen, um die Bedürfnisse meiner Kunden zu erfüllen.

Rein von der "Coding" Seite betrachtet, gibt es einfach Systeme, welche mir mehr Möglichkeiten einräumen (CMS+ Framework). Hat man sich erst mal eingearbeitet, kann man sehr schnell Anpassungen vornehmen (Prototyping). Ein modularer Aufbau und durchdachte API ermöglichen z.B. die Kernfunktionen des CMS zu erweitern, ohne diese Änderungen beim nächsten Update zu verlieren. Ich verwende besagtes CMS seit gut einem Jahr parallel zu WB und anderen Open Source CMS Systemen.

Website Baker ist nach wie vor die erste Wahl für alle meine Kunden die lange Einarbeiung scheuen und auf das derzeit wohl einfachste CMS Backend setzen

Gruss Christian

[Stefek]

Hallo Christian.
Ich schätze es sehr, dass Du Deine Entscheidung näher erläutert hast.

Das hilft ab, auf "krumme Gedanken" zu kommen.

Website Baker ist nach wie vor die erste Wahl für alle meine Kunden die lange Einarbeiung scheuen und auf das derzeit wohl einfachste CMS Backend setzen

Wie wahr, wie wahr.

Viel Erfolg.
Stefek

[chio]

Das hilft ab, auf "krumme Gedanken" zu kommen.

Ja, jetzt wissen wir:
Fast alle von docs Kunden wollen _lange_ Einarbeitungszeit und ein _schwieriges_ CMS
DAS nenne ich Kundenerziehung...

Ich muss mal sagen:
Ich hatte in der letzten Zeit öfter mit Typo3-Projekten zu tun, nur oberflächlich.
Es war kein EINZIGES dabei, das ich nicht Ruck-Zuck mit WB hätte umsetzen können - ohne Core-Änderungen oder sonstwas.
Selbst ein PageRank6 Projekt mit etlichen tausend Seiten (praktisch alle nur virtuell über URL Rewriting), für das ich nur das Design gemacht habe - wäre kein Problem gewesen. URL Rewriting kann man auch mit WB machen.

[Stefek]

Nein, ich meinte eigentlich, dass ich mir keine Gründe erfinden muss. Und das ist gut.
Ich weiß nicht welche Lösungen Christian anbietet, aber die Tatsache, dass seine Corereplacements bei jedem WB Update flöten gehen, macht Sinn.
WB hat eben diese Grenzen und man kann nicht viel verändern am Core, ohne beim nächsten Update Einbussen einzustecken.

Kein Grund diese Debatte fortzuführen - Christian wird seine Arbeitsweise am besten kennen.

Stefek

[doc]

Hi,

Fast alle von docs Kunden wollen _lange_ Einarbeitungszeit und ein _schwieriges_ CMS

Habe ich mich wohl missverständlich ausgedrückt. Die Einarbeitungszeit bezog auf mich (Framework/Coding/API kein duplizieren von Code ...). Der Kundenbereich (Backend, Templatesystem) ist nicht wirklich schwieriger als bei WB.

Und ja, damit können wir diese Debatte von meiner Seite aus beenden

Gruss Christian

[FrankH]

Weil ich gerade ein kleines Modulchen basteln will, habe ich mir gleich mal den neuen Modul-Leitfaden vorgenommen. Ist ja schön, daß es so etwas jetzt gibt.
Angefangen habe ich mit README_module_prime r_step1_Rev-A.txt
Hier meine Anmerkungen zu B2:

• Änderungen an "D:\xampp\php\php.ini" bewirken auf meinem Rechner nichts. Hier wird "D:\xampp\apache\bin\php.ini" ausgewertet.
  

• Name the file "phpinfo.php" and copy it to "D:\xampp\htdocs\webserver\test.php". Remember that you have to create the folder "webserver" manually before. You can execute files located in the "webserver" folder via the URL: "http://localhost/webserver/phpinfo.php".

  Da ist erst mal ein Tippfehler (test.php statt phpinfo.php)
  Außerdem könnte man noch erklären, wie die Ausgabe von error_reporting zu lesen ist. Bei mir erscheint da 6143 wenn ich E_ALL angegeben habe.
  

Falls ich noch was finde, melde ich mich wieder

[FrankH]

Also mit den umständlichen Sprachdefinitionen in Step 2b kann ich mich nicht anfreunden. Das README liefert auch gleich den besten Grund dafür, warum nicht: Man muss sich doppelte Arbeit machen, den gleichen String für Backend und Frontend zweimal definieren (und für jede Sprache 2x übersetzen).

// Text outputs for the frontend
$LANG[0] = array(
    'TXT_HEADER_FRONTEND'        => 'Frontend: Module Primer (Step 2b)',
    'TXT_WELCOME_MESSAGE'        => 'Sorry no backend functions available in Step 2b.'
);

// Text outputs for the backend
$LANG[1] = array(
    'TXT_HEADER_BACKEND'        => 'Backend: Module Primer (Step 2b)',
    'TXT_WELCOME_MESSAGE'        => 'Sorry no backend functions available in Step 2b.'
);

Der Aufwand übersteigt hier meines Erachtens eindeutig den Nutzen.

Hat schon mal jemand mal ausprobiert, ob das Überschreiben der Variablen LANG in einer Seite mit mehreren Abschnitten keine Probleme macht?