manuakasam

update
Bitte dem unteren Posting Beachtung schenken, dieser hier ist nicht mehr direkt Relevant
http://www.php.de/software-design/61...tml#post469982 (Kritik - OOP Event-Calendar (Konzept+Code))
/update



Hallo allesamt,

ich hoffe ich darf eine solche Frage bzw. Bitte hier im Forum posten, wenn es das falsche Forum ist, dann entschuldige ich mich hiermit direkt und bitte um ein Verschieben oder Löschen des Beitrages

Zu meiner Bitte:
Ich habe mich in den vergangenen Monaten immer wieder etwas in OOP eingelesen und versucht mir einige Dinge anzueignen, jedoch habe ich in meinem direkten Umfeld einfach niemandem, der mehr Erfahrung hat als ich und somit auch niemanden, der direkt Kritik an meinem Code ausübt. Aus diesem Grund wende ich mich nun an dies Forum hier!

Ich entwickle derzeit ein Event-Calendar mit spezifischen Anforderungen welche mir hier auf der Arbeit gegeben werden. Aufgrund persönlicher Weiterbilung und Interesse an das Lernen der Materie mag ich dabei nicht auf Fertigscripte zurckgreifen (zum einen) und auch habe ich nichts gefunden, was den Anforderungen absolut gerecht wird (zum anderen).


Hier einmal der gesamte bisherige Code:
./DUIT/index.php (nicht wirklich relevant)
./DUIT/config.ini
./DUIT/Calendar.php
./DUIT/Calendar/Event.php
./DUIT/Calendar/EventMapper.php
./DUIT/Calendar/loc/de.php

Das dazugehörige Datenbanklayout

Ordnerstruktur ist halt nach dem PEAR-Standard ausgerichtet und somit auch die Namensgebung der Klassen. index.php sowie config.ini sind nur zu Testzwecken und befinden sich sonst natürlich woanders.


Meine konkreten Fragen:

1) In der Event.php bzw der dazugehörigen Klassen weise ich derzeit recht kompliziert die einzelnen Daten eines Events zu. Die kann ich bestimmt besser lösen, da gibt es jedoch zig verschiedene Varianten zu.

2) In der Calendar.php sind die unteren printXY() Funktionen enthalten. Als View-Elemente sollten diese überhaupt direkt in der Klasse enthalten sein, oder gliedert man soetwas besser in eine Calendar/View.php aus? (Sowie ich das nun so frage, kommt mir das jedenfalls schon viel sinniger vor oO)

3) Bei den ganzen Datumsgeschichten bezüglich Lokalisierung:
Ich bin leider sehr unbewandert in Datumsgeschichten und lokalisierung, bietet PHP selbst da komplette lokalisierungen für alle möglichen Sprachen (inklusive asiatischer Sprachen?) oder ist das so wie ich das gelößt habe in Ordnung? (<= daran habe ich nämlich irgendwie zweifel )

4) Die Sache mit dem EventMapping mache ich glaube ich auch grundlegend "falsch" aber das ist einfach was, da muss ich mich noch viel besser einlesen.



Ich weis, dass das nicht gerade wenig Code ist und wohl die wenigsten großartig Lust haben über soetwas drüber zu schauen. Ich bin jedoch für jeglichen Kommentar mehr als dankbar!


/edit
Achja, ich benutze dabei auch einige Teile des Zend_Frameworks, aus welchen sich besonders Datenbanktechnisch mit SICHERHEIT viel, viel, viel mehr rausholen lässt, aber aus dieser Dokumentation werde ich persönlich mal überhaupt nicht schlau Gute Tutorials zu finden ist da leider echt eine Herausforderung.


Mit freundlichen Grüßen

Sam

Mister Ad

nikosch

Hallo, willkommen im Forum!

Ich habe mir jetzt bloß die eine Datenbanktabelle angesehen und sehe dort schon große Kritikpunkte. Wenn ich das Datum, Veranstaltung und Location in einem Datensatz sehe, kann ich Dir nur raten, das Konzept der Normalisierung anzusehen und umzusetzen. Erst dann solltest Du weitere Implementierungsoptionen diskutieren.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dr.e.

Um mich Nikosch anzuschließen:
Aus Sicht der OOP hast du es an dieser Stelle mit mehreren Domänen-Objekten zu tun:

• Kalender
• Jahr
• Monat
• Tag
• Event
• Location
• Adresse

Man muss sicher nicht alle Objekte modellieren (Tag, Monat, Jahr), jedoch hätte ich zumindest erwartet, dass eine Location als eigenes Objekt vorgesehen ist. Alles andere ist nur ein Row-Data-Gateway mit allen seinen Nachteilen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

manuakasam

Danke schonmal für die Kritik!

Das mit der Location habe ich ganz zu Beginn auch gedacht, habe es aber Aufgrund der Gegebenheiten der Anwendung welche im Endeffekt dahintersteckt ausgelassen, aber das stimmt schon, eigentlich muss das raus...

Mit der Modellierung von Jahr Monat und Tag, das habe ich auch auf dem Konzeptpapier stehen. Immerhin ist ein Kalendar eine Anhäufung von Jahren, welche eine Anhäufung von Monaten ist, welcher X Tage implementiert ^^
Jedoch muss da doch klar gesagt werden, dass das ganze zwar Umsetzbar ist, jedoch denke ich, dass es performancetechnisch doch dann deutlich mieser wird :ß

@nikosch
Also Datum und Zeit sind doch losgelößt von einem Event? Oo
Das ganze habe ich gemacht, da Events über mehrere Tage gehen können und da gibt es halt verschiedene Möglichkeiten das ganze abzubilden.
1) Jedem Event ein date_from und date_to geben
2) Für jeden Event-Tag einen eigenen Datensatz

Ich finde Ansatz zwei interessanter und besser, einfach dadurch begründet, da sich die Eventzeiten (zB von einer Messe) an jedem Tag verändern können, die Informationen der Messe (Location, Titel, Etc) aber der gleiche bleiben.

Normalisierung ist mir ansonsten schon ein Begriff Und bzgl. der location, das habe ich ja oben schon angeschrieben, werde mir das nochmal durch den Kopf gehen lassen :>


@dr.e
Location und Adresse als eigene Domänen ist mir nicht ersichtlich, kannst du das einmal Begründen?

nikosch

Ja, ok, die zweite Tabelle hatte ich anfangs übersehen. Der Rest bleibt aber gültig. Von einer Doppelung von Locationangaben kann man im Vorfeld ausgehen. Mal ganz unabhängig von der Ausbildung als eigene Domainobjekte, schon DB-technisch ist das nicht korrekt modelliert.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

manuakasam

So guten Morgen

Nachdem man mir nun die Sache mit der Location nochmals unter die Nase gerieben hat, habe ich mich dann doch entschlossen das ganze ordentlich zu machen. Dabei ist mir dann auch direkt der Domainunterschied von Location und Addresse klar geworden... (jedenfalls denke ich, dass es das ist)

Ich habe das neue DB-Model mal gepostet klick me if you want to take a look

Ich denke mal so sollte das DB Model OK sein...
Ich denke nicht, dass ich "Verknüpfungstabellen" erstellen muss, welche dann nur zB loc_id <-> event_id enthalten, oder? Selbiges Spiel dann auch bei loc_id <-> adr_id

PLZ und Stadt zu trennen, da war ich noch nie wirklich ein freund von, auch wenn es rein theoretisch möglich wäre...

xm22

Mir ist gerade was aufgefallen: Du benutzt __set und gibst dort etwas zurück. Das geht nicht, denn Du sprichst das ja so an:
Da gibt es nichts zurück zu geben. Abgesehen davon -> htmlspecialchars gehört in die Ausgabe einer Variable, nicht in die Verarbeitung der Daten.

manuakasam

Hallo allesamt nochmal, ich habe mal mein Konzept (und Code auch schon ) aktualisiert und mag das gerne nochmal zur Kritik vorstellen:

@xm22
Ja, das stimmt und ist mir auch total einleuchtend. Das habe ich mal in irgendeinem PHP Buch aufgeschnappt (eigentlich ein recht gutes) und es ist leider irgendwie hängen geblieben, kA wieso ich das so gemacht habe...


Das Konzept

Was ist ein EventCalendar?

• Ein EventCalendar ist eine Sammlung von Jahren.
• Jedes Jahr ist eine Sammlung von Monaten.
• Jeder Monat ist eine Sammlung von Tagen.
• An jedem Tag können ein oder mehrere Events stattfinden.
• Ein Event ist dabei eine Veranstaltung oder ein Feiertag.
  • Eine Veranstaltung findet immer an einer Location statt, diese hat einen Namen
  • Eine Location hat auch immer genau eine Addresse
  • Eine Veranstaltung kann ein oder mehrere Daten besitzen.

Um dieses abzubilden, habe ich folgendes DB-Schema entworfen:
> Das Datenbank Schema

Das Klassenkonstrukt sieht dabei wie folgt aus:
> Link zur PHPDocumentor Ausgabe
(Oben rechts das Package DUIT_Calendar anklicken - sry, kenne mich mit dem phpdoc tool ned aus, wie man da was einstellt, damit der dinge direkt anzeigt ^^)


Derzeit habe ich nur die reinen Models implementiert. Die Views konzipiere ich gerade, vorgestellt als Use-Case habe ich mir das so

$cal = new DUIT_Calendar();
$view = new DUIT_Calendar_Viewer($cal);

echo $view->printCalendarSmall();
echo $view->printLatestEvents(int $count);
echo $view->printNextHoliday();

etc...

Wie zuvor auch, egal welches Feedback ich bekommen sollte, zum Code selbst, oder zum Konzept, ich bin für alles dankbar!

PS:
Die ganzen *_Db_*.php classes sind vom Zend_Framework abgeleitet, jeweils Active-Records und Row-Data-Gateways

Grüße, sam

Koala

hm ...

wo sind die Controller ?

Der Controller entscheidet anhand der Requestparameter welcher Subcontroller
zu laden ist und dieser holt die Daten aus dem Model (DB), verarbeitet sie
(ggf. mit "Actions") und dann gibt er die aufbereiteten Daten zur Ausgabe an die View.

Von daher paßt das nicht ins Konzept:

$cal = new DUIT_Calendar();
$view = new DUIT_Calendar_Viewer($cal);

echo $view->printCalendarSmall();
echo $view->printLatestEvents(int $count);
echo $view->printNextHoliday();

Wieso überhaupt drei echos ?

Es gibt nur ein echo bei $view->display();

und vielleicht noch
$view->getHeader();
$view->getContent($this->template);
$view->getFooter();

**************

hab jetzt mal auf den Link geklickt:

DUIT_CAL_1 = 'Januar' (line 13) - wieso Konstanten ? wieso kein Array ?

und bei den anderen Dateien seh ich nirgends einen MVC-Ansatz.

manuakasam

@Controller
Die sind ja auch noch garnicht da =) Derzeit sind das nur Models und die Views habe ich mittlerweile fertig. Die Controller sind nun auch da

@multiple echos
Naja ganz simple. Es sind verschiedene Views. Es gibt nicht nur einen View. Es gibt eine Mini-Kalender-Ansicht, eine Groß-Kalender-Ansicht, die Ansicht der letzten Events, nächsten Feiertage, eine größere darstellung der Events der nächsten X Tage/Wochen/MOnate

Das sind verschiedene Views, welche alle einzelnd durch die Controller angesprochen werden. Das Beispiel mit den Echos ist nur die Testausgabe, nicht die fertige implementierung

@konstanten
Das ist mir auch schon ein dorn im Auge gewesen. Das ganze wird auch noch als stdClass umgebastelt.

@mvc
Also wenn das ganze nun noch kein MVC ist, dann versteh ich das wirklich nicht :ß Was soll man den mehr tun, als die einzelnen Komponenten strikt voneinander zu trennen?