[2.0] Umstellung auf Namespaces

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.
Gesperrt
Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

[2.0] Umstellung auf Namespaces

Beitrag von dr.e. » 18.03.2013, 19:40:14

Hallo zusammen,

ich habe am Wochenende einen POC begonnen um das APF auf Namespaces umzustellen. Dies hat an einigen Stellen echte Herausforderungen mit sich gebracht, da Autoloading in PHP offenbar nicht trivial ist :roll: . Aktuell läuft die Sandbox-Anwendung bereits auf einer lokal angepassten APF-Code-Basis.

Da die Umstellung deutliche Änderungen mit sich bringt, bedarf es meiner Ansicht nach einer neuen Major-Version - sprich 2.0.Da dieses Thema auf der Roadmap ein sehr wichtiges ist, würde ich gerne die nächste Version nicht 1.18 taufen, sondern 2.0 und hiermit offiziell den Start der Entwicklung für die neue Version einleiten. Roadmap passe ich entsprechend an.

Hauptfokus von 2.0 wäre aus meiner Sicht:
  • Einführung von Namespaces
  • Umstellung auf Autoloading statt import()
  • Integration eines Autoloadings basierend auf Vendor-Namen um die parallele Nutzung von anderen Frameworks zu vereinfachen und Trennung von APF- und Projekt-Code zu vereinfachen.
Ferner sehe ich noch das Thema GORM als großen Block.

Sofern gewünscht, kann ich im - hoffentlich bald - stattfindenden APF-DEV-Chat meinen aktuellen Stand zeigen.
Viele Grüße,
Christian

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

Re: [2.0] Umstellung auf Namespaces

Beitrag von dr.e. » 21.03.2013, 00:44:41

Hallo zusammen,

damit dieser Thread nicht vereinsamt, hier mal ein Auszug, wie zukünftig Dinge adressiert werden als erstern Eindruck:

Code: Alles auswählen

<core:importdesign
   template="APF\sandbox\pres\templates\navi.html"
/>
<core:addtaglib
   class="APF\sandbox\pres\taglib\SandboxLanguageImportTemplateTag"
   prefix="lang"
   name="umgtimport"
/>
<@controller
   class="APF\sandbox\pres\controller\DbWizzardController"
@>
<html:getstring
   config="APF\extensions\arraypager\language.ini"
   entry="DisplayPage"
/>
Mehr gibts demnächst! 8-)
Viele Grüße,
Christian

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

Re: [2.0] Umstellung auf Namespaces

Beitrag von jwlighting » 21.03.2013, 11:45:04

Hui,

die schöne ::-Schreibweise ist weg :cry:
Das bedarf dann deutlicher Umgewöhnung!

Aus welchem Hintergrund werden Namespace und Dateiname nicht mehr getrennt? Und warum wieder Dateierweiterungen!?

Ich bleibe gespannt!

LG :)
Jan

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

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

Re: [2.0] Umstellung auf Namespaces

Beitrag von dr.e. » 21.03.2013, 21:55:07

Hi Jan,
die schöne ::-Schreibweise ist weg :cry:
Jep. Die PHP-Jungs haben sich entschieden, Namespaces zukünftig mit "\" zu trennen, da bleibt wohl nichts anderes übrig als diesen Schritt mitzugehen. Grundsätzlich finde ich das aber nicht weiter dramatisch, da die Umstellung deutliche Vorteile bietet.
Das bedarf dann deutlicher Umgewöhnung!
Korrekt! Auch die Migration ist nicht trivial. Aber hier möchte ich noch Tools bauen um den Upgrade zu erleichtern.
Aus welchem Hintergrund werden Namespace und Dateiname nicht mehr getrennt?
Soweit bin ich noch nicht. Ich habe erst mal die ganzen Klassen-Adressierungen geändert. Aktuell arbeite ich am ClassLoader. Anschließend sind der ServiceManager und DIServiceManager dran. Sofern es weiter sinnvoll ist, Namespace und Template zu trennen, behalte ich das natürlich bei.
Und warum wieder Dateierweiterungen!?
Die Überlegung war, dass manche IDEs bei der Endung .html etwas allergisch auf das nicht valide HTML reagieren und du dir so in deinem Projekt mit einer anderen Endung behelfen könntest. Allerdings verlierst du dann natürlich den Intellisense-Support. Auch hier gilt: so weit bin ich noch nicht, nehme mir das die kommenden Tage vor.
Viele Grüße,
Christian

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

Re: [2.0] Umstellung auf Namespaces

Beitrag von jwlighting » 21.03.2013, 22:35:15

Vielen Dank für die Antwort.

Sofern du noch in den Kinderschuhen steckst, nimm das nicht als Kritik, sondern als Anreize für die Entwicklung.
Einiges wird sich sicher noch zeigen.
Die Überlegung war, dass manche IDEs bei der Endung .html etwas allergisch auf das nicht valide HTML reagieren und du dir so in deinem Projekt mit einer anderen Endung behelfen könntest.
Ich habe die Überprüfung einfach ein wenig runtergeschraubt - 100% kriegt man es eh nicht hin. Ich find es an sich sehr angenehm, die (immer gleiche) Dateierweiterung nicht tippen zu müssen.
Sonst könnte man diese für Templates ja auch in der Registry ablegen?
Gerade bei der Konfiguration habe ich ja eh einen entsprechenden Provider, womit das Format und damit die Dateiendung schon festgelegt ist.

Viel Erfolg!

LG :)
Jan

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

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

Re: [2.0] Umstellung auf Namespaces

Beitrag von dr.e. » 21.03.2013, 22:53:34

Hi Jan,
Sofern du noch in den Kinderschuhen steckst, nimm das nicht als Kritik, sondern als Anreize für die Entwicklung.
Einiges wird sich sicher noch zeigen.
So habe ich das auch nicht aufgefasst, alles in Ordnung! :)
Sonst könnte man diese für Templates ja auch in der Registry ablegen?
Das kann sicher auch eine Variante sein.
Viel Erfolg!
Danke! Das kann ich gerade beim Thema autoloading gut gebrauchen! :roll: Das ist an manchen Stellen hell on earth.
Viele Grüße,
Christian

proggerxy
Beiträge: 12
Registriert: 24.09.2013, 21:42:46

Re: [2.0] Umstellung auf Namespaces

Beitrag von proggerxy » 25.10.2013, 16:42:37

Hallo dr.e.,
Einführung von Namespaces
Diese Entscheidung begrüße ich. Man kann zwar nun nicht mehr die :: Schreibweise verwenden, die ich so gemocht habe, aber das ist nun mal notwendig, bei der Umstellung auf Namespaces, von daher danke Christian für die Entscheidung!
Umstellung auf Autoloading statt import()
Das wäre auch mal ganz schlau. Aber warum machst du das nicht via Composer und Git? Da brauch man doch nur die json Datei und da kann man dann als Entwickler die Directories angeben (modules, extensions, tools, core).

Ich weiß, du hast besonders mit dem Autoloading viel zu tun, aber ich hätte noch einen Wunsch und fände es sehr schön, wenn man versuchen könnte, diesen für 2.0 zu verwenden.
Es ist so, dass ich bei manchen Projekten, die nicht so komplex sind, ein CMS hernehme. Für extrafunktionen verwende ich dann Plugins. Jetzt ist es aber so, dass ich dabei gerne ein paar APF Komponenten für die Plugins hernehmen würde, aber einige Komponenten sind ja direkt zum Framework abhängig oder sehe ich das falsch? Für ein paar kleine Plugins ist aber ein HMVC Framework etwas überdimensioniert. Daher fände ich es super, wenn du eventuelle Abhängigkeiten lösen könntest.

Auch ich wünsch dir viel Erfolge,
proggerxy

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

Re: [2.0] Umstellung auf Namespaces

Beitrag von dr.e. » 25.10.2013, 17:08:12

Hallo proggerxy,

hast du dir die neue Version schon mal angesehen? Einen aktuellen Snapsho kannst du unter http://files.adventure-php-framework.or ... hp5.tar.gz herunterladen eine Doku zur Umstellung findest du unter http://wiki.adventure-php-framework.org ... 17_auf_2.0. Dort sind bereits einige von deinen Punkten (Namespaces, Autoloading nach PSR-0) umgesetzt. Eine Beta wird in der nächsten Woche erscheinen.
Für extrafunktionen verwende ich dann Plugins.
Plugins für eine Drittsoftware zu schreiben ist grundsätzlich eine gute Idee, eine stabile und (für dich) bekannte Basis dafür zu nehmen eine noch bessere. Sofern die Drittsoftware für Plugins bereits eine saubere Schnittstelle anbietet, solltest du auch keine besonderen Schwierigkeiten haben, basierend auf einem Framework wie dem APF ein Plugin zu schreiben und zu integrieren.
Jetzt ist es aber so, dass ich dabei gerne ein paar APF Komponenten für die Plugins hernehmen würde, aber einige Komponenten sind ja direkt zum Framework abhängig oder sehe ich das falsch? Für ein paar kleine Plugins ist aber ein HMVC Framework etwas überdimensioniert. Daher fände ich es super, wenn du eventuelle Abhängigkeiten lösen könntest.
Die Frage ist: wo siehst du konkrete Abhängigkeiten, die dich behindern? Durch das Umstellen in 2.0 auf Autoloading werden selbst wenn du alle Dateien eines APF-Releases in dein Plugin verpackst nur die explizit genutzten geladen. Auch gibt es Möglichkeiten das APF als eigenständiges Plugin zu verpacken und dann deine "konkreten" Plugins einfach basierend auf diesem erstellst. So hast du keinen Overhead jedes Mal das APF mit deinem Plugin mit ausliefern zu müssen.

Was das Lösen von Abhängigkeiten im Allgemeinen angeht, so tue ich mich schwer bei einem Framework gewisse Abhängigkeiten zu entfernen. Ein Framework wie das APF ist keine Klassenbibliothek wie beispielsweise das Zend Framework und damit weder so designed noch verfolgt es den Anspruch einer vollkommenen Entkopplung.

Daher mein Vorschlag: poste mal deine konkreten Punkte, daran lässt sich einfacher aufzeigen, wie eine Lösung aussehen kann.
Viele Grüße,
Christian

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste