WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: BlackBird on June 28, 2012, 04:45:55 PM
-
Nur weil es mir grad mal wieder auffällt, und vielleicht als Anregung für die Zukunft... WB definiert diverse Dinge doppelt und dreifach! Bespiel Seiten-ID:
Objekteigenschaft $wb->page['page_id']
Globale Variable $page_id
Konstante PAGE_ID
(und ich hab mit Sicherheit noch was übersehen... gibt's nicht auch noch $wb->page_id???)
Folgerichtig wird das dann auch schön durcheinander gemixt genutzt, mal das eine, dann wieder das andere, und das nicht mal in Modulen (die werden meist die Konstante benutzen), sondern vor allem im Framework. :roll:
Was gibt es noch? Was habt Ihr noch gefunden?
-
Deswegen gibt es wegen der Wechselwirkungen Probleme, wenn Communitywünsche umgesetzt werden sollen.
Dietmar
-
Muß ich dieses Statement verstehen???
Es ging darum, daß im Framework eine einheitliche Methode verwendet wird, und nicht hier mal dies und dort mal das. Was hat das jetzt mit Communitywünschen zu tun?
-
Ich stift mal ne Industrierolle Klopapier dass all die existierenden Redundanzen auch draufpassen.... :|
Nur das jetzt im Moment zu bereinigen ist etwas ungünstig, da fast jeder geänderte Wert dann wiederum Änderungen in irgendwelchen Modulen bedingt.
In den nächsten Versionen sind jedoch sowieso einige Änderungen unumgänglich und durch verstärkten OOP-Einsatz lösen sich die meisten Redundanzen von ganz alleine auf.
Da gibts dann eben z.B. nur noch die Objekte $oApplication, $oView, $oCurrentPage, $oCurrentUser, etc. pp. und eben deren Eigenschaften und Methoden. Dafür gibt's dann aber auch eine ganze Reihe Eventhandler, so dass sich z.B. ein 'UserExtend' oder ähnliches bequem und ohne Coreänderungen in das Userobjekt einklinken kann und nur noch einen Bruchteil seines Codes benötigt.
Muß ich dieses Statement verstehen???
Sollte vermutlich nur bedeuten, dass auch wir laufend mit den Redundanzen Probleme haben. Wobei ich selbst versuche, mich möglichst auf die Eigenschaften/Methoden des $wb/$admin - Objektes zu beschränken.
-
Es ging darum, daß im Framework eine einheitliche Methode verwendet wird, und nicht hier mal dies und dort mal das. Was hat das jetzt mit Communitywünschen zu tun?
Ich verstehe Dich.
Aber was schlägst Du vor?
Bzw. was würdest Du da gerne besser machen?
Es ist mir auch schon aufgefallen und es ergibt für mich nicht viel Sinn.
Die PAGE_ID Constant wird ja in den Access file im Ordner Pages bereitgestellt.
Eigentlich "Humbug", man könnte ja genau so gut die Eigenschaft $wb->page_id = N; setzen.
Ich denke allerdings, dass das ganze ziemlich "verschachtelt" ist und dass eine Framework Änderung so einen ziemlichen Rattenschwanz nach sich ziehen würde. (MODULE, TEMPLATES, DROPLETS und natürlich auch das Framework selbst.)
Irgendwann sollte es aber so oder so gemacht werden.
Nur... wann?
-
Irgendwann sollte es aber so oder so gemacht werden.
Ab der 2.9er,
In der 2.8er was zu ändern, was seit Anbeginn so gecodet ist, würde alles zusammenbrechen lassen. Da haben sich ja schon DOC und Aldus rausgehalten.
Werner sollte da auch etwas zu schreiben.
Dietmar
-
Im Pagefile existiert noch keine Class WB eine gewisse Redundanz wird sich da nicht vermeiden lassen.
-
Es ging darum, daß im Framework eine einheitliche Methode verwendet wird, und nicht hier mal dies und dort mal das. Was hat das jetzt mit Communitywünschen zu tun?
Ich verstehe Dich.
Aber was schlägst Du vor?
Bzw. was würdest Du da gerne besser machen?
Ich würde im Framework (=gleichnamiger Folder) eine einheitliche Verwendung einführen. Was die Module machen, steht erst mal auf einem anderen Blatt. Ich hab ja nicht gesagt, daß man die redundanten Möglichkeiten radikal abschaffen soll, sondern daß man sich für das FRAMEWORK auf eine Handhabung einigen soll. Wenn - auf obiges Beispiel bezogen - das Framework durchgängig $wb->page_id verwenden würde, wäre schon viel gewonnen.
Ich bin mir auch nicht sicher, inwiefern (immer auf das Beispiel bezogen) die weiteren Möglichkeiten überhaupt bekannt sind. Mir z. B. war nie klar, daß es $wb->page_id und $wb->page['page_id'] überhaupt gibt, bis ich in die L*-Entwicklung eingestiegen bin. Daher denke ich, die meisten werden PAGE_ID benutzen. Was nicht heißt, daß es nicht vereinzelte Ausnahmen gibt.
Übrigens lassen sich Accessor-Funktionen in PHP 5.3 sehr einfach schreiben. *hüstel* Was immer noch nicht heißt, daß man diesen Wildwuchs im Core hinnehmen muß.
Gruß, Bianka
-
$wb->page_id
Also die 3. Möglichkeit etablieren. Dann noch die 4. (weils schöner aussieht) und die 5. (als Protest gegen den Welthunger)....
Ihr habt wirklich Sorgen....
-
Im Pagefile existiert noch keine Class WB eine gewisse Redundanz wird sich da nicht vermeiden lassen.
:-P
Stimmt. Erst als ich nachgeschaut habe, war es erkennbar.
-
Ich würde im Framework (=gleichnamiger Folder) eine einheitliche Verwendung einführen.
Was die Module machen, steht erst mal auf einem anderen Blatt.
Ich hab ja nicht gesagt, daß man die redundanten Möglichkeiten radikal abschaffen soll, sondern daß man sich für das FRAMEWORK auf eine Handhabung einigen soll. Wenn - auf obiges Beispiel bezogen - das Framework durchgängig $wb->page_id verwenden würde, wäre schon viel gewonnen.
Ich denke, dass genau das das Problem ist, dass es eben einiges an Abhängigkeiten geben wird, die es nicht ohne weiteres möglich machen.
Auf der anderen Seite hast Du recht, die Module ziehen meist noch den Modulwrapper rein, da könnte man dafür sorgen, dass die Sachen wieder vorhanden sind (für Module, die nicht auf der gleichen Höhe wie das Framework sind).
Es wird ja sicher gemacht.
Nur Du schreibst, "es wäre schon viel gewonnen", wenn zumindest das Framework durchgängig die page_id Eigenschaft des wb Objekts verwenden würde.
Kannst Du ein Beispiel geben, damit mir das einleuchtet? Ich meine ein Beispiel eines tatsächlichen Vorteils.
Gruß,
Stefek
-
Du siehst keine Vorteile in einer einheitlichen Lösung!? Das erschreckt mich jetzt etwas.
Wie chio sehr richtig erkannt hat, gibt es bereits jetzt sage und schreibe VIER Möglichkeiten, die Seiten-ID auszulesen. Um's nochmal für alle festzuhalten:
Objekteigenschaft $wb->page['page_id']
Objekteigenschaft $wb->page_id
Globale Variable $page_id
Konstante PAGE_ID
Keine davon ist neu, die gibt es alle schon. Da stellt sich doch die erste Frage: Welche dieser 4 Möglichkeiten soll ich in meinem Modul verwenden? Oder, anders gefragt: Welche davon wird offiziell supportet?
Nun schau ich also einfach mal in den Framework-Ordner, weil ich mir denke: Die Devs werden's ja wohl wissen. Weit gefehlt. Im Framework wird lustig durcheinander mal dies, mal jenes benutzt. Soweit zur Vorbildfunktion.
Nu hab ich mal spaßeshalber über den Framework-Folder gesucht.
$wb->page['page_id'] -> wird offenbar nur ein einziges Mal benutzt, nämlich in get_page_details(), um die Konstante PAGE_ID zu belegen.
$wb->page_id -> wird in class.frontend.php belegt und an drei Stellen auch benutzt. Wird zudem in frontend.functions. php benutzt - um die Globale $page_id zu belegen...
$page_id -> wird relativ viel benutzt
PAGE_ID -> Im Framework eher wenig benutzt, etwa analog zu $wb->page_id
Daraus ergibt sich, daß zumindest zwei der vier Möglichkeiten überflüssig sind. (Erratet Ihr, welche das sind?) Alles, was überflüssig ist, ist unnötiger Ballast. Das heißt, er belastet den Server und damit auch die Performance. Vom Vorbild-Effekt ganz zu schweigen...
Also, was sind nun die Vorteile, wenn man da mal entrümpelt?
* Weniger Ballast = bessere Performance, weniger Arbeitsspeicherverb rauch, kürzere Compile Time
* Wesentlich besser lesbarer und wartbarer Code ("Warum steht jetzt hier X, oben wird doch Y verwendet...?")
* Einheitliche Verwendung zeigt strukturiertes und durchdachtes Vorgehen ("Vorbild-Effekt")
Aber die bisherigen Statements haben leider gezeigt, daß das alles vergebliche Liebesmüh ist. Schade.
-
$page_id -> wird in acces files benötigt
PAGE_ID -> Im Framework eher wenig benutzt, in Modulen usw. sehr viel genutzt....
-
Heißt was?
-
Kann man auf die Schnelle schlecht drauf verzichten ...
-
Oder hab ich jetzt was falsch verstanden ? Wolltest du auf was anderes raus??
-
Aber die bisherigen Statements haben leider gezeigt, daß das alles vergebliche Liebesmüh ist. Schade.
Nur nicht aufgeben :-D
-
Na, klärt mich auf, wenn ich Unsinn verzapfe:
$page_id ist der Klassiker, da wird hundertfach drauf zugegriffen.
PAGE_ID ist relativ neu und hat wohl den Sinn, dass man die Konstante (im Gegensatz zur Variablen) nicht einfach mal verbiegen kann.
Den Sinn hinter den anderen Varianten sehe ich nicht.
Grundsätzlich ist es so, dass Konstante und Variable in WB nicht allzu gut dokumentiert sind, und vielleicht auch, dass die Entwickler gelegentlich mal den Überblick verlieren, was sie sich eigentlich dabei gedacht haben. Dann kommen VOrlieben ins Spiel, und die Dokumentation will keiner mehr machen, weils da aufkommen würde.
Insofern wäre es schon gut, wenn man die Sachen etwas beisammen hält.
-
Viel, ist auch historisch gewachsen und keiner weiß mehr warum es drinn ist und Die die es gemacht haben sind schon lange nicht mehr da.
-
Wo wir grade bei Gerümpel sind.
Kann mir mal jemand sagen ob ich das richtig sehe ?
// We have no page id and are supposed to show the intro page
if((INTRO_PAGE AND !isset($no_intro)) AND (!isset($page_id) OR !is_numeric($page_id))) {
// Since we have no page id check if we should go to intro page or default page
// Get intro page content
$filename = WB_PATH.PAGES_DIRECTORY.'/intro'.PAGE_EXTENSION;
if(file_exists($filename)) {
$handle = @fopen($filename, "r");
$content = @fread($handle, filesize($filename));
@fclose($handle);
$this->preprocess($content);
header("Location: ".WB_URL.PAGES_DIRECTORY."/intro".PAGE_EXTENSION.""); // send intro.php as header to allow parsing of php statements
echo ($content);
return false;
}
}
Wenn die Intro Seite existiert, wird Sie geladen, durch den preprocess Filter gejagt und dann wird ein header Location gemacht und auf die Seite weitergeleitet ???
Danach wird der Inhalt ausgegeben ?
Ist das nicht irgendwie doppelt gemoppelt ?
-
Oder hab ich jetzt was falsch verstanden ? Wolltest du auf was anderes raus??
Nochmal: Es geht nicht darum, irgendwas abzuschaffen, sondern um eine einheitliche (saubere, vorbildliche, nenn's wie du willst) Verwendung EINER Option im Framework! (Sprich im Core.) Ich spreche nicht von Modulen! Das ist der zweite Schritt!
Abschaffen kann man erst, wenn man raus hat, was in Modulen wirklich benutzt wird. Dazu braucht es aber - sorry - Module Guidelines.
-
Ist das nicht irgendwie doppelt gemoppelt ?
Also wenn ich jetzt nicht völlig falsch liege, ist das sogar vollkommen sinnfrei. Nach header('Location...') kann man nämlich meines Wissens nix mehr ausgeben. Damit lenke ich ja auf eine andere Seite um, in diesem Fall die Intro-Seite. Alles, was danach noch kommt, landet im Nirvana.
-
Bezüglich der pageid
Persönlich fände ich es garned scho schlecht wenn ab einer bestimmten Stelle die Konstante benutzt würde
Erstens kann man die nicht mehr ändern , zweitens ist die überall ohne irgendwelche Zusätze verfügbar und grade das finden Nichtprogrammierer immer richtig gut. Also grade dabei doppelt fahren erscheint mir als Vorteil.
Kannst ja mal versuchen ob noch alles rennt wenn man die anderen Definitionen rauswirft ?
Bezüglich des Andern, genau das meinte ich wollte das nur netter sagen :-D
-
Also wenn ich jetzt nicht völlig falsch liege, ist das sogar vollkommen sinnfrei. Nach header('Location...') kann man nämlich meines Wissens nix mehr ausgeben. Damit lenke ich ja auf eine andere Seite um, in diesem Fall die Intro-Seite. Alles, was danach noch kommt, landet im Nirvana.
Ursprünglich wurde der Code ohne das header(location:) erstellt. Das wurde dann im Februar 2007(Revision 433) dazwischen geflickt.
Grund war, dass die ursprüngliche Routine die intro.php als reinen Text, ohne PHP-Header zum Browser schickte.
Durch das header(location:) wird es jedoch vom Webserver aufgerufen, durch den PHP-Parser/Interpreter geschickt (also enthaltener PHP-Code ausgeführt) und dann erst zum Browser gesendet.
Damals(2007) wurde irgendwie übersehen dass das Einlesen und vorverarbeiten des Contents eigentlich überflüssig wurde. Also blieb der überflüssige Code (wie an vielen anderen Stellen leider ebenfalls) einfach drin. Schadet ja nicht, sondern sorgt nur dafür, dass die Handbremse angezogen bleibt.
folgender Code sollte völlig ausreichen:
<?php
$filename = WB_PATH.PAGES_DIRECTORY.'/intro'.PAGE_EXTENSION;
if(file_exists($filename)) {
header("Location: ".WB_URL.PAGES_DIRECTORY."/intro".PAGE_EXTENSION.""); // send intro.php as header to allow parsing of php statements
exit();
}
Das exit() nur um abzusichern, dass nach dem header(location:) garantiert kein weiterer Code mehr ausgeführt werden kann.
-
Um niemand zu verwirren sollte man sich mal lieber bei Linux umgucken als bei Windows (zumindest wie sie es bisher gemacht haben, mittlerweile muss es auch hier dem ursprünglichen Standard genügen).
Versionsnummer: X."geradeZahl".Y (2.4.0,2.6.0): Release-Versionen
Versionsnummer: X."ungeradeZahl".Y (2.3.0, 2.5.0): Entwickler&Co-Spielwiese
Hat kaum jemand verstanden, und daher wurde es auch außerhalb kaum richtig umgesetzt, die Idee war aber gut.
Und ich schlage ja schon seit grauen WB-Dunstzeiten vor, dass man Änderungen 1.) als solche kennzeichnet und 2.) dann auch durchgehend von einer Major zur nächsten durchzieht, auch wenn ein paar vereinzelte weinen. Aber wenn man sich umguckt, wie das im großen Stile gemacht wird, braucht WB sich da eh nicht zu verstecken.
Die Leute werden nur ungeduldig, wenn jedes kleine Updätle (das die anderen mit "Update gefällt mir" Button einspielen) einen WB-Profi & Forenbeiträge en masse benötigt.
Und bitte: Die 3 1/2 verschiedenen Module (ich spreche von im Code verschiedene), die wirklich auf WB aufbauen kann man zur Not an einem Samstag nachmittag updaten.
Mit einer gescheiten API hat man genug andere Probleme (mit OOP sowieso, man sehe sich z.B. die Typo3 Gurus an wie sie von Datenbank-Singeltons wegen massiver Probleme wieder weggegangen sind - nicht alles was toll aussieht ist es halt). Nur würde eine gescheite API auch Gerümpel verhindern, PHP macht's ja selber mit "deprecated" vor.
Es muss einfach nur durchgängig passieren. Dokumentation ist in Zeiten von PHPDOC & Co. ja selbst für Entwickler kein Akt mehr. Schleifen kann die Community drumbinden - hat sie ja bisher auch getan.
Aber egal: WB funktioniert auch so, also warum ändern. 8-)
-
Kannst ja mal versuchen ob noch alles rennt wenn man die anderen Definitionen rauswirft ?
Nochmal - es geht (hier noch) nicht darum, etwas zu streichen. Es geht um eine konsistente Verwendung im Framework selbst. Wenn das Framework schon 4 Varianten von ein und demselben benutzt, wie soll man dann vernünftige Module schreiben? Was soll man sich als Vorbild nehmen? Und wie soll jemand, der nicht so tief drin steckt, den Code pflegen? Ich hab bei *censored* ... äh, an anderer Stelle *hust* so viel seltsamen Code gefunden, von dem niemand wußte, wozu der gut sein soll, daß es mich heute noch gruselt. Das ist aber bei gewachsenem Code, an dem viele Leute rumgefummelt haben, normal. (Mich gruselt es auch manchmal bei eigenem Code, wenn ich nach längerer Zeit mal wieder reingucke... Da hat man halt mal was auf die Schnelle mit der heißen Nadel gestrickt, und für den Moment ging's halt, und aus Zeitgründen hat man es dann so gelassen. Ein paar Monate später, mit mehr Ruhe, guckt man drauf und denkt sich 'Argh, was hast du denn DA gemacht?!?')
Mein Ansatz ist halt, man nimmt sich eine Stelle - und diese hier ist ziemlich einfach -, überdenkt das, streicht die zwei am wenigsten verwendeten Varianten, und schon sieht es etwas sauberer aus. Und dann nimmt man sich das nächste Staubkorn.
Daß das kleine bißchen hier schon solche Wellen schlägt, ist irgendwie erstaunlich. Die einen denken, man will ihnen was wegnehmen, die anderen, man will noch eine weitere Variante einführen, wo eh schon Chaos herrscht, und die dritten meinen, man wolle sie kritisieren. Nichts davon trifft zu. Es ist _eine_ kleine Stelle im Core, die man mal überdenken und bereinigen sollte.
Aber vielleicht ist das typisch weiblich - ab und zu nimmt Frau halt mal den Staublappen zur Hand... Männer erfahrungsgemäß eher nicht. :evil:
-
Bianca, bis auf den Punkt
Aber vielleicht ist das typisch weiblich - ab und zu nimmt Frau halt mal den Staublappen zur Hand... Männer erfahrungsgemäß eher nicht.
kann ich Dir da zu fast 100% einfach nur zustimmen.
Es sind für die nächste Zeit einige Umstrukturierungen im Kern und an einigen Schnittstellen zwingend erforderlich um aus der Sackgasse mit dem derzeitigen, nur noch extrem aufwändig erweiter- und wartbaren, 'Patchworkcode' heraus zu kommen. Allerdings wird jetzt erst einmal die 2.8.4 fertiggestellt, damit es dann etwas mehr Luft dafür gibt. Luft bzw. Zeit vor allem, dass unvermeidliche Änderungen/Anpassungen auch in die bestehenden Module übernommen werden können.
Mir graut nur jetzt schon davor:
Daß das kleine bißchen hier schon solche Wellen schlägt, ist irgendwie erstaunlich. Die einen denken, man will ihnen was wegnehmen, die anderen, man will noch eine weitere Variante einführen, wo eh schon Chaos herrscht, und die dritten meinen, man wolle sie kritisieren. Nichts davon trifft zu.
da es keine extremen, jedoch auch zwangsweise keine minimalen Änderungen sein werden die jedoch unbedingt erforderlich sind, wenn das System zukunftsfähiger werden soll.
Nein, nichts gegen den alten Code, schon erst gar nichts gegen die Ideen die dahinter standen/stehen denn die sind gut.
Aber wie Du schon sagtest: es ist 'gewachsener Code' und solcher erzwingt immer wieder einmal eine grundlegende Überarbeitung. Allein schon, weil der Code immer unübersichtlicher wird und sich auch die Umgebung (Anforderungen, Betriebssysteme, Programmiersprachen, das Netzumfeld, die rechtlichen Grundlagen etc.) über die Jahre teils gravierend verändern.
Was gestern möglich war ist nicht zwangsläufig auch in alle Zukunft möglich. Allerdings kommen auch immer wieder neue Dinge dazu, die vieles vereinfachen können und bisher unmögliches erst möglich machen.
Redundante Variablen und Funktionen stehen schon seit langem auf unserer ToDo-Liste und werden nach der 2.8.4 Schritt für Schritt konsequent angegangen. Wir werden dabei aber darauf achten, dass die dafür notwendigen Änderungen in den Modulen möglichst einfach auszuführen sind.
Anleitungen etc. dazu kommen dann noch rechtzeitig im 'Entwicklerhandbuch' auf der WB-Homepage.