[2.xx] Ideensammlung

Dieser Bereich dient dazu, neue Features zu diskutieren und für die Entwicklung zu dokumentieren. // This area is dedicated to new features including proposals and documentation.
Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

[2.xx] Ideensammlung

Beitrag von MrNiceGuy » 26.05.2010, 18:12:35

Moin moin!

Ich habe mir immer mal wieder Gedanken über eine APF-Version 2.xx gemacht und dabei versucht Dinge zusammen zu tragen, die mich an der aktuellen Version "stören". Stören insofern, als dass das APF ein gewachsenes System ist und dem zur Folge mittlerweile eine meiner Meinung nach überarbeitungswürdige Struktur aufzuweisen hat. Hierzu zählt aber nicht nur die Unterteilung der Komponenten, sondern auch die Coding-Standards, gerade was die Benennung von Variablen (insbesondere deren Groß- und Kleinschreibung) angeht.

Demzufolge habe ich gerade mal ein paar Punkte zusammengefasst, die mir gerade noch einfallen. Es sind nicht alle, aber ich komme gerade nicht mehr auf alles, was mir mal dazu eingefallen ist. Wenn es mir wieder einfällt, werde ich die Liste ergänzen, aber ich will hier mal eure Meinung dazu hören und vielleicht habt Ihr ja auch ein paar Ideen, was man in Version 2.xx alles anders machen könnte!?

PS: Das soll keine Anstiftung dazu sein, dass die Version 1.12/1.13 das letzte Update ist, aber man kann ja auch mal etwas früher zu einem größeren Wurf ausholen!? :)

- Verwendbar ab PHP 5.3.x (oder je nach Veröffentlichung sogar nurnoch ab PHP 6!?)
- Einheitliche Coding-Standards für alle Komponenten des APF (vor Allem Bestimmung der Schreibweisen von Variablen, Konstanten, Funktionen, Methoden und Classen
- Grundsätzliche Verwendung von protected, private und public
- Variable Steuerung aller zu verwendenden Komponenten über die Registry (z.B. ConfigurationManager)
- Globale Schnittstelle für verschiedene Konfigurations-Quellen (z.B. INI, XML, DB)
- Refactoring des GORM zur Nutzung von PDO, eventuell über eine Entkopplung der DB-Schnittstellen, ähnlich wie beim ZF (eine Adapter-Klasse je DB-Schnittstelle!?)
- Umstrukturierung der Komponenten (GORM gehört für mich z.B. eher zu "core", statt zu "modules")
- Auslieferung des Frameworks auch in reinen Core-Komponenten (nicht jeder braucht 2 Gästebücher, etc.)

Eventuell umsetzbar, jedoch nur eine erste Spinnerei von mir:

- Installations-Routine inklusive Setup-Tool:
- Einrichtungs-Assistent von Datenbank-Verbindungen
- Konfiguration vom Standard-Verhalten des APF
- Abrufen von verfügbaren Modulen und Updates des APF
- Automatische Anpassung aller APF-Komponenten auf die neue Version (exrem komplex)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Screeze » 26.05.2010, 18:27:29

Hi,
die Ideen sind größtenteils gut, ich geb mal meinen Senf dazu. :twisted:

Grundsätzliche Verwendung von protected, private und public
Was genau meinst du damit? Wird das noch nicht überall verwendet?
Variable Steuerung aller zu verwendenden Komponenten über die Registry (z.B. ConfigurationManager)
Gehe ich richtig in der Annahme, dass du die komponenten dadurch austauschbar machen möchtest? Dann eine gute Idee. Ich würde hierzu Interfaces mitliefern, die implementiert werden müssen, um eine korrekte Funktion zu gewährleisten.
Auslieferung des Frameworks auch in reinen Core-Komponenten (nicht jeder braucht 2 Gästebücher, etc.)
Das hab ich mir auch schon mehrfach gedacht, vor allem wenn jede extension die es gibt ins Framework integriert wird.
Ich würde sogar soweit gehen, und auf der APF seite eine Art "PackageBuilder" zu erstellen, bei dem man mittels checkboxen auswählen kann welche komponenten, extensions usw. Man möchte. Allerdings weis ich nicht wie gut das dann mit SVN unterstzützung noch funktioniert, da kenn ich mich zu wenig aus.
- Konfiguration vom Standard-Verhalten des APF
Was genau stellst du dir darunter vor?
- Abrufen von verfügbaren Modulen und Updates des APF
Das könnte man mit meiner Idee von oben kombinieren, dass man eine extensions datenbank anlegt, und je nach belieben die dazuladen/nachladen kann.
- Automatische Anpassung aller APF-Komponenten auf die neue Version (exrem komplex)
Öhhh versteh ich das richtig, dass du ein Tool möchtest, dass alle vom APF verwendenden Dateien automatisch bearbeitet, und an z.b. API änderungen anpasst? Wenn ja, hast du mit "extrem komplex" recht, ich gehe einen schritt weiter und sage, fast unmöglich, jedenfalls wenn es mit allen möglichen varianten 100% zuverlässig funktionieren soll. Ich stell mir die Fehlersuche grausig vor, wenn so ein tool über meine Dateien gejagd ist :lol:
Aber ein tool, das alle zu bearbeitenden Stellen raussucht und übersichtlich auflistet, am besten mit Kommentar daneben was nach was geändert werden sollte, wäre hilfreich, die anpassung würde ich dann allerdings lieber manuell vornehmen 8-)

In den anderen Punkten stimme ich soweit mal zu.

Grüsse,
Ralf

APFelsahne
Beiträge: 222
Registriert: 18.03.2010, 13:13:07
Wohnort: Ludwigshafen am Rhein
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von APFelsahne » 26.05.2010, 19:33:57

hi!

interessanter ansatz, stimme mit den punkten überein.
- für mich wichtig wäre auch noch eine komplette überarbeitung der dokumentation.
- eventuell wäre es auch sinnvoller, das system nur noch via frontcontroller ladbar zu machen. die action-features muss man ja nicht zwingend benutzen, was letztlich einen abstrakten pagecontroller übrig lässt. finde, das würde das loading-konzept des systems etwas vereinfachen.
- ein native wrapper-klasse im apf für pdo fände ich auch sehr schön, da ich die pdo-klasse sehr gelungen finde.
- ich tue mich noch etwas schwer mit der umsetzung des model-view-konzeptes sowie der actions, vor allem im bereich mehrere kontexte. eventuell ist das eine sache der dokumentation, hier klarer die themen zu beschreiben. eventuell kann man das ganze aber auch wesentlich einfacher/weniger komplex implementieren?
- toll fände ich von der applikation (optional/wählbar) veränderbare konfigurationsdateien, also dass diese nicht nur lesbar, sondern auch (be)schreibbar ist.

grüße!
Grüße, Florian
BildAPF-Extension wsCatalyst

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Screeze » 26.05.2010, 19:56:00

Achja einen Punkt hab ich vergessen:

Wie ich das so gelesen habe, bin ich nicht der einzige, der die ablage der konfigurationdateien nach dem gegebenen schema etwas "ungeschickt" findet.

Villeicht sollte man im Sinne der 2.x da doch nochmal drüber nachdenken.

Derzeitige Struktur:

Code: Alles auswählen

config/namespace/context
Wenn ich jetzt allerdings einen namespace ändern möchte, oder von einem projekt in ein anderes einsetzen möchte, wird das ab ein paar dateien echt mühsam alles einzeln zu kopieren. (Ich hab vor kurzem eine solche Änderung gemacht, waren ca 20-30 config dateien, die hälfte hab ich beim 1. durchlauf vergessen, weil ich ein paar ordner wohl nicht durchgeschaut habe)

Meiner Meinung nach sinnvoller wäre:

Code: Alles auswählen

config/context/namespace
Dann sind die einzelnen Contexte klar voneinander abgetrennt, aber trotzdem die namespace trennung noch sinnvoll gegeben.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 26.05.2010, 21:03:38

Screeze hat geschrieben:Hi,
die Ideen sind größtenteils gut, ich geb mal meinen Senf dazu. :twisted:
Gern :)
Screeze hat geschrieben:
Grundsätzliche Verwendung von protected, private und public
Was genau meinst du damit? Wird das noch nicht überall verwendet?
Es gibt - zumindest in den Versionen, die ich aktuell noch habe - noch genügend Klassen, in denen das nicht explizit vorhanden ist. Ich meinte damit also eher, dass es IMMER eingetragen wird und nicht nur, wenn es != public ist. Meiner Meinung nach ist das eine sauberere Struktur und wirkt nicht "wie vergessen", denn wenn nichts da steht könnte es auch protected sein, bei dem man die Angabe vergessen hat. Wer weiß das dann schon!?
Screeze hat geschrieben:
Variable Steuerung aller zu verwendenden Komponenten über die Registry (z.B. ConfigurationManager)
Gehe ich richtig in der Annahme, dass du die komponenten dadurch austauschbar machen möchtest? Dann eine gute Idee. Ich würde hierzu Interfaces mitliefern, die implementiert werden müssen, um eine korrekte Funktion zu gewährleisten.
Genau das meinte ich damit und ich würde auch über Interfaces gehen. Intern muss dann halt eine Prüfung stattfinden, ob die gewählte Klasse, die genutzt werden soll, vom entsprechenden Interface ableitet.
Screeze hat geschrieben:
Auslieferung des Frameworks auch in reinen Core-Komponenten (nicht jeder braucht 2 Gästebücher, etc.)
Das hab ich mir auch schon mehrfach gedacht, vor allem wenn jede extension die es gibt ins Framework integriert wird.
Ich würde sogar soweit gehen, und auf der APF seite eine Art "PackageBuilder" zu erstellen, bei dem man mittels checkboxen auswählen kann welche komponenten, extensions usw. Man möchte. Allerdings weis ich nicht wie gut das dann mit SVN unterstzützung noch funktioniert, da kenn ich mich zu wenig aus.
Das ist auch eine gute Idee! Über SVN kann man ja weiterhin das Komplettpaket ausliefern, das heißt ja aber nicht, dass man das auf der Webseite so anbieten muss!? Oder werden die Downloads aktuell rein aus dem SVN gezogen? :|
Screeze hat geschrieben:
- Konfiguration vom Standard-Verhalten des APF
Was genau stellst du dir darunter vor?
Zum Beispiel die standardmäßig zu verwendenden Klassen (siehe oben).
Screeze hat geschrieben:
- Abrufen von verfügbaren Modulen und Updates des APF
Das könnte man mit meiner Idee von oben kombinieren, dass man eine extensions datenbank anlegt, und je nach belieben die dazuladen/nachladen kann.
*check*
Screeze hat geschrieben:
- Automatische Anpassung aller APF-Komponenten auf die neue Version (exrem komplex)
Öhhh versteh ich das richtig, dass du ein Tool möchtest, dass alle vom APF verwendenden Dateien automatisch bearbeitet, und an z.b. API änderungen anpasst? Wenn ja, hast du mit "extrem komplex" recht, ich gehe einen schritt weiter und sage, fast unmöglich, jedenfalls wenn es mit allen möglichen varianten 100% zuverlässig funktionieren soll. Ich stell mir die Fehlersuche grausig vor, wenn so ein tool über meine Dateien gejagd ist :lol:
Aber ein tool, das alle zu bearbeitenden Stellen raussucht und übersichtlich auflistet, am besten mit Kommentar daneben was nach was geändert werden sollte, wäre hilfreich, die anpassung würde ich dann allerdings lieber manuell vornehmen 8-)
Nunja, ich würde es auch eher als "Auf eigene Gefahr" anbieten, so ähnlich wie den GORM-Updater aktuell (sorry Chris ;)).
Screeze hat geschrieben:In den anderen Punkten stimme ich soweit mal zu.

Grüsse,
Ralf
Danke :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 26.05.2010, 21:07:34

Screeze hat geschrieben:Achja einen Punkt hab ich vergessen:

Wie ich das so gelesen habe, bin ich nicht der einzige, der die ablage der konfigurationdateien nach dem gegebenen schema etwas "ungeschickt" findet.

Villeicht sollte man im Sinne der 2.x da doch nochmal drüber nachdenken.

Derzeitige Struktur:

Code: Alles auswählen

config/namespace/context
Wenn ich jetzt allerdings einen namespace ändern möchte, oder von einem projekt in ein anderes einsetzen möchte, wird das ab ein paar dateien echt mühsam alles einzeln zu kopieren. (Ich hab vor kurzem eine solche Änderung gemacht, waren ca 20-30 config dateien, die hälfte hab ich beim 1. durchlauf vergessen, weil ich ein paar ordner wohl nicht durchgeschaut habe)

Meiner Meinung nach sinnvoller wäre:

Code: Alles auswählen

config/context/namespace
Dann sind die einzelnen Contexte klar voneinander abgetrennt, aber trotzdem die namespace trennung noch sinnvoll gegeben.
Ich habe dafür aktuell eine eigene Implementierung, die allerdings voraussetzt, dass ich bei jedem Update des APF diese Stellen nicht aktualisiere... Ich habe auch schon vor langer Zeit diese Thematik im Forum angesprochen und eine Lösung gepostet. Ihren Weg in die Sources hat es aber leider noch nicht gefunden :(
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Screeze » 26.05.2010, 21:24:50

Das ist auch eine gute Idee! Über SVN kann man ja weiterhin das Komplettpaket ausliefern, das heißt ja aber nicht, dass man das auf der Webseite so anbieten muss!? Oder werden die Downloads aktuell rein aus dem SVN gezogen? :|
Ähh ich arbeite lokal mit einem svn client, bei dem ich den svn branch eingebe, und dann mittels 2 klicks das apf lokal auf den allerneusten stand updaten kann, auch wenn nur kleinigkeiten im code geändert wurden online, z.b. nen schneller bugfix. Im gegenzug kann ich mit 2-3 klicks auch eine extension daraus hochladen, oder einen bug schnell fixen oder ähnliches. Ich vermute wenn man das "zerstückelt" anbietet, funktioniert das nicht, da ich, sobald ich ein checkout vornehme, vermutlich doch sämtliche module etc. runterlade.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4538
Registriert: 04.11.2007, 16:13:53

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 26.05.2010, 23:05:26

Hallo zusammen,

vielen Dank für den Input! Einiges haben wir ja schon besprochen (@Lutz ;)) aber auf zukünftige Features verschoben. Einiges haben Manko10 und ich schon angedacht. Vielleicht hat jemand noch Lust die neuen Features auf einer Wiki-Seite zusammenzuschreiben und mit ein paar Umsetzungs-Ideen zu versehen. Das können wir dann als Release-Planung für 2.xx nutzen oder vielleicht schon in den 1.xx-Zweig integrieren. Grundsätzlich denke ich, dass man Änderungen, die mit der 1.xx-API nicht absolut konträr stehen auch schon dort einfließen lassen sollte. 2.xx würde es nur dann rechtfertigen, wenn das Framework in seiner Grundstruktur deutlich geändert würde (z.B. nur noch Front-Controller).

Ich fasse mal grob zusammen:
Hierzu zählt aber nicht nur die Unterteilung der Komponenten, sondern auch die Coding-Standards, gerade was die Benennung von Variablen (insbesondere deren Groß- und Kleinschreibung) angeht.
Das wird bei jedem Update sukzessive verbessert, jedoch ist das einfach ein Prozess, der nicht Morgen abgeschlossen ist. Wenn man sich die Diffs jedoch regelmäßig ansieht, wird man feststellen, dass sich da schon einiges getan hat. Ich möchte hiermit nochmal anbieten, dass es immer die Möglichkeit gibt, schreibenden SVN-Zugriff zu erhalten (Ralf hat das schon), damit kleine Verbesserungen oder auch komplette Features (nach Diskussion und Design) auch von euch umgesetzt werden können. Variablen umbenennen ist nun keine große Sache. ;)
- Verwendbar ab PHP 5.3.x (oder je nach Veröffentlichung sogar nurnoch ab PHP 6!?)
Sehr guter Punkt. Die Einführung von Namespaces in das APF werden sicher einen größeren Umbau bedeuten und das sehe ich auch in 2.xx. Auch hier macht es sicher Sinn, zwei Zweige zu pflegen (ähnlich PHP4/PHP5), damit die bisherigen Versionen noch mit Bugfixes belegt werden können.
- Einheitliche Coding-Standards für alle Komponenten des APF (vor Allem Bestimmung der Schreibweisen von Variablen, Konstanten, Funktionen, Methoden und Classen
Was siehst du hier für Regeln? In neuen Code-Teilen wird überall folgendes umgesetzt:
  • Klassen grundsätzlich in UCC.
  • Controller grundsätzlich in Kleinbuchstaben.
  • Variablen grundsätzlich klein.
  • Private/protected Klassen-Variablen ohne "__".
Das entspricht weitestgehend dem Java Coding Standard.
- Variable Steuerung aller zu verwendenden Komponenten über die Registry (z.B. ConfigurationManager)
Das sollten wir IMHO schon vorher besprechen (konkret: 1.13), denn dort ist eine Änderung des Konfigurations-Verhaltens angedacht. Man kann über die von Ralf vorgeschlagene Art und Weise mehrere ConfigurationManager erlauben. Letzteres halte ich persönlich für die sinnvollste Lösung. Allerdings muss man dann ein vernünftiges Konzept überlegen, welcher generische Informationen-Satz an den ConfigurationManager zu übergeben ist.
- Refactoring des GORM zur Nutzung von PDO, eventuell über eine Entkopplung der DB-Schnittstellen, ähnlich wie beim ZF (eine Adapter-Klasse je DB-Schnittstelle!?)
Der GORM nutzt den ConnectionManager. Das ist IMHO die Entkopplung, die du wünschst, oder? Beim APF heißt "Adapter" nur "DatabaseHandler".
- Umstrukturierung der Komponenten (GORM gehört für mich z.B. eher zu "core", statt zu "modules")
Sehe ich dann eher in tools, denn du musst das Teil ja nicht nutzen. Es kann dir helfen (=tools) - klar - aber du brauchst es nicht umbedingt (core). Korrekt?
- Auslieferung des Frameworks auch in reinen Core-Komponenten (nicht jeder braucht 2 Gästebücher, etc.)
Entrümpelung ist auf jeden Fall sinnvoll - klar. Und das zweite Gästebuch (=das alte) wird über kurz oder lang auch rausfliegen. Denn: es gibt ein neues und das neue ist mit deutlich besserer Umsetzung gesegnet und die Doku ist auch deutlich besser.
- Installations-Routine inklusive Setup-Tool:
- Einrichtungs-Assistent von Datenbank-Verbindungen
Was genau möchtest du installieren? Das APF ist ein Framework das du lokal entpacken und damit loslegen kannst. Hier würde ich eher eine grafische Möglichkeit anbieten eine Applikation einzurichten. Sowas habe ich kürzlich bei einem anderen OS-Projekt gesehen. Da gehst du auf eine GUI, legst ein neues Projekt an, kannst ein Model erstellen und was weiß ich nicht alles. Hierunter könnte dann auch eine DB-Konfiguration fallen. Problem dabei ist jedoch: wenn du austauschbare Komponenten nutzt (z.B. anderen ConfigurationManager, muss das die GUI auch unterstützen!
- Konfiguration vom Standard-Verhalten des APF
Was genau? Dinge wie InputFilter, Error-/ExceptionHandler gibt es schon. In diesem Stil würde ich gerne auch noch weitere Dinge konfigurierbar machen.
- Abrufen von verfügbaren Modulen und Updates des APF
Über eine lokale Konfigurations-GUI?
- Automatische Anpassung aller APF-Komponenten auf die neue Version (exrem komplex)
Einige Dinge kann man automatisch anpassen (hierfür gebe ich auch Hinweise im Migrations-Artikel) aber alles geht nicht. Ich versuche ja die API so weit es geht konstant zu halten, nur manchmal (siehe 1.12) geht das aus Gründen der Weiterentwicklung nicht.
Ich würde sogar soweit gehen, und auf der APF seite eine Art "PackageBuilder" zu erstellen, bei dem man mittels checkboxen auswählen kann welche komponenten, extensions usw. Man möchte. Allerdings weis ich nicht wie gut das dann mit SVN unterstzützung noch funktioniert, da kenn ich mich zu wenig aus.
Das finde ich eine gute Idee, Prämisse muss aber sein, dass man weiterhin das APF in einer Art benutzen kann, wie das jetzt der Fall ist.
- für mich wichtig wäre auch noch eine komplette überarbeitung der dokumentation.
Was bedeutet das? Mit dem 1.11er Release ist die Seite bereits komplett überarbeitet worden.
- eventuell wäre es auch sinnvoller, das system nur noch via frontcontroller ladbar zu machen. die action-features muss man ja nicht zwingend benutzen, was letztlich einen abstrakten pagecontroller übrig lässt. finde, das würde das loading-konzept des systems etwas vereinfachen.
Inwiefern? Bisher ist die Trennung bewusst gewählt, weil es nicht immer notwendig ist den Front-Controller-Overhead zu nutzen.
- ein native wrapper-klasse im apf für pdo fände ich auch sehr schön, da ich die pdo-klasse sehr gelungen finde.
Stimme ich zu. Ich möchte hier in Zukunft sogar noch mehr die Möglichkeit geben, externe Libs mit dem APF zu integrieren. Hier könnte man durch - wie du ansprichst - geeignete Wrapper-Klassen eine Anbindung von z.B. doctrine erreichen. So hat der Einsteiger/Umsteiger noch besser die Möglichkeit bewährte und bekannte Tools zu nutzen. Weitere Vorschläge für Wrapper?

Code: Alles auswählen

- ich tue mich noch etwas schwer mit der umsetzung des model-view-konzeptes sowie der actions, vor allem im bereich mehrere kontexte. eventuell ist das eine sache der dokumentation, hier klarer die themen zu beschreiben. eventuell kann man das ganze aber auch wesentlich einfacher/weniger komplex implementieren?
Die Implementierung ist bewusst komplex gewählt, die Anwendung sollte sich aber auf das Schreiben von Templates und Controllern sowie Taglibs beschränken. Sofern du ein View-Model brauchst, gerne auch das. aber mehr musst du nicht tun. Das sind alle Elemente des MVC-Pattern, die im APF genutzt und entsprechend ausgeführt werden. Das einfacher zu Implementieren bringt uns (leider) dort hin, wo andere Frameworks hängen: extrem eingeschränkte Möglichkeiten bei der GUI-Gestaltung. Man hat da sicher Workarounds gebaut (View-Helper etc.) aber das ist kein sauberes HMVC, wie es das APF als einziges PHP-Framework beherrscht. Vielleicht sollte man besser an der Doku feilen, da lässt sich sicher mehr herausholen. Hierzu gibt es aber mitlererweile im Wiki einige Beiträge:
- toll fände ich von der applikation (optional/wählbar) veränderbare konfigurationsdateien, also dass diese nicht nur lesbar, sondern auch (be)schreibbar ist.
Das wird schon sehr bald kommen. Geplant in 1.13 mit der Überarbeitung der Konfiguration.
Nunja, ich würde es auch eher als "Auf eigene Gefahr" anbieten, so ähnlich wie den GORM-Updater aktuell (sorry Chris ;)).
Wenn's da Probleme gibt, bitte einfach einen neuen Thread eröffnen. Ich hatte das Tool eigentlich nochmal einem Update unterzogen und es sollte auf MySQL5 funktionieren (aktuell lokal getestet mit der Erweiterung des UMGT-Moduls).
Ich habe dafür aktuell eine eigene Implementierung, die allerdings voraussetzt, dass ich bei jedem Update des APF diese Stellen nicht aktualisiere... Ich habe auch schon vor langer Zeit diese Thematik im Forum angesprochen und eine Lösung gepostet. Ihren Weg in die Sources hat es aber leider noch nicht gefunden :(
Wir machen das - versprochen! ;) Zwar nicht explizit, sondern über die Möglichkeit eigene Provider einzuhängen.

Weitere Ideen oder ein freiwilliger, der einen Wiki-Eintrag verfasst? ;)
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 27.05.2010, 09:57:47

dr.e. hat geschrieben:Hallo zusammen,

vielen Dank für den Input! Einiges haben wir ja schon besprochen (@Lutz ;)) aber auf zukünftige Features verschoben. Einiges haben Manko10 und ich schon angedacht. Vielleicht hat jemand noch Lust die neuen Features auf einer Wiki-Seite zusammenzuschreiben und mit ein paar Umsetzungs-Ideen zu versehen. Das können wir dann als Release-Planung für 2.xx nutzen oder vielleicht schon in den 1.xx-Zweig integrieren. Grundsätzlich denke ich, dass man Änderungen, die mit der 1.xx-API nicht absolut konträr stehen auch schon dort einfließen lassen sollte. 2.xx würde es nur dann rechtfertigen, wenn das Framework in seiner Grundstruktur deutlich geändert würde (z.B. nur noch Front-Controller).
Da bin ich d'accord :)
dr.e. hat geschrieben:Ich fasse mal grob zusammen:
Hierzu zählt aber nicht nur die Unterteilung der Komponenten, sondern auch die Coding-Standards, gerade was die Benennung von Variablen (insbesondere deren Groß- und Kleinschreibung) angeht.
Das wird bei jedem Update sukzessive verbessert, jedoch ist das einfach ein Prozess, der nicht Morgen abgeschlossen ist. Wenn man sich die Diffs jedoch regelmäßig ansieht, wird man feststellen, dass sich da schon einiges getan hat. Ich möchte hiermit nochmal anbieten, dass es immer die Möglichkeit gibt, schreibenden SVN-Zugriff zu erhalten (Ralf hat das schon), damit kleine Verbesserungen oder auch komplette Features (nach Diskussion und Design) auch von euch umgesetzt werden können. Variablen umbenennen ist nun keine große Sache. ;)
An dieser Stelle sei nochmal auf folgendes hingewiesen: Nur weil ich hier bestimmte Dinge anspreche heißt das, dass ich es als aktuell ignoriert empfinde. Ich weiß dass z.B. die Benennung von Variablen usw. mit jedem Update voranschreitet (ich muss ja aufgrund mancher Anpassungen von mir im Core (z.B. ConfigurationManager) viele Scripte manuell abgleichen). Ich habe es nur grundsätzlich aufgeführt, damit bei der neuen Version von vornherein eine einheitliche Struktur gewählt wird.
dr.e. hat geschrieben:
- Verwendbar ab PHP 5.3.x (oder je nach Veröffentlichung sogar nurnoch ab PHP 6!?)
Sehr guter Punkt. Die Einführung von Namespaces in das APF werden sicher einen größeren Umbau bedeuten und das sehe ich auch in 2.xx. Auch hier macht es sicher Sinn, zwei Zweige zu pflegen (ähnlich PHP4/PHP5), damit die bisherigen Versionen noch mit Bugfixes belegt werden können.
Eigentlich schrieb ich ja "nur PHP 5.3.x" bzw. "nur PHP 6". Aber es obliegt natürlich dir, wie das dann gehandhabt wird. Es ist ja auch die Frage, wann PHP 6 den Verbreitungsgrad hat, dass es sich lohnen würde "nurnoch" PHP 6 anzubieten.
dr.e. hat geschrieben:
- Einheitliche Coding-Standards für alle Komponenten des APF (vor Allem Bestimmung der Schreibweisen von Variablen, Konstanten, Funktionen, Methoden und Classen
Was siehst du hier für Regeln? In neuen Code-Teilen wird überall folgendes umgesetzt:
  • Klassen grundsätzlich in UCC.
  • Controller grundsätzlich in Kleinbuchstaben.
  • Variablen grundsätzlich klein.
  • Private/protected Klassen-Variablen ohne "__".
Das entspricht weitestgehend dem Java Coding Standard.
Die Regeln sind schon OK denke ich. Man sollte bloß für so ziemlich alle Aspekte eine Regel aufstellen:
- Einrückung bei neuen {}-Abschnitten
- Auflistung von Funktions-/Methodenaufrufen mit mehreren Parametern (ich schreibe zum Beispiel jeden Parameter in eine neue Zeile)
- Benennung von Konstanten
- Benennung von Variablen
- Bennenung von Funktionen/Methoden/Klassen
- usw.

Ich würde zum Beispiel folgendes vorschlagen:

Code: Alles auswählen

<?php
class ClassNameInCamelCase
  extends AbstractClass
  implements InterfaceForClass
{
  public $aArrayVar = array ('Array');
  protected $_sStringVar = 'String';
  private $_fFloatVar = 3.5;
  public $iIntegerVar = 5;
  public $bBooleanVar = TRUE;
  public $mMixedVar = NULL;
  public $oObjectVar = NULL;
  public $rResourceVar = NULL;

  public function methodName
    ( $sParameter1,
      $sParameter2,
      $sParameter3
     )
  {
    return TRUE;
  }
}
?>
Das ist jetzt aber nur ein Beispiel.
dr.e. hat geschrieben:
- Variable Steuerung aller zu verwendenden Komponenten über die Registry (z.B. ConfigurationManager)
Das sollten wir IMHO schon vorher besprechen (konkret: 1.13), denn dort ist eine Änderung des Konfigurations-Verhaltens angedacht. Man kann über die von Ralf vorgeschlagene Art und Weise mehrere ConfigurationManager erlauben. Letzteres halte ich persönlich für die sinnvollste Lösung. Allerdings muss man dann ein vernünftiges Konzept überlegen, welcher generische Informationen-Satz an den ConfigurationManager zu übergeben ist.
Über welche Methode ist mir recht wurscht ;) Ich hatte mal eine Lösung gepostet, die ähnlich der Anpassung der Input-/Output-Filter funktioniert, indem man einfach den Namen der Klasse für die Configuration setzen konnte. Auf diese Weise würde ich gerne ALLES anpassen können. Das setzt im neuen APF dann allerdings eine Kern-Klasse voraus, die die Steuerung nahezu aller Elemente übernimmt, damit auch wirklich alles angepasst werden kann!?
dr.e. hat geschrieben:
- Refactoring des GORM zur Nutzung von PDO, eventuell über eine Entkopplung der DB-Schnittstellen, ähnlich wie beim ZF (eine Adapter-Klasse je DB-Schnittstelle!?)
Der GORM nutzt den ConnectionManager. Das ist IMHO die Entkopplung, die du wünschst, oder? Beim APF heißt "Adapter" nur "DatabaseHandler".
OK, dann nennen wir es "Erweiterung der verfügbaren Datenbank-Treiber" :)
dr.e. hat geschrieben:
- Umstrukturierung der Komponenten (GORM gehört für mich z.B. eher zu "core", statt zu "modules")
Sehe ich dann eher in tools, denn du musst das Teil ja nicht nutzen. Es kann dir helfen (=tools) - klar - aber du brauchst es nicht umbedingt (core). Korrekt?
OK, meinetwegen auch so. Für mich stellt der GORM halt eine reine Daten-Schicht dar, sodass ich nicht finde, dass es ein Modul ist. Zu einem Modul gehört nach meiner Auffassung auch ein nutzbares Frontend - aber das ist sicher auch eine Definitionsfrage!?
dr.e. hat geschrieben:
- Auslieferung des Frameworks auch in reinen Core-Komponenten (nicht jeder braucht 2 Gästebücher, etc.)
Entrümpelung ist auf jeden Fall sinnvoll - klar. Und das zweite Gästebuch (=das alte) wird über kurz oder lang auch rausfliegen. Denn: es gibt ein neues und das neue ist mit deutlich besserer Umsetzung gesegnet und die Doku ist auch deutlich besser.
Auch das war nur ein Beispiel.
dr.e. hat geschrieben:
- Installations-Routine inklusive Setup-Tool:
- Einrichtungs-Assistent von Datenbank-Verbindungen
Was genau möchtest du installieren? Das APF ist ein Framework das du lokal entpacken und damit loslegen kannst. Hier würde ich eher eine grafische Möglichkeit anbieten eine Applikation einzurichten. Sowas habe ich kürzlich bei einem anderen OS-Projekt gesehen. Da gehst du auf eine GUI, legst ein neues Projekt an, kannst ein Model erstellen und was weiß ich nicht alles. Hierunter könnte dann auch eine DB-Konfiguration fallen. Problem dabei ist jedoch: wenn du austauschbare Komponenten nutzt (z.B. anderen ConfigurationManager, muss das die GUI auch unterstützen!
Installieren meint in diesem Sinne eigentlich nur die Grundkonfiguration, wie zum Beispiel die Auswahl bestimmter Klassen für z.B. die Konfiguration oder die zu verwendenden Input-/Output-Filter.
dr.e. hat geschrieben:
- Konfiguration vom Standard-Verhalten des APF
Was genau? Dinge wie InputFilter, Error-/ExceptionHandler gibt es schon. In diesem Stil würde ich gerne auch noch weitere Dinge konfigurierbar machen.
Weitere? Alle! :D Ja, genau sowas ist damit gemeint. Dafür halt eine GUI mit einem entsprechenden Setup-Tool, über das die Standard-Konfiguration des APF bereits im Vorfeld angepasst werden kann (siehe oben).
dr.e. hat geschrieben:
- Abrufen von verfügbaren Modulen und Updates des APF
Über eine lokale Konfigurations-GUI?
Korrekt.
dr.e. hat geschrieben:
- Automatische Anpassung aller APF-Komponenten auf die neue Version (exrem komplex)
Einige Dinge kann man automatisch anpassen (hierfür gebe ich auch Hinweise im Migrations-Artikel) aber alles geht nicht. Ich versuche ja die API so weit es geht konstant zu halten, nur manchmal (siehe 1.12) geht das aus Gründen der Weiterentwicklung nicht.
Das war kein Vorwurf. Aber ich finde es sollte eine Möglichkeit geben diese Anpassungen über eine GUI als Art Update zu führen. Andere Framework-Systeme nutzen doch sowas ähnliches!?
dr.e. hat geschrieben:
Ich würde sogar soweit gehen, und auf der APF seite eine Art "PackageBuilder" zu erstellen, bei dem man mittels checkboxen auswählen kann welche komponenten, extensions usw. Man möchte. Allerdings weis ich nicht wie gut das dann mit SVN unterstzützung noch funktioniert, da kenn ich mich zu wenig aus.
Das finde ich eine gute Idee, Prämisse muss aber sein, dass man weiterhin das APF in einer Art benutzen kann, wie das jetzt der Fall ist.
Da spricht ja auch nichts dagegen. Selbst mit dem oben angesprochenen GUI-Tool wäre es ja auch ohne nutzbar, es soll den Leuten nur die Konfiguration erleichtern, sollten sie es gebrauchen wollen. Wenn du so willst ein Modul ;)
dr.e. hat geschrieben:[...]
- ein native wrapper-klasse im apf für pdo fände ich auch sehr schön, da ich die pdo-klasse sehr gelungen finde.
Stimme ich zu. Ich möchte hier in Zukunft sogar noch mehr die Möglichkeit geben, externe Libs mit dem APF zu integrieren. Hier könnte man durch - wie du ansprichst - geeignete Wrapper-Klassen eine Anbindung von z.B. doctrine erreichen. So hat der Einsteiger/Umsteiger noch besser die Möglichkeit bewährte und bekannte Tools zu nutzen. Weitere Vorschläge für Wrapper?
Meinst du jetzt nur für die Datenbank-Verbindung? Oder generell für die Anbindung externer LIBs mit dem APF?
dr.e. hat geschrieben:[...]
Nunja, ich würde es auch eher als "Auf eigene Gefahr" anbieten, so ähnlich wie den GORM-Updater aktuell (sorry Chris ;)).
Wenn's da Probleme gibt, bitte einfach einen neuen Thread eröffnen. Ich hatte das Tool eigentlich nochmal einem Update unterzogen und es sollte auf MySQL5 funktionieren (aktuell lokal getestet mit der Erweiterung des UMGT-Moduls).
Ich habe die neueste Version noch nicht getestet, aber es war ja mal etwas holprig. Soll nicht heißen, dass es immernoch so ist, sorry. Aber grundsätzlich geschieht die Anpassung einer Datenbank-Struktur mit dem Update-Tool trotzdem auf eigene Gefahr.
dr.e. hat geschrieben:
Ich habe dafür aktuell eine eigene Implementierung, die allerdings voraussetzt, dass ich bei jedem Update des APF diese Stellen nicht aktualisiere... Ich habe auch schon vor langer Zeit diese Thematik im Forum angesprochen und eine Lösung gepostet. Ihren Weg in die Sources hat es aber leider noch nicht gefunden :(
Wir machen das - versprochen! ;) Zwar nicht explizit, sondern über die Möglichkeit eigene Provider einzuhängen.
Na hoffentlich *droh* ;) Dann kann ich vielleicht bald endlich wieder meine Scripte direkt per SVN updaten und muss nicht immer manuell abgleiche *schwärm*
dr.e. hat geschrieben:Weitere Ideen oder ein freiwilliger, der einen Wiki-Eintrag verfasst? ;)
Ich will es nicht versprechen, aber ich kann ja mal den Anfang im Wiki machen, sobald ich ein paar Minuten Zeit habe. Da ich nächsten Monat aber meine letzte Seefahrt habe, bin ich fast den kompletten Monat nicht erreichbar. Da müsste sich dann also entweder jemand Anderes kümmern oder ihr wartet, bis ich wieder da bin :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4538
Registriert: 04.11.2007, 16:13:53

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 27.05.2010, 23:31:09

Hallo Lutz,

ich hab dich schon richtig verstanden, nur wolte ich einfach auf deine Vorlage hin kontern. ;) Ich verstehe die Diskussion sehr wohl als konstruktiv und ich freue mich immer über Weiterentwicklungs-Ideen. Nur so bleibt das APF frisch und effektiv. Danke daher an alle nochmal (sofern das noch nicht so rübergekommen ist, denn wir sind direkt in die fachliche Diskussion eingestiegen)!
Eigentlich schrieb ich ja "nur PHP 5.3.x" bzw. "nur PHP 6". Aber es obliegt natürlich dir, wie das dann gehandhabt wird. Es ist ja auch die Frage, wann PHP 6 den Verbreitungsgrad hat, dass es sich lohnen würde "nurnoch" PHP 6 anzubieten.
Korrekt. Man muss wirklich sehen, wie die Verbreitung wirklich statt findet. Aktuell ist bei einigen Hostern immer noch PHP4 Standard und PHP5 gibt's mit extra Konfiguration (z.B. 1&1). Um zukünftig Überschneidungen der Klassen-Namen zu vermeiden ist es aber definitiv sinnvoll Namespaces einzuführen. Die übrigen Features von PHP5.3 sind IMHO nicht so interessant für das APF, jedoch saubere, echte Namespace-Unterstützung wäre wirklich schön.
Ich würde zum Beispiel folgendes vorschlagen:
Einspruch. Genau das wird in den JAVA Coding Guidelines beschrieben und diese besagt für dein Beispiel folgendes:

Code: Alles auswählen

    class ClassNameInCamelCase extends AbstractClass implements InterfaceForClass {
      public $arrayVar = array ('Array');
      protected $stringVar = 'String';
      private $floatVar = 3.5;
      public $integerVar = 5;
      public $booleanVar = TRUE;
      public $mixedVar = NULL;
      public $objectVar = NULL;
      public $resourceVar = NULL;

      public function methodName($parameter1, $parameter2, $parameter3) {
        return TRUE;
      }
    }
Ungarische Notation ist IMHO outdated. ;) Das APF erfüllt den Standard wie gesagt nicht in allen Bereichen, jedoch wird es zukünftig entsprechend umgesetzt.
Das setzt im neuen APF dann allerdings eine Kern-Klasse voraus, die die Steuerung nahezu aller Elemente übernimmt, damit auch wirklich alles angepasst werden kann!?
Dafür soll die Registry dienen. Das tut sie heute beispielsweise schon bei den Filtern und bei anderen Parametern wie dem ENVIRONMENT.
OK, dann nennen wir es "Erweiterung der verfügbaren Datenbank-Treiber" :)
Da bin ich dabei! Interessant wären auch noch Treiber für Oracle und PostgreSQL. Vor allem aber letztere.
OK, meinetwegen auch so. Für mich stellt der GORM halt eine reine Daten-Schicht dar, sodass ich nicht finde, dass es ein Modul ist. Zu einem Modul gehört nach meiner Auffassung auch ein nutzbares Frontend - aber das ist sicher auch eine Definitionsfrage!?
Das kann man schon so definieren. Das UMGT ist demnach ein klassisches "Modul". Den GORM nach tools zu verschieben ist demnach auch wirklich sinnvoll.
Weitere? Alle! :D Ja, genau sowas ist damit gemeint. Dafür halt eine GUI mit einem entsprechenden Setup-Tool, über das die Standard-Konfiguration des APF bereits im Vorfeld angepasst werden kann (siehe oben).
Wie gesagt gerne, nur müssen wir das konkret für die entsprechenden Konfigurations-Möglichkeiten implementieren, bzw. die Möglichkeit geben, diese entsprechend in einer GUI zu definieren. Da kann sich dann gerne einer von euch versuchen.
Das war kein Vorwurf. Aber ich finde es sollte eine Möglichkeit geben diese Anpassungen über eine GUI als Art Update zu führen. Andere Framework-Systeme nutzen doch sowas ähnliches!?
So habe ich das auch nicht aufgefasst. Aber ein automatisches Update-System kenne ich nur für abgeschlossene Software-Pakete wie beispielsweise PHPBB und nicht für ein Framework auf dem Custom Code aufgesetzt ist. Das Framework selbst lässt sich sehr einfach updaten - klar - nur Custom Code ist (fast) ein Ding der Unmöglichkeit.
Meinst du jetzt nur für die Datenbank-Verbindung? Oder generell für die Anbindung externer LIBs mit dem APF?
Generell. Ich könnte mir das z.B. auch für Schnittstellen-Implementierungen wie einem REST-Webservice-Client vorstellen. Vielleicht kann man hier ja einen intelligenten Class-Loader schreiben, der die Module generisch einbindet. Genauer habe ich mir da aber noch keine Gedanken gemacht, das ist nur eine Idee.
Ich habe die neueste Version noch nicht getestet, aber es war ja mal etwas holprig. Soll nicht heißen, dass es immernoch so ist, sorry. Aber grundsätzlich geschieht die Anpassung einer Datenbank-Struktur mit dem Update-Tool trotzdem auf eigene Gefahr.
Versuch's mal. Dein Feedback würde mich interessieren.
Ich will es nicht versprechen, aber ich kann ja mal den Anfang im Wiki machen, sobald ich ein paar Minuten Zeit habe. Da ich nächsten Monat aber meine letzte Seefahrt habe, bin ich fast den kompletten Monat nicht erreichbar. Da müsste sich dann also entweder jemand Anderes kümmern oder ihr wartet, bis ich wieder da bin :)
Sofern du Zeit hast, fang einfach mal ein paar Zeilen an, falls nicht, findet sich in der Runde hier sicher noch ein Freiwilliger.

EDIT: ich habe im Wiki die Seite http://wiki.adventure-php-framework.org ... es_APF_2.0 angelegt.

So long,
Christian
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 30.05.2010, 20:01:47

Entschuldigunge, dass mir die Zeit fehlte. Ab morgen bin ich leider auch schon wieder unterwegs, aber danach habe ich dann hoffentlich etwas mehr Zeit und fahre dann auch wohl nie wieder zur See und bin weg vom Fenster ;)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
Manko10
Beiträge: 73
Registriert: 16.11.2009, 21:46:58
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Manko10 » 11.07.2010, 21:00:43

Zur Java Coding Convention: müssen es zwei Spaces sein? Kann man da nicht vier nehmen? Zwei sind weder Fisch noch Fleisch; weder richtig eingerückt, noch ganz und gar uneingerückt. Dann schon lieber richtige Tabs, bei denen man sich die Breite im Editor selbst einstellen kann. Aber zwei Spaces finde ich immer ganz furchtbar und wirklich zur Übersicht trägt es mangels deutlicher Einschübe auch nicht. Vor allem muss ich dafür immer alle meine Editoren umkonfigurieren.
Visit Refining Linux for taking your Linux to the next level.


Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 29.07.2010, 19:53:10

So, nach langer Zeit der Abwesenheit nun endlich auch mal wieder etwas von mir:

Ich glaube, dass es wichtigeres zu entscheiden gilt, als die Anzahl der Zeichem beim Einzug. Meinetwegen kann es auch ruhig ein Tab sein, wenn euch das glücklich macht ;)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von jwlighting » 11.08.2010, 18:05:38

Mir fällt noch etwas ein, was vermutlich auch wieder in Richtung Geschmackssache bis Glaubensfrage geht:

Code: Alles auswählen

class Foo{
  function __construct(){ // Constructor
    // ...
  }
}
Ich persönlich finde diese Schreibweise für Konstruktoren eindeutiger und einfacher.

Häufig (beim APF) gesehen und in Java Standart ist

Code: Alles auswählen

class Foo{
  function Foo(){ // Constructor
    // ...
  }
}

Ich fände interessant zu wissen, weshalb ihr euch für die 2. Variante entschieden habt.

LG:
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast