HTML to Text tool

[arvgta]

wie gesagt ist SEO ein wichtiger Gesichtspunkt, ganz gleich, ob es meine originäre Absicht war:

Ich ziele derzeit auf die Keywords "new html tags".

Wenn Ihr auf die deutsche Version von bing.com sowie yahoo.com geht und

"new html tags" eingibt ist New HTML tags auf Platz 1 und sogar Platz 2 gleichzeitig.

Warum? -> Weiß ich auch nicht, liegt wahrscheinlich an der "Keyword density".

Nur so, fällt mir dazu ein...


Liebe Grüße

 

[mermshaus]

"Das ist mit jedem entsprechenden Ansatz zu erreichen."
(Gemeint ist, dass der HTML Code *nicht* redundant ist)

Das habe ich gestern beim erneuten Lesen meines Beitrags auch bemerkt, hatte aber keine Zeit mehr. Sorry, falsch verlesen.

Hier vielleicht noch kurz der Hinweis, dass Code/Text wunderbar komprimiert übertragen werden kann. Meine Einschätzung bleibt, dass dieses Argument für die clientseitige Render-Technik zwar grundsätzlich haltbar ist, aber dass die Technik in dieser Hinsicht im „Standardfall“ – wenn überhaupt – keinen großartigen Vorteil bringt.

Die Keyword-Dichte ist etwas höher, wenn weniger Firlefanz in HTML die Suchmaschine ablenkt.

Ich habe nichts Nettes dazu zu sagen. Ich halte die meisten SEO-Tricks für zwielichtig und schädlich für das Web.

"Wenn ich mit Source-Dateien deines Systems arbeiten sollte, wäre das Erste, was ich machen würde, deinen JS-Compiler in einer serverseitigen Sprache nachzubauen."

Das check ich leider nicht, klingt aber interessant.

Die fertige HTML-Datei serverseitig erzeugen, nicht per JS im Client.

Also dynamisch von JS aus auf PHP zuzugreifen, statt den Client die ganze Arbeit machen zu lassen.

Stichwort Ajax.

was hältst Du nun von der Google Analytics Substitution?

Das ist eine Template-Funktion wie jede andere. Ich sehe da keine Besonderheit.

Wenn Ihr auf die deutsche Version von bing.com sowie yahoo.com geht und

"new html tags" eingibt ist New HTML tags auf Platz 1 und sogar Platz 2 gleichzeitig.

Warum? -> Weiß ich auch nicht, liegt wahrscheinlich an der "Keyword density".

Oder weil der Seitentitel exakt so lautet.

 

[arvgta]

Hallo mermshaus,

Danke für die erneute Antwort!

Gut, wir sind uns also einig, dass es was anderes ist, wenn Abkürzungen vom Mid-Tier rausgesendet werden. Der HTML Code ist dann auf jeden Fall viel kürzer.

SEO kann man aber bei der Bewertung des Tools nicht außen vor lassen.
In diesem Bereich sind große Mehrwerte.

Man nehme allein die PageRank Steigerung durch die Substitution von Links...
Was hälst Du von der "nofollow alternative"? (New HTML tags - "nofollow alternative")

Also, wie ich Dich verstehe, findest Du es interessant, das Tool auszubauen, damit weite Teile des JS per Ajax in PHP abgearbeitet werden, um den Client zu entlasten. Werde mir echt überlegen, ob ich das demnächst mal austeste. Das würde auf jeden Fall den clientseitigen JS Code dezimieren und dem Client Rechenzeit ersparen. Es ist nur fraglich, ob der zusätzliche Handshake zeitraubend ist?

Hast Du die Google Analytics Substitution schon einmal an anderer Stelle im Netz gesehen?
(Vielleicht hast einen Link zur Verfügung)
Wäre interessant...

Wie gesagt, weiß ich nicht, warum New HTML tags bei bing und yahoo so hoch gelistet ist, und gleich zweifach. Ich hoffe natürlich schon, dass es was mit gutem SEO zu tun hat :-)


Liebe Grüße

 

[sysop]

.....
SEO kann man aber bei der Bewertung des Tools nicht außen vor lassen.
In diesem Bereich sind große Mehrwerte.

Das sehe ich anders. Ähnlich wie mermshaus finde ich solche tools schlecht für's web. Ein Grund, warum man bei Google und Co tausende Seiten findet, die nichts mit dem Suchbegriff zu tun haben, sind die SEO's, die sich vordrängeln und unlauter verwedet werden. Würde jeder das in seinen Head schreiben, was wirklich relevant ist, bräuchte man diesen Mist garnicht.

Man nehme allein die PageRank Steigerung durch die Substitution von Links...
Was hälst Du von der "nofollow alternative"? (New HTML tags - "nofollow alternative")

Ähnlich der SEO-Tools empfinde ich Page-Ranker. Der Inhalt sollte entscheiden, wo eine Seite hingehört, Klicks und Referenzen sind nach wie vor das Entscheidende.

Also, wie ich Dich verstehe, findest Du es interessant, das Tool auszubauen, damit weite Teile des JS per Ajax in PHP abgearbeitet werden, um den Client zu entlasten. Werde mir echt überlegen, ob ich das demnächst mal austeste. Das würde auf jeden Fall den clientseitigen JS Code dezimieren und dem Client Rechenzeit ersparen. Es ist nur fraglich, ob der zusätzliche Handshake zeitraubend ist?

Ich habe das als Hinweis gewertet, dass es eventuell schlauer ist, den Server mit Arbeit zu belasten statt des Clients, also Umbau statt Ausbau.

Da ich noch keine wirkliche Meinung zum Tool geäussert habe, ein kleiner Nachtrag. Es funktioniert, macht für mich aber keinen wirklichen Sinn. Das meiste kann mit bestehenden Techniken problemlos nachgebaut werden, du hast gewisser Massen nur eine Art IDE dafür geschaffen, die das für einen abnimmt. Wer's braucht, wird es nutzen können. Ich gehöre eher nicht dazu, was aber nichts bedeuten soll.

Wie ich schon mal gesagt habe, stell es auf sourceforge und beobachte mal, was passiert. Besser wäre es imho mit mehreren daran zu arbeiten, da der Blick dann nicht so getrübt und einseitig ist.

 

[mermshaus]

Gut, wir sind uns also einig, dass es was anderes ist, wenn Abkürzungen vom Mid-Tier rausgesendet werden. Der HTML Code ist dann auf jeden Fall viel kürzer.

Ich bin mir langsam nicht mehr sicher, ob wir nicht ziemlich aneinander vorbeireden.

Das ist nicht das, was ich geschrieben habe. Ich schrieb:

„Meine Einschätzung bleibt, dass dieses Argument [geringere Datenübertragungsmenge] für die clientseitige Render-Technik zwar grundsätzlich haltbar ist, aber dass die Technik in dieser Hinsicht im ‚Standardfall‘ – wenn überhaupt – keinen großartigen Vorteil bringt.“

Das soll heißen: Es dürfte – logischerweise – möglich sein, Fälle zu konstruieren, in denen mit deiner Methode signifikant weniger Daten übertragen werden. Dass das in einem normalen Anwendungsfall (wie auch immer der zu definieren ist) auch so ist, bezweifle ich aber. Das wiederum bedeutet, dass das Argument „geringere Datenübertragungsmenge“ zwar irgendwie richtig ist, aber in vielen Fällen irrelevant sein dürfte.

Analogie: „Dieses Auto verbraucht sehr wenig Sprit.“ – Wenn man es rollen lässt oder gleichmäßig 130 km/h auf der Autobahn fährt, ist das vielleicht korrekt, im Stop-and-Go-Stadtverkehr vielleicht nicht. Wenn nun ein großer Anteil der Käufer im Normalfall in der Stadt unterwegs ist, verbrauchen alle Käufer zusammen vielleicht sogar in der Summe mehr Sprit, als sie es bei einem anderen Modell täten, das besser auf Stadtverkehr eingestellt ist. Dennoch kann man argumentieren, dass dadurch die Aussage, das erste Modell verbrauche wenig Sprit, nicht zwangsläufig falsch wird.

SEO kann man aber bei der Bewertung des Tools nicht außen vor lassen.
In diesem Bereich sind große Mehrwerte.

Man nehme allein die PageRank Steigerung durch die Substitution von Links...
Was hälst Du von der "nofollow alternative"?

Absolut gar nichts. Ich finde die Technik unseriös. Wenn das jeder Seitenbetreiber so machen würde, könnten wir das Web zumachen, weil keine maschinenlesbaren Verlinkungen mehr möglich wären.

Leute, die sowas zum Zwecke von SEO einsetzen, sind dann vermutlich die ersten, die sich beschweren, wenn auf ihre Seiten auch auf diese Weise verlinkt wird.

- Goldene Regel

Also, wie ich Dich verstehe, findest Du es interessant, das Tool auszubauen, damit weite Teile des JS per Ajax in PHP abgearbeitet werden, um den Client zu entlasten.

Nein, ich würde das Tool nicht ausbauen wollen, weil ich den grundsätzlichen Ansatz für schlechter halte als vergleichbare serverseitige Techniken. Wenn ich eine Seite pflegen müsste, die auf diesem Tool basiert, würde ich die clientseitige Generierungskomponente schleunigst rausbasteln, da sie für mich nur wesentliche Nachteile hat.

Hast Du die Google Analytics Substitution schon einmal an anderer Stelle im Netz gesehen?

Das ist doch lediglich eine kleine parametrisierte Ersetzung, oder? Das ist in so ziemlich jeder Programmiersprache die leichteste Übung.

Andere Vorgehensweise:

Wenn du bei der Generierung deiner Seiten den Front-Controller-Ansatz wählst, hast du solche Dinge einmal in einer Layout-Datei stehen, in die der jeweilige Seiteninhalt integriert wird.

Du hast gewissermaßen viele Dateien nach diesem Schema:

insertHeader();

Hier steht der Inhalt

insertFooter();

Der andere Ansatz wäre eine einzige Layout-Datei nach diesem Schema:

Hier steht der Header

insertContent();

Hier steht der Footer

Wie ich schon mal gesagt habe, stell es auf sourceforge und beobachte mal, was passiert.

Oder auf GitHub oder Bitbucket. Aber falls du das tust, dokumentiere es besser. Die bestehende Dokumentation ist unverständlich.

 

[arvgta]

Hallo mermshaus,

der Vorteil von schlankerem HTML ist v.a. im Bereich SEO.
Die Suchmaschine sollte dankbar sein, dass Ihr die Arbeit erleichtert wird und sollte das belohnen.
Wie ich Dich bislang verstehe, interessiert Dich aber SEO nicht die Bohne ;-)

Zum Thema "nofollow alternative":
Meiner Meinung nach sollte ein Linkgeber die Hoheit haben, ob:
- er Link Juice vererben will oder
- überhaupt einen echten Link setzen will, der von der Suchmaschine als solcher erkannt wird

Ansonsten ist er der Suchmaschine ausgeliefert, was nicht ganz fair erscheint.
"nofollow" war lange Zeit eine solche Möglichkeit, funktioniert aber nicht mehr...

Es wäre, was die "Google Analytics Substitution" angeht interessant zu wissen, wo an anderer Stelle im Netz sie implementiert ist. Ich persönlich glaube, das geht am besten in JavaScript.

Sicher, ein php-include tut's auch. Pointe ist nur, dass das HTML redundant ist. Das haben wir aber auch wirklich schon öfters angesprochen.

Nein, ich habe keine Motivation, das Tool vollkommen Open-Source zu machen.
Gebe Dir recht, dass es noch lange nicht marktreif ist und besser dokumentiert werden muß.
Auch der Mehrwert muß größer werden, was Anzahl und Mächtigkeit der "new HTML tags" angeht...
Ich sehe mich aber auf einem guten Wege dahin...

Vielleicht können wir uns wenigstens darauf einigen, dass die Diskussion schwierig ist, wenn Du SEO für "per se" nutzlos hälst. (Ich habe auch meine eigene Skepsis, vielen SEO-Techniken gegenüber, betrachte aber die des Tools als "weißes SEO" - nicht schwarzes)


Liebe Grüße

 

[mermshaus]

Weil das hier doch langsam arg einseitig wird: Falls sich noch jemand in die Diskussion einklinken möchte… (Falls du das hier liest, crash? ;))

der Vorteil von schlankerem HTML ist v.a. im Bereich SEO.
Die Suchmaschine sollte dankbar sein, dass Ihr die Arbeit erleichtert wird und sollte das belohnen.

Du redest von schlankerem HTML, hast aber in Teilen überhaupt kein HTML mehr vorliegen. Ich bin überzeugt davon, dass einer Suchmaschine ein HTML-Dokument mit möglichst viel Semantik lieber ist, als eine kurze Textdatei mit kryptischen Zeichen drin.

Wie ich Dich bislang verstehe, interessiert Dich aber SEO nicht die Bohne

Nein, eher im Gegenteil. Ich kritisiere es hier beispielsweise, nofollow zu setzen, weil auch auf meiner Seite kein Bonus mehr ankommt, wenn ich nur auf die Weise verlinkt werde (was übrigens der Regelfall ist).

Ich denke, dass alle mehr davon haben, sich gegenseitig „fair“ zu verlinken. Wenn ich diversen Artikeln zu dem Thema glaube, ist das auch nicht ganz unrealistisch.

- Suche etwa nach „google nofollow“ begrenzt auf das letzte Jahr

Ich bin immer wieder erstaunt, welche Umstände eingegangen werden, nur um „cleverer“ als die Suchmaschinen zu sein, die ihrerseits mit Hochdruck daran arbeiten, genau das zu verhindern. Ich wäre mir nicht sicher, dass das nicht auch ein Eigentor sein kann.

Generell kann man über solche Themen gerne geteilter Meinung sein, aber es ist nun auch nicht so, dass zum Beispiel Google dazu keine Standpunkte veröffentlichen würde:

- About rel="nofollow" - Webmaster Tools Help
- PageRank sculpting

Meiner Meinung nach sollte ein Linkgeber die Hoheit haben, ob:
- er Link Juice vererben will oder
- überhaupt einen echten Link setzen will, der von der Suchmaschine als solcher erkannt wird

Ja, das sollte er. Aber der Verlinkte sollte ebenso das Recht haben, zu kritisieren, wenn kein Link Juice vererbt wird.

Um Googles Standpunkt dazu zu zitieren: nofollow wird interpretiert als „Untrusted content“ (ich will mit dem ziel nicht assoziiert werden), „Paid links“ (Werbebanner), „Crawl prioritization“ (Seiten, die Logins erfordern, ergeben keinen Sinn für Bots).

Die eigentliche Frage ist: Würdest du wollen, dass du mit nofollow verlinkt wirst? Also ich will das nicht. Ich empfinde es als unhöflich, wenn sich jemand meine Inhalte etwa durch Zitat zu Eigen macht, mich dann aber als „untrusted“ brandmarkt.

Sicher, ein php-include tut's auch. Pointe ist nur, dass das HTML redundant ist. Das haben wir aber auch wirklich schon öfters angesprochen.

Ja, ich habe meinen Standpunkt dazu ebenfalls mehrfach und reflektiert dargelegt. Du kannst initial einmal x Requests mehr fahren und y Kilobyte mehr übertragen. Wenn du Glück hast, besucht der Nutzer mehr als z Seiten und du machst einen Gewinn, weil du gewisse Teile aus dem gecachten JS laden kannst. (Das kann nach 3 oder 4 Seiten der Fall sein, vielleicht auch erst nach 50.) Wenn du Pech hast, machst du Verlust, weil der Nutzer keine z Seiten aufruft. Sobald du auf einer Seite größere Bilder oder längere Inhalte, die nicht redundant sind, laden musst, schrumpft der Gewinn durch das Laden mancher Teile aus dem JS auf einen sehr geringen Prozentsatz zusammen. Sobald du außerdem redundante Teile veränderst, die der Nutzer dann aber im Cache hat, darfst du einen Cache-Refresh durchführen und produzierst dabei wiederum Overhead. Außerdem muss dein System diese Cache Negotiation irgendwie auf die Reihe kriegen, was auch nicht zwangsläufig trivial ist.

Da deine Seite dann übrigens ohnehin bereits von JavaScript abhängt, kannst du auch gleich ein echtes Ajax-System fahren und wirklich nur veränderte Inhalte dynamisch nachladen, also auf harte Page Refreshs verzichten.

Auch hier können wir gerne geteilter Meinung sein. Ich bin der Ansicht, du verfolgst einen ungünstigen Mittelweg. Und das soll keine übermäßige Kritik an der Idee sein. Der Ansatz ist okay, es gibt aber meines Erachtens bessere.

Nein, ich habe keine Motivation, das Tool vollkommen Open-Source zu machen.

Dann viel Glück.

Wenn ich einen Tipp geben darf: Such dir eine halbwegs standardisierte JS-Templating-Technik (im Stile von John Resig - JavaScript Micro-Templating), bau dir eine JS-Klasse, die per Ajax Daten für diese Templates dynamisch nachladen kann (auch in zusammengefassten Paketen, um Requests zu verringern), setze komplett auf Ajax und die HTML5 History API, veröffentliche alles in jedem Fall unter einer freien (as in freedom not as in beer) Lizenz, am besten vielleicht als jQuery Plug-in, und geh dabei davon aus, dass das schon in besser existiert.

Edit: Eine Fallback-Lösung bei deaktiviertem JS wäre eventuell auch notwendig.

GitHub wird beispielsweise mit sowas betrieben.

- https://github.com/

Auch der Mehrwert muß größer werden, was Anzahl und Mächtigkeit der "new HTML tags" angeht...

Je größer der initiale Tagumfang, desto größer der initiale Overhead, desto größer das oben erwähnte z.

Ich sehe mich aber auf einem guten Wege dahin...

Ich wünsche dir in jedem Fall viel Erfolg.

 

[arvgta]

Hallo mermshaus,

Danke nochmal für die ausführliche Antwort!

Nur ganz kurz, vielleicht kann ich auf die anderen Themen ein anderes Mal eingehender antworten.

Ein Punkt, der mir wichtig ist:

Stell Dir mal vor, Du hast ne kleine Seite, mit relativ niedrigem PageRank und möchtest Dich hocharbeiten.
Da finde ich es nicht besonders sinnvoll, Facebook oder anderen "PR Schwergewichten" sein kostbares PageRank nachzuschmeißen. Da finde ich es sinnvoller, man darf zwar zu diesen Anbietern linken, möchte aber das PageRank auf seiner Site behalten...

(Natürlich möchte ich auch nicht unterstützen, dass User zu "dubiosen" Content linken - "untrusted content" etc.)


Liebe Grüße

 

[arvgta]

Hallo mermshaus,

nur kurz möchte ich das "alte nofollow" Thema nochmal aufgreifen.

Fakt ist, das Google nofollow eingeführt hat. Dem alten nofollow entsprechend wurde nicht weiter gespidert UND die verlinkte Seite hat keinen Link Juice erhalten. Bei der alten Version blieb der Link Juice auf der Seite.

Das hat dazu geführt, dass nofollow, meiner Meinung nach aufgrund des zweiten Effekts inflationär gebraucht wurde.

Wenn man beim Fakt-Finding bleibt dann kann man feststellen:

- nofollow war sehr beliebt
- die Absicht der Webmaster war zum einen, a priori "ungetrusted content" zuzulassen und PageRank auf der Site zu behalten

Noch immer gibt es Sites, die nofollow einsetzen, trotz der Umstellung seitens Google.
Da wäre zu nennen webdeveloper.com, ein Forum das ich sehr schätze und vom PageRank stärker ist als dieses.

Was ist die Logik von webdeveloper.com?

- Wir wissen a priori nicht, worauf die User linken wollen
- Wir wollen den End-Usern echte Links bieten
- Wir wollen den verlinkten Parteien keinen PageRank vererben, um Link-Spamming zu vermeiden

(ich vermute damit, dass webdeveloper.com mit meiner "nofollow alternative" besser fahren würde, da das PageRank auf ihrer Site bleiben würde, statt wie jetzt, zu "versiegen")

Aber wie gesagt, würde ich lieber den Fall beleuchten, einer kleinen Site, mit PR 5 oder niedriger, die nicht will, das PageRank auf verlinkte Seiten gerät, die sowieso "gut bedient" sind (also PR 7+).


Liebe Grüße

 

[arvgta]

Hallo Leute,

es ist wieder viel Zeit vergangen und es hat sich wieder einiges getan, bzgl. des Tools:

New HTML tags

Wesentliche Neuheiten:

- "Nofollow Alternative" vereinfacht: neue Syntax: <an href="http://facebook.com">Facebook</an>
- Code auf die Serverseite geschaufelt (PHP)
Die alte Version war ein reines JavaScript File. Nun ist die Hauptlogik in PHP und nur noch wirklich JavaScript benutzende Logik ist im js (http://4nf.org/n.js)
- Dadurch werden bei Versagen von JavaScript oder augeschaltet sein von JavaScript trotzdem die korrekt ersetzten Tags angezeigt - ganz anders als bei der alten Version (die alte Default-Kritik erledigt).

Was meint Ihr dazu?


Danke und liebe Grüße

 

[arvgta]

Ich habe die Empfehlung von Mermshaus und anderen Bekannten gefolgt und nun das ganze als ein jQuery PlugIn integriert - siehe: New plugin - jQuery Forum

Was meint Ihr dazu?


LG

 

[mermshaus]

Ich habe derzeit nicht die Motivation, mich da reinzudenken (wollte aber mal antworten). Ich finde die Homepage noch immer zu schwer verständlich. Ob das an mir liegt: keine Ahnung. Zum Sinn und Zweck und zu möglichen Alternativen habe ich in diesem Thread schon viel gesagt. Du scheinst jetzt eine serverseitige Fallback-Komponente (wenn kein JS möglich) zu haben, aber ich denke, generell ist das meiste von dem, was ich gesagt habe, schon noch halbwegs passend. Serverseitiges Processing + Caching, History-API, Daten dynamisch per Ajax in Rahmen nachladen (als progressive enhancement), …

 

[arvgta]

Hallo Mermshaus!

Danke für die Antwort - freut mich sehr!

Nein, das liegt nicht an Dir - kriege oft zu hören, dass die Homepage schwer verständlich ist.
Da muß ich aufräumen. Hast Du ne Idee, wo ich anfangen könnte?

Ja es gibt nun eine serverseitige Fallback Komponente, wenn JS disabled ist.
Dann wird die Seite korrekt mit erweiterten Tags ausgegeben, aber natürlich ohne JS.
Überhaupt werden nun die Tags serverseitig substituiert.
(Sie werden nun per client-seitigem POST alle auf einmal reingeladen, zwecks Performanz)

Dann gibt es noch kleine Verbesserungen wie z.B. dass auf DOMReady erstmal die Abkürzungen rückgesetzt werden, damit kein "Flickern" von diesen zu sehen ist, wie früher...

Was traumhaft wäre, aber leider nicht möglich scheint, wäre im Punkt "Serverseitiges Processing + Caching" ein Server, der vollkommen persistent wäre, also bereits parat, wenn der HTTP Request reinkommt. Also praktisch, dass man nicht bei jedem POST erstmal serverseitig die ganzen derzeitigen Text-Dateien laden muß, sondern dass die Haupt-Tags persistent da wären, sowie die PHP Verarbeitungsklassen.
Das scheint allerdings mit PHP 5 nicht möglich zu sein.
Wißt Ihr, ob das z.B. mit Python oder Java möglich ist? (ein "persistenter" Server)
Dann steht überhaupt noch aus, eine DB drunterzulegen, wo die Tags reingehören.

(weiß nicht, was Du mit "History-API meinst")

Schließlich bleibt der sehr spannende Punkt "Daten dynamisch per Ajax in Rahmen nachladen". Ja, da kann ich mich sicherlich noch austoben.

Ideen dazu sind:

- erstmal die "Datum!" Abkürzung so verändern, dass sie sich selbst periodisch updatet.
- ein HTTP-Pull von einer Remote-Site in die Abkürzungen rein
(siehe: Pulling a div from remote site - WebDeveloper.com)

Danke nochmal und würde mich freuen, wenn Ihr noch was dazu zu sagen habt?


LG

 

[mermshaus]

Kurz zur History-API (zum Rest später, schaffe ich gerade nicht mehr):

- History API - Dive Into HTML5

Das ist ein Mechanismus, der es erlaubt, den Inhalt der Adressleiste des Browsers zu verändern, ohne tatsächlich ein neues Dokument zu laden. Aus [noparse]http://example.org/foo[/noparse] könnte [noparse]http://example.org/foo/bar[/noparse] werden, ohne dass du einen echten Reload hast.

Nehmen wir mal diesen normalen Seitenaufbau an:

[header]
[content]
[footer]

Beim Wechsel auf eine neue Seite kannst du mit der History-API nun den URL in der Adressleiste ändern, Inhalt per Ajax austauschen, aber Header und Footer unberührt lassen.

Adresse: http://example.org/foo           
                                     
  /---Page----\                      
  |           |                      
  | [header]  |                      
  | [content]<---Ajax---[content_neu]
  | [footer]  |          onready: Adresszeile in 
  \___________/                   http://example.org/foo/bar
                                  ändern per History-API
                                           |
      +------------------------------------+
      |
      v
Adresse: http://example.org/foo/bar

  /---Page--------\                      
  |               |                      
  | [header]      |                      
  | [content_neu] |
  | [footer]      |        
  \_______________/

Ohne JS muss es dabei sowieso möglich sein, eine Seite aufzubauen, denn du kannst ja als erste Seite des Auftritts einen beliebigen URL anwählen, bei dem das Laden von Header und Footer natürlich einmal erforderlich ist.

Du würdest also eine „normale“ Logik mit normalen Verlinkungen programmieren, die serverseitig die kompletten Seiten generiert und ausliefert. Zusätzlich würdest du einen JS-Aufsatz erstellen, der alle internen Links dynamisch von „normalen“ Gesamtseite-Reload-Links auf Ajax-Teilreloads umbaut, der dann natürlich nur dann ausgeführt wird, wenn JS auch verfügbar ist.

onload: für jeden Link:
  wenn interner Link:
    ersetze normale Linkfunktionalität durch JS-Funktion, die Ajax-Aufruf startet

So funktioniert die Seite ganz normal ohne JS und nutzt mit JS (beziehungsweise wenn die History-API verfügbar ist, das wäre der eigentliche Test) das optimierte Ladeverhalten, das wirklich nur die Teile austauscht, die ausgetauscht werden müssen.

 

[arvgta]

Hallo Mermshaus,

absolut genialer Artikel und vielen Dank für Deine Mühe!

Ich habe versucht, das obige zu impementieren - mit einem Teilerfolg.
Aber ich glaube, ich habe einen Fehler gemacht, beim Platzieren von "popstate".
Vielleicht könntest Du den Code nochmal editieren:

http://4nf.org/bo.js

Da innerHTML nicht Skripts korrekt behandelt, habe ich stattdessen folgende Zeile implementiert:

$("#content").replaceWith('<div id="content">'+r+'</div>');

Das obige jQuery behandelt nämlich Skript Tags korrekt.

Das ganze funktioniert nun viel schneller im Firefox und Chrome, allerdings benimmt sich die "Back Button" Funktionalität nicht korrekt. (Keine Veränderung in IE)

Es würde sich bezüglich des Tools um einen Quantumsprung handeln, wenn es funktionieren würde.

Wäre überglücklich, wenn ich die "Back Button" Funktionalität noch irgendwie hinkriegen könnte.

Habe ich den folgenden Code falsch eingefügt? :

window.addEventListener("popstate", function(e) {
swapDiv(location);
});

Vielen Dank nochmal und vielleicht hast Du ja noch eine Idee dazu?

Wäre toll das zum Laufen zu bringen!!


LG

 

[arvgta]

Hallo nochmal,

ich habe nun folgenden Code aktiv, so wie oben beschrieben:

window.onload=function(){
setupHistoryClicks();
window.addEventListener("popstate", function(e) {
swapDiv(location);
});
};

Leider funktioniert die Back-Button Funktionalität nicht und die Site wird mit der Zeit instabil... (ich habe sicherlich einen Fehler drin)

Wer mir hilft, die History API zu integrieren, dem zahle ich gerne €50 als "Dankeschön" :-)

(so wichtig ist mir das strategisch, und so gut finde ich die Idee!)

hier nochmal der Link zum kompletten Quellcode des PlugIns: http://4nf.org/bo.js


Danke und LG

 

[arvgta]

Es funktioniert! Die HTML5 History API ist nun erfolgreich integriert!

Könnt Ihr beobachten, dass die Unterseiten im Firefox und Chrome schneller laden? (New HTML tags sowie Oeko-fakt – Klimawandel, Erneuerbare Energien – News zum Umweltschutz — Öko-Fakt)

Vielen Dank nochmal an Mermshaus für die tolle Idee!!

LG

 

[mermshaus]

Kommentare zur aktuellen Version:

1. Teilweise steht Code noch im globalen Namensraum. Etwa auch die beiden externen Dateien date.js und tggl.js.
   
2. Die gesamte Sache mit der Google-Analytics-Kennung fühlt sich derzeit noch nicht ausgereift an. Die Logik ist momentan ja mehr oder weniger in bo.js hardgecodet. Da sollte eine allgemeinere Lösung für die Arbeit mit derlei Informationen erarbeitet werden. Das heißt wohl: ein genaueres Format/Protokoll zur Ablage verschiedener lokaler Informationen (Google-Analytics-Kennung) oder lokaler Makros.
   
3. Wie html.txt funktioniert, müsste in dem Kontext generell in jedem Fall noch besser kommuniziert werden. Dass dort lokale Informationen zentral abgelegt werden sollen, ist nachvollziehbar, aber wie html.txt ausgewertet wird, ist etwas unklar. Vermutlich zieht bo.php den Inhalt über HTTP?
   
4. Der Code könnte noch weiter nach OOP-Prinzipien aufgedröselt werden (etwa: single responsibility), aber das sollte man auch nicht sofort übertreiben, solange das Konzept noch nicht zum überwiegenden Teil steht. Ansonsten führt es nur zu Refactoring-Orgien. Derzeit existiert nur eine Klasse Bo mit vielen Methoden, die teilweise wenig miteinander zu tun haben.
   
5. Die Zusammensetzung der Standardwerte für den Bo-Konstruktor könnte noch überdacht werden. (verbosity ist etwa eine Debug-Maßnahme, die bo.js dazu verleitet, per window.console.log() Nachrichten an die JS-Konsole des Browser zu schicken. Damit soll vor allem demonstriert werden, dass so was theoretisch möglich ist.)
   
6. getFileContents sollte in jedem Fall asynchron werden. Die Logik müsste derzeit grob im success-Handler eines Ajax-Aufrufs, der html.txt einliest, stehen. Das ist aber keine kleine Umstellung, die vor allem auch Design-Entscheidungen erfordert (erneut die genauere Definition, wie der html.txt-Mechanismus funktioniert).
   
7. In history_parseLink siehe das @todo (siehe die allgemein im Code). Hier ist die Frage, ob nur Domain-Names mit Punkt („example.org“ im Gegensatz zu „localhost“) zulässig sein sollen. Da bo.php auf localhost nicht zugreifen kann, ist es aus Service-Sicht wohl egal, aber beim Entwickeln (das machen Leute natürlich oftmals lokal) nervt die Einschränkung, weil der JS-Code teilweise zu früh abbricht oder schlicht „nicht funktioniert“.
   
8. Das Plugin könnte – wie andere jQuery-Plugins – lediglich auf einer Menge von Elementen arbeiten. Das ergibt zwar für bo.js vielleicht wenig Sinn, weil Aspekte (History-API) global sind, aber die Möglichkeit, nur festlegbaren Elementen Support für New HTML Tags (oder History-API-Links) geben zu können, ist vielleicht interessant.
   
9. Die nachgeladenen Stylesheets sollten auch dokumentiert werden, und es wäre sicherlich sinnvoll, den Styles ein Präfix („bo_“ oder so) zu geben, damit sie nicht mit anderen Styles ins Gehege kommen. Der Mechanismus scheint auch insgesamt noch nicht genau definiert.
   
10. Anmerkung dazu: JS- und CSS-Komponenten sollten generell möglichst so konzipiert sein, dass sie auch zusammen mit anderen gleichrangigen Komponenten funktionieren. Die Einsatzfelder sind eben heterogen. Aber das ist ein schwieriges Thema und immer ein Spagat zwischen „ease of use“ und unnötig langen Namensräumen (class="f" ist schneller getippt als class="mynamespace_f").
    
11. Derzeit gibt es vermutlich Schwierigkeiten, wenn $().bo() doppelt aufgerufen wird, da dann Stylesheets und ähnliches doppelt generiert werden. Da sollte man noch mal drüber nachdenken und vielleicht irgendwo einen Marker setzen, ob bo bereits initialisiert wurde (als data vom html-Element etwa, müsste ich auch genauer recherchieren, was da sinnvoll ist).
    
12. Wenn ein Tag wie „Current Date!“ zweimal auf einer Seite gesetzt wird, werden beide Ersetzungen an der ersten Stelle vorgenommen? Irgendwas passiert da jedenfalls.
    
13. Auch scheint es ein Problem zu geben, wenn bo aufgerufen wird und die Seite überhaupt keinen Tag enthält.
    
14. Ein kleiner, lokal ausführbarer „Echo-Server“ zu Testzwecken wäre sicher eine gute Idee. Der sollte nicht den Funktionsumfang von bo.php haben (vgl. Strategieüberlegungen), aber es würde das Entwickeln erleichtern, da bo.php eben logischerweise nicht von localhost Daten ziehen kann, was die Testbarkeit auf dem eigenen Rechner schon erschwert.

 

[arvgta]

Hallo Mermshaus!

Danke für die tolle Arbeit! Wie fange ich an? Am einfachsten, den "Scope" ein bißchen zu verkleinern, um Punkte, die ich nicht so tragisch sehe:

0. Zielgruppe?: Plakativ gesagt - HTML-Entwickler! Grundidee und einzigartige dabei soll sein, dass die Tags direkt im HTML stehen, egal in welchen Tier - Front-End / Mid-Tier oder sogar Datenbank (!)
Plattformunabhängiger geht's nicht!
1. Da bin ich dabei, die Tags mit einer Funktionalität auszustatten, dass die entsprechenden js's im Header nicht mehr angegeben werden müssen. Außerdem will ich in Zukunft möglichst viel serverseitig anbieten.
2. Ich biete an, dass der Kunde seine Kennung einmalig in "html.txt" angibt und dass GA dann site-global funktioniert. Muß nur garantieren, dass der Code aktuell ist - interessiert den User weiteres?
3. html.txt soll in Zukunft komplett in einer Datenbank bei 4nf.org verschwinden - darüber ein Web-Interface!
4. Geiler Punkt! Würde ich gerne machen - der Frust eines jeden JS-Entwicklers, oder? (In der PHP Welt sehe ich da weniger Leidensdruck - da gibt es in den neueren Subversionen von 5 große Fortschritte)
Wann kommt JavaScript 2.0 endlich??
5. Ein Riesen-Fortschritt, dass einige Sachen überhaupt parametrisierbar sind - klar kann man das erweiteren, z.B. ist mir eingefallen, dass ich vielleicht einen "Switch" für die History API anbieten möchte, dass man sie bei Bedarf auch per Parameter auf diese Art und Weise ausschalten kann?
6. Bin im Moment ganz froh, dass der Algorithmus dadurch einfach bleibt. Bin gespannt, ob jQuery wirklich diese Funktionalität über Bord wirft.
7. Mißverständnis - ich wollte damit auf Deep-Links überprüfen - es funktioniert auch - hab's wieder enabled und brauche es auch im Moment. Hat mit der Domain oder Localhost nichts zu tun...
8. Sehr geil! Diese Möglichkeit wird durch die Architektur als jQuery PlugIn natürlich gefördert und gern gesehen. Dann sollte es auch $(this) zurückgeben für Chainability?
Ich glaube diese Möglichkeit wäre dann aktuell, wenn ich Syntax und Semantik des Ganzen erweitert habe, und es attraktiv ist, auch einzelne Tags anzusteuern, statt die ganze Seite global.
9. Style werde ich vielleicht in Zukunft komplett dem User überlassen. Wahrscheinlich werfe ich diese "Mini-Stylesheets" ganz raus. Sehr fragwürdig, ob das PlugIn sich auch noch in Style überhaupt einmischen sollte?
10. Stimmt - spätestens wenn's "Beschwerden" gibt muß man handeln, am besten schon lange davor!
11. Eine Art __construct()-globale Semaphore könnte ich mir dazu vorstellen? -> Schön performant.
Momentan macht es keinen Sinn, "bo" zweimal aufzurufen. Aber man muß an die Erweiterbarkeit für die Zukunft denken :-)
12. Ge-fixed (glaube ich): Benutzt nun ein <div> mit "class" statt mit "id" - Danke!
13. Dazu habe ich folgende Seite eingeführt: New HTML tags - Mini - A test page without tags - kein einziger Tag - es funktioniert. Außerdem eine kurze Validierung im Code eingefügt.
14. Interessant - Danke!

Ich kann die nächsten Schritte benennen, die ich sehe, abgesehen von dem, was von der obigen Liste übrig bleibt:

- Evaluieren, ob ich das Ding wirklich bei forum.jquery.com einreichen möchte (sobald die Site wieder oben ist) - geht es rechtlich trotzdem die derzeitige Creative Commons Lizenz aufrechtzuerhalten?
- bo.php ausbauen - da ist noch viel Platz, die Syntax+Semantik des ganzen mächtiger zu gestalten - ein Freund von mir meint, ich solle Richtung DSL gehen (Domain Specific Language)
- DB bei 4nf.org dann drunterlegen - Datenmodell möglichst generisch und erweiterbar in MySQL
- Web-Interface bei 4nf.org drüberlegen - Relaunch der gesamten Site

Offene, dringende Fragen an alle:

- Ist die jetztige Creative Commons Lizenz ("no derivatives, commercial needs waiver") tragbar, wenn ich das Ding bei plugins.jquery.com einreiche? Oder muß man komplett "Open Source" gehen?
- Kann ich, bei Einreichung, das PlugIn weiterhin ausschließlich auf meiner Site hosten, oder verlangt plugins.jquery.com dann einen obligatorischen Upload?
(ich würde gerne in gewohnter Art weiterentwickeln, nur eine Version pflegen und für Aktualität des Ganzen garantieren wollen - auf meiner Site)
- Was sind Eure größten Bedenken, das PlugIn einzusetzen? Welche Risiken bestehen? Was kann ich besser machen?


Danke!

LG

 

[mermshaus]

2) Ja, ich denke, es gäbe weitere Variablen, die Nutzer setzen wollen würden. Doofes Beispiel, das mir gerade einfällt: Wenn in einer Seitenspalte auf jeder Unterseite immer die letzten Tweets des Seitenbetreibers auftauchen sollen, müsste der Twitter-Nutzername irgendwo angegeben werden. Wenn du aber eine Funktionalität hast, die generell die Definition eigener Makros/Tags erlaubt, kann sich ein Nutzer natürlich auch einen Tag !ga oder !twitter bauen, der entsprechend ausgewertet wird.

4) Frust oder Lust… Es gibt etliche unterschiedliche Patterns in JavaScript, um OOP zu ermöglichen (Suchbegriff wäre „javascript oop pattern“ oder so). JavaScript nutzt das Konzept der Prototypen. Das ist grob gesagt ein anderer Ansatz als in der „klassenbasierten“ OOP. Es wird nicht durch explizite Syntax vorgeschrieben, wie eine Klassendefinition auszusehen hat. Die allgemeinen Konzepte sind aber prinzipiell irgendwie umsetzbar.

5) Denkbar ist es. Das ist in meinen Augen eine dieser Konzeptentscheidungen, die letztlich kaum qualitativ zu beurteilen sind, wenn man ihnen nicht gerade völlig ablehnend gegenüber steht. Ich denke, so was ist für Außenstehende auch allein deshalb immer kaum möglich, weil es vor allem deine Idee und dein Projekt sind.

8[noparse][/noparse]) Ja zu allem.

9 und 10) Siehe Anmerkungen zu 5. Ich vermag es nicht zu sagen.

11) Ja, den Punkt habe ich mehr der Vollständigkeit halber aufgeführt. Software kann man als Anwender letztlich immer irgendwie falsch bedienen, wenn man es drauf anlegt.

14) Das müsste vielleicht nicht mal eine externe Sache sein, sondern könnte irgendwie in bo.js integriert werden (dass unter bestimmten Bedingungen gar nicht erst ein Ajax-Request abgesetzt wird, sondern bo.js selbst „irgendwas“ macht). Sonst wird es schon wieder zu schwierig, das einzusetzen.

Vielleicht ist es aber die beste Lösung, wenigstens für Testzwecke nicht den URL an bo.php zu schicken, sondern komplett den abzuarbeitenden Content. Den holt sich bo.php ja sowieso, aber wenn er aktiv mitgeschickt wird, funktioniert es auch von Hosts aus, auf die bo.php keinen Zugriff hat.

- Evaluieren, ob ich das Ding wirklich bei forum.jquery.com einreichen möchte (sobald die Site wieder oben ist) - geht es rechtlich trotzdem die derzeitige Creative Commons Lizenz aufrechtzuerhalten?

Kann ich nicht sagen. Ich habe mich mit dem Plugin-Verzeichnis und den Nutzungsbedingungen beziehungsweise der Möglichkeit der Übermittlung von Plugins nie großartig beschäftigt. Das ist glaube ich auch irgendwie umgebaut worden oder wird noch umgebaut, ja.

- bo.php ausbauen - da ist noch viel Platz, die Syntax+Semantik des ganzen mächtiger zu gestalten - ein Freund von mir meint, ich solle Richtung DSL gehen (Domain Specific Language)

Mhm, wobei die Aussage für sich erst mal sehr allgemein ist. Formalisierung/Definition generell ist aber so oder so eine absolut sinnvolle Sache. Das zwingt zu Entscheidungen über Formate und Abläufe, macht die Beschreibung von Schnittstellen möglich und erlaubt auch sinnvolle Dokumentation. Auf bekannte Begriffe (und Formate, Technologien) zu setzen, um überhaupt erst mal das zu benennen, was du tust, halte ich für extrem hilfreich.

Na ja, auch dieser Aspekt fällt für mich stark in den „Dein Projekt, deine Entscheidungen“-Bereich. Das sind jedenfalls keine ganz simplen Überlegungen.