OOP / WB-Libs generell

[Stefek]

Hallo Bianka,

dass Thorn lieber tut als labert ist bekannt

Er hat das Teil ja noch nicht veröffentlicht, von daher wird ja auch nicht wirklich die Sache an sich _zerredet_ sondern es kommen vielmehr die verschiedenen Meinungen zu Programmierstilen zum Vorschein.
Sooo schlimm finde ich es auch nicht.

Übrigens ich hatte die Gelegenheit mit PMF zu arbeiten und es mir anzuschauen und die Arbeit war sehr befriedigend.
Ob das für alle der Fall ist - vor allem für jene, die ihre eigene hausgemachte Lib haben, das ist eine andere Geschichte.

Und ja, persönliche Vorlieben spielen auch eine Rolle.
Deswegen nutze ich persönlich auch WB. Ich habe eine Vorliebe dafür.
Es gibt noch andere Werkzeuge, die ich verwenden kann - aber ich nehme gerne dieses kleine Paket, das (immer noch) ziemlich überschaibar ist.

Was PMF angeht, so habe ich natürlich nur dahin geschaut, wo mich interessiert - das Templating und die Multilanguage Hanhabung.

Was da sonst drin steckt und wie wertvoll es ist kann ich nicht so ohne weiteres sagen, ohne mich (zugegebenermaßen) sehr sehr lange damit auseinander zu setzen.

LG,
Stefek

[Stefek]

Sorry Bianka,
aber wenn ich mir so diesen Beitrag anschaue:
http://www.websitebaker2.org/forum/index.php/topic,16888.msg110994.html#msg110994

... dann denke ich an ganz andere Dinge, wenn man von Overhead spricht 

Zudem, unähnlich Savant3 stellt PMF ein Caching-System zur verfügung, was das ganze wirklich BESCHLEUNIGT.

Gruß,
Stefek

[Waldschwein]

Zudem, unähnlich Savant3 stellt PMF ein Caching-System zur verfügung, was das ganze wirklich BESCHLEUNIGT.

xft2 hat auch eins.  Wobei Caching sowieso so eine Sache ist... Schneller ist das nicht immer.

Gruß Michael

[Stefek]

Zudem, unähnlich Savant3 stellt PMF ein Caching-System zur verfügung, was das ganze wirklich BESCHLEUNIGT.

xft2 hat auch eins.  Wobei Caching sowieso so eine Sache ist... Schneller ist das nicht immer.

Gruß Michael

Wir reden aber grade nicht über xft2

[thorn]

Hallo,

So betrachtet erzeugt PMF einen überflüssigen Overhead, indem es eine Markup-Sprache verwendet und dann die Templates in PHP umwandelt. Meiner Meinung nach rechtfertigt die Komplexität der verwendeten Markups, die ich auch erst lernen muß, diesen Overhead nicht.

Das das nicht so ist hatten wir ja gerade (ein paar Minuten nach deinem Post hier) geklärt.


Zum Thema OOP werd ich mich nicht mehr äußern. Die Diskussion(en) darum haben damals schon genug verbrannte Erde hinterlassen -- hätte nicht gedacht, daß das immer noch so emotionsgeladene Reaktionen hervorruft   .

Ansonsten kann ich feststellen, das wir beide in vielen Ansichten übereinzustimmen scheinen -- leider wohl auch etwas in der (Achtung: übertrieben) "Abneigung" der "Arbeitsweise" des jeweils anderen.


thorn.

[thorn]

Nur weil Du Dich nicht wirklich damit beschäftigt hast.

Das ist wohl häufig das Problem ...   


thorn.

[thorn]

Nur weil Du Dich nicht wirklich damit beschäftigt hast.

Das ist wohl häufig das Problem ...   

thorn.

Wie darf ich das verstehen?

Ach -seufzer!-
Genau so wie es da steht. Ich bin kein Freund von Hinterlist und Tücke - oder von Sarkasmus.
Werd' mal locker


thorn.

[stesel]

Vorschlag:

Einem wie mir, der WB "nur" nutzt und gerade dabei ist, ein Intranet darauf umzustellen, kann beim Lesen dieses Threads schon angst und bange werden... Wäre nicht ein geschlossener Entwickler-Bereich besser für solche Grundsatzfragen?

Liebe Grüße
Stefan

[Stefek]

Wäre nicht ein geschlossener Entwickler-Bereich besser für solche Grundsatzfragen?

Wir sind nicht alle Teil eines geschloßenen Entwickler Bereiches,
deswegen sickern solche Sachen schon mal ins Forum ab. 

Gruß,
Stefek

[Stefek]

Hallo,

ich habe hier eine Liste mit einigen interessnten Template Engines gefunden.
http://www.webresourcesdepot.com/19-promising-php-template-engines/
Na, ist auch viel Schrott bei.

Irgendwie scheint mir das Thema noch nicht ausgeschöpft zu sein.

Oder ist es generell besser, dass jeder Entwickler seine eigene Lib mitbringt? 

Bin da echt überfragt.

Was aber auf jeden Fall nicht geht, ist diese unhandliche phpLib in die nextGeneration WB Entwicklung mit zu schleifen.
Backendbau macht einfach keinen Spaß damit.
Ganz ehrlich 

Gruß,
Stefek

[Waldschwein]

Hallo!

Grundsätzlich muss das Backend natürlich geändert werden, da führt kein Weg dran vorbei.
Gedanken hätte ich viele, könnte ich doch nur gut programmieren... Will ich aber nicht - ich muss andere Dinge können. 
Vor Jahren gab es einen riesen Aufschrei, als Ryan angekündigt hat, WB3 wird Smarty verwenden. Heutzutage wäre es gar nicht so verkehrt - ist doch das kommende Smarty 3 (schon in Beta vielversprechend.
Wenn jetzt aber jeder herkommt und meint, sein Ansatz wäre der Beste ist das Chaos perfekt - wer macht dann noch ein Template?
Dass das jetzige phpLib "deprecated" ist, ist klar.
Ich persönlich bin kein Fan davon, PHP im Template zu benutzen. Aber gut... Andere diskutierten da auch schon drüber: http://forum.de.selfhtml.org/archiv/2006/8/t133980/

Jeder seine eigene Lib: Hallo??? Wir sind nicht Typo3. Das ist jetzt schon ein Chaos, wenn einem ein Modul von Ralf (Berlin) gefällt und eines von aldus. Man hat dann jede Menge Zeug herumliegen, viele libs usw. Das geht jetzt nicht anders bei WB2, aber in der Zukunft muss das anders werden. Denn einfach ist etwas anderes.

Was mir nicht gefällt: Backend-Theme und Frontend-Theme werden grundsätzlich anders behandelt. Ich finde phpLib zu kompliziert. Tut mir leid das so zu sagen - aber wenn ich mir ansehe, wie manche CMS es ermöglichen, per Mausklick oder Backend-Eingabe Blöcke im Frontend zu positionieren muss sich WB schon sehr schwer tun - spätestens dann, wenn obstruses wie ob_start() vorkommt.

Mir persönlich ist es egal, welche Lib verwendet wird, und ob es überhaupt eine klassische gibt, oder ob eine eigene programmiert wird. Sie soll "nur" flexibel, einfach und konsequent sein. Und diese drei Sachen unter einen Hut zu bringen ist viel, viel schwerer als etwas programmiertechnisc h höchst anspruchsvolles mitzugeben. 

Gruß Michael

[Luisehahne]

Mal aus meiner Sicht als Developer. Ich benutze nur eingebaute Funktionen und in WB vorhandene Libs. Hat nämlich einen Vorteil. Als Developer stellt du fest wo du noch verbessern musst. Und meine Meinung ist, WebsiteBaker war noch nie so stabil wie jetzt. Allerdings sind jetzt auch die Moduleentwickler gefragt, sauberen Code zu liefern, sonst wird es immer mehr Probleme mit Modulen geben.

Zu PHPLIB. Also als Coder finde ich die Lib in Ordnung. Zwar veraltet, aber wenn man sich da einmal richtig mit beschäftigt hat, gibt es sehr viele Möglichkeiten. So manches display:none hätte man sich sparen können, da auch PHPLIB in der Lage ist Blöcke nachzuladen. Sicher für Nchtcoder ist es kompliziert. Deswegen haben wir ja programmieren und coden gelernt.

Auch Droplets müssen sauber gecodet sein. Da gibt es viele Probleme und es liegt nicht an der Droplet Engine selber

Das mal aus meiner Sichtweise

Dietmar

[Waldschwein]

Hallo!

Zum Thema sauber programmieren: Wir wissen alle, dass die wenigsten in der WB-Community gut programmieren können. Die meisten suchen sich Codestücke aus dem Netz und anderen Modulen zusammen, programmieren ein wenig herum, und wenn es läuft kommt es raus.
Das soll bitte nicht missverstanden werden - wir hätten wohl kaum ein Add-on sonst - aber es ist halt Fakt, und soll auch nicht missverstanden werden (ich mach es selber ja nicht anders).

Das Problem mit den eingebauten Funktionen: Leider führt das dazu, dass man in die Codedateien gehen muss teilweise. Das ist zwar in WB2 so, aber absolut nicht zu empfehlen - zumindest nicht für jemand, der nicht weiß, was er da tut!

Sauberen Code kann man nur liefern, wenn es auch Richtlinien gibt, wenn klar geregelt ist was man darf und was nicht. Zum Beispiel eval() in Droplets verbieten, und zwar von vorne herein. So als kleine Anekdote.
Droplets sind aber nicht das Problem, weil die immerhin ein ganz nettes Feedback geben. Schlimmer wird es dann bei "echten" Modulen. Man kann natürlich mit der Keule kommen bei soetwas und unsauberes einfach nicht ausführen - aber das wäre einfach auch der falsche Weg. Grundsätzlich ist es auch verkehrt, erst alles zu ermöglichen und später zu verbieten - wenn man generell alles, was sicherheits-/performancetechnisch, etc. nicht zu vertreten ist gar nicht annimmt, wäre es super. Aber wie andere schon sagten - wir brauchen für WB2 gar nicht drüber zu diskutieren, weil das System dafür nicht gedacht ist.

Zum Thema PHPLib: Man darf nicht davon ausgehen, dass jemand sich näher beschäftigt mit etwas. Die Leute sind aus anderen Systemen Klicki-Bunti gewohnt (und nein, damit meine ich nicht bloß Frontpage & Co. KG, sondern auch Typolight, Drupal & Co.). Aber so etwas könnten Umfragen auch herausarbeiten. 

Gruß Michael

[Luisehahne]

Nicht das wir uns missverstehen. Es geht nicht um Änderungen im Core, sondern um Benutzung der bereits vorhandenen Funktionen. Änderungen der Coredateien gehört absolut verboten.

@Code
Richtlinen gibt es genug. Jeder Programmierer/Coder sollte das beherrschen. Refactoring ist das Zauberwort. Professionelle Entwickler kennen das und haben es gelernt. Sicher wird es in Zukunft Richtlinien geben, damit ein Modul als geprüft zugelassen werden kann. Nur was 6 Jahre lang versäumt worden ist, kann nicht von Heute auf Morgen erstellt werden.

Sicherlich gibt es viele LIBs die nicht für DAUS gemacht sind. Von einem Moduleentwickler sollten doch weitreichende Kenntnisse erwartet werden. Lasst uns festhalten, ein Programmierer muss nicht gleichzeitig Coder sein. Das sind 2 grundverschiedene Positionen, die immer gerne in einen Topf geworfen werden.

Dietmar

[Waldschwein]

@Code
Richtlinen gibt es genug.

Nein! Es gibt _keine_ für websitebaker. Daher gibt es zwar viele Richtlinien, aber keiner kann sie anwenden. Wir müssen definieren was jemand tun soll und nicht tun soll, nicht irgendein Wordpress-Blogschreiber der meint, zu wissen, was eine Richtlinie wäre. Es geht nicht darum bei einer Richtlinie festzulegen, wann man lieber MD5 und wann lieber SHA nimmt, sondern es geht darum zu sagen: Entweder du nutzt jQuery aus /include oder dein Modul musst du selber vertreiben, weil wir es nicht unterstützen.

Gruß Michael

[Luisehahne]

Wir werden von Coden allgemein, nicht von WebsiteBaker Richtlinien ( die auch noch kommen werden ). Ein sauberes Coding kann man doch von Entwicklern erwarten, so dass der Code lesbar und nachvollziehbar ist.

Dietmar

[Stefek]

Du vergisst aber, dass es hier um Template Engines ging eben, oder?
Weißt Du wofür die gedacht sind?

Es gibt zwei Seiten der Medaille in der Webentwicklung...
Du tust ja manchmal grade zu so, als wenn  Coder irgendwelche Götter wären.

Denk mal ab und zu an die Leute, die mit dem Kasten arbeiten.
Die Minderheit davon sind Coder.

(Nichts gegen Coder, ich kann nicht ohne sie... aber ganz gut mit ihnen, wenn sie nicht all zu verbohrt sind. Von manchen kann man sogar was lernen.)

[Luisehahne]

Gut ich wusste nicht, wenn man mit einer Template Engine arbeitet, dies nicht zum programmieren/coden gehört sondern für DAUS sein soll. Mal wieder was dazu gelernt.

Dietmar

[Stefek]

Gut ich wusste nicht, wenn man mit einer Template Engine arbeitet, dies nicht zum programmieren/coden gehört sondern für DAUS sein soll. Mal wieder was dazu gelernt.

Dietmar

Das steht da nicht...

[Waldschwein]

Dafür gibt's doch Programme. *duck*
Wenn ich eine CSS-Datei bekomme oder bearbeite lasse ich die grundsätzlich immer vorher sauber formatieren.

Gruß Michael

[Luisehahne]

Das steht da nicht...

Es geht ja bei der Template Engine nicht nur um dne HTML Bereich, sondern der muss ja auch mit Daten gefüllt werden. Kann das ein Webdesigner? Nöööö, dafür braucht er einen Programmierer/Coder

Dietmar

[Stefek]

Das steht da nicht...

Es geht ja bei der Template Engine nicht nur um dne HTML Bereich, sondern der muss ja auch mit Daten gefüllt werden.

Sehr gut erkannt.
Du kommst ja der Lösung immer näher.

Worum es geht: die phpLib ist weder für den Designer noch für den Entwickler schön.
Aber Du kannst meinetwegen sogar mit Hammer und Meißel coden...

[Stefek]

Darum auch, ja. Wobei es einfach grundsätzlich schlechter Stil ist, Code-Bandwürmer zu produzieren. Ganz gleich, ob ich mir das dann neu formatieren kann oder nicht. Erschwert das Debuggen extrem.

Was für einen nach "schlechten Manieren" aussieht, kann für den anderen ein Versuch sein, etwas neues zu lernen, über den Tellerrand hinaus zu schauen.

Ich habe an WebsiteBaker (Community) immer die Hilfsbereitschaft bewundert, was auch der Grund war, dass ich hier sesshaft geworden bin - es liegt auch in meiner Natur, zu helfen und "gleich und gleich gesellt sich leicht".

Ich finde es auf der einen Seite gut, dass Standards existieren - denn nur so kann man eine Disziplin draus machen.
Auf der anderen Seite sind hier die Standards "verschwommen", als wollte man sich nicht einigen.

Das ist schade, denn es HILFT niemandem.
Standards helfen.

Mir als Laien hat es z.B. sehr geholfen Docs Primer zu studieren.
Ich konnte zumindest nach Anleitung und weiterer Hilfe von erfahrenen Programmierern hier im Forum etwas tun, was ich vorher nicht für möglich gehalten habe.

Und übler Code?
Nun, schon manch ein häßliches Entlein ist schon ein zu einem schönen Schwan herangewachsen


Gruß,
Stefek

[chio]

Wobei es einfach grundsätzlich schlechter Stil ist, Code-Bandwürmer zu produzieren. Ganz gleich, ob ich mir das dann neu formatieren kann oder nicht.

Dafür drücke ich nicht durch, wenn Code nur mehr aus Funktionsaufrufen besteht. Eine Codewurst kann man ja lesen, da sieht man wenigstens was passiert. Für die Geschwindigkeit ist es auch egal.

Hat einfach jeder seinen Stil.

Das Problem das ich sehe, ist dass jeder nur _seine_ Module(bzw Code-Teile)  in _seinem_ Stil macht und die Module anderer als "schlechter Stil" abtut.
Die Folge ist Doppelgleisigkeit und Wildwuchs.

Mag schon stimmen, dass die Module die ich gemacht habe, mäßig "eleganten" Code enthalten. Immerhin funktionieren sie halbweg.

Natürlich bin ich für Standards. Diese Standards sollen aber nicht vorschreiben, ob ich " oder ' verwenden soll, sondern Do's and Dont's im Zusammenhang mit websitebaker.
Was hat im Kopf einer Modul-Datei zu stehen, bevor der erste Datenbank-Zugriff erfolgt?
Was muss ich bedenken, wenn ich in Modulen AJAX verwende?
Wie sind $_POST Daten aufzubereiten, bevor sie in die Datenbank geschrieben werden?

Zu OOP:
OOP + PHP mag im Einzelfall seine Berechtigung haben. Man muss sich aber die Frage stellen: Wie oft wird ein Objekt in seiner Lebenszeit verwendet? 2x? Vergiss es, bremst nur ein.

[Ralf (Berlin)]

Dafür drücke ich nicht durch, wenn Code nur mehr aus Funktionsaufrufen besteht. Eine Codewurst kann man ja lesen, da sieht man wenigstens was passiert. Für die Geschwindigkeit ist es auch egal.

Hat einfach jeder seinen Stil.

Das Problem das ich sehe, ist dass jeder nur _seine_ Module(bzw Code-Teile)  in _seinem_ Stil macht und die Module anderer als "schlechter Stil" abtut.
Die Folge ist Doppelgleisigkeit und Wildwuchs.

Gerade OOP bietet die Möglichkeit Individualität zuzulassen und gleichzeitig dafür Sorge zu tragen, dass die Standards eingehalten werden.

Wenn ich eine "Codewurst" (passender Ausdruck...) ändern will, bleibt mir nichts anderes übrig, als eine neue Codewurst zu schreiben oder im Original herumzufuhrwerken (was nebenbei nicht der Sinn von Open Source ist).

Bei OOP überschreibe ich das entsprechende Objekt, füge die Funktion mit der gewünschten Funktionalität ein und fertig.

Gerade auch im Sinne einer einfachen Modulerstellung und -Pflege spielt OOP seine Stärke aus. Ein "Hello World" Modul für WB ist momentan ein Bündel aus -zig Dateien, deren Funktionen ich erst einmal kapieren muss. Ein Modul für WB auf OOP Grundlage käme dagegen mit 2 Dateien aus, einer info.php und einer modul.php, "Hello World" reduziert sich auf ein paar Zeilen darin:

Code:

class meinModul extends wbModulePage {

  function show() {
    return 'Hello World';
  }

}

... einfacher geht es kaum.

Gruß
Ralf