Fragen zum Usermanagement-Modul

Hier finden sich Fragen und Ergänzung zur Dokumentation. // All questions and discussions about the documentation.
Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Fragen zum Usermanagement-Modul

Beitrag von MrNiceGuy » 30.07.2009, 13:21:01

So, nun hatte ich mehrfach versucht das über das obige Beispiel zu handhaben, bin dabei jedoch auf ein Problem gestoßen: Die ID ist immer 1, egal, wieviele User ich hinzufüge. Warum? Das habe ich mich auch gefragt und bei näherer Betrachtung der Quellcodes und einiger Test-Ausgaben musste ich feststellen, dass der GenericORRelationMapper nur die ID des Objekts zurückgibt, das gespeichert wurde und nicht der in relation dazu stehenden Objekte - was ja auch Sinn macht. Die Methode saveUser() jedoch speichert kein Objekt vom Type "User", sondern bastelt das User-Objekt in ein Application-Objekt. Somit funktioniert das leider nicht wie es eigentlich gedacht war :( Schade, aber umso wichtiger finde ich jetzt die Funktion, dass die ID automatisch via Referenz gesetzt wird :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

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

Re: Fragen zum Usermanagement-Modul

Beitrag von dr.e. » 30.07.2009, 21:54:21

Hallo Lutz,
Die ID ist immer 1, egal, wieviele User ich hinzufüge. Warum? Das habe ich mich auch gefragt und bei näherer Betrachtung der Quellcodes und einiger Test-Ausgaben musste ich feststellen, dass der GenericORRelationMapper nur die ID des Objekts zurückgibt, das gespeichert wurde und nicht der in relation dazu stehenden Objekte - was ja auch Sinn macht.
Korrekt. Der GORM gibt bei der Methode saveObject() die ID des gespeicherten Objekts zurück - egal ob es neu erzeugt oder upgedatet wurde. Die in Relation stehenden Objekte werden bei dieser Aktion nicht beachtet, da du ja explizit nur ein Objekt übergibts. Der Rest passiert implizit durch den GORM, der auch Objektbäume auflösen kann.
Die Methode saveUser() jedoch speichert kein Objekt vom Type "User", sondern bastelt das User-Objekt in ein Application-Objekt. Somit funktioniert das leider nicht wie es eigentlich gedacht war :( Schade, aber umso wichtiger finde ich jetzt die Funktion, dass die ID automatisch via Referenz gesetzt wird
Das ist korrekt. Dieses Mapping ist notwendig, damit der Benuter einer Applikation zugeordnet wird. In diesem Fall ist die Implementierung jedoch Blödsinn, denn du wirst nie die ID des Benutzers erhalten (wie oben schon erwähnt). Um die Implementierung zu ändern brauchen wir die neue Funktion. Ich nehme das gleich in meine TODO-Liste auf. Derweilen kannst du dir mit dem diskutierten Workaround behelfen. :(


Viele Grüße,
Christian
Viele Grüße,
Christian

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

Re: Fragen zum Usermanagement-Modul

Beitrag von Screeze » 09.08.2009, 20:06:26

ich glaub ich stell mich grad dumm an...

sry dass ich schon wieder ne frage hab, aaaber....:
Ich versuch grad den login zurechtzubasteln....
Error-ID: ed6bee32267ff47a58eee10c87212054
Message: [Singleton::getInstance()] Class "umgtManager" cannot be found! Maybe the class name is misspelt!
Number: 256
File: E:\xampp\APF\core\singleton\Singleton.php
Line: 63
was mir das sagen will is klar, er findet den umgtManager nicht.

im stacktrace find ich dazu auch
coreObject->__getAndInitServiceObject() E:\xampp\APF\sites\GAME_mainpage\pres\documentcontroller\accountline_controller.php 31
Is logisch, da versuch ichs einzubinden:

das is z 31:

Code: Alles auswählen

$uM = &$this->__getAndInitServiceObject('modules::usermanagement::biz','umgtManager','Default');

1:1 die zeile aus dem beispiel für einen login.

Am namespace muss ich denke ich nichts ändern, wenn ich es im /modules/ Ordner gelassen hab wie es ausgeliefert wurde. konfiguriert isses, ich hab ja gestern schon das backend ausprobiert, das hat komischerweiße auf anhieb funktioniert.

Warum findet er die klasse nicht? hab ich was vergessen einzubinden? ich kann aber nichts was darauf hindeuted finden in der doku oder der beschreibung...

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Fragen zum Usermanagement-Modul

Beitrag von MrNiceGuy » 09.08.2009, 20:59:45

Du musst die Datei vorher per import() manuell einbinden, aktuell ist der Namespace im Quellcode der Methoden get*ServiceObject() nämlich noch als "ignoriert" oder sowas gemarkert. Vielleicht sollte aber angestrebt werden den Import in die Methoden einzubauen!?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

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

Re: Fragen zum Usermanagement-Modul

Beitrag von dr.e. » 09.08.2009, 22:45:58

Hallo zusammen,

an dieser Stelle ist es tatsächlich so, dass die Klasse/Komponente zunächst mit

Code: Alles auswählen

import('modules::usermanagement::biz','umgtManager');
eingebunden werden muss. Das hat den Hintergrund, dass nicht standardmäßig alle Klassen/Komponenten zur Benutzung präsent sind, da die Anwendungen sonst wegen des erheblichen höheren IOs deutlich zu langsam werden würden. In diesem Punkt war jedoch die Doku nicht vollständig, was ist gerade behoben habe. Im Beispiel steht nun das obige Code-Snippet vor der Benutzung der Komponente mit dabei.

Zu diesem Fehler gilt jedoch immer: wenn eine Komponente nicht da ist, einfach per import() einbinden. ;)

Viele Grüße,
Christian
Viele Grüße,
Christian

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

Re: Fragen zum Usermanagement-Modul

Beitrag von Screeze » 09.08.2009, 22:51:54

ahhh danke...
wenn mans weiß isses logisch, aber wenn mans nicht weiß ist man hilflos :lol:

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Fragen zum Usermanagement-Modul

Beitrag von MrNiceGuy » 10.08.2009, 08:01:09

@dr.e: Es ist schon klar, dass es unsinnig wäre alle Komponenten "einfach mal eben so" vorher zu laden, aber warum importieren die Methoden __get*ServiceObject() die nötige Klasse nicht automatisch? Dazu hatte ich zuerst ja auch vermutet, dass der Namespace übergeben wird. Ich fände es praktisch, da ein unnötiger Arbeitsschritt wegfallen würde, denn die Methode bekommt alle nötigen Informationen, die sie bräuchte!?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

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

Re: Fragen zum Usermanagement-Modul

Beitrag von Screeze » 10.08.2009, 09:16:08

MrNiceGuy hat geschrieben:@dr.e: Es ist schon klar, dass es unsinnig wäre alle Komponenten "einfach mal eben so" vorher zu laden, aber warum importieren die Methoden __get*ServiceObject() die nötige Klasse nicht automatisch? Dazu hatte ich zuerst ja auch vermutet, dass der Namespace übergeben wird. Ich fände es praktisch, da ein unnötiger Arbeitsschritt wegfallen würde, denn die Methode bekommt alle nötigen Informationen, die sie bräuchte!?
das wollt ich heut auch nochmal fragen. denn wozu übergebe ich dieser methode den namespace sonst? ich bin mal den methodenaufrufen gefolgt... kann es sein dass der namespace NIE verwendet wird? ich find jedenfalls keine stelle.
ich bin ebenso davon ausgegangen dass diese methode die datei importiert...

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

Re: Fragen zum Usermanagement-Modul

Beitrag von dr.e. » 10.08.2009, 09:20:40

Hallo Lutz,

bequemer ist es definitiv. Das wirkt sich jedoch insofern negativ auf die Performance aus, als dass potentiell __get*ServiceObject() mehrmals in einer Applikation aufgerufen wird und ein import() - weil es include() nutzt - relativ teuer ist. Sofern nur ein import() im Code steht ist das auf jeden Fall schneller. Ich habe in der Vergangenheit mehrfach Tests durchgeführt und mich deshalb dafür entschieden, die Module vom Entwickler selbst einbinden zu lassen, da er auch weiß, was er verwenden will.

@Screeze: der Namespace ist an dieser Stelle vorhanden, da in der Vergangenheit geplant war, den Namespace zur Konfiguration von Service-Komponenten zu nutzen. Dies wurde durch die Einführung von __getDIServiceObject() und dem DIServiceManager obsolet. Effektiv wird der Namespace nicht genutzt, sondern dient nur zur expliziten Benennung der genutzten Komponente.

@all: Ich prüfe aber trotzdem mal im Rahmen des Release 1.11, ob das aus Sicht der Performance verkraftbar ist. Einverstanden?

Viele Grüße,
Christian
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: Fragen zum Usermanagement-Modul

Beitrag von MrNiceGuy » 10.08.2009, 09:27:57

Prüft deine import-Funktion denn nicht vorher, ob die Datei bereits geladen ist? Dann dürfte das doch garnicht so einen "teuren" OH verursachen!? Oder ist es die Prüfung, die die Performance in den Keller reißt?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

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

Re: Fragen zum Usermanagement-Modul

Beitrag von dr.e. » 10.08.2009, 11:26:09

Hi,

die import()-Funktion gibt es genau deshalb. Ich habe hier ein bischen magic getrieben, damit nicht immer include_once() benötigt wird, was unerträglich langsam ist. Was aber trotzdem hinzukommt, ist die Prüfung selbst. Diese ist gut optimiert, so dass es bestenfalls keinen Einfluss haben wird. Wie gesagt: ich prüfe das. Tendenz: es sollte kein Problem sein. Einverstanden? :)

Viele Grüße,
Christian
Viele Grüße,
Christian

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

Re: Fragen zum Usermanagement-Modul

Beitrag von dr.e. » 10.08.2009, 22:57:00

Hallo Lutz,

ich habe mir gerade lokal ein paar Debug-Ausgaben in den Code gebaut. Hier ein kleiner Auszug:

Code: Alles auswählen

start Singleton: 1249937511.9896
end (b) Singleton: 1249937511.9908
start Registry: 1249937511.9909
end (b) Registry: 1249937511.9919
start errorhandler: 1249937511.9921
start ErrorHandlerDefinition: 1249937511.9933
end (b) ErrorHandlerDefinition: 1249937511.9942
end (b) errorhandler: 1249937511.9943
start exceptionhandler: 1249937511.9943
start ExceptionHandlerDefinition: 1249937511.9953
end (b) ExceptionHandlerDefinition: 1249937511.9962
end (b) exceptionhandler: 1249937511.9963
start ServiceManager: 1249937511.9963
end (b) ServiceManager: 1249937511.9974
start DIServiceManager: 1249937511.9974
end (b) DIServiceManager: 1249937511.9988
start configurationManager: 1249937511.9988
end (b) configurationManager: 1249937512.0002
start BenchmarkTimer: 1249937512.0003
end (b) BenchmarkTimer: 1249937512.0022
start FilterFactory: 1249937512.0022
end (b) FilterFactory: 1249937512.0032
start Frontcontroller: 1249937512.0033
end (b) Frontcontroller: 1249937512.0052
start FrontControllerInputFilter: 1249937512.0058
end (b) FrontControllerInputFilter: 1249937512.0067
start FrontcontrollerRewriteRequestFilter: 1249937512.007
start AbstractRequestFilter: 1249937512.0082
end (b) AbstractRequestFilter: 1249937512.0093
end (b) FrontcontrollerRewriteRequestFilter: 1249937512.0094
start generic_taglib_importdesign: 1249937512.0119
start Frontcontroller: 1249937512.0133
end (a) Frontcontroller: 1249937512.0133
end (b) generic_taglib_importdesign: 1249937512.0133
start NavigateAction: 1249937512.0155
start AppModel: 1249937512.0167
end (b) AppModel: 1249937512.0177
start SessionSingleton: 1249937512.0177
start SessionManager: 1249937512.0189
end (b) SessionManager: 1249937512.0199
end (b) SessionSingleton: 1249937512.02
end (b) NavigateAction: 1249937512.02
start NavigateInput: 1249937512.02
end (b) NavigateInput: 1249937512.0211
getServiceObject(test::modules::usermanagement::biz,AppModel)
start AppModel: 1249937512.0213
end (a) AppModel: 1249937512.0213
start GenericOutputFilter: 1249937512.0242
end (b) GenericOutputFilter: 1249937512.0251
start HtmlLinkRewriteFilter: 1249937512.0252
end (b) HtmlLinkRewriteFilter: 1249937512.0264
Man sieht darin, dass das Inkludieren der Klasse AppModel beim ersten Mal 177ms-167ms=10ms dauert, beim zweiten Mal über den ServiceManager stattliche 213ms-213ms = 0ms. Ein paar andere Beispiele zeigen den selben Effekt, so dass ich die Methode getServiceObject() - und damit implizit auch die getAndInitServiceObject() mit einem

Code: Alles auswählen

import($namespace,$serviceName);
ausgestattet habe. Nun ist es nicht mehr notwendig die Komponente vor der Verwendung einzubinden. Einen Hinweis in der Doku ergänze ich gleich noch.

Zum Ausprobieren: die geänderte Datei findet sich unter http://adventurephpfra.svn.sourceforge. ... e/service/.


Viele Grüße,
Christian
Viele Grüße,
Christian

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

Re: Fragen zum Usermanagement-Modul

Beitrag von Screeze » 14.10.2009, 15:23:47

Welche felder kann man beim user object problemlos entfernen?
Sehe ich dass richtig das mindestens folgende Felder enthalten sein müssen?
DisplayName = "VARCHAR(100)"
FirstName = "VARCHAR(100)"
LastName = "VARCHAR(100)"
EMail = "VARCHAR(100)"
Username = "VARCHAR(100)"
Password = "VARCHAR(100)"
Mir würden (von neuen mal abgesehen) von der obigen config nämlich diese reichen:
EMail = "VARCHAR(100)"
Username = "VARCHAR(100)"
Inwieweit krieg ich da probleme?

edit: eigentlich kann ich sogar auf die email verzichten merk ich grad, ich brauch nur den username

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

Re: Fragen zum Usermanagement-Modul

Beitrag von dr.e. » 14.10.2009, 16:49:02

Hi,

sofern du den GORM plain verwendest, reichen dir username/password, solltest du den umgtManager nutzen, sind - gemäß der GUI - Name und Vorname verpflichtend.
Viele Grüße,
Christian

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

Re: Fragen zum Usermanagement-Modul

Beitrag von Megger » 14.10.2009, 19:05:03

Ich benutze bei mir zwar auch nur Username Password und Email, habe den Rest allerdings trotzdem mal drin gelassen. Kann man wunderbar dazu nutzen freiwillige Angaben des Spielers zu speichern.
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 1 Gast