[kampfgnom]

heiho,
angeregt durch den Thread [Design] CMS-System: Seitenstruktur

stellt sich mir die Frage, wie man an so etwas herangeht.
Gibt es dazu Tutorials?

Meine Frage, um es noch einmal deutlicher zu sagen ist, wie plant man so ein "Projekt" im sinne des Codes (wie Programiert man es).

Ich bin halt lernender und hab noch seeehr viel zu lernen, und hab zum teil den Code von mepeisen nciht verstanden.
z.b. wann nimmt man eine neue Klasse? Man könnte doch so manches mit methoden lösen.

Naja ich hoffe cih hab einigermasen verständlich geschireben.

grüße
Gabriel

[Ben]

Hi Gabriel,
du sprichst da ein Thema an, was man glaube ich nicht mit einer konkreten Antwort abschließen könnte.

Zitat von kampfgnom

stellt sich mir die Frage, wie man an so etwas herangeht.

Nun, es gibt ja sogenannte Design Patterns / Entwurfsmuster, die oftmals die Grundstruktur von Anwendungsstrukturen prägen.

Ich denke auch, dass da jeder eine andere Sicht hat. Ich habs ja gerade hier beschrieben. Ich habe lange versucht herauszufinden, wie ich so etwas selbst erstelle und bin letztlich irgendwie daran gescheitert, weil ich irgendwie nicht voran kam. Klar, man soll sowieso immer verbessern, immer in Iterationen entwickeln und implementieren. Nichtsdestotrotz steht für mich am Ende, dass man so etwas erstes nur mit Erfahrung auf die Reihe bekommt und zweitens leichter den Einstieg findet, wenn man mal ein anderes Framework genutzt hat.
Einfach nur genutzt.

Also gar nicht darauf achten, wie es implementiert ist, sondern einfach nur auf Basis eines solchen Frameworks eine kleine Anwendung erstellen.

Deine Frage richtet sich jetzt nicht direkt an die Nutzung von Frameworks am im Prinzip ist es genau das, was du brauchst. Einen Pool von Komponenten, die du dann in Lego-Technik-Manier zusammensteckst.

Ich finde, dass du auf diesem Weg eine gewisse Sensibilität dafür entwickelst, was du gut findest und was nicht, was du intuitiv verwenden kannst und wo du denkst .. ach ne, das hätt ich aber eigentlich gerne anders gemacht.

Ist ja völlig egal, was man nimmt. Es muss nicht mal ein großes oder gutes Framework sein. Es muss nicht mal ein Framework sein.
Du kannst dir auch einfach mal ein OpenSource-CMS oder so runterladen und mal schauen, wie die das lösen. Bestenfalls was ganz Kleines, wo nicht so viel mit Modulen etc. gearbeitet wird. Dann versuchst du das mal nachzubauen, nur Teile und so weiter und so fort.

So lernst du, gewinnst Erfahrungen und kommst irgendwann auch dahinter, was andere da eigentlich machen und vor allem .. WARUM sie es machen.

Learning by doing .. viel geschwafelt und simples Fazit.

[kampfgnom]

ok danke erstmal für den Tipp.

Gut ich merk schon das Thema ist sehr komplex und das kann man nicht so einfach erklären.

Naja ein versuch wars wert^^
Hab mir jetzt ersteinmal ein Tutorial
gesucht mit dem ich mich mal ins Zend Framework einarbeiten möchte...mal sehen obs funzt...

grüße
Gabriel

[mepeisen]

Zitat von Ben

Nichtsdestotrotz steht für mich am Ende, dass man so etwas erstes nur mit Erfahrung auf die Reihe bekommt und zweitens leichter den Einstieg findet, wenn man mal ein anderes Framework genutzt hat.

genau das. Ums mal zu ergänzen: Ich bin nun fast 10 Jahren Profi-Entwickler (wenn ich mir mal die Azubi-Zeit mit anrechne *g*). Und zu Anfang hätte ich mich sowas nicht mal getraut, weil ich dann ganz einfach auch nicht gewusst hätte, wie man loslegt.

Und wie mach ichs heute? Ich lege nicht einfach so los. Nun, gewissermaßen schon, weil mir 5 bis 6 Blätter mit Zeichnungen als Konzept reichen, wobei man sowas eher einem Genie mit Hang zum Wahnsinn abkauft und keinem Entwickler . Aber nichts destotrotz sind dort Wochen in die Lande gezogen, wo ich immer mal in einer freien Minute oder wenn im Fernsehen Werbung lief oder wie auch immer darüber nachgedacht habe, bevor ich es zu Papier brachte.

Auch wenn ich derzeit wenig schriftliches Konzept habe, gehört doch eine Menge Erfahrung dazu, sowas zu machen, so dass es auch zielführend ist. Und vor allem, wie Ben schrieb: gehört gerade bei PHP einfach auch mal die Erfahrung mit anderen Systemen dazu. Ich hab das Glück, beruflich in einem richtig großen Java-Projekt mitzuarbeiten, kenne also viele Sachen wie Anwendungsdesign, was ein PHP-Entwickler bei Webseiten eigentlich kaum kennenlernt, seit Jahren aus dem FF.

Zitat von kampfgnom

Gibt es dazu Tutorials?

Nö, glaube nicht.

Zitat von kampfgnom

Meine Frage, um es noch einmal deutlicher zu sagen ist, wie plant man so ein "Projekt" im sinne des Codes (wie Programiert man es).

So wie jedes andere Projekt. Man entwirft zunächst ein großes Ganzes, sowie die Ziele. Bei mir waren das:

• Unterteilung der Webseite in Komponenten
• Manipulieren aller Komponenten per Ajax
• Identischer Code für Ajax-Requests, Komplettaufbau und XML-Schnittstellen
• Simulation eines "echten" Lebenszyklus einer Anwendung auch über Requests hinaus
• Datenaustausch zwischen Anwendungsinstanzen (beispielsweise mehreren Usern)

Als nächstes wird das ganze in Teilprobleme unterteilt. Man pickt sich nach und nach aus dem großen Ganzen Teilprobleme heraus und versucht sie so zu lösen, dass sie funktionieren. Beispielsweise das Manipulieren der Webseite per Ajax-Request:

• Wie identifiziere ich die einzelnen Komponenten? Lösung: Sie erhalten eine ID, die ich im Client und Server immer kenne. Die ID wird zentral immer vergeben und neue Komponenten (beispielsweise ein neues Span-Tag) kriegt immer auch eine neue ID.
• Wie werden Komponenten beeinflusst? Ansatzpunkte: Man kann neue HTML-Tags erzeugen, bestehende löschen oder auch bestehende beeinflussen bei Attributen und Style-Tags.

Das alles klingt bereits jetzt nach viel Arbeit im Detail und das ist es auch. Da ist dann noch lange keine Zeile Code geschrieben. Sicher kann man auch langsam loslegen und experimentieren, wobei das bei sowas durchaus schwierig sein kann.

Zitat von kampfgnom

und hab zum teil den Code von mepeisen nciht verstanden.

hmmm.
Ich werde das ganze vielleicht sogar noch heute abend zum Download anbieten zusammen mit einem kleinen Tutorial. Dan kann man auch experimentieren und vielleicht so hinter den Code kommen. Anfassen wirkt doch manchmal mehr als die graue Theorie

Zitat von kampfgnom

z.b. wann nimmt man eine neue Klasse? Man könnte doch so manches mit methoden lösen.

Ähhhm. Klassen kapseln Daten (=Attribute/ Objektvariablen) und Funktionalitäten (=Methoden). Wenn du mehrere Gruppen bilden kannst, kannst du theoretisch mehrere Klassen bauen
Wenn du einfach etwas entwickelst, insbesondere kleinere PHPs oder Webseiten, macht man sich darüber kaum Gedanken. PHP ist ja schliesslich auch eine Skriptsprache. Wenn du ein Framework entwickelst, willst du immer auch eine Basis bereitstellen, die man nutzen kann. Eine durchdachte Klassenhierarchie ist nie ein verkehrter Ansatz bei sowas.

[kampfgnom]

ok danke,
es hilft immer wenn es jmd zumindest versucht, ob ichs verstnaden hab ist mal ne andere sache...
werd mir dann mal dein Framework Runterladen und anschauen ob ich damit zurecht komme.

Vielen Dank für die Tipps

[Koala]

Hier gibts ein gutes, kleines Tutorial zum Thema PHP/OOP:

http://www.phpit.net/article/simple-mvc-php5/5/

[Ben]

Hi,
allein die objektorientierte Programmierung anwenden zu können reicht aber meiner Erfahrung nach nicht aus. Es ist eben gerade mehr, als zu wissen, wie man Daten kapselt, Schnittstellen anbietet und implementiert oder Design Patterns anwendet.

mepeisen hat das schon super auf den Punkt gebracht.
Nichtsdestotrotz stimme ich dir zu, dass die objektorientierte Sichtweise im Bezug auf die Anwendungsstruktur eigentlich ein absolutes Muss ist.

PS:
Willkommen beim Developer's Guide.

[Koala]

Danke für die Begrüßung

na ja - ob OOP ein MUSS ist ?

Es wird heutzutage beruflich verlangt - als PHP-Anfänger würd ich allerdings erst mal prozedural anfangen.

Aber wer oft programmiert, der wird immer wieder über Klassen/OOP stolpern
- z.B. bei Javascript oder wenn man was ändern muß in einer mysql-Klasse oder beim phpmailer, smarty ...

Es ist also nur von Vorteil, OOP nachvollziehen zu können.

edit:
ach so - ich hab ein Tutorial geschrieben über die prozedurale vorgehensweise:
http://www.jakoby-edv.de/tutorial

... ist aber noch nicht ganz fertig

[Ben]

Zitat von Koala

na ja - ob es ein MUSS ist ?

Nein, ist es sicher nicht. War vielleicht etwas missverständlich geschrieben.

Aber du sagst es ja selbst:

Zitat von Koala

Aber wer oft programmiert, der wird immer wieder über Klassen/OOP stolpern
[..]
Es ist also nur von Vorteil, OOP nachvollziehen zu können.

Man wird nicht nur darüber stolpern, sondern man wird auch irgendwann lernen, warum es sinnvoll sein kann, Funktionalität in Klassenstrukturen abzulegen. Aber das ist ja eigentlich schon wieder ein anderes Thema.

Dass es auch ohne objektorientierte Strukturen geht ist unzweifelbar richtig.

[kampfgnom]

Hi! ich muss diesen Thread nocheinmal aus der versenkung zurückholen!

Zitat von mepeisen

Und wie mach ichs heute? Ich lege nicht einfach so los. Nun, gewissermaßen schon, weil mir 5 bis 6 Blätter mit Zeichnungen als Konzept reichen, wobei man sowas eher einem Genie mit Hang zum Wahnsinn abkauft und keinem Entwickler . Aber nichts destotrotz sind dort Wochen in die Lande gezogen, wo ich immer mal in einer freien Minute oder wenn im Fernsehen Werbung lief oder wie auch immer darüber nachgedacht habe, bevor ich es zu Papier brachte.

Du hast alles aufgeschrieben. Da interresiert mich jetzt mal was genau di da aufschreibst.
Zur Zeit bin ich dabei mir eine Art Framework zu basteln (nicht wirklich, letztendes nur um zu lernen) und was ich dabei gerade gelernt habe, ist das mein Konzept nicht wirklich aufgeht.
Ich hab halt einfach mal so drauf los geschrieben.

Daher meine Frage:
Was schreibt ihr euch vorher genau auf? Meinetwegen als Beispiel das ZF.
Wenn ihr sowas Planen und schreiben müsstet, wie würdet ihr rangehen.
Also MVC-Prinzip und naja ihr kennt ja sicher alle das ZF.

Schreibt ihr euch nur die Anforderungen auf, so wie das mepeisen mal erwähnt hat. Oder macht ihr euch konkrete gedanken über Klassen die ihr braucht.

Naja, das lässt sich sicher nicht so einfach beantworten, aber deswegen frag ich ja. Wenn es einfach wäre, dann hätt ich ja auch von alleine draufkommen können

Also dann, fröhliches schreiben

[mepeisen]

Wenn du nicht weisst, wie du loslegen sollst, dann eigentlich daher, dass das aktuelle Problem für dich zu komplex ist. Also legst du am besten immer mit einer Anforderungsliste los. Was soll ein solches Framework leisten? Welches Themengebiet behandelt es? Welche Vorgaben soll es machen? Welche Annahmen treffen? Es gibt genug Beispiele, wo ein Framework zunächst als eine Art lose Bibliothek startet und nicht komplett neu auf der grünen Wiese. Manche Frameworks wachsen erst nach und nach zu etwas, was man Framework nennen könnte. Daher ist es auch für Frameworks ein guter Start, sich typische Problemstellungen, die man immer wieder hat, herauszunehmen und sie in einer Art Bibliothekssammlung zu lösen. Die Lösungen sollten durchgängig sein. Aber ein Framework ist ebend auch eine solche Bibliothek. Wie ich oben schon geschrieben hatte: Man zerlegt das Problem in Teilprobleme und verschafft sich dadurch eigentlich zwangsläufig einen Überblick, was man eigentlich machen will.

Was man sich dabei herauspickt, ist fast schon zweitrangig. Es gibt genug Problemstellungen, die man im Rahmen eines Frameworks lösen kann. Da wäre zum Beispiel die Frage nach Fehler-Behandlung. Nun kommt es halt stark darauf an, was für Teilprobleme identifiziert wurden. Bei einer Datenbank-Schnittstelle (Zend_DB) möchte man folgendes:
Eine allgemeine Zugriffsklasse unabhängig vom Datenbank-Typ.
Man benötigt also eine Abstraktionsschicht, mit der man auf eine Datenbank zugreifen kann und eine Art Treiber- oder Implementierungsschicht für unterschiedliche Datenbanken.

So entsteht nun nach und nach ein Klassenmodell. Man benötigt Klassen für eine Datenbank-Verbindung, für eine Datenbank-Tabelle. Man benötigt eine Lösung für das Problem: Wer legt Datenbankverbindungen an? Wer verwaltet sie?

Ich denke, wenn du derart strukturiert vorgehen willst oder aufgrund der Größe eines Problems auch musst, empfehle ich, UML zu lernen. Und zwar nicht nur Klassendiagramm, sondern mehr. So Sachen, wie beispielsweise Aktivitätsdiagramme, Objektfluss u.ä. lassen sich mit UML-Diagrammen sehr gut zu Papier oder in ein UML-Programm bringen. Das hilft, sein Problem strukturiert und zielführend zu lösen. Und prinzipiell ist das, was ich an Notizen benötige, nicht viel mehr als ein UML-Diagramm. Auch wenn ich mich nicht immer an die sturen Vorgaben halte, wie eine Aktivität zu zeichnen ist

[kampfgnom]

Vielen dank mepeisen für deinen sehr ausführlichen Beitrag.
Ok also ich möchte das ganz nocheinmal kurz für mich zusammenfassen:

1. Teil Problem raussuchen
2. Dann anhand eines UML-Diagramm dieses Problem auf "Klassenstruktur" bringen (Also jetzt bei der Datenbank zum Beispiel: Abstraktionsklasse für Treiber)

Das so lange machen bis man Alle Probleme gemeistert hat.

Da habe ich aber gleich nocheimal eine Frage, sollte man sich nicht eigentlich erst mit den großen, ich nenn sie jetzt einmal "globalen" Problemen beschäftigen, sowas wie Fehler Behandlung, Abhängigkeiten, etc?

grüße
Gabriel

[mepeisen]

Das kommt drauf an, was du vorhast. Bei sowas mache ich mir eigentlich immer eine Abhängigkeitsliste, also welches meiner Teilprobleme von anderen abhängig ist und hoffe, dass ich eines finde, das von nichts abhängt Voraussetzung ist, dass du dir bereits einen Überblick verschafft hast, das sollte klar sein.

Ne, im Ernst. Fehlerbehandlung ist ein klassisches Beispiel, da sowas schon sehr zentral ist und eine saubere Fehlerbehandlung, die zieht sich durch das gesamte Framework durch. Ob du Datenbankzugriffe machst oder Berechnungen. Fehler wollen erkannt und zurückgegeben werden. Das Framework kann die behandeln, dann hast du zwangsläufig auch sowas wie eine Fehlerpräsentation (HTML-seitig wie auch immer) oder du entscheidest dich, dass du (mit PHP5 und mein Favorit) einfach Exceptions wirfst und die Anwendung damit halbwegs sinnvoll umgehen muss. Geschmacksache und eine Frage, was du willst.

Aber an dem Beispiel sieht man auch wie schnell sowas nicht mehr zielführend ist. Wenn du beispielsweise in Datenbankzugriffen Fehlerhandling brauchst, um Fehler zu melden/ zu protokollieren usw. Aber wenn du gleichzeitig beispielsweise zum Übersetzen der Fehlertexte Datenbankzugriffe hast, lässt sich sowas für Nicht-Chaoserprobte-Genies schwer stabil realisieren und zielführend ist es eigentlich auch nicht in meinen Augen

[kampfgnom]

So ich hab jetzt mal was ausprobiert
Ich hab mich einfach mal rangesetzt und ganz grob in nem Diagramm aufgeschrieben:

was will ich jetzt von euch?! Naja ihr sollt mich schon im Ansatz fertig machen
Mir wärs zwar lieber ihr würdet sagen: Toll haste das gemacht.
Aber wenns scheiße is, dann is es scheiße

Und nich zimperlich sein!!

[mepeisen]

Ich empfehle dir, nochmal typische Requests und Anwendungsfälle darauf abzubilden. Um ein Gefühl dafür zu kriegen, was bei deinem Modell passiert, wer welche Objekte anlegt. Beispiel:
-> FrontController fängt an
-> FrontController legt Template anhand der URL fest o.ä.
-> FrontController erfragt eine typische Konfigurationseinstellung
-> FrontController verarbeitet Daten und greift dazu ggf. aufs Modell zu
-> Modell fordert eine Datenbank-Verbindung an, die anhand der Konfiguration erstellt wird.
-> Das Template wird je nach Ergebnis des FrontController mit Daten/Modellen oder auch einem Fehler gefüttert, das es dann anzuzeigen hat.

Bemerkenswert finde ich, dass du die Fehler als solche bzw. die Fehlerinformation und deren HTML-Darstellung trennen willst (so verstehe ich es). Das ist auch durchaus sinnvoll. So kann man Fehler, wie beispielsweise SQL-FehlerCodes, die man einem User (auch saus Sicherheitsgründen) nicht zumuten will, zwar Loggen, aber als allgemeinen Fehler auf der Oberfläche ausgeben.

Weiter so ))

[kampfgnom]

Zitat von mepeisen

Ich empfehle dir, nochmal typische Requests und Anwendungsfälle darauf abzubilden. Um ein Gefühl dafür zu kriegen, was bei deinem Modell passiert, wer welche Objekte anlegt. Beispiel:
-> FrontController fängt an
-> FrontController legt Template anhand der URL fest o.ä.
-> FrontController erfragt eine typische Konfigurationseinstellung
-> FrontController verarbeitet Daten und greift dazu ggf. aufs Modell zu
-> Modell fordert eine Datenbank-Verbindung an, die anhand der Konfiguration erstellt wird.
-> Das Template wird je nach Ergebnis des FrontController mit Daten/Modellen oder auch einem Fehler gefüttert, das es dann anzuzeigen hat.

Bemerkenswert finde ich, dass du die Fehler als solche bzw. die Fehlerinformation und deren HTML-Darstellung trennen willst (so verstehe ich es). Das ist auch durchaus sinnvoll. So kann man Fehler, wie beispielsweise SQL-FehlerCodes, die man einem User (auch saus Sicherheitsgründen) nicht zumuten will, zwar Loggen, aber als allgemeinen Fehler auf der Oberfläche ausgeben.

Weiter so ))

mhmm, du schreibst, das der Frontcontroller hier viel Verarbeitet.
Aber letztendlich splittet er ja nur (zu mindest vor meinem Geistigen Auge) die URL und ruft anhand eines Vorher Konfigurierten Schemas das Model auf (MVC?).
So, da muss der FrontController ja letztenendes nich viel machen, oder täusche ich mich?!

Das mit den Fehlern, kommt daher das wenn auf ner Seite mal Plötzlich eine Exception geworfen wurde dann sieht das sehr unschön aus und is auch ncih besonders sicher.
Außerdem würde da ja auch zum Beispiel ein ERROR 404 darunter fallen.

Naja gut ich werd mich nochmal daran setzen.
Danke aber erstma bis hierhin, dieses Forum is echt Klasse

Ok, jetzt hab ich nochmal sozusagen den Weg vom Request bis zur Ausgabe veranschaulicht:

[robo47]

nach dem Frontcontroller sollte denke ich erstmal der Controller des Moduls kommen und der nutzt dann betreffende Models und unter umständen, umleitung, fehler etc kann es von dort aus dann wieder zu einem anderen controller gehen der wiederrum Models nutzt und dann irgendwann am ende kommt dann aufgerufen aus dem Controller des letzen Moduls der aufruf des Views (der wiederrum kann eine templateengine nutzen) und es kommt zu Ausgabe (was ja alles sein kann von html über xml [feeds, sitemap], pdf, csv, txt ...... lässt sich fortsetzen)

[kampfgnom]

Zitat von robo47

nach dem Frontcontroller sollte denke ich erstmal der Controller des Moduls kommen und der nutzt dann betreffende Models und unter umständen, umleitung, fehler etc kann es von dort aus dann wieder zu einem anderen controller gehen der wiederrum Models nutzt und dann irgendwann am ende kommt dann aufgerufen aus dem Controller des letzen Moduls der aufruf des Views (der wiederrum kann eine templateengine nutzen) und es kommt zu Ausgabe (was ja alles sein kann von html über xml [feeds, sitemap], pdf, csv, txt ...... lässt sich fortsetzen)

Mhmm, das hab ich jetzt nicht verstanden...wie meinst du das mit Module?
Also zum Beispiel News modul Blog modul? aber das is doch letztendlich das Model, oder hab ich da was falsch verstanden?

Is schon gut das ich hier nochmal Frage

[robo47]

meines Wissens nach, (z.b. ZendFramework macht es so)
, gliedert sich ein Modul in 2 Teile, seinen Controller und sein Model das Model ist für die Daten zuständig, auslesen aus der db, reinschreiben etc ...
im Controller hast du aber verschiedene Methoden für verschiedene Aktionen, mal ein einfaches Beispiel:

class BlogController
{

	indexAction()
	{

	}
	showEntryAction()
	{

	}
	showCategorysAction()
	{

	}
	showTagsAction()
	{

	}
}

und aus diesen Methoden heraus wird dann auf die Models zugegriffen.

Beim ZendFramework wertet der FrontController über Routen die Url aus und erkennt passend welche Methode im welchem Controller aufgerufen wird. Die Arbeitet das ganze dann ab und danach wird der View genutzt zur Ausgabe.

[$traight-$hoota]

Ob man Module verwendet oder nicht und was in ein Modul reinkommt ist imo erstma nicht so wichtig.
Aber die Geschäftslogik besteht beim MVC-Prinzip nicht nur aus einem Frontcontroller, der wirklich nur als Einstiegspunkt dient und die Abarbeitung eines Request in Gang setzt. Vielmehr gibt es "normale" Controller, wie Benjamin schon geschrieben hat, die sich um die direkte Verarbeitung eines Requests kümmern. Je nach Art des Request ruft der Frontcontroller den zugehörigen Controller quasi als Fachbearbeiter auf. Der kümmert sich dann darum, dass alle zur Ausgabe nötigen Daten beschafft und aufbereitet werden, gegebenenfalls leitet er dabei Unteraufgaben an weitere Controller weiter, das ganze nennt man dann .
Ich vermute, Du hast diese Aufgaben dem Model zugeschrieben, aber das ist in erster Linie eben nur als Datenmodel gedacht und enthält selber keine weitergehende Datenverarbeitung. An dieser Stelle ist es zwar mitunter strittig, was im Model an Verarbeitung erfolgen und was im Controller geschehen sollte, aber das ist eher nebensächlich. Die Aufgabe des Model ist einfach, die Daten darzustellen, während sich der Controller um die Verarbeitung kümmert.