Wechsel von 1.14 auf 1.15

Das Forum soll der Ablage von Lösungen für immer wieder auftauchende Problemstellungen dienen. // This forum contains solutions to problems that frequently occur.
Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Wechsel von 1.14 auf 1.15

Beitrag von dave » 19.11.2011, 19:42:59

Ich weiss ja nicht genau, wie es bei den anderen Leuten so aussieht aber um weiter vorran zu kommen, bin ich nun gezwungen, von 1.14 auf 1.15 zu wechseln. Leider kann ich meine bisher verwendete Chart-Libary über jQuery nicht verwenden, da sie zu "dumm" ist und ich muss nun eine PHP-Version einbinden.

Dies möchte ich nun aber gleich vernünftig machen und dazu den DIServiceManager verwenden. Dazu ist jedoch einiges an Vorarbeit für mich nötig.

Das UMGT hat sich ja "völlig" geändert. So gibt es nun einige Config-Dateien mehr. Dabei sind auch Login- und Logout-Provider sowie eine LogoutAction. Wie verhält sich denn nun das ganze, wenn ich weiterhin auf meine Methoden setzen möchte und nicht die neuen Möglichkeiten des UMGT 1.15 nutzen möchte? Ich bin ja gezwungen, die Konfiguration anzugeben, aber ich möchte die ja gar nicht nutzen ;).

Ich habe mich bisher immer davor gedrück, ein Update zu fahren, aber mittlerweile muss ich ja, weil ich sonst mit dem DIServiceManager nicht weiter komme.

Den genauen Vorteil des DIServiceManager kann ich auch noch nicht so ganz nachvollziehen. Ok, ich kann den Service ganz einfach via

Code: Alles auswählen

$umgt = &$this->getDIServiceObject('modules::usermanagement::biz', 'UmgtManager'); 
beziehen. Schaue ich mir allerdings die Konfiguration dazu an, erschlägt es mich! Da nutze ich doch lieber die etwas längere Variante

Code: Alles auswählen

$uM = &$this->getAndInitServiceObject('modules::usermanagement::biz', 'UmgtManager', 'Default'); 
blicke aber komplett durch und mache weniger Fehler bei der Konfiguration.

Mir ist die Vorgehensweise auch noch nicht klar, wie ich nun einen neuen Service für meinen Anwendungsfall der Diagramm-Erstellung mit einer externen Klasse und dem GORM via DIServiceManager realisiere. Aber eins nach dem anderen ;) ....

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

Re: Wechsel von 1.14 auf 1.15

Beitrag von dr.e. » 19.11.2011, 20:03:16

Hi dave,

die notwendigen Schritte zur Migration auf 1.15 werden hier erklärt.

Solltst du noch weitere Fragen dazu haben, melde dich einfach. :) Vielleicht wirst du mit der Zeit und einigen weiteren Erläuterungen den DIServiceManager irgendwann lieben...
Viele Grüße,
Christian

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: Wechsel von 1.14 auf 1.15

Beitrag von dave » 19.11.2011, 20:36:49

Hi, die Migration habe ich natürlich schon gesehen und dadurch bin ich erst auf diese vielen neuen Configs fürs UMGT gestossen.

Ich werde einfach mal beginnen und mich bei Problemen hier wieder melden.

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: Wechsel von 1.14 auf 1.15

Beitrag von dave » 19.11.2011, 22:14:49

Hier mal nach und nach die Probleme, die bei mir auftreten um diese dann vllt. auch in der Migration zu ergänzen :)

HTML-Header:
  • Es wird eine DEAFULT_actionconfig.ini erwartet
  • Anschliessend wird eine DEFAULT_JsCssInclusion.ini im Verzeichnis "biz" erwartet
Usermanagement:
Vorneweg: Die Migrations-Doku ist Spitze! Selbst die späteren Anmerkungen bezüglich des GDO statt des erwarteten Typs UmgtUser etc. sind eingetreten. Da ich es aber zuvor komplett gelesen habe, wusste ich Bescheid.
  • Nach dem Update des Daten-Modells lief es immer noch nicht. Grund: ServiceTyp des UmgtManager sowie des GORM auf SESSIONSINGLETON. Dies auf SINGLETON geändert, was in meiner Testversion sowie grundsätzlich der Fall ist, und es klappte! Dies vllt. auch noch im entsprechenden Absatz, wo auf den möglichen Fehler eingegangen wird, kurz erwähnen.
  • Die Assoziations-Tabelle ass_role2permission bzw. die Relation Role2Permission muss manuell erzeugt werden. Dazu muss die *umgt_relations.ini erweitert werden und ein Datenbank-Update mit dem GORM durchgeführt werden. Die Config sollte um folgendes erweitert werden:

    Code: Alles auswählen

    ;
    ; Definition of the association between Role and Permission
    ;
    [Role2Permission]
    Type = "ASSOCIATION"
    SourceObject = "Role"
    TargetObject = "Permission"
  • Die Assoziations-Tabelle ass_role2group bzw. die Relation Role2Group muss manuell erzeugt werden. Dazu muss die *umgt_relations.ini ebenfalls erweitert werden.

    Code: Alles auswählen

    [Role2Group]
    Type = "ASSOCIATION"
    SourceObject = "Role"
    TargetObject = "Group"
  • Es sind eine ganze Menge Methoden weg gefallen bzw. haben sich deren Namen teilweise verändert.

    assignRole2Users() ist nun attachUser2Roles()! Die Verwendung hat sich dabei auch etwas geändert. Der Methode wird nun ein Array der Rollen übergeben (vorher Array der User), welche dem User zugeweisen werden sollen. Die Assoziation Role2User bleibt erhalten.
To Be continued ...
Zuletzt geändert von dave am 01.02.2012, 19:52:45, insgesamt 3-mal geändert.

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

Re: Wechsel von 1.14 auf 1.15

Beitrag von dr.e. » 20.11.2011, 13:46:59

Danke für dein Feedback! Wenn du deine Erfahrungen aufgeschrieben hast, kann ich diese ins Wiki übernehmen. Alternativ kannst du sie auch gleich dorthin posten, dann müssen wir das nich zweimal tun.
Viele Grüße,
Christian

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: Wechsel von 1.14 auf 1.15

Beitrag von dave » 20.11.2011, 18:12:18

Jo, ich ergänze das dann im Wiki ... und hier mache ich es, weil der Thread-Titel so gut passt und man vllt. noch eher ins Forum als ins Wiki schaut :). Ich mache mir damit ja kaum Mejrarbeit ... Copy und Paste lässt grüssen 8-)

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

Re: Wechsel von 1.14 auf 1.15

Beitrag von dr.e. » 20.11.2011, 18:14:03

Einverstanden! :)
Viele Grüße,
Christian

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: Wechsel von 1.14 auf 1.15

Beitrag von dave » 20.11.2011, 18:49:17

dr.e. hat geschrieben:Einverstanden! :)
Cool ;)


Jetzt bin ich an einem Punkt angelangt, an dem ich nicht mehr weiter komme. Ich habe manuell die Option integriert, einenm Bestätigungslink zu folgen und somit seine Registrierung zu bestätigen. Dies habe ich realisiert, indem ich im Controller zur Registrierung und zum Login den GORM mit integriere und via

Code: Alles auswählen

loadRelatedObject($user, 'Activation2User') 
den Aktivierungstatus beispielsweise auslese.

Dies funktioniert nun jedoch nicht mehr, weil es sich beim Objekt $user nicht um ein Object des Typs GenericDomainObject handelt. Gleiches auch bei setDataComponent().

Wie kann ich das nun umgehen bzw. elegant lösen?

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

Re: Wechsel von 1.14 auf 1.15

Beitrag von dr.e. » 21.11.2011, 00:09:59

Hallo dave,

das verstehe ich nicht ganz. Die Signaturen sind doch

Code: Alles auswählen

abstract class UmgtUserBase extends GenericDomainObject  {
}

class UmgtUser extends UmgtUserBase {
} 
Insofern kannst du doch die beiden Methoden direkt auf dem Objekt anwenden, sofern die Instanz den GORM kennt. Hast du's mal versucht? Kennt deine aktuelle GORM-Instanz die Beziehung zur Activation? Falls nicht, kannst du das ganz einfach in dier DI-Konfiguration hinzufügen ohne, dass das UMGT das mitbekommt.
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Wechsel von 1.14 auf 1.15

Beitrag von Megger » 21.11.2011, 11:42:28

Kann es sein, dass du den User aus der UmgtUserSession holst? Da ist mir nämlich auch schon aufgefallen, dass man die entsprechende Datenkomponente wieder hinzufügen muss.
Den genauen Vorteil des DIServiceManager kann ich auch noch nicht so ganz nachvollziehen. Ok, ich kann den Service ganz einfach via

Code: Alles auswählen

$umgt = &$this->getDIServiceObject('modules::usermanagement::biz', 'UmgtManager');  
beziehen. Schaue ich mir allerdings die Konfiguration dazu an, erschlägt es mich! Da nutze ich doch lieber die etwas längere Variante

Code: Alles auswählen

$uM = &$this->getAndInitServiceObject('modules::usermanagement::biz', 'UmgtManager', 'Default');  
blicke aber komplett durch und mache weniger Fehler bei der Konfiguration.
Die Konfiguration ist manchmal wirklich ziemlich kompliziert. Zum Beispiel auch wenn man den Gorm mit ein paar weiteren Relations und Mappings ausstatten will, dann kann dies schnell ziemlich lang werden. Ich habe es mir aber inzwischen angewöhnt, nur noch eine zentrale serviceobjects.ini zu führen, sodass ich per

Code: Alles auswählen

$umgt = $this->getDIServiceObject('megger', 'usermanager');
$gorm = $this->getDIServiceObject('megger', 'gorm');
 
darauf zugreifen kann. Das ist in meinen Augen ein ziemlicher Vorteil, da der Namespace sich nicht mehr 'ändert'.

Code: Alles auswählen

[gorm]
...
init.rel_event.method = "addDIRelationConfiguration"
init.rel_event.namespace = "megger"
init.rel_event.name = "gorm-conf-relation-event"
init.map_event.method = "addDIMappingConfiguration"
init.map_event.namespace = "megger"
init.map_event.name = "gorm-conf-mapping-event"

[gorm-conf-relation-event]
servicetype = "NORMAL"
namespace = "modules::genericormapper::data"
class = "GenericORMapperDIRelationConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "megger"
conf.affix.method = "setConfigAffix"
conf.affix.value = "event"

[gorm-conf-mapping-event]
servicetype = "NORMAL"
namespace = "modules::genericormapper::data"
class = "GenericORMapperDIMappingConfiguration"
conf.namespace.method = "setConfigNamespace"
conf.namespace.value = "megger"
conf.affix.method = "setConfigAffix"
conf.affix.value = "event"
Und wenn man nun bedenkt, dass man 10 weitere Relations und Mappings hat, kann man leicht mal den Überblick verlieren
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

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

Re: Wechsel von 1.14 auf 1.15

Beitrag von dr.e. » 21.11.2011, 13:38:16

Hallo Tobi,
Kann es sein, dass du den User aus der UmgtUserSession holst? Da ist mir nämlich auch schon aufgefallen, dass man die entsprechende Datenkomponente wieder hinzufügen muss.
Im UMGT: ja. Der UmgtUserSessionStore ist exakt dazu vorgesehen.
Das ist in meinen Augen ein ziemlicher Vorteil, da der Namespace sich nicht mehr 'ändert'.
Für eigene Applikationen kannst du das gerne so handhaben, für das Umgt sind die Namespaces schon vorgegeben (=Modul-Namespace).

Oder war dein Post garnicht auf meinen bezogen?
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Wechsel von 1.14 auf 1.15

Beitrag von Megger » 21.11.2011, 14:53:16

Für eigene Applikationen kannst du das gerne so handhaben, für das Umgt sind die Namespaces schon vorgegeben (=Modul-Namespace).
Ja ist eher ein Beispiel dafür wie ich es mache, da ich die *serviceobjects.ini des Usermanagements nicht nutze (zumindestens nicht um den UmgtManager zu beziehen), sondern eine eigene zentrale *serviceobjects.ini habe. Das ist allerdings noch mein Vorgehen aus 1.14 Zeiten.
Im UMGT: ja. Der UmgtUserSessionStore ist exakt dazu vorgesehen.
Momentan ist halt soetwas nicht möglich

Code: Alles auswählen

$userObject = $umgtUserSessionStore->getUser($this->getContext());
$roleList = $userObject->loadRelatedObjects('Role2User');
 
Man muss vor 'loadRelatedObjects' erst wieder eine Datenkomponente setzen
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: Wechsel von 1.14 auf 1.15

Beitrag von dave » 21.11.2011, 17:24:48

Ich melde mich dazu in 2-3 Tagen ... muss leider erstmal weg fahren ;)

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

Re: Wechsel von 1.14 auf 1.15

Beitrag von dr.e. » 21.11.2011, 23:15:08

@Tobi: das ist korrekt, die Komponente ist nicht komplett serialisierbar (theoretisch jedoch schon, wenn alle als SESSIONSINGLETON vom DIServiceManager bezogen werden). Das könnte man jedoch theoretisch einfach dadurch sicherstellen, dass das Serializing angepasst wird.

@dave: alles klar, erhol dich gut!
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Wechsel von 1.14 auf 1.15

Beitrag von Megger » 22.11.2011, 11:35:43

@Tobi: das ist korrekt, die Komponente ist nicht komplett serialisierbar (theoretisch jedoch schon, wenn alle als SESSIONSINGLETON vom DIServiceManager bezogen werden). Das könnte man jedoch theoretisch einfach dadurch sicherstellen, dass das Serializing angepasst wird.
Habe gedacht Datenbankverbindungen kann man nicht serialisieren? o.O
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Antworten

Wer ist online?

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