Gerümpel

[BlackBird]

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.

Was gibt es noch? Was habt Ihr noch gefunden?

[Luisehahne]

Deswegen gibt es wegen der Wechselwirkungen Probleme, wenn Communitywünsche umgesetzt werden sollen.

Dietmar

[BlackBird]

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?

[DarkViper]

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.

[Stefek]

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?

[Luisehahne]

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

[NorHei]

Im Pagefile existiert noch keine Class WB eine gewisse Redundanz wird sich da nicht vermeiden lassen.

[BlackBird]

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

[fischstäbchenbrenner]

$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....

[Stefek]

Im Pagefile existiert noch keine Class WB eine gewisse Redundanz wird sich da nicht vermeiden lassen.

Stimmt. Erst als ich nachgeschaut habe, war es erkennbar.

[Stefek]

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

[BlackBird]

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.

[NorHei]

$page_id -> wird in acces files benötigt
PAGE_ID -> Im Framework eher wenig benutzt, in Modulen usw. sehr viel genutzt....

 

[BlackBird]

Heißt was?

[NorHei]

Kann man auf die Schnelle schlecht drauf verzichten ...

[NorHei]

Oder hab ich jetzt was falsch verstanden ? Wolltest du auf was anderes raus??

[Stefek]

Aber die bisherigen Statements haben leider gezeigt, daß das alles vergebliche Liebesmüh ist. Schade.

Nur nicht aufgeben 

[fischstäbchenbrenner]

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.

[NorHei]

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.

[NorHei]

Wo wir grade bei Gerümpel sind.

Kann mir mal jemand sagen ob ich das richtig sehe ?

Code: [Select]

// 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 ?

[BlackBird]

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.

[BlackBird]

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.

[NorHei]

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 

[DarkViper]

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:

Code: [Select]

<?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.

[easyuser]

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.