nicht angemeldet
Merkliste erstellen: Daten via JS/Ajax in Mysql
suitHi,
ich würde auf meiner Seite gerne eine "Merkliste" anbieten. Letzten Endes soll das so funktionieren: Auf der jeweiligen Seite soll ein Link erscheinen, wenn man diesen anklickt, hat man die Seite quasi mit einem Lesezeichen versehen. Auf einer anderen Seite hat man dann alle angeklickten Links beisammen. Ich hoffe das war einigermaßen deutlich.
Ein Login-Skript habe ich bereits, es soll also keine Cookie-Speicherung "stattfinden" (Läuft auf Php/MySQL-Basis).
Ich habe viel gegoogelt und weiß jetzt auch, wie ich grundlegend vorgehen muss (hinsichtlich der Tabelle, etc.). Dazu möchte ich erwähnen, dass ich noch ein Frischling bin :-).
Bei meiner Recherche habe ich mir auch einige Quelltexte angeguckt und bin dabei mehrfach auf die Verwendung von javascript:void gestoßen (z. B. hier: http://www.relilex.de/artikel.php?id=4915).
Die Frage, die ich mir noch stelle, ist, dass ich nicht weiß, wie ich am besten den Link in die Datenbank schreibe. Mit einem Formular geht das ja recht einfach, ich hätte aber gerne eine JS/Ajax-Lösung ohne großen Reload der Seite.
Sehr dankbar wäre ich für konkrete Ideen, Lösungshilfen (Schlagworte), eventuell Tutorials oder ähnliches. Ich betrete mit der ganzen Sache Neuland und freue mich daher über jede Hilfe - vielen Dank!
-
Moin,
also bei deinem Problem sehe ich zwei Lösungen:
1. du kannst die Seite neu laden
2. du speicherst den Favoriten per ajax abNehmen wir mal an der User ist aus www.example.org/artikel?id=5. Dann gibt es dort einen Favoriten Link der so aussieht: www.example.org/artikel?id=5&merken=true. Wenn der User da drauf klickt lädt sich die Seite neu und du kannst per PHP in der $_GET Variable abfragen ob merken == true ist. Wenn ja, dann merke bei User (der eingeloggt sein muss, sprich eine Session besitzt) bei den Favoriten den Artikel 5.
Ähnlich mit ajax, bloß schickst du den Ajax request an eine feste url mit dynamischer Artikelid. Serverseitig ist es jedoch das gleiche spiel.Es ist spät und ich bin nicht top fit, hoffe ich konnte dir trotzdem ein wenig helfen.
Gruß
bei deinen Favoriten immer ganz oben stehender
T-Rex-
Ähnlich mit ajax, bloß schickst du den Ajax request an eine feste url mit dynamischer Artikelid. Serverseitig ist es jedoch das gleiche spiel.
Dasselbe mit Ajax, nur dass ein zusätzlicher parameter drangehängt wird, der dem Server sagt, er soll nicht das vollständige Dokument generieren sondern einen XML-Schnipsel mit "OK" oder "nicht OK"
/artikel/foo?merken=true
und per XHR:
/artikel/foo?merken=true&ajax-
Dasselbe mit Ajax, nur dass ein zusätzlicher parameter drangehängt wird, der dem Server sagt, er soll nicht das vollständige Dokument generieren sondern einen XML-Schnipsel mit "OK" oder "nicht OK"
GET? Wieso GET? POST wäre wohl angebracht.
XML? Wieso XML? text/plain wäre wohl angebracht.
Wieso »OK« und »nicht OK«? HTTP-Status 2xx oder 4xx/5xx wären wohl angebracht.Mathias
-
GET? Wieso GET? POST wäre wohl angebracht.
Da gebe ich dir recht - wenn man aber deine dritte Frage betrachtet, wäre ein HEAD-Request wohl ausreichend :)
XML? Wieso XML? text/plain wäre wohl angebracht.
Wieso? Wenn man ein paar Infos zurückschicken will, die über eine Simple Zeichenkette hinausgehen (z.B. eine aktualsierte Form des Dokumentenkorbs), ist ein mehrdimensionales Austauschformat wie XML oder JSON sicher praktischer als text/plain mit einer Zeichenwurst :)
Wichtig ist das besonders, weil man ja meherere Browserfenster/-tabs offen haben kann und in jedem dieser Instanzen soll der Dokumentenkorb synchron gehalten werden, da hilft dann ein einfaches "hat gepasst" nicht, hier ist es schon erforderlich, den derzeitigen Inhalt/Status komplett zu übermitteln - und dafür ist XML oder JSON wohl besser geeignet als eine plaintext-Wurst (wobei das natürlich auf die vorhandene Schnittstelle für die Antwort ankommt - wenn die mit CSV umgehen kann, mit XML oder JSON aber nicht, ist natürlich XML weniger schlau :p).
Wieso »OK« und »nicht OK«? HTTP-Status 2xx oder 4xx/5xx wären wohl angebracht.
Wenn "OK" und "nicht OK" etwas mehr beinhaltet als nur die Rückmeldung technischer Natur, dann ja.
Es ist halt die Frage ob man hier nur mit Statuscodes hantiert und die nötigen Texte für die Ausgabe am Client dort schon vorliegen oder ob man diese Zeichenketten am Server erzeugt und an den Client schickt.
-
Danke für die bisherigen Antworten!
Ich habe mich weiter auf die Suche nach Möglichkeiten gemacht, Daten ohne Reload der Seite an MySQL zu versenden und bin dabei hierauf gestoßen:
http://www.9lessons.info/2011/09/submit-form-without-refreshing-page.htmlhttp://www.9lessons.info/2011/09/submit-form-without-refreshing-page.html
Wenn ich das ein wenig modifiziere, dürfe es ja seinen Sinn und Zweck erfüllen. Oder haltet Ihr das für einen falschen Weg?
Vielen Dank!
-
http://www.9lessons.info/2011/09/submit-form-without-refreshing-page.htmlhttp://www.9lessons.info/2011/09/submit-form-without-refreshing-page.html
Wenn ich das ein wenig modifiziere, dürfe es ja seinen Sinn und Zweck erfüllen. Oder haltet Ihr das für einen falschen Weg?
Sinn und Zweck ja - aber das als Anleitung zu verwenden ist wohl etwas unsinnig - da sind so viele seltsame Sachen drin, der Autor scheint nicht viel Ahnung davon zu habe, was er da tut.
Beispiele:
if(strlen($name)>0 && strlen($email)>0 && strlen($message)>0)strlen? Ernsthaft? Warum nicht empty()?
Ein Formular mit dem Form-Plugin zu übermitteln ist zwar schön und gut, es ist aber nichts, was man mit jQuery nicht auf einfachste Art und Weise auch nativ machen könnte - und besonders in einem Fall (Merkzettel) hilft dir das auch wenig weiter, weil du ja kein "umfangreiches" Formular mit Nutzereingaben abschickst sondern im Grunde genommen gar kein Formular hast sondern einen Button der in einem form-Element liegt, als mittel zum Zweck - oder eben einen Link (wobei hier molilys Einwand greift - dass POST wohl besser geeignet ist).
In Summe kommst du mit $.ajax einfach zum Ziel.
Zuvor ist es aber notwendig, dass die Sache ohne JavaScript funktioniert - die "Seite nicht neu laden"-Funktionalität wird dann oben drauf gesetzt.
-
-
-
-
-