[dr.e.]

Das APF-Team (http://adventure-php-framework.org) hat heute das Release 1.8 (RC1) angekündigt. Die für Produktivumgebungen freigegebene Version beinhaltet ein neues Lizenzmodell, weitere Produktivitätstools, ein Remake bewährter Komponenten, zusätzliche kleine Dinge, die das Leben des Entwicklers einfacher gestalten und einige Bugfixes.


Neue Lizenz!
Um auch Enterprise-Nutzern die Möglichkeit zu bieten, das Framework für Closed-Source- oder eigene Lizenz-Produkte einsetzen zu können, wurde das Framework mit Veröffentlichung des Releases 1.8-RC1 unter die LGPL v3 gestellt.


Weitere Produktivitätstools:
Das Release beinhaltet zusätzliche Tools, die die Entwicklung erleichtern und die Produktivität steigern. Hierzu zählen der AdvancedLogger für erweiterte Logging-Aufgaben, die <core:appendnode /> Taglib, zur globalen Wiederverwendung von Template-Fragmenten, die <*:mediastream /> Taglibs zur Auslieferung von GUI-Elementen direkt aus dem Namespace der Applikation (-> deutliche einfacheres Packaging!) und eZ-style Templates, die mit Hilfe spezieller Tags und XML-Dateien übersetzt werden. Weitere Produktivitätstools sind im Kapitel Spezielle TagLibs (http://de.adventure-php-framework.or...zielle-TagLibs) aufgeführt.


Remake bewährter Komponenten:
Im Zuge des Refactorings wurden einige Komponenten überarbeitet um den gewachsenen Ansprüchen zu genügen. Durch neue, generischere Konzepte ist nun nicht nur die Verwendung, sondern auch die Erweiterung deutlich vereinfacht werden. Der FilesystemManager wurde von Abhängigkeiten bereinigt die Methoden wurden hinsichtlich der aktuellen Anforderungen reviewed. Durch die Einführung der Provider-Logik wurd die Erweiterbarkeit und Konfigurierbarkeit des AdvancedBBCodeParser deutlich verbessert. Trotz der guten Erweiterbarkeit werden die wichtigsten Provider werden mitgeliefert! Auch die Taglib <html:template /> wurde einem Refactoring unterzogen. Dadurch ist es deutlich
einfacher geworden, die Funktionen per <template:addtaglib /> zu erweitern. Auch beim Cache-Manager wurde mit Hilfe von Providern die Verwendbarkeit und Anpassbarkeit erhöht. Zusätzlich dazu wurden neue Caching-Backends wie memcache und database hinzugefügt.


Ease the daily work!
Das Adventure PHP Framework (APF) ist auf die Lösung von alltäglichen Problemen, die Produktivität von Entwicklern und der Qualität von Webanwendungen ausgerichtet. Die in diesem Release enthaltenen Verbesserungen unterstützen dies noch deutlicher: besseres Debugging beim Einbinden von Templates, bessere Benchmark IDs, besserer Schutz vor SQL-Injections im MySQLHandler und der Verfügbarkeit der aktuellen URL in der Registry.


Bugfixes:
Das neue Release enthält wichtige Bugfixes:

* init()-Methode des MySQLxHandler aktiviert nun den Debug-Mode sauber.
* Aufruf von MySQLHandler::escapeValue() baut sebständig Verbindung zur Datenbank auf.
* html_taglib_form::__createFormElement() initialisiert nun neue Formular-Elemente korrekt.
* Generierung der Captcha-Bild-URL funktioniert nun fehlerfrei.


Details zu den einzelnen Themenbereichen können dem ausführlichen Changelog (http://de.adventure-php-framework.or...nloads#1.8-RC1) auf der Download-Seite entnommen werden. Hier finden Sie zudem entsprechende Hinweise auf Diskussionen im Forum.

[Jann Hendrik]

Inzwischen berichtet auch heise davon:
http://www.heise.de/developer/Advent...meldung/119956

[dr.e.]

Hallo zusammen,

heute wurde der erste Release Candidate des 1.9er-Zweiges des Adventure PHP Frameworks (APF) offiziell freigegeben. Das Release setzt auf mehr Flexibilität in der Konfiguration von globalen Services, Erweiterung von bestehenden Komponenten zur Erleichterung der Implementierung von Anwendungen und der Bereinigung von veralteten Komponenten.

Einhergehend mit dem Refactoring der Filter-API wurden die Formular-TagLibs um Eingabe-Filter erweitert, um so die Sicherheit von Webanwendungen zu erhöhen. Ein weiterer großer Teil der Neuerungen ist die Überarbeitung der Usermanagement-Moduls, das nun als vollwertige zur mandantenfähigen Verwaltung von Benutzern eingesetzt werden kann.

Details zu den einzelnen Themenbereichen können dem ausführlichen Changelog
(http://de.adventure-php-framework.or...nloads#1.9-RC1) auf der Download-Seite entnommen werden. Der Artikel http://adventure-php-framework.org/S...on-1-8-auf-1-9 beinhaltet zudem
Hilfestellungen zur Migration auf die neu im Framework integrierten Klassen.

Happy coding!

[kampfgnom]

Wann stellst du eigentlich komplett auf PHP 5 um? Von PHP 4 ist ja mittlerweile dr Support eingestellt oder irre ich?

[dr.e.]

Hallo Gabriel,

ab dem Stable-Release von 1.9 branche ich komplett ab. Das bedeutet Umstellung des Codes auf PHP 5 und Ende des PHP 4 Supports. Bugs werden dabei weiter im 4er-Zweig behoben, Features jedoch weitestgehend nur noch im 5er-Zweig gepflegt.

Grundsätzlich läuft noch ein großer Anteil der PHP-Applikationen auf Version 4. Gerade im Enterprise-Bereich (RHEL 4.x) ist die Version 4 die offiziell supportete.

Viele Grüße,
Christian

[dr.e.]

Hallo zusammen,

Das APF-Team hat heute das Release 1.10 (RC1) angekündigt. Mit diesem wurde die Entwicklung komplett auf PHP5 umgestellt, für PHP4 ist voraussichtlich bis Anfang 2010 eine Kompatibilitäts-Version erhältlich. Einhergehend mit der vollständigen Einführung der PHP5-Sprachkonstrukte wurden einige Aufräumarbeiten platziert. Darüber hinaus sorgen Performance-Optimierungen für eine gleichbleibend exzellente Performance. Die größte technische Neuerung ist die Einführung eines "dependency injection container", ähnlich der Objekt-Initialisierung von SPRING (JAVA). Darüber hinaus wurden bewährte Komponenten einer Pflege unterzogen um Entwicklung und Einsatz der Tools zu erleichtern.

Downloads sowie ein ausführliches Changelog gibt es unter Downloads :: Adventure PHP Framework (APF), der Artikel Migration Version 1.9 auf 1.10 :: Adventure PHP Framework (APF) beschreibt die notwendigen Anpassungen auf die neue Version.

Für die, die noch nicht wissen, welches Framework denn das richtige ist, gibt es unter Yii vs. APF :: Adventure PHP Framework (APF) und Why APF? :: Adventure PHP Framework (APF) einige Argumente für das APF.

Happy coding,
Dr.E.

[dr.e.]

Hallo zusammen,

das APF-Team hat heute das Release 1.10 (RC2) veröffentlicht.

Diese Version behebt durch ein Refactoring der Filter-Implementierung die mit den PHP-Versionen >= 5.2.10 und >= 5.3.0 aufgetretenen Fehler. Die Hintergründe dazu können dem Foren-Eintrag Fehler: Declaration of FrontControllerInputFilter::filter() entnommen werden.

Weiter sind natürlich alle Features der Version 1.10-RC1 enthalten:
Mit diesem wurde die Entwicklung komplett auf PHP5 umgestellt, für PHP4 ist voraussichtlich bis Anfang 2010 eine Kompatibilitäts-Version erhältlich. Einhergehend mit der vollständigen Einführung der PHP5-Sprachkonstrukte wurden einige Aufräumarbeiten platziert. Darüber hinaus sorgen Performance-Optimierungen für eine gleichbleibend exzellente Performance. Die größte technische Neuerung ist die Einführung eines "dependency injection container", ähnlich der Objekt-Initialisierung von SPRING (JAVA). Darüber hinaus wurden bewährte Komponenten einer Pflege unterzogen um Entwicklung und Einsatz der Tools zu erleichtern.

Downloads sowie ein ausführliches Changelog gibt es unter Downloads :: Adventure PHP Framework (APF), der Artikel Migration Version 1.9 auf 1.10 :: Adventure PHP Framework (APF) beschreibt die notwendigen Anpassungen auf die neue Version.

Für die, die noch nicht wissen, welches Framework denn das richtige ist, gibt es unter Yii vs. APF :: Adventure PHP Framework (APF) und Why APF? :: Adventure PHP Framework (APF) einige Argumente für das APF.

Happy coding,
Dr.E.

[dr.e.]

Hallo zusammen,

das APF-Team hat heute das Release 1.10 (stable) veröffentlicht. Mit diesem Maintenance-Release wurde die Entwicklung komplett auf PHP5 umgestellt, für PHP4 ist bis Anfang 2010 eine Kompatibilitäts-Version erhältlich. Neben einigen Aufräumarbeiten sorgen Performance-Optimierungen für eine gleich bleibend exzellente Performance. Die größte technische Neuerung ist die Einführung eines "dependency injection container", ähnlich der Objekt-Initialisierung von SPRING (JAVA). Auch in diesem Release finden sich zahlreiche Features im Framework wieder, die im Entwickler-Forum als Wunsch diskutiert wurden.

Downloads sowie ein ausführliches Changelog gibt es unter Downloads :: Adventure PHP Framework (APF), der Artikel Migration Version 1.9 auf 1.10 :: Adventure PHP Framework (APF) beschreibt die notwendigen Anpassungen auf die neue Version.

Für die, die noch nicht wissen, welches Framework denn das richtige ist, gibt es unter Yii vs. APF :: Adventure PHP Framework (APF) und Why APF? :: Adventure PHP Framework (APF) einige Argumente für das APF.

Happy coding,
Dr.E.

[pago]

Hmm... ich guck mir ja eigentlich bei jedem neuen Release mal die Doku an, weil du ja immer wieder nette Sachen erwähnst, aber von dem "DI-Container" bin ich, was ich von der Doku her sehe, doch etwas enttäuscht. Das sieht für mich sehr stark nach nem ServiceLocator mit ner etwas erweiterten Konfiguration aus. Ist jetzt nicht schlecht, nur halt was völlig anderes als das, was du da anpreist. Zumal die Ini-Konfigurationsdateien nur bedingt lesbar sind.
Ein DI-Container würde die Abhängigkeiten der Controller direkt auflösen, statt bestimmte Services zur Verfügung zu stellen, die auf Wunsch aus dem Container geladen werden können. Zumindest meinem Verständnis nach sollte der DI-Container nur auf der obersten Schicht (also dort, wo das bootstrapping der Anwendung selbst durchgeführt wird) sichtbar sein. Alles darunter sollte automatisch (bzw. per Konfiguration/Konvention) geschehen.
Hast du da irgendwelche Verbesserungen geplant?

Weil ich verwende momentan ja das ZF und die Einbindung des Symfony-DIC ist auch nicht viel besser, als das, was du da hast, aber das könnte für mich zu nem Argument werden, mich tatsächlich mal mit dem APF auseinanderzusetzen (vom lesen der Doku abgesehen), wenn das vernünftig und sinnig umgesetzt wäre.

[dr.e.]

Hi Pago,

Das sieht für mich sehr stark nach nem ServiceLocator mit ner etwas erweiterten Konfiguration aus. Ist jetzt nicht schlecht, nur halt was völlig anderes als das, was du da anpreist.

Jein. Ein ServiceLocator ist im JAVA-EE-Bereich quasi nur ein Bean-Lookup, das an Hand einer Factory zurückgeliefert wird. Er übernimmt Konstruktion und Caching, jedoch nicht das Thema Initialisierung (siehe Core J2EE Patterns - Service Locator). Diese übernimmt im APF der ServiceManager. Die Funktion der Initialisierung übernimmt dann der DIServiceManager. Er initialisiert die Komponente mit statischen und dynamischen Konfigurationen und bereitet damit die Möglichkeit für eine saubere Entkopplung von Komponenten vor. Diese Themen sind IMHO ganz klar dem Thema dependency injection zuzuordnen (siehe Dependency injection - Wikipedia, the free encyclopedia).

Zumal die Ini-Konfigurationsdateien nur bedingt lesbar sind.

Warum?

Ein DI-Container würde die Abhängigkeiten der Controller direkt auflösen, statt bestimmte Services zur Verfügung zu stellen, die auf Wunsch aus dem Container geladen werden können.

Das ist nicht korrekt. Der DI-Container hat nichts mit Controllern zu tun, sondern bei der Verwendung geht es mehr um Services im Bereich Business- und Datenschicht.

Zumindest meinem Verständnis nach sollte der DI-Container nur auf der obersten Schicht (also dort, wo das bootstrapping der Anwendung selbst durchgeführt wird) sichtbar sein. Alles darunter sollte automatisch (bzw. per Konfiguration/Konvention) geschehen.

Wie bereits angedeutet ist eben das Gegenteil der Fall. Im Bereich der Präsentations-Schicht sind andere Pattern und Verfahrensweisen sinnvoll und anwendbar. Dort ist sicher auch dependency injection anwendbar, jedoch sollten im GUI-Bereich die Entkopplung auf andere Weise gegeben sein: GUI-Widgets in Kombination mit HMVC.

Hast du da irgendwelche Verbesserungen geplant?

Sicher, jedoch ist die aktuelle Lösung schon sehr effizient.

Weil ich verwende momentan ja das ZF und die Einbindung des Symfony-DIC ist auch nicht viel besser, als das, was du da hast, aber das könnte für mich zu nem Argument werden, mich tatsächlich mal mit dem APF auseinanderzusetzen (vom lesen der Doku abgesehen), wenn das vernünftig und sinnig umgesetzt wäre.

Die Lösung mag unscheinbar erscheinen, ist meiner Überzeugung und Erfahrung nach jedoch besser. Den Grund dafür sehe ich im Konzept der Konfiguration und der Anbindung von Services im APF. Zudem ermöglicht der Page-Controller die Möglichkeit, deutlich granularere GUI-Strukturen zu schaffen als es mit ZF und Symfony möglich ist. Sobald du einen APF-Controller hast, kannst du implizit den richtigen Service mit dem richtigen Context und der richtigen Sprache und Umgebung erzeugen ohne in der Anwendung darüber nachdenken zu müssen. Diese Art und Weise kenne ich in ZF und SF nicht - es sei denn, soetwas wäre im letzten halben Jahr implementiert worden.
Wenn dich das APF interessiert, kann ich dir mal per PN einen Artikel zuschicken, in dem ich die Implementierung mit dem DIServiceManager beschreibe. Dieser ist leider noch nicht online/veröffentlicht, sonst könnte ich direkt verweisen.
Wenn du möchtest, können wir uns gerne mal ein Beispiel suchen und die Umsetzung und die Möglichkeiten des APF daran diskutieren. Gerne auch hier.

[pago]

Hi, über den Artikel würde ich mich sehr freuen.

Das ist nicht korrekt. Der DI-Container hat nichts mit Controllern zu tun, sondern bei der Verwendung geht es mehr um Services im Bereich Business- und Datenschicht.

Kann man denke ich ein wenig drüber streiten. Ein Controller ist letztlich auch nur ein etwas missratenes Objekt (basierend auf ZF-Kenntnissen) mit Abhängigkeiten (z.B. braucht der LoginController ein User-Objekt, eine UserRepository, eine HashStrategy und was weiß ich noch alles). Diese sind im Idealfall dann austauschbare Services. Soweit sind wir uns, denke ich, einig.
Der Knackpunkt ist: Sollte der Controller manuell einen Service anfragen (der dann eventuell vom DIServiceManager weiter konfiguriert/initialisiert wird), oder sollten in einer perfekten Welt diese Services in den Controller injected werden?

Für mich ist das ein Unterschied. Ich meinte auch nicht speziell das JEE-ServiceLocator-Muster, sondern das ganz Allgemeine.
Ich werf einfach mal ein Fowler-Zitat in den Raum:

The key difference is that with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.

(Quelle: Inversion of Control Containers and the Dependency Injection pattern)

Ich finde es optimaler, wenn es diese Abhängigkeit zum Locator nicht gibt. So wie ich deine Doku verstehe muss ich aber irgendwo coreObject erweitern, um die getDIService-Methode zu bekommen, d.h. es existiert eben jene Abhängigkeit und die Klasse, die von coreObject erbt, nutzt einen ServiceLocator (getDIService) um eine Abhängigkeit aufzulösen. Ob das nun der Controller macht oder die erste Ebene der Business-Schicht, soll mir dabei egal sein.

Aber bevor ich hier noch weiter rede, sollte ich mir vielleicht erstmal deinen Artikel durchlesen. Denke das wird einiges klarer machen, was ich jetzt noch nicht so ganz nachvollziehen kann.

[dr.e.]

Hallo Patrick,

Kann man denke ich ein wenig drüber streiten. Ein Controller ist letztlich auch nur ein etwas missratenes Objekt (basierend auf ZF-Kenntnissen) mit Abhängigkeiten (z.B. braucht der LoginController ein User-Objekt, eine UserRepository, eine HashStrategy und was weiß ich noch alles). Diese sind im Idealfall dann austauschbare Services. Soweit sind wir uns, denke ich, einig.

So allgemein würde ich das nicht sehen. Ja ein (Präsentations-Schicht-)Controller nutzt (Business-Schicht-)Services, jedoch ist meiner Ansicht nach zwischen (H)MVC-Controllern und der Art von Controllern, die die Front-Controller-Implementierung darstellt zu unterscheiden. Die Abhängigkeit der beiden Arten ist auf Grund der Zuordnung zu anderen Schichten unterschiedlich. Eine Front-Controller-Action darf sicher direkten Zugriff oder direkte Abhängigkeit auf einen Service haben, da diese zur Business-Schicht gehört.

Der Knackpunkt ist: Sollte der Controller manuell einen Service anfragen (der dann eventuell vom DIServiceManager weiter konfiguriert/initialisiert wird), oder sollten in einer perfekten Welt diese Services in den Controller injected werden?

Meiner Auffassung nach ersteres, denn der technische Lifecycle gibt dir vor, dass die Präsentations-Schicht bei der Darstellung auf Services zurückgreifen muss (z.B. wegen notwendiger Daten). Du kannst zwar in einer FC-Action bereits ein Model - oder allgemeiner - einen Container mit den relevanten Daten vorher befüllen, der Controller wird jedoch immer an der relevanten Stelle auf diese Quelle von sich heraus zugreifen.
Man könnte nun sicher das Model in den Controller injizieren, bei einer HMVC-Implementierung in Verbindung mit dem 3-Schicht-Architektur-Pattern ist dies jedoch nicht mehr generisch lösbar, da ein Modul oder gar ein Controller mehrere Models nutzen können muss.

Ich finde es optimaler, wenn es diese Abhängigkeit zum Locator nicht gibt. So wie ich deine Doku verstehe muss ich aber irgendwo coreObject erweitern, um die getDIService-Methode zu bekommen, d.h. es existiert eben jene Abhängigkeit und die Klasse, die von coreObject erbt, nutzt einen ServiceLocator (getDIService) um eine Abhängigkeit aufzulösen. Ob das nun der Controller macht oder die erste Ebene der Business-Schicht, soll mir dabei egal sein.

Das würde ich nicht als Nachteil sehen, denn das Vererbungs-Konzept des APF bringt mit sich, dass jedes Objekt automatisch mit dem aktuell gültigen Context und mit der gewählten Sprache versorgt wird. Dies ermöglicht nicht nur eine erweiterte Form der Konfigurierbarkeit, sondern erleichtert dir auch die Implementierung. Hier ist jedoch bereits berücksichtigt, das "Die Komposition [..] der Vererbung stets vorzuziehen [..]" ist. Per se bist du jedoch nicht gezwungen, deine Klasse von coreObject abzuleiten, der DIServiceManager kann wie in der Methode __getDIServiceObject() beschrieben "auch so" verwendet werden.

Insgesamt ist die gewählte Integrationsform des APF z.B. zum ZF stark unterschiedlich, da die Konzepte der GUI-Strukturen einfach zu stark differieren. Hieraus ergibt sich beim ZF exakt der Aufbau und die Struktur der Lokalisierung und Injizierung von Komponenten, genau wie das auch beim APF für das dort vorhandene Konzept notwendig und richtig ist. Wenn du hierzu ein bischem Mehr Hintergrund-Information möchtest, nimm dir den Artikel zur Hand oder lass uns hier weiter diskutieren.

Aber bevor ich hier noch weiter rede, sollte ich mir vielleicht erstmal deinen Artikel durchlesen. Denke das wird einiges klarer machen, was ich jetzt noch nicht so ganz nachvollziehen kann.

Ist in deiner Inbox. :)

[dr.e.]

Hallo zusammen,

Reiner Rottmann, Spezialist für LINUX Cluster-Systeme hat kürzlich einen eigenen YUM-Channel für die Installation desAPF per RPM veröffentlicht. Das RPM-Installations HOWTO beschreibt wie die Pakete mit Hilfe des Yellowdog Update Managers (YUM) verwaltet werden können.

Happy RPM'ing,
Christian

[dr.e.]

Hallo zusammen,

das APF-Team freut sich, zusammen mit der neuen Webseite das APF in der stabilen Version 1.11 ankündigen zu können.

Die neue Version wartet mit einer Überarbeitung der Formular-Unterstützung auf Basis von Taglibs auf. Diese beherrscht nun die generische Definition von Validatoren und Filtern auf Basis des Observer-Patterns und ist deutlich einfacher an die eigenen Bedürfnisse anzupassen.

Der bereits im Release 1.9 erschienene OR-Mapper GenericORMapper wurde in dieser Ausgabe um Tools zum automatischen Setup und Update einer Datenbank erweitert. Der Entwickler kann sich nun komplett auf die Entwicklung der Logik der Anwendung kümmern, die Speicherung der Objekte wird vom Mapper übernommen.

Inhalt der Performance-Optimierungen des Releases waren Optimierungen im Kern des Frameworks und die Überarbeitung des integrierten BenchmarkTimers. Dieser unterstützt den Entwickler nun durch eine besser grafische Aufbereitung der Messungen noch besser in der Analyse der Hot Spots in einer Anwendung. Er ermöglicht nun, die Applikationen optimal auf den Einsatz im Live-Betrieb vorzubereiten.

Mit Erscheinen des Releases 1.11 wurde die Unterstützung für PHP 4 abgekündigt und die Kompatibilität mit PHP 5.3 nochmals verbessert. In der kommenden Version 1.12 liegt der Fokus auf der Erweiterung der neuen Formular-Unterstützung und der Überarbeitung der Konfigurations-Komponente.

Happy coding,
Dr.E.