UMGT und eigene Domänen-Objekte

Im Entwickler-Forum können Implementierungsdetails sowie Alternativen der Umsetzung diskutiert werden. // Here, developers can discuss implementation details of features of their projects.
Antworten
Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

UMGT und eigene Domänen-Objekte

Beitrag von Thalo » 07.01.2014, 05:56:08

Hallo,

leider ist der UMGT in Version 1.17 nicht mit den eigenen Domänen-Objekten des GORM zu benutzen. Entweder es gibt Class-Redeclaration-Errors durch den vohrigen import der standard DM in den UMGT-Komponenten (bei gleichen Klassennamen und nur anderen „Namespace“) oder es scheitert an den Type-Hints in den Signaturen.

Ist das vorgesehen? Evtl. wenn das Feature „nativ“ implementiert wird (wie würde man sowas unabhängig von APF-Updates machen?) oder das UMGT auf ein Minimum begrenzt (Username, Password, Salt, Pepper). :)

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von dr.e. » 07.01.2014, 15:31:42

Hallo Thalo,

verstehe ich richtig, dass du das UMGT nutzt und mit deinen eigenen Domänen-Objekten befüllst? Das wird - aus gutem Grund - so nicht funktionieren, da der UmgtManager nur Objekte verwenden kann, die mindestens den Umgt*-Domänen-Objekten entsprechen.

Solltest du eigene Objekte verwenden, so sind diese an die Umgt*-Domänen-Objekte gebunden und müssen mindestens von diesen erben.
Evtl. wenn das Feature „nativ“ implementiert wird (wie würde man sowas unabhängig von APF-Updates machen?) oder das UMGT auf ein Minimum begrenzt (Username, Password, Salt, Pepper). :)
Was meinst du mit "nativ"er Implementierung? Nutzung der PHP-Namespaces?
Viele Grüße,
Christian

Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: UMGT und eigene Domänen-Objekte

Beitrag von Thalo » 07.01.2014, 17:25:15

Hi Doc,

ich meine dieses Feature des GORM: http://adventure-php-framework.org/Seit ... en-Objekte

Edit: Ach, ist es ja schon! :D

Dann wäre es schön, wie oben geschrieben, wenn entweder nicht die DO mitgeliefert werden sondern manuell generiert werden müssen oder zumindest die Basis-Klasse schlanker wäre (Username, Password, Salt, Pepper). :)

Ferner fällt mir auch auf, dass überall noch die Basisklassen (z.B. UmgtRole) importiert (auch z.B. im UmgtManager) werden, das belegt natürlich unnötig RAM wenn sowieso nicht benötigt.

Dass die Pres-Komponenten angepasst werden müssen ist klar aber die Biz-Komponenten sollten doch flexibler gegenüber Änderungen an den DOs sein und das modifizierte DO returnen. :?

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von dr.e. » 07.01.2014, 22:29:03

Hallo Thalo,

verstehe, was du meinst. Die Idee des UMGT ist, eine fertige Anwendung inkl. Administrations-Interface bereit zu stellen und weniger ein Framework dafür. Insofern ist erst mal nicht angedacht, eigene DOs zu unterstützen. Ich stelle mir das auch ehrlich gesagt schwierig vor, denn die Admin-GUI muss sich ja am Ende auf irgendwas verlassen können. :roll:
Ferner fällt mir auch auf, dass überall noch die Basisklassen (z.B. UmgtRole) importiert (auch z.B. im UmgtManager) werden, das belegt natürlich unnötig RAM wenn sowieso nicht benötigt.
Korrekt, das wirkt sich negativ aus. In APF 2.0 ist das jedoch mit dem neuen AutoLoading-Mechanismus gelöst. Selbst wenn die Klasse per use deklariert wird, wird sie nur bei expliziter Verwendung geladen.
Dass die Pres-Komponenten angepasst werden müssen ist klar aber die Biz-Komponenten sollten doch flexibler gegenüber Änderungen an den DOs sein und das modifizierte DO returnen. :?
was du natürlich machen kannst, ist die GORM-Konfiguration des UMGT anpassen und in deinen Anwendungen darauf arbeiten. Die DOs sind ja immer vom GenericDomainObject abgeleitet und du kannst per getProperty()/setProperty() alles abfragen und manipulieren, was du hinzugefügt hast. Sofern du dann noch die *_domainobjects.ini anpasst - natürlich mit den richtigen Basis-Objekten (siehe oben) - dann schaffst du auch eigene DOs zu verwenden. Hast du das schon mal ausprobiert? Sollte klappen. :)
Viele Grüße,
Christian

Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: UMGT und eigene Domänen-Objekte

Beitrag von Thalo » 07.01.2014, 23:31:35

Hallo Doc,
dr.e. hat geschrieben:verstehe, was du meinst. Die Idee des UMGT ist, eine fertige Anwendung inkl. Administrations-Interface bereit zu stellen und weniger ein Framework dafür. Insofern ist erst mal nicht angedacht, eigene DOs zu unterstützen. Ich stelle mir das auch ehrlich gesagt schwierig vor, denn die Admin-GUI muss sich ja am Ende auf irgendwas verlassen können. :roll:
Ist das nicht etwas an der Praxis vorbei? Nicht jede Anwendung benötigt so viele Informationen. Oft genügt ein einfaches Login-Backend. Wenn das UMGT reduziert wird (siehe ersten Post) dann wäre das auch mit dem Administrations-Interface kein Problem und schafft mehr Flexibilität.
was du natürlich machen kannst, ist die GORM-Konfiguration des UMGT anpassen und in deinen Anwendungen darauf arbeiten. Die DOs sind ja immer vom GenericDomainObject abgeleitet und du kannst per getProperty()/setProperty() alles abfragen und manipulieren, was du hinzugefügt hast. Sofern du dann noch die *_domainobjects.ini anpasst - natürlich mit den richtigen Basis-Objekten (siehe oben) - dann schaffst du auch eigene DOs zu verwenden. Hast du das schon mal ausprobiert? Sollte klappen. :)
Das ist mir bewusst. Habe ich aber immer noch in der Datenbank sehr viele unnötige Felder. ;)

Wie haben die anderen das denn gelöst? Bin ich der einzige den das stört?

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von dr.e. » 09.01.2014, 13:30:39

Hallo Thalo,
Ist das nicht etwas an der Praxis vorbei? Nicht jede Anwendung benötigt so viele Informationen. Oft genügt ein einfaches Login-Backend. Wenn das UMGT reduziert wird (siehe ersten Post) dann wäre das auch mit dem Administrations-Interface kein Problem und schafft mehr Flexibilität.
Ich denke, dass das Modul sehr nahe an der Praxis ist, da es inzwischen (fast) alle Anwendungsfälle abdeckt. Darunter fällt auch eine Login-Funktion.

Es ist doch wie mit einem Auto: du kannst mit einem Ferrari mit 250km/h über die Autobahn heizen, musst es aber nicht. Auch wenn du es nicht tust ist es schön einen Ferrari zu fahren. Genauso verhält es sich mit dem UMGT: du kannst die Funktionen nutzen, musst es aber nicht.
Das ist mir bewusst. Habe ich aber immer noch in der Datenbank sehr viele unnötige Felder. ;)
Korrekt, du hast sicher ein paar Felder mehr, die du ggf. nicht brauchst. Allerdings bringt das meiner Ansicht nach keinen nennenswerten Nachteil, da vorhandene Spalten, die nicht gefüllt sind auch keinen Speicherplatz verbrauchen oder die Performance egativ beeinflussen. Auch hier ein Analogon zum Auto: du kannst deine Nebelscheinwerfer verwenden, wenn du es nicht tust hat das für dich erstmal keinen Nachteil. Gut ist es jedoch sie zu haben, denn falls du mal im Nebel steckst, kannst du sie einfach anschalten ohne vorher erst welche einbauen zu müssen. ;)
Wie haben die anderen das denn gelöst? Bin ich der einzige den das stört?
Mein Feedback zum UMGT war bisher: tolles Modul, ich nutze a, b, c aber nicht d, e, f.
Viele Grüße,
Christian

Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: UMGT und eigene Domänen-Objekte

Beitrag von Thalo » 10.01.2014, 05:02:45

Hallo Doc,

grundsätzlich gebe ich dir da recht, gerade bei dem Funktionsumfang. Aber bei den Eigenschaften denke ich doch, dass weniger in diesem Fall mehr ist. :)
Nachteile hat man hier durch nicht.

Ein Kompromiss wäre doch, dass die DOs für das UMGT manuell generiert werden müssen bei Setup. So würde sich das bei einem Update nicht überschreiben wenn man Modifizierungen vornimmt.

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von dr.e. » 11.01.2014, 19:56:29

Hallo Thalo,
Ein Kompromiss wäre doch, dass die DOs für das UMGT manuell generiert werden müssen bei Setup. So würde sich das bei einem Update nicht überschreiben wenn man Modifizierungen vornimmt.
Das ist sicher eine Option. Die Idee des Moduls ist dann jedoch eine andere. Ferner kann sich die Administrations-Oberfläche dann nicht mehr darauf verlassen, was der Anwender in seine Konfiguration einbezieht und was nicht - es kommt unweigerlich zu Fehlern.
Viele Grüße,
Christian

Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: UMGT und eigene Domänen-Objekte

Beitrag von Thalo » 13.01.2014, 03:58:16

Siehst du denn eine andere Möglichkeit? Die Eigenschaften reduzieren wäre keine Option?

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von Coach83 » 13.01.2014, 14:45:31

Ich verstehe Dein Problem nicht ganz, Thalo.. wenn Du doch in deiner Präsentationsschicht einfach die nicht erwünschten Angaben ausblendest, ist doch alles okay. oder?

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von Screeze » 26.01.2014, 01:47:46

Ich versteh ihn durchaus. Habe immer wieder das selbe Problem, und finde es auch recht störend wenn da zig Felder leer bleiben immer, weil ich sie nicht brauche. Aber mir fällt da bisher auch keine sinnvolle andere Lösung ein - außer das ganze komplett neu aufzuziehen und mit seeehr viel dynamik in der GUI zu arbeiten. Das wird kompliziert.

Womit ich ganz gut leben konnte bisher, ist, die DB zu belassen wie sie ist, und in der Gui einfach nicht benötigte Felder einfach nur per CSS auszublenden - zumindest im Backend kann man das gut machen, im Frontend gibts außer dem Login ja eh nicht viel.

Einziger Haken: Wenn man zusätzliche, oder andere Felder benötigt (wie in meinem Fall derzeit ein Benutzerkürzel z.B. und eine Position innerhalb der Firma), dann wird es schwierig. Ich habe mir in diesem Fall damit beholfen, die Sprach-Konfig zu editieren, und einfach 2 nicht benötigte Felder umzulabeln, sie in der DB aber halt mit den alten Bezeichnungen laufen zu lassen. Ist fehleranfällig, aber alles andere ist derzeit etwas umständlich. Vielleicht hat ja jemand mal für die Zukunft *die* Idee wie wir das Umgt flexibler bekommen. (Hatte dann das Problem, dass ich Benutzerkürzel mit 2 Buchstaben zulassen musste, aber alle freien Felder nur minimal 3 als validator gesetzt hatten in der GUI.....)

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

Re: UMGT und eigene Domänen-Objekte

Beitrag von dr.e. » 26.01.2014, 20:40:25

Hallo ihr beiden,

ich sehe das wie bei jedem Feature: wenn jemandem eine bessere Lösung einfällt, dann setzen wir diese auch um. Daher meine Bitte an euch beiden: setzt euch mal zusammen und arbeitet ein Proposal für eine Erweiterung/Verbesserung etc. aus und wir planen das in die kommenden Releases ein.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast