datenbanktabellen, GORM, DIServiceManager ect

Im Entwickler-Forum können Implementierungsdetails sowie Alternativen der Umsetzung diskutiert werden. // Here, developers can discuss implementation details of features of their projects.
Antworten
dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dingsda » 10.02.2014, 14:28:50

hallo,

war mir jetzt etwas unsicher mit dem thread-titel und dem forumsbereich. weiß auch noch nicht so recht, wo das denn nun wirklich hingehört. hoffe es passt hier einigermaßen.

ich hab mich ja nun die letzte woche recht intensiv mit dem APF beschäftigt. an manchen stellen hackt es aber immer noch.

allem voran bin ich bei den konfigurationen unsicher. ich versuche mich gerade am GORM und dem DIServiceManager.

habe nun folgende serviceobjects.ini in meinem config-ordner:

Code: Alles auswählen

[OR-Mapper]
servicetype = "SESSIONSINGLETON"
class = "APF\modules\genericormapper\data\GenericORRelationMapper"
setupmethod = "setup"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\berichte"
conf.db.method = "setConnectionName"
conf.db.value = "MyDB"
init.rel.method = "addDIRelationConfiguration"
init.rel.namespace = "mytestapp\berichte"
init.rel.name =  "CONFIG-RELATION"
init.map.method = "addDIMappingConfiguration"
init.map.namespace = "mytestapp\berichte"
init.map.name =  "CONFIG-MAPPING"

[OR-Manager]
servicetype = "SESSIONSINGLETON"
class = "APF\modules\genericormapper\data\tools\GenericORMapperManagementTool"
setupmethod = "setup"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\berichte"
conf.db.method = "setConnectionName"
conf.db.value = "MyDB"
init.rel.method = "addDIRelationConfiguration"
init.rel.namespace = "mytestapp\berichte"
init.rel.name =  "CONFIG-RELATION"
init.map.method = "addDIMappingConfiguration"
init.map.namespace = "mytestapp\berichte"
init.map.name =  "CONFIG-MAPPING"

[CONFIG-MAPPING]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIMappingConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\berichte"
conf.affix.method = "setConfigAffix"
conf.affix.value = "mytestapp"

[CONFIG-RELATION]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIRelationConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\berichte"
conf.affix.method = "setConfigAffix"
conf.affix.value = "mytestapp"
 
hab das so ein bischen von hier und da zusammengesucht und bin schon froh, dass es überhaupt funktioniert.
mit

Code: Alles auswählen

         $setup = & $this->getDIServiceObject('mytestapp\berichte', 'OR-Manager');
         $setup->run(true); 
kann ich nun leicht die tabellen in der DB erstellen.
und mit

Code: Alles auswählen

         $orm = & $this->getDIServiceObject('mytestapp\berichte', 'OR-Mapper');
         $orm->saveObject($myobject);
 
kann ich etwas drin speichern.

aber verstehen tu ich da einiges noch nicht.

was genau bedeutet z.b. setupmethod="setup"?
soweit ich das verstanden hab wird die bei setupmethod angegebene methode gleich bei der initialisierung des Objects (oder muss ich service sagen?) ausgeführt.
hier wird es ja auch so verwendet wie ich es in meiner ini hab.
aber welche anderen parameter könnte ich da noch angeben?

die section OR-Mapper und OR-Manager in meiner ini sind ja zum größten teil ziemlich gleich. das kann man doch bestimmt auch anders machen, damit man sich in der ini nicht ständig wiederholt. nur hab ich nicht herausgefunden wie.

was ich auch noch nicht verstehe ist wann ich conf.* und wann ich init.* in der serviceobjects.ini verwenden kann/soll und was ich noch zusätzlich verwenden könnte.

und dann noch ne frage zu den tabellen. ich hab ja nun in der serviceobjects.ini angegeben wo meine tabelleneinstellungen zu finden sind. und wenn ich nun in einem anderen ordner auch noch tabelleneinstellungen habe? leg ich dann nochmal ne serviceobjects.ini an für den GenericORRelationMapper? und wiederhole mich dann auch dort wieder bei fast allen einstellungen? oder sollte ich einfach gleich alle tabelleneinstellungen in einem ordner haben? in meinem geplanten project sind schon recht viele tabellen vorgesehen. das hätte ich es eigentlich schon lieber wenn ich die ein bischen nach "thematik" trennen kann um den überblick zu behalten.

geht das mit der trennung überhaupt, wenn die tabellen zum teil auch in zwei bereiche gehören? also z.b. hab die tabellen ent_user, ent_berichte und ass_berichte2user, welche mir der GORM angelegt hat. wenn ich das umgt einbinde wird es aber auch die tabelle ent_user benötigen.
wie löse ich das dann?
trag ich dann einfach zusätzlich in config/modules/usermanagement/data/umgt_objects.ini die user ein? und müssen die eintragungen dann auch exakt übereinstimmen? oder kann z.b. bei der umgt_objects.ini der eintrag so lauten:

Code: Alles auswählen

[User]
DisplayName = "VARCHAR(100)"
FirstName = "VARCHAR(100)"
LastName = "VARCHAR(100)"
StreetName = "VARCHAR(100)"
StreetNumber = "VARCHAR(100)"
 
und in nem anderen ordner so

Code: Alles auswählen

[User]
DisplayName = "VARCHAR(100)"
FirstName = "VARCHAR(100)"
 
weil ich da weniger informationen über den user brauch.

oder sollte ich die tabelle für das umgt abtrennen und dann ne komposition zu meiner usertabelle herstellen?

versteh einfach noch nicht so richtig wie der GORM arbeitet.

ich danke schonmal im vorraus für die antworten.

lg
Dingsda

edit: sorry falls ich überall falsche bezeichnungen nutze. mit den ganzen "objekten" und "services" komm ich einfach noch nicht klar

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

Re: datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dr.e. » 11.02.2014, 23:53:12

Hallo dingsda,
war mir jetzt etwas unsicher mit dem thread-titel und dem forumsbereich. weiß auch noch nicht so recht, wo das denn nun wirklich hingehört. hoffe es passt hier einigermaßen.
Nur keine Scheu, wenn es garnicht passt, verschieben wir den Thread einfach. :)
aber verstehen tu ich da einiges noch nicht.
Dann wollen wir das mal ändern! ;)
was genau bedeutet z.b. setupmethod="setup"?
soweit ich das verstanden hab wird die bei setupmethod angegebene methode gleich bei der initialisierung des Objects (oder muss ich service sagen?) ausgeführt.
hier wird es ja auch so verwendet wie ich es in meiner ini hab.
Die "setupmethod" referenziert eine Methode eines Services, die beim Erzeugen desselben durch den DIServiceManager aufgerufen wird um den internen Zustand (z.B. Datenbank-Verbindung) zu initialisieren. In deinem Beispiel hat der Service eine Methode

Code: Alles auswählen

public function setup() {
} 
die vom DIServiceManager genutzt wird um z.B. den Mapping- und Relation-Tabelle sowie die Domänen-Objekt-Konfiguration zu erzeugen - kurzum ihn für dich benutzbar zu machen.

Mehr Information zur Konfiuguration von Services findest du unter http://adventure-php-framework.org/Seit ... ons-Schema.
aber welche anderen parameter könnte ich da noch angeben?
Das Schema der Konfiguration von Services findest du unter http://adventure-php-framework.org/Seit ... figuration. Es gibt im Grunde drei Bereiche: die Implementierung (PHP-Klasse), die Konfiguration (Injektion von einfachen Parametern oder weiteren Services, die mit dem DIServiceManager erzeugt wurden) und der Ausführung der Setup-Methoden.
die section OR-Mapper und OR-Manager in meiner ini sind ja zum größten teil ziemlich gleich. das kann man doch bestimmt auch anders machen, damit man sich in der ini nicht ständig wiederholt. nur hab ich nicht herausgefunden wie.
Du hast in deinem Post die [OR-Mapper]-Sektion definiert. Diese reicht völlig aus. Eine [OR-Manager]-Sektion ist nicht notwendig. Das GenericORMapperManagementTool kannst du einfach in einem Script z.B. wie unter http://adventure-php-framework.org/Seit ... -Datenbank beschrieben einsetzen. Hierzu brauchst du keinen Service zu definieren.
was ich auch noch nicht verstehe ist wann ich conf.* und wann ich init.* in der serviceobjects.ini verwenden kann/soll und was ich noch zusätzlich verwenden könnte.
Diese dienen dazu, deine Klasse mit den benötigten Parametern zu versehen. Der eine braucht nur "einfache" Parameter (z.B. einen String oder ein Boolean-Flag), ein anderer braucht vielleicht einen weiteren Service ("komplexer Parameter") um seine Arbeit verrichten zu können. Die "einfachen" Parameter kannst du mit den conf.* Attributen einimpfen, "komplexe" Konfigurationen mit den init.*-Sektionen. Näheres findest du unter http://adventure-php-framework.org/Seit ... figuration.
und dann noch ne frage zu den tabellen. ich hab ja nun in der serviceobjects.ini angegeben wo meine tabelleneinstellungen zu finden sind. und wenn ich nun in einem anderen ordner auch noch tabelleneinstellungen habe? leg ich dann nochmal ne serviceobjects.ini an für den GenericORRelationMapper? und wiederhole mich dann auch dort wieder bei fast allen einstellungen? oder sollte ich einfach gleich alle tabelleneinstellungen in einem ordner haben? in meinem geplanten project sind schon recht viele tabellen vorgesehen. das hätte ich es eigentlich schon lieber wenn ich die ein bischen nach "thematik" trennen kann um den überblick zu behalten.
Du kannst dem GORM mehrere Tabellen (=Mappings) und mehrere Beziehungen mitgeben - im Grunde so viele du möchtest. Das geht einfach dadurch, dass du (Vorlage siehe http://adventure-php-framework.org/Seit ... ung-via-DI) mehrere

Code: Alles auswählen

init.rel.method = "addDIRelationConfiguration"
init.rel.namespace = "VENDOR\data\mapper"
init.rel.name =  "CONFIG-RELATION"

init.map.method = "addDIMappingConfiguration"
init.map.namespace = "VENDOR\data\mapper"
init.map.name =  "CONFIG-MAPPING"
Sektionen definierst. Etwa so:

Code: Alles auswählen

init.rel-1.method = "addDIRelationConfiguration"
init.rel-1.namespace = "VENDOR\data\mapper"
init.rel-1.name =  "CONFIG-RELATION-1"

init.rel-2.method = "addDIRelationConfiguration"
init.rel-2.namespace = "VENDOR\data\mapper"
init.rel-2.name =  "CONFIG-RELATION-2"

init.map-1.method = "addDIMappingConfiguration"
init.map-1.namespace = "VENDOR\data\mapper"
init.map-1.name =  "CONFIG-MAPPING-1"

init.map-2.method = "addDIMappingConfiguration"
init.map-2.namespace = "VENDOR\data\mapper"
init.map-2.name =  "CONFIG-MAPPING-2"
Du kannst natürlich Konfigurationen auch aus unterschiedlichen Ordnern (=Namespaces) einbinden. Einfach dazu den Parameter init.*.namespace entsprechend anpassen.
geht das mit der trennung überhaupt, wenn die tabellen zum teil auch in zwei bereiche gehören? also z.b. hab die tabellen ent_user, ent_berichte und ass_berichte2user, welche mir der GORM angelegt hat. wenn ich das umgt einbinde wird es aber auch die tabelle ent_user benötigen.
wie löse ich das dann?
Generell kannst du eine Instanz des GORM für die komplette Applikation verwenden und ihm einfach alle Mappings und Relations geben. Das ist das einfachste. Wenn du wirklich trennen musst oder möchtest, löst du die Abhängigkeiten in der Anwendung auf. Sprich du erstellst/konfigurierst zwei Instanzen des GORM - eine für das UMGT und eine für deine Anwendung - und nutzt in einer weiteren Komponente deiner Anwendung (z.B. einem Document-Controller) beide für jeweils den Bereich für den sie zuständig sind. Wenn du alle Posts eines Benutzers anzeigen möchtest, dann holst du dir von der einen Instanz den aktuellen Benutzer und von der anderen z.B. alle Posts für den Benutzer mit einer entsprechenden ID, die du aus dem Ergebnis eines Aufrufs vom UMGT-Service erhalten hast.
trag ich dann einfach zusätzlich in config/modules/usermanagement/data/umgt_objects.ini die user ein? und müssen die eintragungen dann auch exakt übereinstimmen? oder kann z.b. bei der umgt_objects.ini der eintrag so lauten:
In der 1-Instanz-Lösung nein, für eine 2-Instanz-Lösung kannst du das machen. Allerdings ist dein User dann nur ein Stellvertreter des "echten" im UMGT. D.H. er braucht eigentlich "nur" eine Stellvertreter-ID, die mit der ID des Users im IMGT gefüllt ist.

Im Prinzip:

UMGT:

Code: Alles auswählen

[User]
DisplayName = "VARCHAR(100)"
FirstName = "VARCHAR(100)"
LastName = "VARCHAR(100)"
StreetName = "VARCHAR(100)"
StreetNumber = "VARCHAR(100)"
Anwendung (z.B. Forum):
[User]
ProxyID = "INT(10)"[/code]
oder sollte ich die tabelle für das umgt abtrennen und dann ne komposition zu meiner usertabelle herstellen?
Das ist die einfachste Möglichkeit im 1-Instanz-Ansatz.
edit: sorry falls ich überall falsche bezeichnungen nutze. mit den ganzen "objekten" und "services" komm ich einfach noch nicht klar
Alles gut! :)
Viele Grüße,
Christian

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dingsda » 13.02.2014, 11:20:01

danke für deine anwort. hatte letztlich auch selbst viele antworten noch gefunden nach dem gefühlt 100-sten mal lesen der dokus. aber gut, es nochmal bestätigt zu wissen.

dazu aber mal ne frage:
dr.e. hat geschrieben: Du kannst dem GORM mehrere Tabellen (=Mappings) und mehrere Beziehungen mitgeben - im Grunde so viele du möchtest. Das geht einfach dadurch, dass du (Vorlage siehe http://adventure-php-framework.org/Seit ... ung-via-DI) mehrere

Code: Alles auswählen

init.rel.method = "addDIRelationConfiguration"
init.rel.namespace = "VENDOR\data\mapper"
init.rel.name =  "CONFIG-RELATION"

init.map.method = "addDIMappingConfiguration"
init.map.namespace = "VENDOR\data\mapper"
init.map.name =  "CONFIG-MAPPING"
Sektionen definierst. Etwa so:

Code: Alles auswählen

init.rel-1.method = "addDIRelationConfiguration"
init.rel-1.namespace = "VENDOR\data\mapper"
init.rel-1.name =  "CONFIG-RELATION-1"

init.rel-2.method = "addDIRelationConfiguration"
init.rel-2.namespace = "VENDOR\data\mapper"
init.rel-2.name =  "CONFIG-RELATION-2"

init.map-1.method = "addDIMappingConfiguration"
init.map-1.namespace = "VENDOR\data\mapper"
init.map-1.name =  "CONFIG-MAPPING-1"

init.map-2.method = "addDIMappingConfiguration"
init.map-2.namespace = "VENDOR\data\mapper"
init.map-2.name =  "CONFIG-MAPPING-2"
Du kannst natürlich Konfigurationen auch aus unterschiedlichen Ordnern (=Namespaces) einbinden. Einfach dazu den Parameter init.*.namespace entsprechend anpassen.
was spricht eigentlich dagegen die methoden addDIMappingConfiguration und addDIRelationConfiguration zu einer einzigen Methode zu verbinden?
die könnte dann z.b. addDIMappingAndRelationConfiguration heißen.

dann wird aus

Code: Alles auswählen

[GORM]
...
init.umgtrel.method = "addDIRelationConfiguration"
init.umgtrel.namespace = "mytestapp\gorm"
init.umgtrel.name =  "umgt-rel"

init.umgtmap.method = "addDIMappingConfiguration"
init.umgtmap.namespace = "mytestapp\gorm"
init.umgtmap.name =  "umgt-map"

init.berichterel.method = "addDIRelationConfiguration"
init.berichterel.namespace = "mytestapp\gorm"
init.berichterel.name =  "berichte-rel"

init.berichtemap.method = "addDIMappingConfiguration"
init.berichtemap.namespace = "mytestapp\gorm"
init.berichtemap.name =  "berichte-map"

[berichte-rel]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIRelationConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\gorm"
conf.affix.method = "setConfigAffix"
conf.affix.value = "berichte"

[berichte-map]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIMappingConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\gorm"
conf.affix.method = "setConfigAffix"
conf.affix.value = "berichte"

[umgt-rel]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIRelationConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\gorm"
conf.affix.method = "setConfigAffix"
conf.affix.value = "umgt"

[umgt-map]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIMappingConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\gorm"
conf.affix.method = "setConfigAffix"
conf.affix.value = "umgt"
das hier

Code: Alles auswählen

[GORM]
...
init.umgt.method = "addDIMappingAndRelationConfiguration"
init.umgt.namespace = "mytestapp\gorm"
init.umgt.name =  "umgt"

init.berichte.method = "addDIMappingAndRelationConfiguration"
init.berichte.namespace = "mytestapp\gorm"
init.berichte.name =  "berichte"

[berichte]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIMappingAndRelationConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\gorm"
conf.affix.method = "setConfigAffix"
conf.affix.value = "berichte"

[umgt]
servicetype = "NORMAL"
class = "APF\modules\genericormapper\data\GenericORMapperDIMappingAndRelationConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "mytestapp\gorm"
conf.affix.method = "setConfigAffix"
conf.affix.value = "umgt"
letzteres ist kürzer und damit übersichtlicher. die meisten würden doch sowieso die zusammenpassenden *_objects.ini und *_relations.ini ins selbe verzeichnis legen, oder?

soweit ich sehen konnte ist dafür nur der klasse BaseMapper eine zusätzliche methode hinzuzufügen

Code: Alles auswählen

public function addDIMappingAndRelationConfiguration(GenericORMapperDIMappingAndRelationConfiguration $config) {
      $this -> addMappingConfiguration($config -> getConfigNamespace(), $config -> getConfigAffix());
      $this -> addRelationConfiguration($config -> getConfigNamespace(), $config -> getConfigAffix());

    }
 
und eine neue klasse GenericORMapperDIMappingAndRelationConfiguration zu erstellen, die genau so aussieht wie die klassen GenericORMapperDIRelationConfiguration und GenericORMapperDIMappingConfiguration
dr.e. hat geschrieben:
die section OR-Mapper und OR-Manager in meiner ini sind ja zum größten teil ziemlich gleich. das kann man doch bestimmt auch anders machen, damit man sich in der ini nicht ständig wiederholt. nur hab ich nicht herausgefunden wie.
Du hast in deinem Post die [OR-Mapper]-Sektion definiert. Diese reicht völlig aus. Eine [OR-Manager]-Sektion ist nicht notwendig. Das GenericORMapperManagementTool kannst du einfach in einem Script z.B. wie unter http://adventure-php-framework.org/Seit ... -Datenbank beschrieben einsetzen. Hierzu brauchst du keinen Service zu definieren.
das ich das nicht brauche ist mir klar. hatte es auch schon anfangs so realisiert gehabt. aber um die konfiguration vom script zu trennen find ich es doch praktisch, dass ich auch den manager als DIService anlegen kann. optimal fände ich es wenn man es so machen könnte, dass man dem manager anweisen kann dieselben mapping/relation/datenbank-konfiguration zu nutzen wie der mapper. das gilt eigentlich sowohl dafür wenn man den manager als DIService aufruft als auch wenn man ein setup-script wie in der doku erstellt. auch beim script würde man sich paar mal wiederholen da man die konfigurationen ja schon schon für den mapper vorgenommen hat
Generell kannst du eine Instanz des GORM für die komplette Applikation verwenden und ihm einfach alle Mappings und Relations geben. Das ist das einfachste.
werd ich wohl so machen. die 2-instanzlösung kling echt kompliziert.

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

Re: datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dr.e. » 13.02.2014, 18:11:30

Hallo dingsda,
was spricht eigentlich dagegen die methoden addDIMappingConfiguration und addDIRelationConfiguration zu einer einzigen Methode zu verbinden?
die könnte dann z.b. addDIMappingAndRelationConfiguration heißen.
Einiges. :) Es ist einerseits nicht immer gegeben, dass du Beziehungen verwalten möchtest und andererseits kannst du vielleicht bei getrennten Konfigurationen (z.B. bei Modul-übergreifender Nutzung von Objekten und Beziehungen) nicht immer mit der zusätzlichen Definition von Beziehungen eine Objekt-Definition mitliefern. Insofern wurden zwei Methoden definiert, die die volle Flexibilität für jeden Anwendungsfall bereithalten.
die meisten würden doch sowieso die zusammenpassenden *_objects.ini und *_relations.ini ins selbe verzeichnis legen, oder?
Das gilt wie gesagt für Nutzung des GORM für ein Modul. Sobald du Modul-übergreifend agierst bist du damit eingeschränkt.

Es erscheint auf den ersten Blick sicher einfacher, die Konfiguration erstellst du jedoch einmal und da sind 3 Zeilen mehr IMHO effektiv nicht so ausschlaggebend.
aber um die konfiguration vom script zu trennen find ich es doch praktisch, dass ich auch den manager als DIService anlegen kann. optimal fände ich es wenn man es so machen könnte, dass man dem manager anweisen kann dieselben mapping/relation/datenbank-konfiguration zu nutzen wie der mapper. das gilt eigentlich sowohl dafür wenn man den manager als DIService aufruft als auch wenn man ein setup-script wie in der doku erstellt.
Das hast du doch schon so in deiner [OR-Manager]-Sektion realisiert?! :roll:
werd ich wohl so machen. die 2-instanzlösung kling echt kompliziert.
Im Endeffelt ist sie nicht schwerer als die erste, es ist beim Coding einfach ein wenig anders. Wenn du mit der ersten nicht zurecht kommst, sag Bescheid, dann kann ich dir ein paar Beispiele oder Hilfestellungen geben.
Viele Grüße,
Christian

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dingsda » 13.02.2014, 19:26:14

dr.e. hat geschrieben:
was spricht eigentlich dagegen die methoden addDIMappingConfiguration und addDIRelationConfiguration zu einer einzigen Methode zu verbinden?
die könnte dann z.b. addDIMappingAndRelationConfiguration heißen.
Einiges. :) Es ist einerseits nicht immer gegeben, dass du Beziehungen verwalten möchtest und andererseits kannst du vielleicht bei getrennten Konfigurationen (z.B. bei Modul-übergreifender Nutzung von Objekten und Beziehungen) nicht immer mit der zusätzlichen Definition von Beziehungen eine Objekt-Definition mitliefern. Insofern wurden zwei Methoden definiert, die die volle Flexibilität für jeden Anwendungsfall bereithalten.
man kann ja auch sowohl die methoden bereitstellen, die nur die mappings- oder nur die relations-konfiguration hinzufügen als auch die methode die beides zusammen hinzufügt. die alten methoden sollten ja sowieso beibehalten werden wegen rückwärtskompatibilität.
dr.e. hat geschrieben:
die meisten würden doch sowieso die zusammenpassenden *_objects.ini und *_relations.ini ins selbe verzeichnis legen, oder?
Das gilt wie gesagt für Nutzung des GORM für ein Modul. Sobald du Modul-übergreifend agierst bist du damit eingeschränkt.
selbst bei mehreren modulen würd ich ja nun nicht z.b. nicht die objekte fürs umgt ins verzeichtnis "config/umgt" legen mit dem prefix "blabla" und die beziehungen dann z.b. ins verzeichnis "config/andererordner" mit dem prefix "blub". und wenn das jemand möchte kann er ja trotzdem noch auf die getrennten methoden addDIMappingConfiguration und addDIRelationConfiguration zugreifen statt auf die zusammenfassende neue methode.
dr.e. hat geschrieben:Es erscheint auf den ersten Blick sicher einfacher, die Konfiguration erstellst du jedoch einmal und da sind 3 Zeilen mehr IMHO effektiv nicht so ausschlaggebend.
tatsächlich sind es 10 zeilen code die man pro konfiguration zusätzlich hat ;) . denn nicht nur bei der methode spart man 3 zeilen sondern auch bei der relation/mapping-Section.
ja klar macht man das nur einmal. aber wenn man das vereinfachen kann warum sollte man das nicht machen?

die nachteile die du angibst sehe ich nur dann, wenn man die schon vorhandenen methoden durch die neue ersetzt. ich stelle mir aber eher eine erweiterung des methodenumfangs vor.
dr.e. hat geschrieben: Das hast du doch schon so in deiner [OR-Manager]-Sektion realisiert?! :roll:
vielleicht hab ich dich missverstanden. es ging doch grade darum dass du meintest dass ich eben genau diese section weglassen kann.
darauf meine antwort in dem teil:
aber um die konfiguration vom script zu trennen find ich es doch praktisch, dass ich auch den manager als DIService anlegen kann.
beim rest hab ich mich vielleicht selbst auch missverständlich ausgedrückt. ich hab mir halt vorgestellt, dass man sowas machen könnte:

services.ini in config/myapp/gorm

Code: Alles auswählen

[GORM]
servicetype = "SINGLETON"
class = "APF\modules\genericormapper\data\GenericORRelationMapper"
setupmethod = "setup"
conf.db.method = "setConnectionName"
conf.db.value = "MyDB"

// hier verschieden mappings und relations hinzugefügt

[mapping1]
// hier die mappings
[mapping2]
// nochmal mappings
[relations1]
// hier die relations
[relations2]
// nochmal relations
 
services.ini in config/modules/umgt

Code: Alles auswählen

[GORM]
servicetype = "SINGLETON"
class = "APF\modules\genericormapper\data\GenericORRelationMapper"
setupmethod = "setup"
conf.db.method = "setConnectionName"
conf.db.value = "MyDB"

// hier mappings und relations fürs umgt hinzugefügt

[umgt-map]
// hier die mappings
[umgt-rel]
// hier die relations
 
und die services.ini in config/setup

Code: Alles auswählen

[OR-Manager]
servicetype = "SINGLETON"
class = "APF\modules\genericormapper\data\tools\GenericORMapperManagementTool"
setupmethod = "setup"

init.config-1.method="addConfigFrom"
init.config-1.namespace="config/modules/umgt"
init.config-1.name="GORM"

init.config-2.method="addConfigFrom"
init.config-2.namespace="config/myapp/gorm"
init.config-2.name="GORM"
oder als setupscript:

Code: Alles auswählen

$setup = new GenericORMapperManagementTool();
$setup->addConfigFrom('config/modules/umgt','GORM');
$setup->addConfigFrom('config/myapp/gorm','GORM');
 
macht es etwas weniger fehleranfällig als

Code: Alles auswählen

$setup = new GenericORMapperManagementTool();
$setup->addMappingConfiguration('config/modules/umgt','umgt-map');
$setup->addRelationConfiguration('config/modules/umgt','umgt-rel');
$setup->addMappingConfiguration('config/myapp/gorm','mapping1');
$setup->addRelationConfiguration('config/myapp/gorm','relation1');
$setup->addMappingConfiguration('config/myapp/gorm','mapping2');
$setup->addRelationConfiguration('config/myapp/gorm','relation2');
 
aber an sich ist das wirklich nur ne kleinigkeit und nicht so wichtig. da man das GenericORMapperManagementTool auch als DI-service erstellen kann ist das copy&paste von den anderen serviceobjects.ini eben nicht grade schwer. kann mir auch vorstellen, dass es vielleicht nicht so einfach ist das so zu machen. zumal wie ich hier gelesen habe und auch selbst schon feststellen durfte das GenericORMapperManagementTool noch weit von der perfektion entfernt ist und daher andere sachen da wohl grad wichtiger sind.

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

Re: datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dr.e. » 14.02.2014, 18:45:41

Hallo dingsda,
man kann ja auch sowohl die methoden bereitstellen, die nur die mappings- oder nur die relations-konfiguration hinzufügen als auch die methode die beides zusammen hinzufügt. die alten methoden sollten ja sowieso beibehalten werden wegen rückwärtskompatibilität.
Das ist sicher eine Option.
tatsächlich sind es 10 zeilen code die man pro konfiguration zusätzlich hat ;) . denn nicht nur bei der methode spart man 3 zeilen sondern auch bei der relation/mapping-Section.
ja klar macht man das nur einmal. aber wenn man das vereinfachen kann warum sollte man das nicht machen?
Nicht falsch verstehen, ich bin nicht gegen Verbesserungen! Es geht mir nur darum, den Code übersichtlich und konsistent zu halten. Vorschlag: erstell mal einen Feature-Request mit ein bischen Code-Vorschlag im [ur=http://tracker.adventure-php-framework.org/l]Tracker[/url].
vielleicht hab ich dich missverstanden. es ging doch grade darum dass du meintest dass ich eben genau diese section weglassen kann.
darauf meine antwort in dem teil:
Verstanden. Das passt auch für mich! :)
kann mir auch vorstellen, dass es vielleicht nicht so einfach ist das so zu machen. zumal wie ich hier gelesen habe und auch selbst schon feststellen durfte das GenericORMapperManagementTool noch weit von der perfektion entfernt ist und daher andere sachen da wohl grad wichtiger sind.
Das Tool ist noch nicht 100% fertig - richtig. :D Sofern du Verbesserungen beitragen möchtest immer gerne! Es gibt noch viel zu tun...
Viele Grüße,
Christian

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: datenbanktabellen, GORM, DIServiceManager ect

Beitrag von dingsda » 15.02.2014, 19:37:35

dr.e. hat geschrieben: Nicht falsch verstehen, ich bin nicht gegen Verbesserungen! Es geht mir nur darum, den Code übersichtlich und konsistent zu halten. Vorschlag: erstell mal einen Feature-Request mit ein bischen Code-Vorschlag im Tracker.
Ich werd erstmal so mit dem APF arbeiten und dann nochmal drüber nachdenken. Vielleicht sind so manche wünsche, die ich habe einfach meinem Anfängerstatus geschuldet und nicht wirklich sinnvoll. Die zeit wird es zeigen.
dr.e. hat geschrieben: Das Tool ist noch nicht 100% fertig - richtig. :D Sofern du Verbesserungen beitragen möchtest immer gerne! Es gibt noch viel zu tun...
sobald ich herrausfinde wie das Toll arbeitet werd ich das machen :D

Antworten

Wer ist online?

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