Gibt es dazu eine DEMO
0 0 0 0 0 5 
Matti Mäkitalo
0 
Matthias Apsel
0 0 0 0 0 
Der Martin
0
0
-2 2 0 
Rolf B
Gibt es dazu eine DEMO
Christian Kruses. Thema, Wiki Artikel ToDo zum MVC.
MFG
akzeptierte Antworten
Gibt es dazu eine DEMO
Matti Mäkitalo
Bewertung: +5, 5 Stimmen
-
-
-
Selbstverständlich wird derjenige der ein Ticket schließt bzw. eine Aufgabe auf erledigt setzt, seine hierzu geleistete Tätigkeit dokumentieren, also da reinschreiben was er gemacht hat.
Was den MVC betrifft; ich hab da noch Einiges dazugeschrieben, also wie ich das gemacht habe und dazu auch den gesamten CODE offengelegt. Typisch für den MVC ist, daß mit denselben Daten unterschiedliche Views erzeugt werden. Was auch gleichbedeutend mit der Zweckbestimmung für dieses Entwurfsmuster ist.
So arbeitet meine Anwendung/Demo konsequenterweise mit mehreren Templates zum Erzeugen der veschiedenen Sichten (Views) auf die Daten. Welche Templatedatei geladen wird, steht HTML Quelltext was diesen Code sehr wartungsfreundlich und auch skalierbar macht. Z.B. das Einfügen von Attachments, Anhängen von Dokumenten an ein Ticket.
MFG
-
Was den MVC betrifft;
Mit MVC hat dein Code nicht viel zu tun. Da fehlt zum einen das Modell, das M in MVC. Stattdessen übernimmt dein Controller die Aufgaben des Modells. Das kann man so machen, dann sollte man aber nicht MVC dranscreiben.
-
Was den MVC betrifft;
Mit MVC hat dein Code nicht viel zu tun. Da fehlt zum einen das Modell, das M in MVC. Stattdessen übernimmt dein Controller die Aufgaben des Modells. Das kann man so machen, dann sollte man aber nicht MVC dranscreiben.
Natürlich gibt es das Modell aber sowas von:
Lt. Wiki:
Das Modell enthält Daten, die von der Präsentation dargestellt werden.
In Fakt, das Modell ist die Klasse
ToDo. Die Instanz dieser Klasse transportiert nämlich sämtliche Daten bzw. referenziert diese Daten, also Benutzereingaben und auch die Daten aus dem Repository die zur Darstellung ins View gerendert werden. Hierzu gibt es Eigenschaften und Methoden.Unabhängig vom DAL haben diese Daten sogar immer dieselbe Struktur. Was auch den Transportlayer transparent macht.
Im Übrigen dient mein Controller dazu die Benutzereingaben zu validieren. Wobei auch das Umschalten zu einer anderen Sicht (View) eine Benutzereingabe ist. Die gesamte Logik ist, und das haben Webanwendungen so an sich, über eine Parameterkontollstruktur abgebildet.
MFG
-
Hallo,
deine Klasse ToDo macht viel zu viel und widerspricht daher dem SRP. Funktionen darin umfassen:
- Tabellen anlegen
- abfragen des Modells (das Modell ist der array mit dem Namen STASH, nicht die ToDo-Klasse)
- escapen von Werten (htmlspecialchars in ToDo? Obwohl ToDo gar nichts mit HTML zu tun hat?)
- Validierung von User-Eingaben (in control(), _validate($date))
- Ausgabe von human-readable Fehlertexten (ich interpretiere die Aufrufe von dd() zumindest so)
- Es weiß Bescheid über Parameter ToDo::param und steuert daraufhin seine Funktion. Diesbezüglich hat es Controller-Charakter.
- Business-Logik, z.B. zum anlegen/schließen von Todos => dies gehört üblicherweise in ein Model.
Man merkt deutlich deinen Einfluss auf das Klassendesign, was sich vom heute üblichen Klassendesign merklich unterscheidet. Ich würde jedem empfehlen, sich dieses Klassendesign nicht anzueignen.
Du schreibst halt gerne große Klassen, welche üblicherweise auch Monolithen sind. Gängige Praxis ist aber, viele und spezialisierte kleinere Klassen zu schreiben. Wesentlicher Vorteil dieser Praxis ist es, dass kleinere Klassen besser testbar sind. Dein Code ist quasi nicht als Unit-Test testbar (streng genommen geht es, aber du kannst es z.B. nicht von einer DB abklemmen).
Für ein modernes MVC-Framework in PHP schau dir Symfony an. Dort gibt es auch einen "Einsteiger-Guide" MVC-Frameworks, den ich gerne empfehle: https://symfony.com/doc/current/introduction/from_flat_php_to_symfony.html
Viele Grüße Matti
-
Hallo Matti Mäkitalo,
Für ein modernes MVC-Framework in PHP schau dir Symfony an. Dort gibt es auch einen "Einsteiger-Guide" MVC-Frameworks, den ich gerne empfehle: https://symfony.com/doc/current/introduction/from_flat_php_to_symfony.html
Den Einsteiger-Guide finde ich wirklich gut geschrieben. Danke für den Link.
Bis demnächst
Matthias--
Du kannst das Projekt SELFHTML unterstützen,
indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt. -
Dieser Beitrag wurde gelöscht: Beitrag ist Spam.
-
Für ein modernes MVC-Framework in PHP schau dir Symfony an.
Wozu diese Empfehlung? Ich habe mir schon viele FWs angeschaut und bin jedesmal froh darüber daß ich damit nicht arbeiten muss.
MFG
-
Ich habe mir schon viele FWs angeschaut und bin jedesmal froh darüber daß ich damit nicht arbeiten muss.
Dann solltest Du aber wissen, dass es einem Dritten mit dem, was Du als Dein Framework bezeichnest, ebenso gehen kann.
Du kennst das Deine, subsitutierst also Lernaufwand durch Programmieraufwand. Die Entwicklung Deines Zeugs wird zudem durch Deine Interessen und durch von Dir definierte Aufgaben getrieben. Ich bin sehr weit davon entfernt, zu behaupten, dass Dein Vorgehen schlecht oder gar falsch sei - auch weil ich immer wieder sehe, dass irgendein Framework irgendetwas eben nicht (oder nicht sicher) kann und Implementationsversuche dann in Nebenläufigkeiten mit wahrhaft grausigen Ergebnissen oder kaum zu erkennenden Sicherheitsproblemen enden - aber mancher sieht das eben anders.
-
Ich habe mir schon viele FWs angeschaut und bin jedesmal froh darüber daß ich damit nicht arbeiten muss.
Dann solltest Du aber wissen, dass es einem Dritten mit dem, was Du als Dein Framework bezeichnest, ebenso gehen kann.
Nein. Es gibt nur einen der mit meinem FW entwickelt. Und der ist froh daß er den Code den er heute schreibt aufgrund seiner Einfachheit morgen noch versteht. Und dabei bleibt es auch.
MFG
-
Hallo,
Dann solltest Du aber wissen, dass es einem Dritten mit dem, was Du als Dein Framework bezeichnest, ebenso gehen kann.
Nein. Es gibt nur einen der mit meinem FW entwickelt. Und der ist froh daß er den Code den er heute schreibt aufgrund seiner Einfachheit morgen noch versteht. Und dabei bleibt es auch.
wenn du also gar nicht vorhast, dieses Framework anderen zur Verfügung zu stellen ... warum preist du es dann hier immer wieder an, als wäre es das Beste seit geschnitten Brot? Werbung für ein Produkt, das nicht erhältlich ist, ergibt wenig Sinn.
So long,
Martin--
Ich stamme aus Ironien, einem Land am sarkastischen Ozean.-
Hallo,
Dann solltest Du aber wissen, dass es einem Dritten mit dem, was Du als Dein Framework bezeichnest, ebenso gehen kann.
Nein. Es gibt nur einen der mit meinem FW entwickelt. Und der ist froh daß er den Code den er heute schreibt aufgrund seiner Einfachheit morgen noch versteht. Und dabei bleibt es auch.
wenn du also gar nicht vorhast, dieses Framework anderen zur Verfügung zu stellen ... warum preist du es dann hier immer wieder an, als wäre es das Beste seit geschnitten Brot? Werbung für ein Produkt, das nicht erhältlich ist, ergibt wenig Sinn.
Ich preise es ja nicht an. Vielmehr schreibe ich nur über mein Hobby genauso wie andere über ihre Hobbies schreiben.
Und ich bin froh daß mir dieses Hobby geblieben ist!
-
Hallo pl,
Ich preise es ja nicht an.
Das ist vielleicht nicht deine Absicht, aber doch – genau das tust du…
Vielmehr schreibe ich nur über mein Hobby genauso wie andere über ihre Hobbies schreiben.
Dann nutze dafür doch dein Weblog?
Freundliche Grüße,
Christian Kruse
-
-
-
Dann solltest Du aber wissen, dass es einem Dritten mit dem, was Du als Dein Framework bezeichnest, ebenso gehen kann.
Nein. Es gibt nur einen der mit meinem FW entwickelt. Und der ist froh daß er den Code den er heute schreibt aufgrund seiner Einfachheit morgen noch versteht. Und dabei bleibt es auch.
Wir sind glücklich, wenn Du es bist. Deine Herangehensweise ist ja auch komplett legitim. Für Dich.
Aber lass uns das doch mal etwas weiter spinnen. Wir gehen vermutlich konform, wenn wir unterstellen, dass Du und Dein Framework vermutlich nicht alleine die Basis der Softwareentwicklung im 21.ten Jahrhundert bilden werden, korrekt?
Wenn nun Deine Strategie „ich bau mein eigenes Framework, weil ich damit klarkomme“ die „korrekte“ sein soll, dann darf man das wohl auch für alle anderen Teilnehmer und Entwickler des großen Ganzen annehmen, korrekt?
Also sollte ein jeder sein eigenes Framework bauen, richtig? Hältst Du es für möglich, dass ein öffentlich entwickeltes, dokumentiertes und von einer breiten Community entwickeltes Framework Vorteile gegenüber einer jeweils selbstgestrickten Lösung haben kann?
-
-
-
-
Was den MVC betrifft;
Mit MVC hat dein Code nicht viel zu tun. Da fehlt zum einen das Modell, das M in MVC. Stattdessen übernimmt dein Controller die Aufgaben des Modells. Das kann man so machen, dann sollte man aber nicht MVC dranscreiben.
Natürlich gibt es das Modell aber sowas von:
Den Dump eines Modells kann man jetzt auch im Browser ausgeben, der Dump zeigt das Modell genauso wie es in das Template gerendert wird, zweckmäßigerweise sind die Namen der Eigenschaften gleichzeitig auch die Namen der Platzhalter.
Ein MVC macht also auch das Debuggen einfach 😉
MFG
PS: Ich bin auf der Suche nach einer neuen Templating-Enging, was nehmt Ihr das so, Empfehlung?
-
-
-
-
-
-
s. Thema, Wiki Artikel ToDo zum MVC.
Noch ein paar Anmerkungen zu euren MVC Wikiartikel:
Wenn man den MVC gemäß Entwurfmuster konsequent umsetzen will, ist das Modell eine Instanz einer dedizierten Klasse. Bekanntlich lebt eine Instanz nur solange bis keine Referenzen mehr auf sie verweisen und umgekehrt. Was OOP veranlasst den Destruktor zu rufen.
Bei einer konsequenten Umsetzung des MVC bietet es sich von daher an, den Destruktor zu nutzen um Änderungen am Modell wieder persistent zu machen.
das könnte z.B. so aussehen
function __destruct(){ $this->write(); }Das setzt natürlich voraus, daß es einen transparenten Data Access Layer (DAL) gibt und auch, daß Änderungen am Modell und nur da erfolgen. Ein solcher DAL ist unabhängig von MySQL und damit stehen DB eigene Methoden wie z.B. Datumsfunktionen, Trigger, Indizies u.dgl. die MySQL so bietet, bei einer Mustermäßigen MVC Umsetzung garnicht zur Verfügung. Derartige Funktionalitäten sind allesamt in Methoden des Modells zu implementieren.
MFG
-
Bei einer konsequenten Umsetzung des MVC bietet es sich von daher an, den Destruktor zu nutzen um Änderungen am Modell wieder persistent zu machen.
Das könnte man in einem Active-Record-Modell so machen, im Artikel benutzen wir aber ein Data Mapper-Modell. Das Domain-Model weiß nichts von der Datenbank, es weiß auch nicht, wie es sich zu speichern hätte. Dort macht es also keinen Sinn im Destruktor eine Speicher-Methode aufzurufen. Das Resource-Model befindet sich bei uns per Konstruktion immer in einem konsistenten Zustand mit der Datenbank. Bei jedem Aufruf von
fetchoderupdatewird das betroffene Modell automatisch mit der Datenbank synchronisiert. Hier macht es also auch keinen Sinn im Destruktor nochmal etwas zu speichern, das sowieso schon aktuell ist.-
Dann hast Du wohl keine lose Kopplung an den Data Access Layer. Und damit auch keine saubere Trennung des DAL vom Modell. MFG
-
Dann hast Du wohl keine lose Kopplung an den Data Access Layer. Und damit auch keine saubere Trennung des DAL vom Modell.
Troll.
-
-
-
Hallo pl,
Es setzt voraus, dass es einen DAL gibt, ja. Und es setzt eine definierte Schnittstelle am Modell voraus, an den der DAL andockt. Dafür gibt es diverse Konzepte, die einzige Notwendigkeit ist, dass Modell und DAL zusammenpassen.
Der konkret verwendete DAL kann ein solcher sein, der universell ist und einen minimalen Standard SQL Sprachumfang voraussetzt. Das ist aber keine zwingende Forderung. Es kann auch einer sein, der abstrakt an das Modell andockt und für mehrere Datenbanken spezifische SQL Generatoren bereit stellt.
Einen Destruktor würde ich allerdings nie verwenden, um write auszulösen. Es gibt meines Wissens keine definierte Reihenfolge für ihre Ausführung, d.h. es kann sein, dass der Schreibvorgang auf bereits zerstörte Objekte zugreifen muss. Destruktoren sollen nicht mehr aus den Objekt "hinausgreifen". Sie sind dafür da, Ressourcen freizugeben, die explizit vom Objekt verwaltet werden, für das der Destruktor läuft. Schreiben in die DB ist meiner Auffassung nach mehr.
Rolf
--
sumpsi - posui - clusi-
Fetch Object ist auch ganz interessant in Sachen MVC. Abe wie schon mehrfach festgestellt, es ist letztendlich nur eine Frage ob Daten Instanzen mit eigenen Methoden sind oder ob Daten durch Methoden anderer Instanzen bewegt werden.
Wie man das umsetzt ist keine Frage irgendwelcher Entwurfsmuster sondern eine Frage der Zweckmäßigkeit und eine Frage des handwerklichen Geschickes derjenigen die das umsetzen. MFG
-
Fetch Object ist auch ganz interessant in Sachen MVC. Abe wie schon mehrfach festgestellt, es ist letztendlich nur eine Frage ob Daten Instanzen mit eigenen Methoden sind oder ob Daten durch Methoden anderer Instanzen bewegt werden.
Wie man das umsetzt ist keine Frage irgendwelcher Entwurfsmuster sondern eine Frage der Zweckmäßigkeit und eine Frage des handwerklichen Geschickes derjenigen die das umsetzen. MFG
Und natürlich eine Frage von Pioniergeist und Kreativität!
-
-
-
