turk porno porno escort rokettube
Seite 1 von 2 1 2 LetzteLetzte
Ergebnis 1 bis 20 von 23

Thema: ZF 1.9.6 resources und src?

  1. #1
    Neuer Benutzer
    Registriert seit
    02.04.2009
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Idee ZF 1.9.6 resources und src?

    Hallo alle,

    ich weiß nicht, ob es jemandem aufgefallen ist, aber da kommen aus dem 1.9.6 gegenüber dem 1.9.5 zwei (leere) Verzeichniss namens "resources" und "src" aus dem Zend Framework ZIP heraus.

    Hat das einen besonderen Grund?

    Ich hoffe ja, denn ich bin immer noch der Meinung, dass die Aufteilung in module und dann MVC plus alles Mögliche (data, layouts, forms, ...) inkonsistent/unpraktisch ist, da im ZF ja einerseits die Dateien nach Typ/Art gegliedert werden und im "application"-Verzeichnis auf einmal pro Modul. Jedenfalls finde ich das dadurch entstehende Splitting der PHP Quelldateien unpraktisch.

    Gerade im Hinblick auf PHAR und namespaces könnten "src" und "resource" nun endlich mal Frieden in die Strukturdiskussion bringen (IMHO).

    Was meint Ihr?

    Karsten

  2. #2
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Ehrlich gesagt habe ich am Ende nicht mehr den Sinn deines Posts verstanden, da die Einleitung schon völlig misslungen ist.

    1. gibt es 2 verschiedene Release-Pakete, du nennst aber keines davon.
    2. hört es sich im weiteren Verlauf so an, als würdest du vom Ergebnis nach "zf create project wurst" sprechen
    3. wer sollte auf die Idee kommen, in PHAR das komplette entpackte Zip-Archiv zu legen? Worauf willst du da hinaus?
    4. Die Aufteilung in Forms, Models etc. dient der Übersichtlichkeit, ka. wo du da ein Problem hast ...
    Neues Projekt: zandman.de - Status: WIP




  3. #3
    Neuer Benutzer
    Registriert seit
    02.04.2009
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Also grundsätzlich gibt es keinen Grund hier erstmal rumzupampen. Das ist schon wieder typisch.

    Ich bin ein "ausgebrochener" Java-Programmierer und noch ein ZF Frischling, also Entschuldigung, wenn ich hier einfach so reinplatze. Es kann gut sein, dass ich hier einige alte Hasen veräger, weil ich einfach nicht an die ZF Umgebung bzw. die best practices gewöhnt bin.

    Der Sinn ist folgender:

    Für mich ist das ZF etwas inkonsistent was die Aufteilung der Dateien in Projekten angeht: einerseits wird im Root nach *Dateiart* unterschieden, dafür gibt es Verzeichnisse application, data, docs, library, maint(enance)/scripts, temp, tests, usw. Je nachdem ob shared hosting oder nicht, dann eben noch css, forms, images, js, layouts, ...

    Im "application"-Verzeichnis, das (für mich) i.w.S. das "src" Verzeichnis darstellt bzw. darstellen sollte, wird aber nach Modulen die Verzeichnisstruktur gebildet und das oft auch noch auf 2+ Ebenen (default Modul in application und andere in extra Verzeichnissen). Selbst wenn man das Default-Modul als eigenes Unterverzeichnis in application anlegt, führt die Art der Aufteilung letztlich zu einem "Splitting" der PHP Quellen und aller anderen Dateiarten, die ja eigentlich eher Ressourcen sind, wie z.B. configs, data, forms, layouts, ... Diese müssten eigentlich in die entsprechenden Verzeichnisse im Root. So sehe ich es zumindest.

    Ich finde es so wie es ist inkonsistent bzw. für relative Neulinge schwer nachzuvollziehen, warum es so ist.

    Das mit dem Phar kam genau deswegen auf, weil man es in Java so macht, dass man einzelne "Module" in Jars steckt, in denen dann sowohl die Sources (src) als auch die Ressourcen (resources) befinden. Ich dachte spontan, dass es in dieselbe Richtung gehen könnte und das wollte ich erfragen bzw. was diese Verzeichnisse im ZF Full Package 1.9.6 sollen, wenn sie keinen Sinn erfüllen.

    Schließlich hat es in der Vergangenheit ewige Diskussionen zur Verzeichnisstruktur gegeben, die meiner Meinung nach immer noch berechtigt sind.

    Um Deine Fragen mal zu beantworten:

    1. Full
    2. Ja
    3. Das weiß ich selbst noch nicht genau, da ich mir nicht sicher bin, ob Phar dieselbe Funktionalität bietet wie Jar...
    4. Habe ich oben beschrieben.

    Karsten
    Geändert von kwutzke (03.12.2009 um 17:04 Uhr)

  4. #4
    Erfahrener Benutzer Avatar von deetee
    Registriert seit
    17.12.2007
    Beiträge
    1.459
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Selbst wenn man das Default-Modul als eigenes Unterverzeichnis in application anlegt, führt die Art der Aufteilung letztlich zu einem "Splitting" der PHP Quellen und aller anderen Dateiarten, die ja eigentlich eher Ressourcen sind, wie z.B. configs, data, forms, layouts, ... Diese müssten eigentlich in die entsprechenden Verzeichnisse im Root.
    Ein Vorteil am ZF ist auch, dass man die Verzeichnisstruktur sehr flexibel ändern kann. Ich habe es so gemacht, wie du es beschrieben hast - das default Modul als eigenes Verzeichnis. Siehe Anhang.

    Die Modularität hinsichtlich Verzeichnisstruktur hat sich seit 1.7.x sehr verbessert. Es ist mir bisher zwar noch nicht gelungen ein Projekt zu erstellen mit 100% autarken Modulen (eine gewisse Abhängigkeit zur index.php, oder application.ini bleibt bei meinen Versuchen immer), aber ich denke schon, dass es mit ein paar Kniffen mehr doch gehen sollte, bzw. irgendwann so sein wird.


    Ja, auf Phar Integration in PHP Projekten bin ich auch gespannt. Das Potenzial sollte ähnlich sein, wie bei JAR Paketen.
    Angehängte Grafiken Angehängte Grafiken

  5. #5
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Also grundsätzlich gibt es keinen Grund hier erstmal rumzupampen. Das ist schon wieder typisch.
    In dem Sinne pampe ich mal mit: Ich versteh dein Problem nicht mal jetzt vollständig.
    Für mich ist das ZF etwas inkonsistent was die Aufteilung der Dateien in Projekten angeht: einerseits wird im Root nach *Dateiart* unterschieden, dafür gibt es Verzeichnisse application, data, docs, library, maint(enance)/scripts, temp, tests, usw. Je nachdem ob shared hosting oder nicht, dann eben noch css, forms, images, js, layouts, ...
    Du wirfst hier einiges in einen Topf
    1. Von den ersten 7 genannten "Dateiarten" werden gerade mal 2 wirklich gebraucht werden, nämlich application/ und library/, wobei diese nun wirklich nicht in einem Verzeichnis liegen müssen. Das sie es (initial) trotzdem tun liegt wohl vorallen an der Frage "Wohin denn sonst?!?"
    2. CSS, JS (usw) liegen im public/. Das das notwendig ist, ist offensichtlich und da kann auch das Framework nicht viel gegen machen.
    3. Wieso du da die Layouts mit drin hast, ist mir schleierhaft, bei mir sind die mindestens unter application/. Is auch logisch: Sie gehören zur Anwendung.

    Wo besteht eigentlich die Verbindung zu "Shared Hosts"? Du brauchst je nach hoster (oder wasauchimmer) keine Unterschiede machen.

    Im "application"-Verzeichnis, das (für mich) i.w.S. das "src" Verzeichnis darstellt bzw. darstellen sollte, wird aber nach Modulen die Verzeichnisstruktur gebildet und das oft auch noch auf 2+ Ebenen (default Modul in application und andere in extra Verzeichnissen). Selbst wenn man das Default-Modul als eigenes Unterverzeichnis in application anlegt, führt die Art der Aufteilung letztlich zu einem "Splitting" der PHP Quellen und aller anderen Dateiarten, die ja eigentlich eher Ressourcen sind, wie z.B. configs, data, forms, layouts, ... Diese müssten eigentlich in die entsprechenden Verzeichnisse im Root. So sehe ich es zumindest.
    Module sind in sich abgeschlossene Einheiten. Wozu sollte man den Inhalt auseinander reißen?
    Das application/-Verzeichnis beinhaltet übrigens (wer hätte das gedacht?) die Anwendung. Ich wüsste nun nicht, wieso man Teile der Anwendung aus selbigem raus nehmen sollte.
    Im Gegenteil: Wenn man nun die Einheit über x Verzeichnisse verteilt, ist das wohl eher ein "Splitting".
    Das mit dem Phar kam genau deswegen auf, weil man es in Java so macht, dass man einzelne "Module" in Jars steckt, in denen dann sowohl die Sources (src) als auch die Ressourcen (resources) befinden. Ich dachte spontan, dass es in dieselbe Richtung gehen könnte und das wollte ich erfragen bzw. was diese Verzeichnisse im ZF Full Package 1.9.6 sollen, wenn sie keinen Sinn erfüllen.
    Und auch da wiederholt sich bei gleichartigen Modulen die (interne) Verzeichnisstruktur, auch wenn man sie da nicht sieht. Stell dir vor, ein Modul unter modules/ entspricht einer Phar-Datei.

  6. #6
    Erfahrener Benutzer Avatar von bate
    Registriert seit
    17.04.2007
    Beiträge
    205
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Unterschied Java und PHP sollten dir hoffentlich klar sein.

    im App Verzeichnis befinden sich module damit du alles was View/Module und Controller angeht noch nach Modulen abstrahieren kannst.

    alles was du vom web aus brauchst (CSS/JS/IMG etc) muss auch im Webverzeichnis liegen.

    Da es in PHP erst mit 5.3 namespaces gibt wurde zuvor etwas anders abtrahiert und namespaces geschaffen.

    Class Prefixing (Zend_Service_Foo_Bar => Zend/Service/Foo/Bar.php)

    ... bitte wende keine Java Konzepte in PHP direkt an, dies müssen immer etwas anders verwendet bzw. adaptiert werden wenn du es denn gern so umständlich haben möchtest.

  7. #7
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Zitat Zitat von kwutzke Beitrag anzeigen
    Also grundsätzlich gibt es keinen Grund hier erstmal rumzupampen. Das ist schon wieder typisch.
    Also "pampig" ist bei mir was anderes, ich versuche erstmal die komplette Problemstellung zu verstehen bevor ich anfange herumzudoktern, was gemeint sein könnte. Daher die Aufzählung, was für mich völlig unklar oder nicht genau genug ist.
    Neues Projekt: zandman.de - Status: WIP




  8. #8
    Erfahrener Benutzer Avatar von ice-breaker
    Registriert seit
    29.03.2008
    Ort
    Steinbach/Taunus
    Beiträge
    1.862
    Thanks
    0
    Thanked 9 Times in 5 Posts

    Standard

    Zitat Zitat von kwutzke Beitrag anzeigen
    Ich bin ein "ausgebrochener" Java-Programmierer
    Willkommen
    Von denen haben wir hier nicht viele

    Zitat Zitat von kwutzke Beitrag anzeigen
    Im "application"-Verzeichnis, das (für mich) i.w.S. das "src" Verzeichnis darstellt bzw. darstellen sollte
    vergiss was die Sachen in Java bedeuten, das hat hier in PHP keinerlei Relevanz, das Libraries in der Java-Welt immer die gleiche Struktur haben (die auf Continous Integration ausgelegt ist) gibt es in PHP nicht, hier ist alles etwas "rückschrittlicher". Jeder backt seine eigenen Brötchen.


    Zitat Zitat von kwutzke Beitrag anzeigen
    Das mit dem Phar kam genau deswegen auf, weil man es in Java so macht, dass man einzelne "Module" in Jars steckt, in denen dann sowohl die Sources (src) als auch die Ressourcen (resources) befinden. Ich dachte spontan, dass es in dieselbe Richtung gehen könnte und das wollte ich erfragen bzw. was diese Verzeichnisse im ZF Full Package 1.9.6 sollen, wenn sie keinen Sinn erfüllen.
    PHAR sind bei weitem noch nicht mit JARs zu vergleichen, hier ist es das gleiche wie oben, auch bei PHARs wird jeder sein Brötchen backen und es wird keine gemeinsame Struktur geben. Dinge wie das MANIFEST oder WEB-INF sind hier leider fehlt am Platz, soweit wurde bei dem Erstellen des Standards nicht gedacht.
    "Die Wahrheit entgeht dem, der nicht mit beiden Augen sieht." -Orici

  9. #9
    SKC
    SKC ist offline
    Erfahrener Benutzer Avatar von SKC
    Registriert seit
    05.05.2009
    Beiträge
    103
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von KingCrunch Beitrag anzeigen
    In dem Sinne pampe ich mal mit: Ich versteh dein Problem nicht mal jetzt vollständig.
    Puh, dann bin ich dahingehend ja nicht alleine...

    Was mich jetzt trotzdem interessiert, warum steigst du denn von Java auf PHP um?

  10. #10
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Was mich jetzt trotzdem interessiert, warum steigst du denn von Java auf PHP um?
    Totschlagargument: Wird vom Kunden vorgegeben Alternativ: Es ist auf der Zielplatform bereits vorhanden und ein zweites System wäre nicht zweckmässig, oder man will mal über den Tellerrand schauen.

  11. #11
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Immerhin bin ich nicht alleine, der das Problem nicht so wirklich verstanden hat
    Neues Projekt: zandman.de - Status: WIP




  12. #12
    Erfahrener Benutzer Avatar von ice-breaker
    Registriert seit
    29.03.2008
    Ort
    Steinbach/Taunus
    Beiträge
    1.862
    Thanks
    0
    Thanked 9 Times in 5 Posts

    Standard

    Zitat Zitat von SKC Beitrag anzeigen
    Was mich jetzt trotzdem interessiert, warum steigst du denn von Java auf PHP um?
    Weil ordentliche Web-Applikationen in Java eine Qual sind.
    "Die Wahrheit entgeht dem, der nicht mit beiden Augen sieht." -Orici

  13. #13
    tsk
    tsk ist offline
    Erfahrener Benutzer
    Registriert seit
    08.09.2008
    Ort
    Vaals
    Beiträge
    132
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ohne alles genau gelesen zu haben und um auf einen Teil der ursprünglichen Frage zurück zu kommen. Könnte 'resources' nicht später die durch T. Weidner angekündigten Validatorenstrings aufnehmen. Ich meine, im Blog so etwas in der Art gelesen zu haben.

    Ich freu mich grundsätzlich über jedes neue Verzeichnis - egal ob voll oder leer.

  14. #14
    Neuer Benutzer
    Registriert seit
    02.04.2009
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von SKC Beitrag anzeigen
    Puh, dann bin ich dahingehend ja nicht alleine...

    Was mich jetzt trotzdem interessiert, warum steigst du denn von Java auf PHP um?
    Wer sagt denn, dass ich umsteige? Ich habe eben vor ein paar Jahren auch mal eine Arbeit als PHP-Programmierer gehabt, aber relativ schnell gemerkt, dass PHP etwas unsauber und relativ wenig Struktur von außen bekommt.

    Nachdem ich letztes Jahr vom Zend Framework gehört habe, dann PHP 5.3 namespaces, Phar und Phing, da habe ich Ohren bekommen und nun will ich mir PHP als Hintertürchen offen lassen...

    Der Sinn ist: PHP kommt ja durch obiges so langsam aus den Kinderschuhen heraus und alles deutet seehr stark auf ähnliche Konstrukte wie in Java hin. Ich sehs als Portfolio-Erweiterung:

    Java ~ PHP
    ------------------
    OO ~ seit PHP5 OO
    JDK bzw. Seam, Spring, etc. ~ Zend Framework
    Ant ~ Phing
    Jar ~ Phar
    JUnit ~ PHPUnit
    Tomcat, JBoss ~ Zend Server
    Packages ~ Namespaces

    Nur die Verzeichnisstruktur fehlt! Ich frage mich, warum man hier das Rad neu erfinden sollte...

    Es riecht nun mal ziemlich stark danach, dass Phar irgendwann sehr änhlich wie Jars funktionieren und dann werden in diesen einzelnen Phars auch ganz unterschiedliche Dateien mit einem entsprechenden Dateibaum drinstecken, die dann u.a. mit Hilfe von Phing zusammengebaut und deployed werden.

    Karsten

  15. #15
    Neuer Benutzer
    Registriert seit
    02.04.2009
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von ice-breaker Beitrag anzeigen
    Willkommen
    Von denen haben wir hier nicht viele
    Das dachte ich mir fast. Also Jungs und Mädels, aufwachen.

    Zitat Zitat von ice-breaker Beitrag anzeigen

    vergiss was die Sachen in Java bedeuten, das hat hier in PHP keinerlei Relevanz, das Libraries in der Java-Welt immer die gleiche Struktur haben (die auf Continous Integration ausgelegt ist) gibt es in PHP nicht, hier ist alles etwas "rückschrittlicher". Jeder backt seine eigenen Brötchen.
    Genau DAGEGEN wehre ich mich aber. Ich habe schon zuviel PHP Spaghetticode gesehen, aber RICHTIG Spaghetti!

    Keinerlei Relevanz? Hmmm das kann ich leider so nicht akzeptieren, ich werde wohl selbst mal schauen müssen wie weit man mit Phing, Phar und einer Java-like Verzeichnisstruktur mit dem Zend Framework kommt.

    Denn so muss ich auch nur einmal "best practices" kennen, die ich dann für Java UND PHP nahezu ähnlich anwenden kann.

    Karsten

  16. #16
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Der Sinn ist: PHP kommt ja durch obiges so langsam aus den Kinderschuhen heraus und alles deutet seehr stark auf ähnliche Konstrukte wie in Java hin. Ich sehs als Portfolio-Erweiterung:
    PHP ist nicht Java. Wollts nur angemerkt haben
    Warum? Weil, wenn man das umdreht, hat man den Kritikpunkt gegen Java: "Java ist star und unflexibel". Das man den Entwicklern alle Freiheiten lässt, muss nicht zwangsläufig ein Nachteil sein. Ich hatte Anfangs zB arge Probleme mit Java.
    Genau DAGEGEN wehre ich mich aber. Ich habe schon zuviel PHP Spaghetticode gesehen, aber RICHTIG Spaghetti!
    Ich auch. Kann aber auch daran liegen, dass ich schon viel PHP-Code gesehen habe
    Ne, im Ernst: PHP ist verhältnismässig einfach, was schnell dazu führt, dass sich viele für die Pro-Programmierer überhaupt halten. Das führt eben dazu, das Murks-Code "verkauft" (also entweder wörtlich oder im OpenSource-Gedanken) wird.
    Ob hier allerdings der Verursacher allein bei PHP zu Suchen ist, oder bei den Entwicklern (und damit mittelbar der Einfachheit und Beliebtheit der Sprache), würd ich auch nicht überbewerten. So eine Diskussion führt zu nix . Zum Vergleich kann man sich Python anschauen: Da kann man noch wesentlicher ekliger Programmieren, aber irgendwie kriegen die Leute es hin
    Und sei dir sicher: Spaghetti-Code geht auch in Java


    Mir ging eben noch ein Zitat eines Mitstudenten durch den Kopf: Java ist eine coole Sprache, aber Webanwendungen ... Never ever!
    Den Spass hatte ich auch mal. Irgendwie fühlt sich da Java endgültig oversized an ^^

    JDK bzw. Seam, Spring, etc. ~ Zend Framework
    Interessanter Punkt, den du ansprichst. Die JDK find ich persönlich sehr beeindruckend. Bei anderen Java-Bibliotheken hatte ich auch immer das Gefühl, als seien sie irgendwie durch "die Macher" unterstützt worden, auch wenns vllt nur gutes Zureden oder mal nen Blogeintrag war.
    Aus dem PHP-Haus kam da nie wirklich was. Irgendwann kam SPL, aber meines Erachtens ist das inkonsequent und inkonsistent umgesetzt und ausserdem hab ich das Gefühl, dass es alle Jubeljahre mal geupdatet wird. Das es schon mehrere Jahre auffm Buckel hat, merkt man es zumindest nicht an.
    Und PEAR? kA, irgendwie hab ich dazu keine Meinung.
    Das Zend Framework war auf jeden Fall ein wichtiger Schritt, nur auch in Hinblick des Alters von PHP selbst viel zu spät. Und sowieso fehlt PHP auch weiterhin eine zweckmässige und brauchbare Basis-Bibliothek.

    Edit
    Tomcat, JBoss ~ Zend Server
    Seh ich ja jetzt erst
    Sry, aber Tomcat nehm ich nicht ernst (JBoss sagt mir nichts). Is rein subjektiv.
    Auf der rechten Seite fehlt noch mod_php, was schließlich die Standardinstallation für PHP überhaupt ist! .. Zumindest auf Apache-Basis, es gibt noch genug andere Server, auf die PHP läuft.

    OO ~ seit PHP5 OO
    Ich ergänz das mal ganz fies
    NIX ~ Prozedural

    Oha, viel Text, war so nicht geplant -.-
    Geändert von KingCrunch (10.12.2009 um 02:16 Uhr)

  17. #17
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Zitat Zitat von kwutzke Beitrag anzeigen
    Genau DAGEGEN wehre ich mich aber. Ich habe schon zuviel PHP Spaghetticode gesehen, aber RICHTIG Spaghetti!
    Du kennst da aber wohl Perl noch nicht Da gibt es Beispiele wie man eine 20 Zeilen Funktion in nur eine Zeile kriegt - wartbar ist es nicht mehr, aber man spart sich ja Tipparbeit ...


    Zitat Zitat von kwutzke Beitrag anzeigen
    OO ~ seit PHP5 OO
    Die Einführung kam mit PHP4 und wurde mit PHP5 erweitert (wenn man die Timeline von PHP betrachtet).
    Neues Projekt: zandman.de - Status: WIP




  18. #18
    Erfahrener Benutzer
    Registriert seit
    22.03.2007
    Ort
    Böbingen/Rems
    Beiträge
    734
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Also ich würde mir wünschen das gerade in Bezug auf die Namespaces in PHP, hier eine einheitliche Struktur geschaffen wird. Und das Java Namespace Konzept finde ich persönlich am besten.

    Ich nehme mal Punkte das die Backslashs raus gelöscht werden.

    PHP-Code:
    namespace com.zend.framework;
    namespace 
    net.php;
    namespace 
    net.php.spl;
    namespace 
    net.pear
    Ich habe dieses Konzept auf alles angewandt wo es nur geht. Eclipse Projekte werden bei mir so genannt die Ordner dazu. Projekte werden im SVN so benannt. Ich hatte schon viele Strukturen aber diese scheint mir am besten durchdacht.

    Gerade wenn man mehrere Sprachen in einem Projekt mischt kann man so eine gleiche Struktur aufbauen.

    PHP und Flex
    Java und Flex
    PHP und JavaScript (Wenn die irgendwann mal Namespaces ein bauen, haben sie ja bei der neusten Version nicht hinbekommen)

    Mfg Akkie
    Mohiva Common - A PHP library which provides functionality shared by some mohiva projecs
    Mohiva Elixir - A dynamic XML template language
    Mohiva Pyramid
    - An operator precedence parser based on the “Precedence climbing” algorithm
    Mohiva Manitou - A code generator
    Mein Blog

  19. #19
    Neuer Benutzer
    Registriert seit
    02.04.2009
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ja genau dieser Meinung bin ich eben auch. Man sollte die Verzeichnisstruktur und die namespaces parallel laufen lassen.

    Bei konsequenter Verwendung von namespaces fällt das Prefixing von Klassennamen ala "Zend_View_" flach, das ja sowieso nur zur "downward compatibility" da war. Aus diesem Grunde sehe ich nun auch nicht mehr, warum namespaces noch "Gross" geschrieben werden sollen. In meinen Augen obsolet und klein schreiben ist einfach generell zum Tippen und mit den Namen der Verzeichnisse besser.

    Was aufgrund der Parallelität von namespaces und Verzeichnisnamen weiter wegfällt, ist das eher komplizierte ressourcenbasierte Autoloading von Klassen, wie es durch die jetzige MVC-Modul-Verzeichnisstruktur, also den Verzeichnissen "models", "views" und "controllers", umgesetzt ist. Man könnte das Autoloading sehr stark vereinfachen, wenn man einen extra Verzeichnisbaum aufmacht und nicht die MVC-Struktur vorraussetzt, sondern lediglich namespace-Verzeichnisse (nur für die Quellen).

    Dadurch würde auch diese nervige Diskussion um plural vs. singular Verzeichnisnamen endlich beigelegt, genauso eben das komplizierte Mapping zwischen "models" als Verzeichnis und "Model" bzw. "model" als namespace.

    Weiterer Vorteil: selbst bei einer modulbasierten Struktur, kann man die Quellen seiner eigenen Applikation in einem Verzeichnisbaum halten, so wie Zend*, ZendX* und jede andere library eben. Theoretisch muss man ja auch kein extra "src" Verzeichnis im root aufbauen, sondern könnte es einfach zu den anderen libraries packen, da man seine eigene Applikation so oder so mit einem Basis-Namensraum versehen wird, z.B. MyApi/myapi oder MyCms/mycms.

    Das Ganze hatte ich mir dann so vorgestellt:

    Code:
    root
      |
      +-- lib
      |   +-- Zend
      |   +-- ZendX
      |   +-- myapi
      +-- res
      |   +-- admin
      |       +-- models
      |           +-- data
      |       +-- views
      |           +-- filters
      |           +-- helpers
      |           +-- layouts
      |           +-- scripts
      |   +-- main (default module)
      |       +-- models
      |       +-- views
      |   +-- modulex
      |       +-- models
      |       +-- views
      +-- src
      |   +-- mycms
      |       +-- admin
      |           +-- controller
      |       +-- main
      |           +-- controller
      |       +-- modulex
      |           +-- controller
     ...
    Bitte beachten, dass Zend und ZendX wie oben beschrieben eigentlich klein geschrieben werden sollten. Ich bin mir nicht sicher, ob die namespaces unbedingt mit den Modulnamen übereinstimmen müssen. So weit bin ich noch nicht. Ich habe hier als Default-Modul einfach mal Main genommen, da "public" und "default" in fast allen Anwendungen in anderen Kontexten vorkommen und verwirren.

    Man könnte die "Erkennung" von Modulen anhand der "res"-Unterverzeichnisse vornehmen, zur Not reicht eben auch ein leeres Verzeichnis. Das Autoloading was die Quellen angeht ist ja eh autark. Ich finde die Trennung von Quellen und Ressourcen schon sehr sehr wichtig und vorteilhaft.

    Ich finde diese Struktur ist einfacher zu verstehen, gerade auch für Leute die noch nichts mit dem ZF gemacht haben.

    Karsten

    PS: Abschließend sollte man evtl. drüber nachdenken, "models" und "views" ebenfalls zu singularisieren, da M, V und C jeweils Domänen und keine Sammlungen von Ansichten, Modellen usw. sind. Meines Erachtens ist MVC erschöpfend, d.h. es sollte i.d.R. möglich sein, Ressourcen genau einer dieser Domänen zuzuordnen. For configs heißt das dann eben, dass die in einer Config-Datei stehenden Configs in "model"-, "view", und "controller"-Configs gehören. So weit bin ich hier aber auch noch nicht. Ich muss das selbst erst noch testen.

  20. #20
    Neuer Benutzer
    Registriert seit
    12.12.2009
    Beiträge
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Eine intressante Diskussion.
    Ich muss sagen, ich habe nicht viel mit Java gemacht, habe also keine Erfahrung mit der Struktur.
    Ich komme eher von der Spagetti-Front, bin aber seit PHP5 soweit wie möglich auf OOP umgestiegen.

    Die Idee mit dem kleinschreiben der Klassen ist nicht schlecht, auch gefällt mir das "starke" Namespaceverhalten. WObei ich finde, dass Java dieses OO-Verhalten teilweise zu stark anwendet.

    Zu deiner Vorgeschlagenen Verzeichnisstruktur möchte ich sagen, dass ich als mehr oder weniger ZF einsteiger nicht wirklich klarkomme.

    Mir gefällt die standardstruktur auch nicht, ganz besonders das inkonsistente verhalten der resourcen. (models/ => Model_, etc)
    ich finde die idee, dass die applikation zusammengehört besser, ich würds begrüßen, dass man das defaultmodul aber schon standardmäßig als modul liefert (und nicht wie momentan). noch schöner wäre es dann, wenn man einzelne module "exportieren" kann und in andren projekten "importieren". aber das funktioniert leider nicht wirklich. nagut man kann das manuell machen, indem man hand anlegt für datenbanken und die configs. das finde ich ein wenig schade

Seite 1 von 2 1 2 LetzteLetzte

Ähnliche Themen

  1. Antworten: 8
    Letzter Beitrag: 20.10.2009, 19:19
  2. resources.view.basePath wird ignoriert
    Von Innocentus im Forum Einsteigerfragen
    Antworten: 32
    Letzter Beitrag: 08.09.2009, 18:14
  3. Resources
    Von crow_in_cage im Forum Core
    Antworten: 4
    Letzter Beitrag: 07.09.2009, 11:12
  4. Antworten: 11
    Letzter Beitrag: 11.06.2009, 19:25
  5. Antworten: 2
    Letzter Beitrag: 06.03.2009, 02:42

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •