nicht angemeldet
Text mit Formular in Tabelle einfügen
Möchte sozusagen das es wie ein cms funktioniert nur natürlich viel einfacher. Habe eine Seite wo zum Beispiel Personendaten stehen. Möchte aber natürlich nicht jedes mal wenn eine neue Person hinzukommt alles in html bearbeiten, sonder ein Formular benutzen. Also da ist zum Beispiel ein Input wo "Name:" steht, dann trag ich einen Namen ein und wenn ich auf "Senden" klicke erscheint der Name unter den ganzen anderen Namen die auf der Seite stehen.
Wie realisiere ich das? Ist das Prinzip so ähnlich wie ein Gästebuch?
-
Hello und schönen Sonntag,
Möchte sozusagen das es wie ein cms funktioniert nur natürlich viel einfacher. Habe eine Seite wo zum Beispiel Personendaten stehen. Möchte aber natürlich nicht jedes mal wenn eine neue Person hinzukommt alles in html bearbeiten, sonder ein Formular benutzen. Also da ist zum Beispiel ein Input wo "Name:" steht, dann trag ich einen Namen ein und wenn ich auf "Senden" klicke erscheint der Name unter den ganzen anderen Namen die auf der Seite stehen.
Wie realisiere ich das? Ist das Prinzip so ähnlich wie ein Gästebuch?
Als erstes verschaffst Du Dir mal eine Übersicht über den Aufwand.
Dazu nimmst Du Dir kleine Zettelchen (z.B weiße für den Client und rote für den Server) und skizzierst Dir auf den weißen die Bildschirme, die Du brauchen wirst für- Einstiegsseite
- Anmeldung
- Normalannzeige
- Eingabeformular
- Korrekturformular (mit Löschfunktion?)
- Übersichtsliste (mit Blätterfunktion?)
- Suchformular
- Administrationsformular zur Einstellung der Konfiguration
- ???
und dann vermerkst Du Dir auf jedem Bildschirm die
- einfachen Textfelder (Skalare)
- Auswahl- ud Kontrollelemente (Selects, Radios, Checkboxen)
- Steuerelemente (i.d.R. Buttons und Links, requestbestimmend)
- Grids (i.d.R. sich wiederholende Listen von Textfeldern,
ergänzt durch Kontrollelemente und Steuerelemente)
Wenn Du die weißen kärtchen fertig hast, dann überlegst Du dir die roten, die auf die unteraschiedichen Requests reagieren sollen.
Wenn Du das alles fertig hast, dann lohnt es sich, das erste Mal "<?php" zu schreiben.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
So habe hier mal eine kleine Skizze gemacht, bin nicht früher zu gekommen ^^.
Reicht das für den Anfang?
-
So nach einigen hin und her habe ich mal das auf die Beine gestellt. Kann man sicherlich noch einfacher machen aber da muss ich mich halt erstmal reinarbeiten xD. Aber bei meiner Version wird das Bearbeiten schwer ^^...werde noch mal weiter schauen ist ja nur der Anfang. Die anderen beiden Dateien stell ich mal nicht hier rein, die sind nicht so spannend:
<?php $datei = fopen("spieler.txt","a+"); $wtcteam = $_POST["wtcteam"]; $gegnerteam = $_POST["gegnerteam"]; if($wtcteam == "" OR $gegnerteam == "") { echo "Bitte alle Felder ausfüllen!"; } else { fwrite($datei, "<table align=\"center\">"); fwrite($datei, "<tr>"); fwrite($datei, "<td width=\"150\" align=\"center\">"); fwrite($datei, $wtcteam); fwrite($datei, "</td>"); fwrite($datei, "<td width=\"150\" align=\"center\">"); fwrite($datei, $gegnerteam); fwrite($datei, "</td>"); fwrite($datei, "</tr>"); fwrite($datei, "</table>"); fclose($datei); } ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Formularübergabe</title> </head> <body> <form id="form1" name="form1" method="post" action="index.php"> <p>Unser Team: <input type="text" name="wtcteam" id="1" /> </p> <p>Gegner Team: <label> <input type="text" name="gegnerteam" id="gegnerteam" /> </label> </p> <p> <input name="Senden" type="submit" value="Eintragen" /> </p> </form> <p><br /> <a href="spielernamen.php">>>Gehe zur Liste<<</a></p> <p>>><a href="loeschen.php">Liste löschen</a><<</p> </body> </html>-
Hello,
So nach einigen hin und her habe ich mal das auf die Beine gestellt. Kann man sicherlich noch einfacher machen aber da muss ich mich halt erstmal reinarbeiten xD. Aber bei meiner Version wird das Bearbeiten schwer ^^...werde noch mal weiter schauen ist ja nur der Anfang. Die anderen beiden Dateien stell ich mal nicht hier rein, die sind nicht so spannend:
Und schon ist es passiert...
Erst gecoded und nicht gelpant und nun sollen die Anderen es richten :-)- Du verspielst die Möglichkeit, Daten und Darstellung getrennt zu halten.
- Du verspielst die Möglichkeit eines klar gegliederten und übersichtlichen
Konzeptes bei dr Steuerflußkontrolle
a.) Request erhalten und der passenden Ressource zuführen
b.) Auftrag ermitteln
c.) Daten übernehmen
d.) Daten prüfen
e.) Daten dazu holen, vervollständigen und verarbeiten
f.) verarbeitete Daten wegschreiben
g.) Ergebnis ermitteln und aufbereiten (nur Daten)
h.) Steuerelemente für Response festlegen und aufbereiten
i.) Darstellung auswählen
j.) h mit f und g zusammenführen
k.) Response abschickenOb man nach dieser Liste nun auch MVC-Patterns anwenden kann, überlass ich mal der allgemeinen Diskussion. Was habe ich vergessen in der Liste?
<?php
$datei = fopen("spieler.txt","a+");erst prüfen, ob fopen() auch geklappt hat.
$wtcteam = $_POST["wtcteam"];
$gegnerteam = $_POST["gegnerteam"];Erst prüfen, ob überhaupt ein POST-Request vorlag und ob die Variablen gesetzt sind!
Umkopieren von einer Variable in eine andere ohne jegliche weitere Verarbeitung ist Unsinn.
Benutze direkt die Werte in $_POST, dann weißt Du wenigstens, woher sie kamen
if($wtcteam == "" OR $gegnerteam == "")
{
echo "Bitte alle Felder ausfüllen!"; ### [1]nicht Datenübernahme, erste Schritte der Verarbeitung. Formulierung von Meldungen und
Absenden der Meldung mischen. Web-Client-Server-Technik ist plumpe Batchverarbeitung
}
else
{aus dem Folögenden eine Funktion machen!
nicht Daten und Darstellung vermischen, wenn es dafür keinen triftigen Grund gibt
fwrite($datei, "<table align="center">");
nicht mit den alten HTML-Attributen arbeiten, sondern CSS-Benutzung ermöglichen
fwrite($datei, "<tr>");
fwrite($datei, "<td width="150" align="center">");
fwrite($datei, $wtcteam);durch diese Art der Speicherung ^ werden leider auch eingeschleuste Angriffe (JavaScript,
HTML, CSS, ...) mit abgespeichert (was erstmal nicht schlimm ist) und lassen sich bei der
Ausgabe nur schwer wieder entfernen (was schlimm werden kann)
fwrite($datei, "</td>");
fwrite($datei, "<td width="150" align="center">");
fwrite($datei, $gegnerteam);
fwrite($datei, "</td>");
fwrite($datei, "</tr>");
fwrite($datei, "</table>");
fclose($datei);
}
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>wieso erst hier Document-Type und HTML-Grundgerüst? Du hast doch bei [1] schon Ausgaben gemacht?
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Formularübergabe</title>
</head><body>
<form id="form1" name="form1" method="post" action="index.php">Encryption-Type würde ich immer gleich mit angeben (multipart/form-data)
<p>Unser Team:
<input type="text" name="wtcteam" id="1" />
</p>
<p>Gegner Team:
<label>
<input type="text" name="gegnerteam" id="gegnerteam" />
</label>
</p>
<p>
<input name="Senden" type="submit" value="Eintragen" /></p>
</form><p><br />
Die Trennung von AUfgaben ist prinzipiell gut,
aber die Zerspliterung in einzelne Scripte sorgt auch für eine
Vervielfachung des Aufwandes für Zugangskontrolle, Sessions,
einheitliche Darstellung, usw.
überleg Dir das gut
<a href="spielernamen.php">>>Gehe zur Liste<<</a></p>
<p>>><a href="loeschen.php">Liste löschen</a><<</p>
</body>
</html>Für den Start ist es trotzdem schon ganz gut, denn es sieht so aus, als würde es sogar funktionieren. Aber lasse diese erste Lösung besser noch nicht auf einem öffentlich zugänglichen Webspace laufen. Vielleicht magst Du ja auch die eine oder andere Anregung erst noch einfließen lassen? Liebe Grüße aus dem schönen Oberharz Tom vom Berg  -- Nur selber lernen macht schlau <http://bergpost.annerschbarrich.de>-
Hello,
a.) Request erhalten und der passenden Ressource zuführen
b.) Auftrag ermitteln
c.) Daten übernehmen
d.) Daten prüfen
e.) Daten dazu holen, vervollständigen und verarbeiten
f.) verarbeitete Daten wegschreiben
g.) Ergebnis ermitteln und aufbereiten (nur Daten)
h.) Steuerelemente für Response festlegen und aufbereiten
i.) Darstellung auswählenj.) i mit g und h zusammenführen
k.) Response abschicken
Ja nee is klar Murat...
Wenn man nachträglich was ändert, treten leicht Fehler auf.Nun stell Dir mal vor, wie das erst bei Deiner Lösung aussieht, wenn du nachher 50 Einzelscripte hast...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Jo alles klar werd dann nochmal anfangen zu planen und neu beginnen. Die Ideen kommen bei mir allerdings erst immer wärend ich schon code, naja mal sehen was drauß wird xD
-
Hi!
Ob man nach dieser Liste nun auch MVC-Patterns anwenden kann, überlass ich mal der allgemeinen Diskussion. Was habe ich vergessen in der Liste?
Ach Tom, könntest du dich bitte erst einmal mit dem MVC-Pattern auseinandersetzen und es nicht einfach nur provokant in den Raum werfen? Das Pattern beschreibt nicht die zu erledigenden Aufgaben sondern die Zuständigkeiten dafür.
Lo!
-
Hello,
Ob man nach dieser Liste nun auch MVC-Patterns anwenden kann, überlass ich mal der allgemeinen Diskussion. Was habe ich vergessen in der Liste?
Ach Tom, könntest du dich bitte erst einmal mit dem MVC-Pattern auseinandersetzen und es nicht einfach nur provokant in den Raum werfen? Das Pattern beschreibt nicht die zu erledigenden Aufgaben sondern die Zuständigkeiten dafür.
Ja und? Wie soll ich das jetzt verstehen? Als Provokation? :-)
Kann man die Aufgaben nicht den drei Bereiche zuordnen?
Ggf. muss man Aufgaben noch zerlegen, um eine saubere Trennung zu bekommen.Also mal los! Unterstütz mich mal!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Also mal los! Unterstütz mich mal!
In den Models steckt die gesamte Geschäftslogik. Jedes Model beschäftigt sich dabei mit einem abgegrenzten Thema. Oft findet man zu einer Tabelle im DBMS ein Model, was aber nicht zwingend so sein muss. Models können sich auch mit anderen Aspekten beschäftigen, reinen Berechnungen ohne Datenhaltung beispielsweise. Sie sind auf alle Fälle so zu implementieren, dass sie eigenständig ihre Aufgabe erfüllen können. Sie bekommen ihre Daten, die sie nicht über die Datenhaltung beziehen können, über eine definierte Schnittstelle und liefern ein Ergebnis. Sie müssen und sollen nichts über den Anfrage (Request) wissen und auch nicht wie die Antwort (Response) aussehen soll.
Den Request entgegenzunehmen, die Daten daraus zu extrahieren und das Ergebnis an den Aufrufer zurückzuliefert ist Aufgabe des Controllers. Er ermittelt, welches Model für die Erledigung der Geschäftslogik in Frage kommt und welche View sich um die konkrete Formulierung der Antwort kümmern soll.
Die Aufgabe einer View ist es, aus den Daten, die ihr der Controller gibt, eine Ausgabe zu erstellen. Dazu kann sie sich eines (oder mehrerer) Templates bedienen.
Wenn man sich mit diesem Thema beschäftigen möchte, sollte man seine ersten Erfahrungen mit einer der bereits existierenden MVC-Implementationen sammeln. Da gibt es noch genug bei der richtigen Anwendung und Aufgabenverteilung falsch zu machen. Zusätzlich zur eigentlichen Aufgabe auch noch ein MVC aufzusetzen, sehe ich als äußerst gewagt an.
Man kann sich das vorstellen, wie in einem großen Unternehmen. Die Poststelle bekommt die Kundenanfragen geliefert (Front Controller als ein Teil vom C). Sie entscheidet, welche Fachabteilung für die Beantwortung zuständig ist. Deren Chef (Action Controller als weiterer ein Teil vom C) hat für seine Aufgaben Actions definiert, die den eigentlichen Lösungsablauf beschreiben. Das fachliche Thema bearbeitet ein geeigneter Mitarbeiter (Model) und gibt das Ergebnis an den Chef. Die ermittelten Daten bekommt eine Schreibkraft, die daraus ein Antwortschreiben aufsetzt (View). Das gibt der Chef zurück an die Poststelle, die es dem Anfragenden zurücksendet. (Und jetzt schlagt mich nicht ob dieser heutzutage nicht mehr realisischen Firmenstruktur (Model und View macht nun der selbe Mitarbeiter, die Schreibkraft wurde wegrationalisiert). Das MVC-Pattern wurde bereits Ende der 70er formuliert, und in die Zeit passt mein Beispiel gut. :-)
Lo!
-
Hello,
SO finde ich das verständlich erklärt!
Den Request entgegenzunehmen, die Daten daraus zu extrahieren und das Ergebnis an den Aufrufer zurückzuliefert ist Aufgabe des Controllers. Er ermittelt, welches Model für die Erledigung der Geschäftslogik in Frage kommt und welche View sich um die konkrete Formulierung der Antwort kümmern soll.
Die Aufgabe einer View ist es, aus den Daten, die ihr der Controller gibt, eine Ausgabe zu erstellen. Dazu kann sie sich eines (oder mehrerer) Templates bedienen.
Und zurück, Benutzereingaben (stumpf) entgegen zu nehmen und dem Controller zuzuleiten.
Wie setzt man es im Model am besten um, eine Abstraktion für den Zugriff auf die eigentliche Datenhaltung aufzubauen, wenn die Datenhaltung entweder im Filesystem, oder aber in einer Datenbank oder sonstwo stattfinden soll? Es ist ja leider so, dass die Fähigkeiten der unterschiedlichen Speichermöglichkeiten sehr unterschiedlich sind.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Hello,
SO finde ich das verständlich erklärt!
Den Request entgegenzunehmen, die Daten daraus zu extrahieren und das Ergebnis an den Aufrufer zurückzuliefert ist Aufgabe des Controllers. Er ermittelt, welches Model für die Erledigung der Geschäftslogik in Frage kommt und welche View sich um die konkrete Formulierung der Antwort kümmern soll.
Die Aufgabe einer View ist es, aus den Daten, die ihr der Controller gibt, eine Ausgabe zu erstellen. Dazu kann sie sich eines (oder mehrerer) Templates bedienen.
Und zurück, Benutzereingaben (stumpf) entgegen zu nehmen und dem Controller zuzuleiten.
Das ist nicht Aufgabe der View. Jedenfalls nicht im Webumfeld. Die Benutzereingaben kommen mit dem nächsten Request, da ist die View längst Geschichte. Und es ist ja noch nicht mal gesagt, dass die Eingabewerte überhaupt mit Hilfe eines von irgendeiner View erzeugten Gebildes erstellt wurden.
Wie setzt man es im Model am besten um, eine Abstraktion für den Zugriff auf die eigentliche Datenhaltung aufzubauen, wenn die Datenhaltung entweder im Filesystem, oder aber in einer Datenbank oder sonstwo stattfinden soll? Es ist ja leider so, dass die Fähigkeiten der unterschiedlichen Speichermöglichkeiten sehr unterschiedlich sind.
Das ist deiner Phantasie überlassen. Software-Pattern beschreiben keine konkreten Implementationen, sondern Lösungsprinzipien. Das MVC-Pattern ist erschöpft mit der Aussage, dass das Model die Geschäftslogik und Datenhaltung übernimmt. Wenn du ein DBMS-Layer hast, kannst du das vom Model aus ansprechen. Wenn du einen ORM hast, nimm den. Wenn du direkt das Dateisystem ansprichst, ist das auch in Ordnung. Wenn das Dateisystemhandling umfangreicher wird, lohnt sich da auch eine Abstraktionsschicht.
Lo!
-
Hello,
Und zurück, Benutzereingaben (stumpf) entgegen zu nehmen und dem Controller zuzuleiten.
Das ist nicht Aufgabe der View. Jedenfalls nicht im Webumfeld. Die Benutzereingaben kommen mit dem nächsten Request, da ist die View längst Geschichte. Und es ist ja noch nicht mal gesagt, dass die Eingabewerte überhaupt mit Hilfe eines von irgendeiner View erzeugten Gebildes erstellt wurden.
Dann ggf. mit Hilfe einer neuen View.
Ob es ganz ohne sichtbare View geht, das bezweifele ich. Dann ist die nur verlagert worden, vielleicht nach China oder Rumänien.Wie setzt man es im Model am besten um, eine Abstraktion für den Zugriff auf die eigentliche Datenhaltung aufzubauen, wenn die Datenhaltung entweder im Filesystem, oder aber in einer Datenbank oder sonstwo stattfinden soll? Es ist ja leider so, dass die Fähigkeiten der unterschiedlichen Speichermöglichkeiten sehr unterschiedlich sind.
Das ist deiner Phantasie überlassen. Software-Pattern beschreiben keine konkreten Implementationen, sondern Lösungsprinzipien. Das MVC-Pattern ist erschöpft mit der Aussage, dass das Model die Geschäftslogik und Datenhaltung übernimmt. Wenn du ein DBMS-Layer hast, kannst du das vom Model aus ansprechen. Wenn du einen ORM hast, nimm den. Wenn du direkt das Dateisystem ansprichst, ist das auch in Ordnung. Wenn das Dateisystemhandling umfangreicher wird, lohnt sich da auch eine Abstraktionsschicht.
ORM ? Vielleicht http://www.das-orm.de/Was-ist-das-Orm.html? :-)
oder Object referred model
oder Observer related model
oder Object relational mapping
oder Object Role modeling
oder gar Olympia-Regattaverein München? Vielleicht sind da ein paar kluge köpfe drunter, die mir aus der Verknotung der Gedanken heraushelfen können?Jedenfalls muss das sowas Unanständiges sein. Wie das schon klingt!
Da lob ich mir die Versuche, mit SQL eine normierbare Schnittstelle zwischen dem Model und dem Controller zu schaffen. Aber die sind schon zu SQL-Scalables und Pervasive-Computing nicht zum Erfolg gekommen. Ich hab ja auch schon diverse Versuche gemacht, das möglichst schmerzfrei austauschbar zu machen. Gescheitert bin ich da eigentlich immer an der Endlichkeit des Arbeitsspeichers. Wenn man hingegen die klassischen sparsamen Methoden benutzt, schwupps, verschmelzen wieder Model und Controller (zumindest große Teile davon), ohne dass man es will.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
ORM ?
oder Object relational mappingEine Umsetzungsschicht, die aus dem relationalen Datenmodell der DBMSe eine für OOP besser handhabbares objektorientiertes macht und umgekehrt.
Wenn man hingegen die klassischen sparsamen Methoden benutzt, schwupps, verschmelzen wieder Model und Controller (zumindest große Teile davon), ohne dass man es will.
So schwer ist das nicht, das Datenbankhandling für konkrete Aufgaben jeweils in eine Funktion zu gießen, die gegebenenfalls Parameter entgegennehmen und ein Ergebnis zurückgibt. Und schon hast du ein Model. Das Model ist auch für die Plausibilitätsprüfung zuständig, denn der Controller kann zwar kennen, welche Daten es gibt, aber weiß nichts von ihrer Verarbeitung.
Lo!
-
-
-
-
-
-
-