wsCatalyst

Dieser Bereich dient dazu, eure Tricks und Erweiterungen vorzustellen, damit diese auch andere Anwender nutzen können. // This area can be used to publish your tricks and extensions to the APF to be used by other developers.
Antworten
APFelsahne
Beiträge: 222
Registriert: 18.03.2010, 13:13:07
Wohnort: Ludwigshafen am Rhein
Kontaktdaten:

wsCatalyst

Beitrag von APFelsahne » 30.09.2010, 04:57:34

Hallöchen!

Möchte hier meine Erweiterung vorstellen, die sich wesentlich in drei Punkten unterteilt. Einmal bringt sie einen Extension-Namespace wsc mit, der die eigentliche Erweiterung zum APF bildet.
Dazu gibt es im selben Namespace noch drei kleine Module. Der dritte Teil bildet ein Gerüst um das APF und die Projekte und ermöglicht ein gewisses Handling mit den Projekten.
Der letzte Teile ist optional, man kann also auch ganz wie gewohnt mit dem APF weiterarbeiten und nur die erweiterten Klasse und Module nutzen.

Das ganze beinhaltet einiges, deswegen möchte ich einfach auf das TracWiki unter Sourceforge verlinken: https://sourceforge.net/apps/trac/wscat ... /WikiStart
Eine Anleitung und Beschreibung der Bestandteile findet man unter https://sourceforge.net/apps/trac/wscat ... umentation

Die aktuelle Version kann man sich über

Code: Alles auswählen

https://wscatalyst.svn.sourceforge.net/svnroot/wscatalyst/stable/1.2.0
herunterladen.

Kernpunkt der Erweiterung sind:
- Konfigurierbare Mailer-Klasse
- Erweiterter Iterator
- Taglib für das Laden von Templates mit integrierter Benutzerverwaltung
- Datenbank-Wrapper für APF-Datenbank-Klassen, GORM und PDO
- Integriertes Unittest-System
- Gettext-Support
- Drei Module
- Projektverwaltung via Compiler


Ich möchte noch anmerken, dass die Erweiterung keine Daten/Klassen des APFs überschreibt und dass ein Projekt default als Beispiel-Projekt vorhanden ist.

Über Kritik und Vorschläge würde ich mich sehr freuen! :)
Grüße, Florian
BildAPF-Extension wsCatalyst

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

Re: wsCatalyst

Beitrag von APFelsahne » 27.02.2011, 14:23:35

Hallöchen!

Eine aktuelle Version kompatibel zum APF1.13(RC2-beta) liegt vor:
wsCatalyst 1.3.0-beta r149, dazu wird ein Minipatch für das APF benötigt wsCatalyst 1.3.0-beta r151 Patch.
Der Patch fügt dem BaseMapper lediglich die Möglichkeit hinzu, die Konfig-Dateiendung frei zu bestimmen.

Über Feedback freue ich mich immer ;)

Wie immer werden außer durch den Patch keine Dateien des APF überschrieben.
Zuletzt geändert von APFelsahne am 28.02.2011, 18:12:46, insgesamt 1-mal geändert.
Grüße, Florian
BildAPF-Extension wsCatalyst

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

Re: wsCatalyst

Beitrag von dr.e. » 28.02.2011, 00:17:10

Hallo Florian,

ich hab mir deinen Patch angesehen. Können wir diesen nicht ins APF direkt integrieren?

Ansonsten bin ich immer noch nicht dazu gekommen, den wsCatalyst auszuprobieren. :(
Viele Grüße,
Christian

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

Re: wsCatalyst

Beitrag von APFelsahne » 28.02.2011, 10:26:24

Hallo Christian!
dr.e. hat geschrieben:ich hab mir deinen Patch angesehen. Können wir diesen nicht ins APF direkt integrieren?
Das wäre super! Am Standardverhalten seitens des APF würde sich nichts ändern, ermöglicht aber dem Entwickler auch einen anderen ConfigProvider als den Ini zu nutzen. Würde mich sehr freuen, wenn das direkt ins APF fließen würde. :)
dr.e. hat geschrieben:Ansonsten bin ich immer noch nicht dazu gekommen, den wsCatalyst auszuprobieren. :(
Schade, ich hoffe du findest mal die Zeit, deine Meinung dazu fände ich sehr interessant :D

Edit: Der Patch war nicht korrekt, nun korrigiert und getestet:
wsCatalyst 1.3.0-beta r151 Patch
Grüße, Florian
BildAPF-Extension wsCatalyst

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

Re: wsCatalyst

Beitrag von APFelsahne » 09.03.2011, 20:28:48

Hallöchen!

Ein erster RC gibts nun unter wsCatalyst 1.3.0 zum laden (Patch dazu fürs APF1.13: Patch).

Neben der Anpassung an das APF in Version 1.13 gibt es folgende Veränderungen:
- Compiler refaktorisiert
- Module refaktorisiert
- Unittest-Umgang verbessert
- Skripte zur Erzeugung von Passwort und PrivatKeys hinzugefügt
- xMailManager verbessert
- xMailManager lässt nun externe Dateien als Templates in der Config definieren
- Bugfixes

Auf Feedback freue ich mich.
Grüße, Florian
BildAPF-Extension wsCatalyst

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

Re: wsCatalyst

Beitrag von dr.e. » 09.03.2011, 22:52:49

Hallo Florian,

ich habe mir grade den Code zu deinem Patch nochmal angesehen und überlegt, wie man das am besten in den GORM integrieren kann. Vom Prozess her müsste man dieses Attribut eigentlich beim Erzeugen über die Factory mitgeben. Z.B. so:

Code: Alles auswählen

final class GenericORMapperFactory extends APFObject {
   public function &getGenericORMapper($configNamespace, $configNameAffix, $connectionName, $configExtension = 'ini', $debugMode = false) {
   }
} 
Das statisch zu injizieren finde ich nicht ganz so schön, da es die Bedeutung einer Instanz des GORM vom Konzept aufweicht. Im Grunde sollte eine Factory immer in der Lage sein, ein Objekt ohne weitere Hacks zu erzeugen und zu initialisieren.

Weitere Möglichkeit ist folgendes:

Code: Alles auswählen

final class GenericORMapperFactory extends APFObject {
   public function init($initParam){
      $this->configExtension = $initParam;
   }
   public function &getGenericORMapper($configNamespace, $configNameAffix, $connectionName, $debugMode = false) {
   }
} 
Das würde die API nicht brechen und ermöglicht das Erzeugen des GORM mit unterschiedlichen Config-Extensions. Bedingung dabei wäre, dass die Factory die Abhängigkeit erfährt und bei der Konstruktion berücksichtigen kann.

Noch schöner ist für meine Begriffe jedoch die Umstellung auf den DIServiceManager, sprich die Konfiguration eines GORM wird immer und ausschließlich über den DI-Container geregelt. Dann kannst du diese Abhängigkeit komplett aus der Applikation in eine Config ziehen. Das würde dann so aussehen, dass du wie unter http://wiki.adventure-php-framework.org ... n_des_GORM beschrieben, den GORM wie auch immer konfigurieren kannst und in deiner Applikation nur noch den Service-Namen kennen musst.

Wie erzeugst du heute deinen GORM üblicherweise?
Viele Grüße,
Christian

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

Re: wsCatalyst

Beitrag von APFelsahne » 10.03.2011, 11:24:17

Hi!

der Gorm wird über folgende Methode erzeugt/geholt (letztlich mittels des ServiceManagers):

Code: Alles auswählen

static public function getORM( $sNamespace = 'core::system' , $sAppendix = 'default' )
{
    $ORMF = self::$__oDBWrapper->getServiceObject('modules::genericormapper::data','GenericORMapperFactory', "SINGLETON" );
    return $ORMF->getGenericORMapper( $sNamespace , $sAppendix , self::$__sCurrentDriver );
}
 
Der DIServerManager würde eine Config-Datei zwischenschalten, in der man die Endung definieren kann? Dann wäre das imo die beste Wahl. Das Einzige was dann noch hinzugefügt werden muss im GORM, ist, dass er dieses Attribut aus der Config nutzt.

Edit:
Ich meine also ein Attribut welches folgende Angabe anpassbar macht:

Code: Alles auswählen

/config/modules/mymodule/services/{CONTEXT}/{ENVIRONMENT}_serviceobjects.ini
So dass man vllt das Anhängsel oder nur die Dateiendung selbst bestimmen kann.
Grüße, Florian
BildAPF-Extension wsCatalyst

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

Re: wsCatalyst

Beitrag von dr.e. » 11.03.2011, 00:02:12

Hallo Florian,

genau das wäre auch meine Idee gewesen. Angelehnt an den Wiki-Eintrag würde dann die Config wie folgt übergeben:

Code: Alles auswählen

[GORM-CONFIG]
servicetype = "NORMAL"
namespace = "modules::genericormapper::data"
class = "GenericORMapperDIConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "..."
conf.affix.method = "setConfigAffix"
conf.affix.value = "..."
conf.conn.method = "setConnectionName"
conf.conn.value = "..."
conf.debug.method = "setDebugMode"
conf.debug.value = "true|false"
conf.ext.method = "setConfigFileExtension"
conf.ext.value = "orm"
Das ist dann sauber gekapselt und ermöglicht einfache Wiederverwendbarkeit. Alternativ sollte man die Factory noch mit getAndInitServiceObject() unter Angabe der Endung erzeugen können, dann haben wir alle Fälle abgedeckt.

Ich bau das mal ein und melde mich bei dir zu einem Test.
Viele Grüße,
Christian

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

Re: wsCatalyst

Beitrag von dr.e. » 12.03.2011, 17:19:18

Hallo Florian,

ich habe die Implementierung abgeschlossen und es gibt in Summe drei Möglichkeiten den GORM zu erzeugen und die Datei-Endung für den GORM zu beeinflussen. Die Möglichkeiten habe ich dir unter http://wiki.adventure-php-framework.org ... tei-Endung aufgezeigt.

Für deinen aktuellen Anwendungsfall ist wohl Variante 1 über die Factory die beste.

Die neuen APF-Pakete dafür kannst du unter http://adventurephpfra.svn.sourceforge. ... /?view=tar aus dem SVN herunterladen.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast