ich habe jetzt ein bisschen herumgeschaut und so wie ich es verstanden habe, will das ZF Doctrine sowieso einbinden, statt Zend_Entity weiterzuführen.

Hier ein paar Links:

http://www.danceric.net/2009/10/29/doct … -friendly/
http://n4.nabble.com/Discontinuing-Zend … 48011.html
http://framework.zend.com/wiki/display/ … in+Eberlei
http://www.doctrine-project.org/documen … troduction

Habe mich dann noch etwas bei Doctrine umgesehen und bin jetzt noch fester als vorher davon überzeugt, dass wir Doctrine bei uns benutzen sollten.

Doctrine baut auf dem Active-Record-Pattern auf ( http://en.wikipedia.org/wiki/Active_record_pattern ) und wie in der Doku schon geschrieben wurde: "[...] we also admit that the ActiveRecord approach is certainly not suited for complex business logic (which is often approached using Domain-Driven Design) as it simply puts too many restrictions and has too much influence on your domain model." Ist das für uns ein Problem? Ich denke nicht. Unser Modell ist nämlich nicht komplex. "Note that complexity != size. A domain model can be pretty large without being complex and vice versa. Obviously, larger domain models have a greater probability of being complex." Das trifft es imho. Wenn wir uns bemühen, können und sollten wir das Domain Model simpel halten.

Die Frage: Ist eine Diskussion über ORM wirklich nötig?

Wie genau sieht die Alternative aus?

nein - ich bin nach wie vor nicht verschollen
Ich verfolge nach wie vor die Bugtrackers, das Forum und das stillschweigende Subversion.

Wollte nur mal ein kleines Lebenszeichen von mir geben (zur Zeit aus London).

Kurz zu meiner derzeitigen Arbeit: Ich bin fest am Wiki dran. Viel am Konzept wie auch an der Datenflut.
(Zwar nicht im Dokuwiki - da ich in London nur alle paar Tage in den Genuss eines Internet-Zugangs komme - sondern mittels "zim" Desktop Wiki  (Ist fast identisch mit dokuwiki, nur eben auf desktop-basis (bazzar-faehig, txt2tags-export (somit dokuwiki faehig), etc pp) - http://zim-wiki.org )

Also keine Angst, ich bin nach wie vor bei euch, auch wenn derzeit nicht visuell

Wenns Probleme gibt, dann ruhig mir eine Email schreiben - die wird auf mein Handy gepushed.

Kind Regards from U.K
Alex

mir ist aufgefallen, dass es scheinbar keine Möglichkeit gibt, aus dem Controller heraus mehrere View-Scripts rendern zu lassen. Heißt, man kann zwar das zu rendernde Script ändern, aber nicht einfach eins hinzufügen (oder habe ich die Möglichkeit irgendwie übersehen?).

In den View-Scripts selbst ist das natürlich kein Problem, aber da will ich das nicht machen, weil das imho ein Teil der Applikationslogik ist. Die Möglichkeit, die ich sehe:

In irgendeinem Action-Helper ein paar Methoden schreiben, mit denen man (wie bisher) Templates vor, nach oder angehängt an das Inhaltstemplate hinzufügen kann. Diese werden dann im Layoutscript entsprechend abgefragt und gerendert.

Ich würde es natürlich vorziehen, eine vorhandene Lösung zu benutzen, aber so eine habe ich noch nicht gefunden. Hat jemand 'ne Idee dazu?

also ich habe mich jetzt nur kurz bei Mantis umgeschaut und muss sagen: Es gefällt mir. Viele Konfigurationsmöglichkeiten und soweit ich bisher sehe keine Nachteile gegenüber dem SF-Tracker.

Will das ganze aber erstmal intensiver testen, werde dazu morgen mal einige Tickets aus dem SF-Tracker übernehmen.

Auch dort gibt es wieder die Hauptkategorie 'Project', wie machen wir das da? Nach Modulen? Nach Meilensteinen? Nach Versionen?

Ich wäre dafür, das ganze nach Versionen zu machen. Also für jedes Release ein Projekt und dann eben 'Development' oder 'SVN' oder so.

Was meint ihr?

Edit: Ich sehe gerade, es gibt auch noch Kategorien und Subprojekte... und ich hatte schon die Hoffnung, man hätte die sinnlose Komplexität, die mich beim SF-Tracker auch nervt, weggelassen  Wir müssen das natürlich nicht nutzen (zumindest die Subprojekte), aber Kategorien braucht man wohl...

es gibt einen recht nützlichen View-Helper (HeadScript), um das Einbinden von JS-Dateien zu verwalten. Fände es jedoch etwas mühselig und unübersichtlich, den direkt im Controller zu benutzen (denn dort wird ja praktisch abhängig von der Aktion entschieden, ob und welche JS-Dateien eingebunden werden sollen). Stattdessen würde ich einen Action-Helper vorschlagen, der sozusagen als Wrapper für den View-Helper dient und die Benutzung vereinfacht (ähnlich der Funktionen addJsFile(), adJsTexts() und addScriptaculousFiles() der Klasse Dsao_View_Smarty).

Oder habt ihr eine Idee für ein besseres Design?

mich stört es etwas, den SF-Bugtracker für alles mögliche zu benutzen, daher wollte ich fragen, wie ihr es finden würdet, TaskFreak! dafür zu benutzen? Wird von SF angeboten, bräuchten wir also nur zu aktivieren. So dass im Bugtracker wirklich nur Bugs landen. Was meint ihr?

Oder würde das nur zur allgemeinen Unübersichtlichkeit beitragen (nach dem Motto "omg, schon wieder eine neue Plattform")?

Ansonsten würde ich folgendes vorschlagen:

Bugtracker -> Bugs
Uservoice -> Feature-Request
TaskFreak! -> nur für am Projekt Beteiligte änderbar (natürlich für alle einsehbar), sozusagen zur Organisation und Verteilung der Aufgaben

Natürlich könnten wir auch einen eigenen Tracker für diesen Zweck erstellen, was für mich aber auf's gleiche hinausläuft. Meinungen?

nachdem ich im Moment vom ZF eher frustriert bin (bzw. von mir selbst), hatte ich erwogen, ein anderes Framework zu benutzen. Aber im Endeffekt scheint die Komplexität einfach bei allen großen Frameworks vorhanden zu sein und das ZF zumindest ein gut durchdachtes Design zu haben.

Thorn (willkommen nochmal an dieser Stelle, ich hoffe, dass mit dir jetzt endlich mal etwas Schwung in die Bude kommt ) hat auch gemeint, das ZF sei keine schlechte Wahl und so bin ich mittlerweile auch eher dafür, beim ZF zu bleiben (ja, ich weiß, ich ändere meine Meinung oft und schnell )

Meinungen?

Wenn wir beim ZF bleiben, dann liegt jetzt noch folgendes an:

- Menü. Da bin ich ja schon etwas länger dran, das sollte relativ schnell fertig werden
- ORM. Angeblich implementiert das ZF ja selbst ORM, aber ich finde das etwas schwach. Wäre daher dafür, Doctrine zu benutzen. Ansonsten bilden sich so Auswüchse wie die Klasse Dsao_DataHandler ^^
- Zend_View. Alle Smarty-Templates umschreiben und überlegen, welche View-Helper man wie einsetzt und welche man noch selbst schreiben muss

Nur mal für Thorn, zur Orientierung. Falls du (oder jemand anders) jetzt im Moment noch Fragen hat, am besten hier rein. Falls mir noch Ergänzungen zur Liste einfallen, setze ich sie oben rein.

devel
    application
        Bootstrap.php
        configs
            application.ini
        layouts
            views
                $layout
                    index.phtml
        models
            Dsao
                Model
                    Class.php
        modules
            $module
                IndexController.php
        views
            helpers
            scripts
                $layout
                    module
                        controller
                            action.phtml
    data
        lang
        xml
    library
        Dsao
        Zend
    public
        css
        images
        js
        index.php
    tmp

So, nun verschiedene Sachen:

- http://framework.zend.com/manual/en/zen … dular.html <- findet ihr eine solche Struktur besser als die bisherige?
- Ist das tmp-Verzeichnis notwendig? Anderenfalls würde ich einfach als temporäres Verzeichnis das nehmen, was von der PHP-Funktion sys_get_temp_dir() ausgespuckt wird. Also in den meisten Fällen /tmp (unter Linux)

Commiten werde ich die aktuelle Struktur hoffentlich in den nächsten Tagen, sobald ich zumindest die Startseite ordentlich gerendert bekommen habe.

Hier eine unsortierte Liste der Dinge, die im Zuge dieser Umstellung umgeschrieben / neu implementiert werden müssen:

- Templates umschreiben
- Navigation / Menü (ACL-gestützt)
- Einbinden von JavaScript sowie Ablauf von Ajax-Anfragen
- Anzeige von während der Ausführung aufgetretenen Fehlern
- Sitemap
- Breadcrumbs

Mehr fällt mir im Moment nicht ein, aber da ist bestimmt noch mehr.

Werde daraus natürlich noch Tickets machen, wollte aber erstmal mein gedankliches Chaos etwas ordnen. Wenn jemand etwas davon übernehmen will, bitte Bescheid sagen, dann commite ich öfter mal, auch wenn's noch nicht läuft.

Thorn fragte mich, wo das Konzept ist, und ich konnte ihm das nicht beantworten. Alex? Ich hab gar keinen Plan, in welcher Form das Konzept bei dir vorliegt, bzw. wie die weitere Planung aussieht. Ist das Konzept irgendwo online?

Was auch teilweise mit dem Konzept zu tun hat: Wir sollten  den Bugtracker aufräumen und uns überlegen, dass wir dort nur noch wirkliche _Bugs_ reinpacken und die "Task-Management" (bzw. Planung / Konzeptionierung usw.) woanders vornehmen. Das wäre jedenfalls mein Vorschlag. (Oder zumindest einen anderen Tracker anlegen)

ich wuensch Euch allein einen frohen und ruhigen heiligen Abend sowie die darauf folgende Weihnachtszeit.

Natuerlich darf der "gute Rutsch", der kurz darauf folgt, nicht fehlen

In diesem Sinne

Gehabt Euch wohl beisammen.

Liebe Gruesse,
Alex

Was für mich die zentrale Frage ist, die anscheinend auch in diesem Projekt nicht geklärt ist: Was ist das Ziel?

ich bin jetzt in dem Buch 'Domain-Driven Design' weit genug gekommen, um zu erkennen, dass das ganze für uns nichts ist. Ich habe nämlich einen entscheidenden Punkt vernachlässigt: Das ZF ist zwar komplex, aber unsere Applikation, also DSAo-Md selbst ist weniger komplex. Ein Domain-Driven Design wäre so kompliziert und würde so viel Zeit in Anspruch nehmen (es muss alles geplant werden etc.), dass es sich einfach nicht lohnen würde.

Aber nun die Frage: Wie gestalten wir die Modell-Komponente? Im Moment sieht's ja so aus:

View: Templates (und bald View-Helper), keine Applikationslogik, das ist okay.
Controller: Relativ schlank, aber noch nicht schlank genug, sollte noch weiter ins Modell ausgelagert werden.

Model:

- Modell-Klassen, die einfach eine Sammlung von Funktionen darstellen, ergänzt um einige Klassen (Dsao_User usw.), die bestimmte Daten und Methoden kapseln und Elemente des Systems darstellen. Datenbankoperationen sind atm noch wild verstreut, manche im Modell, manche in den Klassen.

Ich würde gerne eine klar getrennte Schichtung haben. Heißt, oberste Schicht besteht sozusagen aus 'Manager'-Klassen, die ähnlich wie die bisherige Modell-Klassen fungieren. Darunter ein möglichst strukturiertes System von Klassen, die Elemente des Systems wiederspiegeln und darunter kommt dann Doctrine als ORM. Weiß noch nicht, wie und wo z.B. die Validierung erfolgt oder von wo aus Doctrine aufgerufen wird...

Jemand Ideen / Vorschläge?

ab sofort gibt es zwei primaere Schnittstellen, um zum einen die Kommunikation zwischen der Community und dem Team zu verbessern und zum anderen, um dem Team ein komfortabeles und produktives Arbeitsmittel zu bescheren.

Die erste Schnittstelle stellt dieses Forum dar.
Es ist in zwei Kategorien unterteilt: Allgemein (fuer oeffentliche Diskussionen, Bekanntmachungen - wie diese hier -  und fuer sonstigen Smalltalk) sowie Interna (Teamorientierte Ausarbeitungen, Diskussionen und Ankuendigungen). Auf lange Sicht hin, wird das Forum wohl die beiden Mailinglisten abloesen und zur primaeren Kommunikationsplattform werden.

Die zweite Schnittstelle stellt Uservoice dar.
Wer die Webapplikation Ideatorrent (bislang von uns genutzt worden) kennt, wird sich schnell im Uservoice zurrecht finden.
Es ist eine Plattform um Ideen, Wuensche, Features und Anregungen effektiv zu verwalten, zu organisieren und auszuarbeiten. Jeder (auch anonym) hat die Moeglichkeit, seine Ideen dort kund zu tun (und wird hiermit auch offiziell dazu aufgefordert) und diese, sowie vorhandene zu bewerten. Wer den Weg ueber die Registrierung genommen hat, hat zudem die Moeglichkeit, Kommentare zu den Ideen hinzuzufuegen und aktiv an der Umsetzung teilzunehmen (ob produktiv in der Entwicklung oder als "Beobachter" ist vollkommen egal). Zu finden ist Uservoice unter http://dsao.uservoice.com

Dies soll eine staerkere Verbindung zwischen der Community und dem Team sicherstellen und gewaehrleisten.
Weiterhin traegt es um ein vielfaches zur Transparenz von DSAo-Md bei.

Mit den besten Gruessen,
Euer DSAo-Md Team.