Anregungen - Unterstützung

waja · Beitrag von **waja** » 22. Sep 2009, 15:57

Hallo liebes Admidio-Team,

und erstmal ein dickes Lob von mir für dieses tolle Projekt. Da ich in mehreren Vereinen aktiv bin, habe ich lange nach einer Open-Source Lösung für eine Mitglieder-(Selbst-)Verwaltung gesucht, und alle mögliche Groupwares und ähnliche getestet, und ich muss zugeben dass Admidio die schlankeste und einfachste Lösung war, die meine Anforderungen entsprach. Einfach zu konfigurieren, zu bedienen, sehr übersichtlich, modular, so dass man alles nach dem Prinzip "What You See Is What You Need" gestalten kann.

Ich habe mir auch den Quellcode angeschaut, und das finde ich sehr übersichtlich, und einfach anpassbar. Mir fehlten allerdings folgendes :

Eine Abstrahierung der Datenhaltungsschicht : So könnte man theoretisch das Datenbanktyp ändern, oder Benutzerdaten aus anderen Systemen holen, um Redundanzen zu vermeiden. Es wird teilweise durch die Klasse "TableAccess" gemacht, ich finde allerdings viele andere Klassen (unter "adm_program/system/classes/table_*" und sonst überall in den einzelnen Modulen), die direkt mit der Datenbank kommunizieren.
Eine Trennung zwischen Präsentations- und Anwendungsschicht : Das wird schon durch die "Themes" gemacht. Die Datei "adm_program/system/message_text.php" wäre auch ein gutes Beispiel für die Trennung. Das ist allerdings schade dass die Datein "adm_program/system/message_text.php" und "adm_program/system/common.php" oder "adm_program/system/logout.php" im selben Verzeichnis sind, da sie eigentlich total verschiedene Aufgaben implementieren. Ein ganz schlechtes Beispiel ist die Datei "adm_program/modules/mail/mail.php" die gleichzeitig SQL-Anfragen, Anwendungslogik und HTML-Ausgaben beinhaltet...
- Man hat eben öfters den Bedarf, die Grafische-Oberfläche, Texte, Fehlermeldungen usw... anzupassen. (Wie ein Formular, eine Liste, ein Profil aussieht, lieber Popup-Fenster oder Thickboxes...). Und wenn man so viele Anpassungen in verschiedene Verzeichnisse und Dateien vornimmt, wird ein Upgrade in die nächste Version sehr erschwert.
- Durch eine Trennung könnte man die Software auch sehr einfach in eine andere Sprache übersetzen, und trotzdem upgraden können.

Allerdings haben mir einige Features gefehlt, die ich hier erstmal auflisten werde, bzw. ggf. später einzelne Threads drüber eröffnen.

Ein neues Modul für Todos : Ähnlich wie im Trac-Projekt sollten die Benutzer Aufgaben im Rahmen eines Projekts (Rolle) an andere Benutzer vergeben können, und danach kontrollieren. Eine Aufgabe hat also ein "Reporter" ein "Owner" und eine "Deadline" und bezieht sich auf eine Rolle. Der Benutzer hat ein Übersicht über die von ihm "owned", "reported" Aufgaben, und die von seinen Rollen. Deadlines könnten im Kalender ausgezeichnet werden. Wer Aufgaben für wen vergeben darf, sollte man bestimmen.
Authentifizierung gegen LDAP : So könnte man die Zugangsdaten mit anderen Systemen (z.B. pop3/smtp, ftp, ssh, samba...) koordinieren.
Verwaltung der Mitgliederbeiträge : Eine berechtigte Rolle kann melden, wenn ein Mitglied sein Beitrag bezahlt hat. Wenn eine bestimmte Deadline überschritten wird, werden die Mitglieder die noch nicht bezahlt haben in eine andere Rolle automatisch verschoben und benachrichtigt (ehemalige Mitglieder). Die berechtigte Rolle hat die Übersicht drüber, wer, wann und was gezahlt hat.
Integration in anderen CMS wie typo3 oder Drupal.
Schreibe und Leserechte trennen in Downloads, Fotogalerien, Ankündigungen und Termine.
Zugriffsrechte an Rollen binden : für Fotogalerien (wie in Downloads) und für Termine und Ankündigungen (man kann dann bestimmen, für welche Rollen die Ankündigungen angezeigt werden, und wie für Listen und Emails, ob jederAnkündigungen/Termine für eine Rolle hinzufügen kann, oder nur Rollenmitglieder, oder niemand?)
Zugriffsrechte fein-granular bearbeiten : Für Email, Listen, Termine, Ankündigung. Man hat (bzw. hätte für Termine und Ankündigung) ja nur die Auswahl zwischen {niemand, rollenmitglieder, alle} mit einer Ausnahme für "superuser". Besser wäre wenn man für jede Rolle bestimmt, an welche andere Rollen Emails schreiben darf, die Liste von welchen anderen Rollen anschauen darf, die Termine/Ankündigungen von welchen anderen Rollen bearbeiten kann. So hätten wir für jedes Modul eine Matrix von Zugriffsrechten. Und wenn man eine Rolle "A" anlegen möchte bestimmt man zum Beispiel :
- An welche andere Rollen darf die Rolle A schreiben : [_] A ; [_] B ; [_] C ; [_] D
- Von welchen anderen Rollen darf die Rolle A angeschrieben werden : [_] A ; [_] B ; [_] C ; [_] D

Einige Erweiterungen werde ich auf jedem Fall brauchen (wie z.B. 1, 2 und 3) und werde ich ggf. selber implementieren. Ich habe allerdings gesehen (in den Feature-Requests in Source-Forge und hier im Forum), dass die Entwicklung in eine Richtung die einige Punkte oben lösen werden. Meine Fragen an das Admidio-Team wären, in wieweit selbst-entwickelte Erweiterungen in das Hauptprojekt integriebar wären? Gibts schon eine Roadmap für das Projekt wo man sehen kann was schon geplant ist, um eventuell doppelte Arbeit zu sparen. Ist die Softwarearchitektur der Anwendung irgendwo dokumentiert? (ich habe im Wiki nur die Programmierrichtlinien gefunden)

Gruß
Wassim

Jochen · Beitrag von **Jochen** » 7. Okt 2009, 17:06

Hallo Wassim,

entschuldige die späte Antwort, momentan haben irgendwie alle in ihrem sonstigen Leben was viel zu tun.

Zu a und b, dass ist sicherlich auf lange Sicht auch unser Ziel.

3. 5. und 6. sind in Planung

An sauber programmierten Lösungen die Admidio verbessern sind wir immer interessiert. Unser Chefentwickler ist momentan leider nicht im Lande vielleicht nimmst Du mal mit ihm direkt Kontakt auf. An der Typo3Integration hätte ich auch selbst Interesse.

Gruß Jochen

Beitrag von **fasse** » 17. Okt 2009, 12:35

Hallo Wasim,

noch ein paar Anmerkungen zu a und b:

zu a: ein wenig haben wir da schon was in diese Richtung getan. Der direkte Zugriff auf die DB erfolgt über die MySQL-Klasse, welche dann durch eine andere DB-Klasse ersetzt werden kann. Natürlich ist das nur der Anfang, da manche SQL-Syntax MySQL-Spezifisch ist und dann auch angepasst werden müsste. Hier wäre es aber dann sinnvoll notwendige Änderungen in der bisherigen Struktur zu implementieren, wenn sich jemand finden würde, der eine Anbindung an eine andere DB implementieren will.

zu b: deine beschriebene Trennung wäre natürlich auch für uns das Ziel. Allerdings ist Admidio aus einer kontreten Webseitenimplementierung entstanden und hat sich erst einmal ohne diese Trennung weiterentwickelt. Im Moment sind wir aber alle so mit anderen Dingen beschäftigt, dass so eine tiefgreifende Veränderung im Moment noch bei keinem von uns auf der ToDo-Liste steht. Falls sich hier jemand finden würde, der evtl. bereits Erfahrung mit Smarty oder ähnlichem hat, ist er natürlich herzlich willkommen. Einen kleinen Schritt wollen wir aber schon in der nächsten Version gehen. Dann sollen die Texte schon mal in einer xml-Datei gesammelt werden und aus den einzelnen Dateien verschwinden, so dass Übersetzungen möglich sind.

Viele Grüße
Fasse

Szabolcs · Beitrag von **Szabolcs** » 4. Nov 2009, 02:42

Hallo,

zu Punkt b: daran hätte ich auch sehr starkes Interesse, da wir einen internationalen Verein haben, mit mindestens 3 Sprachen.

Ein XML-Datei wäre jedenfalls sehr nützlich, denn dann könnten wir die Übersetzung selbst vornehmen, die wir natürlich gegebenenfalls auch zur Verfügung stellen könnten. Womöglich ist meine kommende Frage irritierend, aber kann denn mit dem selben Aufwand wie für eine XML-Datei nicht direkt eine .po/.mo basierte Übersetzungsmöglichkeit geschaffen werden?

Was natürlich ein Trumpf wäre, wenn die User nach Sprachen geordnet werden könnten, um somit nach dem Einloggen direkt die eigene Sprachdatei aufrufen zu können, in der eigenen Sprache.

Ansonsten kann ich nur ein großes Danke schön sagen, im Name des gesamten Vereins.

Szabolcs
Budapest

fasse hat geschrieben:Hallo Wasim,

noch ein paar Anmerkungen zu a und b:

zu a: ein wenig haben wir da schon was in diese Richtung getan. Der direkte Zugriff auf die DB erfolgt über die MySQL-Klasse, welche dann durch eine andere DB-Klasse ersetzt werden kann. Natürlich ist das nur der Anfang, da manche SQL-Syntax MySQL-Spezifisch ist und dann auch angepasst werden müsste. Hier wäre es aber dann sinnvoll notwendige Änderungen in der bisherigen Struktur zu implementieren, wenn sich jemand finden würde, der eine Anbindung an eine andere DB implementieren will.

zu b: deine beschriebene Trennung wäre natürlich auch für uns das Ziel. Allerdings ist Admidio aus einer kontreten Webseitenimplementierung entstanden und hat sich erst einmal ohne diese Trennung weiterentwickelt. Im Moment sind wir aber alle so mit anderen Dingen beschäftigt, dass so eine tiefgreifende Veränderung im Moment noch bei keinem von uns auf der ToDo-Liste steht. Falls sich hier jemand finden würde, der evtl. bereits Erfahrung mit Smarty oder ähnlichem hat, ist er natürlich herzlich willkommen. Einen kleinen Schritt wollen wir aber schon in der nächsten Version gehen. Dann sollen die Texte schon mal in einer xml-Datei gesammelt werden und aus den einzelnen Dateien verschwinden, so dass Übersetzungen möglich sind.

Viele Grüße
Fasse