powie.de Tech Forum

Hallo,
ich würde hier gerne des strukturellen Aufbau klären. Es geht darum, wie man das System organisiert. Nutzt man eine in sich geschlossene Architektur oder eine offene modulare Architektur?
Vorteile / Nachteile der geschlossenen Architektur:
+ in sich geschlossen und abgegrenzt
- hoher Aufwand beim Hinzufügen neuer Module bzw. Skripte
- schlecht zu warten und zu aktuallisieren
 
Vorteile / Nachteile der offenen und modularen Architektur:
+ schnelle und reibungslose Installation durch den Benutzter / Enduser, als auch für den Administrator und Entwickler
+ einfache Aktualisierung und Wartung der einzelnen Module
- aufwendiger zu implementieren, als erstere Variante
- Administratorskript muss der Verwaltung angepasst und ausgerüstet sein (nicht unerheblich)

---

Ich würde, wie schon geschrieben, eine modulare Architektur anstreben. Eine gemeinsame Basis für alle Module. Dann eine Art Modulmanager, der es erlaubt neue pModule anzubinden. Dabei sollten sie dann im Ordner ../Modules einen eigenen Unterordner gemäß ihres Namens erhalten. Vielleicht noch mit Version?
Dort sollen ihre genutzten Bibliotheken, Bilder, CSSFiles etc. liegen. Man könnte nun hierbei für jedes Modul einen eigenen Templateordner einbauen. (Speicherung mehrerer Templates möglich?)
=> ../Modules/ModuleName/Templates/administrator
=> ../Modules/ModuleName/Templates/normal
Somit braucht man nur den jeweiligen Moduleordner auszutauschen, wenn man etwas aktuallisieren möchte. Wie man das dann verwalten könnte, das überlasse ich erstmal euch, denn ich bin mir da noch nicht richtig im Klaren darüber. (abgegrenzter Adminbereich?)
 
Strukturell zu dem Aufbau der jeweiligen Skripte möchte ich noch sagen, das es so werden sollte, das alles voneinander getrennt ist. PHP, HTML, CSS. Vielleicht sogar SQL auch noch raus. Vielleicht das funktionelle in die Hauptbibliotheken und dann vielleicht eine Art *Zwischenschicht* für die Anbindung an den HTML Code.
Das wären ersteinmal meine Gedanken dazu. Die Diskussion ist eröffnet /uploads/emoticons/icon_e_smile.gif.4a0acefcb917340d2c82e5239c009e6e.gif\" alt=\":)\" />
 
kOOni

Also ich wäre auch dafür den SQL herauszulösen. Ich habe das Thema gberade @work, dort ist eine Anwendung die mit 3 Datenbanken handhaben muss: DB2, Oracle, mySQL... Einfache Standardqueries sind gleich, aber immer wenn man richtig SQL machen will unterscheiden sich viele viele Dinge zwischen den Systemen.
In der Anwendung werden nur Schlüsselwörter an die SQL\'s übergeben, zum Beispiel Suchbegriffe , Sortierungen oder ähnliches, den strukturellen Aufbau der SQL\'s selbst aber macht man in einer Bibliothek wo alle verwendeten SQL\'s drinstehen. Dabei sties man darauf das man viele viele SQLs immer und immer wieder benutzt... An vielen Stellen immer wieder die selben.

Ich weiß jetzt nicht richtig, wie tief du dich mit in die Codebelange reinhängen möchtest, da du ja geschrieben hast, dass du *nur* organisatorisch mitwirken möchtest. Also ok:
Also was hälst du allgemein davon, die offene und modulare Version zu verfolgen?
 
kOOni
ps.: Wäre schön, wenn hier schon mal die ersten Gedanken geäußert werden. Oder wollt ihr alles im Skype bzw. Teamspeak klären ?

Was spricht gegen bewährte Abstraktionsmechanismen wir PEAR::DB?
Man muss das Rad doch nicht immer neu erfinden...

Damit habe ich mich (leider!) noch nicht auseinander gesetzt. Links? /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />
 
kOOni