t R I A S schrieb:
Noch mehr Anhänger dieses JSON Clans. Für was soll ich Markup bzw. Text serialisieren? Das bringt mir rein gar nichts
und dafür verwendet man auch kein JSON.
nein, json ist rein für die daten verantwortlich. json verwendet man deshalb, da der overhead sehr gering wird. nehmen wir mal ein beispiel dafür an (der unten stehende code ist rein semantisch zu verstehen, denn ich hab jetzt keine lust richtiges js o.ä. zu schreiben - peudo code also):
json:
Code:
{{'hans','wurst','12.12.1212','beispielstadt'},{'inge','borg','11.11.1111','testhausen'}}
diese daten bettest du jetzt per javascript über die dom in die seite ein.
Code:
function user_einbetten( daten )
{
haupt = neuer div();
haupt.style = 'xyz';
name = neuer div();
haupt.anhängen( name );
// dieser schritt für jedes einzelne element
}
realisierung ohne json (beispiel xml):
Code:
<users>
<user>
<firstname>hans</firstname>
<lastname>wurst</lastname>
<birthdate>12.12.1212</birthdate>
<town>beispielstadt</town>
</user>
<user>
<firstname>inge</firstname>
<lastname>borg</lastname>
<birthdate>11.11.1111</birthdate>
<town>testhausen</town>
</user>
</users>
diesen code müsstest du nun in js auseinander nehmen und ihn ebenso via js einbetten, was aber weitaus komplizierter ist xml erst einmal korrekt zu parsen und dann noch einfach damit zu arbeiten. abseits dessen könntest du deine seite mit xslt ausstatten, wodurch das thema xml parsen wiederum wegfallen würde.
beim thema realisierung mit html wäre dies das gleiche schema, außer dass du mit javascript nur den textinhalt ändern musst anstatt selbst zu basteln. der nachteil ist allerdings der gleiche wie bei xml - du hast einfach massig overhead und rechenzeit liegt komplett brach.
und um overhead zu verringern, weniger traffic zu bekommen und die last mehr auf die userseite zu schieben (ein rechner arbeitet ja nun nicht wenn im internet gesurft wird) anstatt auf die seite des servers (wo mitunter 100 anfragen pro sekunde eintreffen können), wählt man korrekterweise den weg mit json.
t R I A S schrieb:
Ich weiss auch nicht auf was ihr beide da hinaus wollt. Er will lediglich Inhalte in eine Seite includen was man in seinem Fall mit PHP wie er sagt oder Frames etc. lösen kann. Er bevorzugt eine AJAX Lösung bzw. möchte wissen wie das geht?
beispiele und erklärung siehe oben. man kann ajax natürlich einbinden wie man will, nur bringt es dir genau null vorteile, wenn du auf xml/html setzt. dann kannst du gleich die komplette seite neu laden.
t R I A S schrieb:
Die Anzahl der Requests (falls du @nesQuick überhaupt weisst was das ist weil ich bei einem Request vllt. ne ID oder so mitschick, massive overhead and performance loss, YO - omg) bleibt immer gleich wenn du neue Daten anforderst, egal ob über PHP oder AJAX.
massiv overhead und ein performanceeinbruch sind bei letzterer variante stets vorhanden. anstatt ein wenig json zu generieren, generierst du weitere 100 sachen drumherum, die alleinig dem markup dienen.
stellen wir uns mal folgendes szenario vor:
traffickosten: 0,5 € pro mib (vorsicht, reine fantasiezahl)
anfragen pro tag: 1.000.000
webserver 1 (json):
traffic pro request: 89 byte
traffic pro tag: 84,88 mib
kosten pro tag: 42,44 €
kosten pro monat (31d): 1315,60 €
webserver 2 (xml):
traffic pro request: 327 byte
traffic pro tag: 311,85 mib
kosten pro tag: 155,93 €
kosten pro monat: 4833,70 €
und genau hier fasst die lösung mit json fuß. anstatt unnötig geld zu verpulvern und komplettes xml zu schicken, schickst du die daten und auf dem client wird gerendert. du sparst dadurch nur nerven und enorme traffic-kosten (bei seiten mit 100 usern mag das wohl kaum sein, aber bei einer größe wie cb könnte man so wohl mindestens 10.000 € einsparen [weiß grad nicht wieviel der traffic so allgemein kostet]).
Mr. Snoot schrieb:
- Suchmaschinen können solche Seiten nicht indizieren
google soll das bald(?) können. andere werden nachziehen.
Mr. Snoot schrieb:
- Benutzer ohne Javascript können die Seite nicht nutzen
es sollte
immer einen fallback auf eine lösung ohne javascript geben. seiten die javascript zwingend benötigen, sollten imo sofort gesperrt werden. einfach auch realisierbar durch einen kleinen handler, der z.b. alle standardlinks durch die ajax-äquivalente ersetzt oder einfach einen onclick-handler einbinden. geht ganz einfach von der hand - letzteres ist nur ein wenig aufwändiger.
Mr. Snoot schrieb:
- der Zurück-Button im Browser funktioniert nicht mehr
wohl wahr, wohl wahr. daran sollten die browser-hersteller schleunigst arbeiten. atm könnte man wohl nur eine eigene history-funktion schreiben. ist zwar aufwändig, aber es kann realisiert werden.
Mr. Snoot schrieb:
- man kann die Seite nicht mehr direkt verlinken
siehe punkt 2. eine standard-, nicht javascript benötigende form sollte
immer vorhanden sein.
Mr. Snoot schrieb:
Um einen normalen Seitenaufbau zu realisieren ist - denke ich - AJAX fehl am Platz.
imo ist ajax überall verwendbar und zwar allein dadurch, dass traffickosten gespart werden können und auch modem-user wieder mit dem internet zufrieden sein können (auf dem dorfe sieht man das ja mal gut und gern und dsl gibts dort ja kaum). so werden ein paar byte an daten gesendet und der browser rendert alles korrekt. du brauchst also keine 100000 flashbanner mehr laden, keine 10000000000 werbe-ads, keine statischen menüs oder sonstiges. der reine inhalt wird neu geladen - das wars auch schon. und die seitenaufbauzeit steigert sich allein dadurch enorm. schnell aufbauende seiten kann es heutzutage also auch noch geben.
