Jquery Mobile - sinnvoll ???
benzo
- javascript
Nabend @ all!
Ich erstelle gerade eine mobile Webseite für unsere private Tippgemeinschaft. Es soll bewusst eine abgespeckte Version der Hauptseite sein, um das tippen über Smartphone oder tablet zu vereinfachen. Nun habe ich mir Jquery Mobile mal angeschaut, so weit bin ich auch sehr angetan. Allerdings besteht meine Seite, bzw. das im kopf erarbeitete Konzept, aus sehr vielen dynamisch generierten Seiten, also zum Beispiel für jeden Spieltag eine. Nun bin ich nicht wirklich überzeugt davon, das ich diese Seiten immer alle erstellen soll, damit sie dann per Ajax geladen werden können. Normalerweise will der User ja nur einen oder von mir aus zwei Spieltage betrachten, wieso also 34 generieren?
Ich würde das framework lieber "normal" nutzen, sprich eine neue Seite soll auch bitte neu vom Server angefordert werden (wenn ich Ajax nutzen will, dann für "sinnvolle" Sachen)
Hat mein Vorhaben, Ansinnen einen Nachteil? Ist es besser die One-Site-Taktik von Jquery zu nutzen.
Danke für Eure Kommentare und Hilfen
Grüße
Kapier ich nicht.
Normalerweise will der User ja nur einen oder von mir aus zwei Spieltage betrachten, wieso also 34 generieren?
Wer sagt denn dass du Seiten generieren sollst die nicht an den Browser sollen? Auch bei Ajax wird nur das erzeugt was auch wirklich an den Browser gesendet werden soll.
Ist es besser die One-Site-Taktik von Jquery zu nutzen.
Was verstehst du darunter?
Meine Sicht der Dinge: Ajax wird dann verwendet wenn man nicht die komplette Seite neu laden will, sondern nur Teile davon.
Wer sagt denn dass du Seiten generieren sollst die nicht an den Browser sollen? Auch bei Ajax wird nur das erzeugt was auch wirklich an den Browser gesendet werden soll.
Wenn ich es richtig verstanden habe, sagt jquery das über sein mobile Framework.... deswegen ja meine frage....
Thx und grüße
sagt jquery das über sein mobile Framework....
*was* sagt es?
Wenn du erzählst was du da raus liest und interpretierst wirds vielleicht einfacher.
sei mir nicht böse, aber mehr als DAS hab ich nicht zu bieten.
Ohne das Du es jetzt falsch verstehst (nicht böse sein, bitte), schön wäre es, wenn jmd antworten würde, der mit dem Framework schon zu tun gehabt hätte (ohne das ich Deine Mühen nicht wertschätzen würde)
Ganz, Ganz lieben Dank
Da bin ich dir nicht böse.
Ich denke einfach du stellst dir hinter der Sache etwas ganz anderes vor als es wirklich ist.
In Kürze: AJAX lädt Teile einer Seite und baut sie in eine bestehende Seite ein, im Vergleich zum komplett neu laden einer neuen Seite.
Auch wenn ich das mobile Framework nicht kenne, dürfte dieses Prinzip immer noch das selbe sein.
Aus deiner verlinkten Seite würd ich auch nicht schlau werden. Erkundige dich nochmal von vorne was AJAX ist und was es macht, dann dürften sich deine Bedenken von selbst in Luft auflösen ;-)
Hi benzo,
Wenn du dynamisch mit JQM arbeitest, erstellst du ein oder mehrere Seitentemplates welche dann via AJAX mit Inhalten gefüllt werden (je nach Anwendung empfiehlt es sich hier auch noch ein weiteres Framework wie AngularJS oder Vergleichbares hinzuzuziehen, aber das ist ein anderes Thema.)
Im Unterschied zu klassischen dynamischen Seiten, die z.B. mit PHP zusammengebaut werden, werden bei JQM nur die Inhalte übertragen und keine Struktur oder Layout. Das wird nur einmal initial geladen.
Hier ist also ein bisschen umdenken angesagt.
Generell kannst du aber auch klassische PHP-Seiten ausliefern, welche entweder speziell auf den Einsatz auf kleinen Bildschirmen angepasst sind (obwohl "klein" mittlerweile schon ziemlich groß sein kann) oder aber, du greifst gleich auf Responsive Design (entweder rein clientseitig, oder, wenn du mehr optimieren möchtest mittels RESS) zurück, so dass du nur einen Satz Seiten für alle Endgeräte ausliefern musst.
Es ist Geschmachssache.
Gruß
Ole
Hallo Benzo
Nun habe ich mir Jquery Mobile mal angeschaut, so weit bin ich auch sehr angetan. Allerdings besteht meine Seite, bzw. das im kopf erarbeitete Konzept, aus sehr vielen dynamisch generierten Seiten, also zum Beispiel für jeden Spieltag eine. Nun bin ich nicht wirklich überzeugt davon, das ich diese Seiten immer alle erstellen soll, damit sie dann per Ajax geladen werden können. Normalerweise will der User ja nur einen oder von mir aus zwei Spieltage betrachten, wieso also 34 generieren?
Leider versteh ich dein Gedankengang noch nicht so wirklich. Du meinst, dass du beim Multi-Page template 34 Unterseiten erstellen musst? Aber wenn die Seiten erstellt sind, musst du sie ja nicht mehr per Ajax laden.
Wenn du Ajax zum Laden benutzt, kannst du ja immer nur die Daten des angezeigten Spieltages laden lassen(z.B. ueber einen Parameter in der URL).
Was genau meinst/willst du?
Ich würde das framework lieber "normal" nutzen, sprich eine neue Seite soll auch bitte neu vom Server angefordert werden (wenn ich Ajax nutzen will, dann für "sinnvolle" Sachen)
Hat mein Vorhaben, Ansinnen einen Nachteil? Ist es besser die One-Site-Taktik von Jquery zu nutzen.
Die One-Site-Taktik ist vor allem fuer kleine Apps geeignet oder zusammenhaengende "Seitenteile". Bei groesseren Apps wirst du automatisch dazu uebergehen Links einzubauen. Der Inhalt der Links wird von JQM automatisch per AJAX geladen, um Overhead beim Parsen des DOMs zu sparen. Du kannst aber auch ueber ein Attribut im Link-Tag angeben, dass die Seite vollstaendig neugeladen werden soll. Du kannst natuerlich auch immer auf die gleiche Seite verlinken, aber durch einen Parameter angeben, welcher Spieltag angezeigt werden soll.
Gruesse,
Junker
Hallo,
Nun bin ich nicht wirklich überzeugt davon, das ich diese Seiten immer alle erstellen soll, damit sie dann per Ajax geladen werden können.
Den Satz verstehe ich nicht. »Erstellt« werden dynamisch generierte Seiten i.d.R. erst, wenn ein Client sie per HTTP anfordert. Ob das im Browser mit oder ohne XMLHttpRequest erfolgt, ist erst einmal unwichtig.
Ich würde das framework lieber "normal" nutzen, sprich eine neue Seite soll auch bitte neu vom Server angefordert werden (wenn ich Ajax nutzen will, dann für "sinnvolle" Sachen)
Hat mein Vorhaben, Ansinnen einen Nachteil? Ist es besser die One-Site-Taktik von Jquery zu nutzen.
»One-Site-Taktik« ist mir kein Begriff. Es gibt den Begriff der Single-Page-App. Der bedeutet lediglich, dass nur der erste HTTP-Request eine vollständige HTML-Seite ausliefert. Alle folgenden Inhalte werden mithilfe von JavaScript (zumeist XMLHttpRequest) geladen und in das bestehende DOM eingebaut. Wie das genau stattfindet, ist einem selbst überlassen – z.B. ob HTML, JSON oder sonst welche Daten übertragen werden.
Solche Single-Page-App verhalten sich für den Endnutzer bestenfalls so wie eine herkömmliche Website – sie sind nur performanter. Einzelne Seiten lassen sich per URL adressieren und sind direkt zugänglich.
Single-Page bedeutet nicht, dass alle Inhalte, die irgendwann irgendwie in der App angezeigt werden, bereits im initialen HTML enthalten sind oder automatisch initial nachgeladen werden. Das kann man natürlich machen, wenn es einem vorteilhaft erscheint. Vor allem bei Mobilseiten (Stichwort Latency) ist es sinnvoll, oft aufgerufene Inhalte in die initiale HTTP-Antwort zu schreiben, damit nicht für jede Nutzeraktion ein Request geschickt werden muss, nur um ein bisschen Daten nachzuladen.
jQuery Mobile verhält sich standardmäßig wie eine Single-Page-App, da es neue »Seiten« per XMLHttpRequest nachlädt und die URL entsprechend anpasst:
http://jquerymobile.com/demos/1.2.0/docs/pages/page-links.html
Grüße,
Mathias