[1.15] Umgt

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

[1.15] Umgt

Beitrag von dr.e. » 24.08.2011, 19:47:35

Hallo Tobi,

ich bin gerade dran, die Umstellung des UMGT komplett auf DIServiceManager vorzunehmen. Ein Punkt, der aktuell etwas stört ist die Übergabe der Konfigurations-Sektion an den UmgtManager und die PasswordHashProvider. Aktuell wurde hier ohnehin immer "Default" als Wert gesetzt, insofern denke ich, dass wir diesen einfach entfernen können. Einverstanden?

@all: wird bei euch der UmgtManager in mehreren Instanzen genutzt?
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [1.15] Umgt

Beitrag von Screeze » 24.08.2011, 19:53:55

Ich glaube zwar du meintest mich mit dem DIServiceManager, aber egal ;)
@all: wird bei euch der UmgtManager in mehreren Instanzen genutzt?
Nope.

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

Re: [1.15] Umgt

Beitrag von Megger » 24.08.2011, 19:59:45

Also mehrere Instanzen habe ich bisher auch noch nicht genutzt, aber wie läuft das dann in Zukunft mit mehreren PasswordHashProvidern ab?
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: [1.15] Umgt

Beitrag von dr.e. » 24.08.2011, 20:05:50

Hmm, ich hatte im Code nur

Code: Alles auswählen

@author Tobias Lückel
gefunden. :roll: :)
Nope.
OK, ist ohnehin viel eleganter.
Also mehrere Instanzen habe ich bisher auch noch nicht genutzt, aber wie läuft das dann in Zukunft mit mehreren PasswordHashProvidern ab?
Die PasswordHash-Provider verhalten sich wie zuvor auch. Es geht lediglich darum, wie der UmgtManager und die PasswordHash erzeugt werden.

OK, dann refactore ich das und melde mich mit einem kurzen HOWTO für die Umstellung.
Viele Grüße,
Christian

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

Re: [1.15] Umgt

Beitrag von Megger » 24.08.2011, 20:20:20

Achso ja! Es geht also gar nicht wirklich um den Inhalt der Config Datei :D
Ich habe irgendwann mal die Möglichkeit mit den mehreren PasswordHashProvidern eingebaut, aber Screeze hat das ganze nochmal überarbeitet
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: [1.15] Umgt

Beitrag von dr.e. » 24.08.2011, 20:26:50

Jep, das funktioniert aber alles wie gehabt (schon bei mir lokal). :)
Viele Grüße,
Christian

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

Re: [1.15] Umgt

Beitrag von dr.e. » 25.08.2011, 22:26:24

Ich revidiere: es gibt noch einige komische Effekte mit der Initialisierung der PasswortHashProvider. Diese werden manchmal richtig deserialisiert und manchmal nicht. Den Grund finde ich jedoch noch heraus. :D
Viele Grüße,
Christian

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

Re: [1.15] Umgt

Beitrag von dave » 25.08.2011, 22:47:51

dr.e. hat geschrieben:@all: wird bei euch der UmgtManager in mehreren Instanzen genutzt?
Was meinst du genau damit? Hast du ein kleines Beispiel zur Erläuterung parat?

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

Re: [1.15] Umgt

Beitrag von dr.e. » 25.08.2011, 22:53:07

Hi dave,

der Manager wurde im Code bisher nur per

Code: Alles auswählen

$umgt = &$this->getServiceAndInitObject('modules::usermanagement::biz', 'UmgtManager', 'Default'); 
bezogen. "Default" ist dabei der Name der Konfigurations-Sektion. Die Frage ist nun, ob du mehrere dieser Instanzen beispielsweise mit

Code: Alles auswählen

$umgtOne = &$this->getServiceAndInitObject('modules::usermanagement::biz', 'UmgtManager', 'Default');
...
$umgtTwo = &$this->getServiceAndInitObject('modules::usermanagement::biz', 'UmgtManager', 'Foo'); 
nutz. Falls nicht - und davon gehe ich aus - passt meine Vorgehensweise.
Viele Grüße,
Christian

Coach83
Beiträge: 271
Registriert: 13.05.2010, 17:33:12
Kontaktdaten:

Re: [1.15] Umgt

Beitrag von Coach83 » 26.08.2011, 06:27:13

Nun, ich habe mir das Ganze etwas umgeschrieben - ich nutze das mit meinem eigenen Context - und musste daher auch eine config-Datei anpassen (die mit Default eingebunden wird)

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

Re: [1.15] Umgt

Beitrag von dave » 26.08.2011, 16:16:29

dr.e. hat geschrieben:Falls nicht - und davon gehe ich aus - passt meine Vorgehensweise.
Dabei gehst du (bei mir) vom völlig richtigen aus :). Danke für die schnelle Erläuterung! So kann auch ich es verstehen ;)

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

Re: [1.15] Umgt

Beitrag von dr.e. » 26.08.2011, 17:40:49

Hallo Coach,

kannst du mal deinen Code hierzu posten? Kommt es dir entgegen, dass der UmgtManager zukünftig komplett per Di bezogen wird?

@dave: ok, dann passt das auch für dich. :)
Viele Grüße,
Christian

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

Re: [1.15] Umgt

Beitrag von dr.e. » 27.08.2011, 15:42:00

Hallo zusammen,

die notwendigen Änderungen (es dann doch mehr Code-Changes erforderlich als vermutet) sind nun in das SVN integriert. Die Migration auf die neue Version ist unter http://wiki.adventure-php-framework.org ... 4_auf_1.15 beschrieben. Im SVN finden sich zudem alle notwendigen Beispiel-Konfigurationsdateien.

Welche Änderungen habe ich durchgeführt?
  • UmgtManager: Der UmgtManager kann nun nur noch über den DIServiceManager bezogen werden. Damit entfallen einige Konfigurations-Attribute in der Konfiguration, die über die Service-Objekt-Konfiguration injiziert werden. Hierzu zählt die ApplicationId und der GORM.
  • DIServiceManager: Der DIServiceManager wurde dahingehend erweitert, dass er einen Service per eigener Methode initialisieren kann. Hierzu kann das Attribut "setupmethod" den Namen derjenigen Methode enthalten, die für die Initialisierung des Objektes nach der Injizierung aller Konfigurations-Attribute und abhängigen Services ausgeführt wird. Das Konzept mag ähnlich der ServiceManager::getAndInitServiceObject()-Methode klingen, hat jedoch einen Vorteil: die Initialisierung per init() wurde bei jedem Bezug des Objektes über den ServiceManager (auch innerhalb eines Requests) ausgeführt. Ein APFDIService (neues Interface!) besitzt dagegen zur Steuerung das Attribut isInitialized und die Methode isInitialized() mit der der DIServiceManager den Status der Initialsierung abfragen kann. Hiermit ist es nun möglich, eine Initialisierung mehrmals pro Request (Status wird auf false belassen), einmal pro Request (Status wird nach erster Ausführen auf true gesetzt, das Attribut jedoch nicht serialisiert) oder einmal pro Session (Attribut wird nach erster Ausführung auf true gesetzt und serialisiert).
  • GORM: Der O/R-Mapper kann nun sauber per DI-Container bezogen werden. Dies war in 1.14 nur mit einem Workaround möglich, da der Aufbau der Datenbank-Connection in der Methode setConnectionName() versteckt wurde. Mit der "setupmethod"-Implementierung des DIServiceManager passiert dies nun deterministisch nach dem Erzeugen des Objekts.
  • GORM II: Die Klasse GenericORMapperDIConfiguration wurde entfernt, da die Initialsierung des O/R-Mapper nun nativ per DI-Container mit den entsprechenden setter-Methoden erfolgt. Die Klassen zum Update der Konfiguration (zusätzliche Mappings: GenericORMapperDIMappingConfiguration; zusätzliche Beziehungen: GenericORMapperDIRelationConfiguration; zusätzliche Domänen-Objekte: GenericORMapperDIDomainObjectsConfiguration) wurden beibehalten.
Ich habe die Änderungen in meinen Projekten lokal umfassend getestet und bisher keine Fehler endecken können. Sofern ihr ein paar Minuten Zeit habt, würde ich mich über Feedback freuen.
Viele Grüße,
Christian

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

Re: [1.15] Umgt

Beitrag von dr.e. » 02.09.2011, 07:38:55

Hallo zusammen,

hat sich schon jemand die neue Art der Konfiguration angesehen? Gibt es Probleme mit dem GORM/UmgtManager?

In der Zwischenzeit habe ich mich mit der GUI-Struktur des UMGT auseinander gesetzt und diese ein wenig aktualisiert. Folgende Grafiken zeigen die einzelnen Main-Views mit den deutlich erweiterten Möglichkeiten der Verwaltung dar. Ich habe jeweils Icons für die einzelnen Daten-Typen eingeführt und diese in den möglichen Aktionen auf einen Datensatz wiederholt. Mehrfach-Auswahl ist noch nicht implementiert, soll aber noch folgen. Hier die Screens im Detail:

Benutzer:
umgt_1_15_user.jpg
umgt_1_15_user.jpg (34.86 KiB) 1928 mal betrachtet
Gruppen:
umgt_1_15_group.jpg
umgt_1_15_group.jpg (26.61 KiB) 1928 mal betrachtet
Rollen:
umgt_1_15_role.jpg
umgt_1_15_role.jpg (37.35 KiB) 1928 mal betrachtet
Funktions-Berechtigungen:
umgt_1_15_permission.jpg
umgt_1_15_permission.jpg (28.4 KiB) 1928 mal betrachtet
Sichtbarkeits-Berechtigungen:
umgt_1_15_proxy.jpg
umgt_1_15_proxy.jpg (62.81 KiB) 1928 mal betrachtet
Bitte um Feedback!
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [1.15] Umgt

Beitrag von Screeze » 02.09.2011, 09:09:26

Ich werde mir das nach meinem Urlaub ansehen, aber einen Vorschlag zum Backen habe ich noch:
Da in Kundenprojekten oft nicht alle Funktionen verwendet werden, wäre es sinnvoll per config Datei zu definieren welche menüpunkte überhaupt angezeigt werden sollen, und welches die 'startseite' des moduls ist.

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast