ugrás a tartalomhoz

Képzeletbeli kliensoldali HTML include utasítás

Anonymous · 2006. Ápr. 9. (V), 10.26
Egy megoldás XmlHttpRequest segítségével
 
1

IFRAME, SCRIPT

attlad · 2006. Ápr. 9. (V), 11.44
Az IFRAME-mel hasonló dolog megoldható és az JavaScript független.

A javascriptet nem látják a keresők.

Külső JavaScript (script src) megoldás ellen ez az érv az oldalon. De a megoldás ugyanúgy JavaScript és XMLHttpRequest függő. Akkor mi az előnye?
2

Pontosabban

Bártházi András · 2006. Ápr. 9. (V), 12.27
Az iframe-mel azért egy elég ronda probléma van: nem lesz az oldal része a tartalma (háttérszínről, stílusról, kontextusról gondoskodnod kell), és a tartalom nem határozza meg a doboz nagyságát. Meg a dobozból nem is tudsz igazán "kitörni".

Ami a keresőket illeti, ezt látják. Ha egy sima linkkel teszed be az oldalba, akkor azt követni fogják, és szépen leindexelik.

Ez a megoldás nem abszolút jó, vagy abszolút rossz természetesen. Egy új(!) eszközt ad a webfejlesztőnek, amivel lehet élni, ha úgy hozzák a körülmények.
3

Re

attlad · 2006. Ápr. 9. (V), 12.49
A Google nekem simán indexel IFRAME-t is, további előnye hogy JavaScript nélkül is megy.

A SCRIPT SRC-vel összehasonlítva:
  • mindkettővel lehet HTML részt beilleszteni
  • mindkettőnek JavaScriptre van szüksége, a linkelt megoldásnál XMLHttpRequest támogatásra is
  • mindkettőnél megadható alternatív tartalom, amit látnak a keresők
  • a sima SCRIPT-es megoldásnál a NOSCRIPT bármit tartalmazhat, viszont A elembe nem rakható bármi
5

Félrebeszélünk

Bártházi András · 2006. Ápr. 9. (V), 16.53
Az iframe megoldás valóban működik JS nélkül is, de mint írtam, az oldal egységébe illeszkedő beillesztést megnehezítheti (az oldal CSS-e, színei, stb. nem fognak közvetlenül hatni az iframe tartalomra, illetve a doboz nagyságát sem a tartalom határozza meg). Ez van ahol jó lehet, s van, ahol rossz.

A script megoldással összehasonlítva a meglátásaid jók, de ha megnézzük, hogy jellemzően mire lehet egy ilyen megoldást használni, akkor még kiegészülnek a következőkkel:
  • A script tartalmát nem fogja leindexelni a kereső, egy belinkelt oldalt igen.
  • A noscript részbe valóban lehet tenni bármit, de ha egy HTML részlet behúzása a célünk, azt úgyse tudjuk helyettesíteni így, vagy ha igen, akkor pedig minek húzzuk be? Szóval így is, úgy is egy rövid szöveg, link kerülhet oda.
  • A script megoldás document.write()-jait macerásabb előállítani, mint egy sima HTML kódrészletet.
Mint korábban is írtam, nem ez az ultimate megoldás, viszont én úgy látom, hogy igenis van helye a webfejlesztői palettán. Hogy ellene is felhozzak valamit: míg script-et bárhonnan a webről, addig XMLHtttpRequest kérést (szerver oldali támogatás nélkül) csak ugyanarról az oldalról lehet kezdeményezni.
6

Lista

attlad · 2006. Ápr. 9. (V), 19.07
Akkor hogy teljes legyen a lista:
  • Blogmarkos megoldásnál a belinkelt oldal nem lesz valid, nem lehet formázni CSS-sel, a felhasználó furcsálhatja az oldalt
  • Az IFRAME megoldás kb. 3 sorral több (DOCTYPE, TITLE, LINK) valid és mindenhol megy, a bizonyos esetekben jelentkező hátrányát leírtad
  • SCRIPT SRC megoldással 2x kell dolgozni, de valid, kereső- és felhasználóbarátabb lesz

Amúgy az ötlet és a megvalósítás szerintem nem rossz. De inkább váltson tárhelyet, akinek ilyesmire lenne szüksége és nincs a tárhelyen PHP vagy egyéb szerver oldali lehetőség.
7

Namégegyszer

vbence · 2006. Ápr. 9. (V), 20.30
Csak annyit tennék hozzá, hogy a Blogmarknál a belinkelt html örökli a linkelő oldal minden css paraméterét, és hogy a SCRIPT SRC _NEM_ keresőbarát :)
8

Re: Namégegyszer

attlad · 2006. Ápr. 9. (V), 20.59
Arra írtam, hogy maga a fragment HTML fájl tartalmaz formázást. JS nélkül a linkre kattintva formázatlan oldal lesz látható.

SCRIPT SRC: Csinálsz egy JS fájlt és egy HTML-t is, a NOSCRIPT-be rakod a linket a HTML fájlra van, ezért írtam, hogy 2x kell dolgozni. Mivel van indexelhető HTML oldal, ezért keresőbarát.

Amúgy a te verziód lehetne a legjobb, ha mondjuk a fragment HTML fájl nem csak a kódrészletet tartalmazna, hanem egy teljes HTML oldal lenne és lenne benne egy ilyen rész: <div id="fragment">...</div> a JS azt szúrná be ami ebben a DIV-ben van.
9

Vagyúgy

vbence · 2006. Ápr. 9. (V), 23.52
Oké, ha használod a noscriptet, valóban keresőbarát, de akkor minek az include?

Amúgy a szkript olyanra készült, hogy ne kellessen nagyon profinak lenni a használatához, ezért is text módban kéri le a fájlt. Ha mindenáron valid fragmentumokkal akarsz dolgozni nem kell sokat módosítani, csak ellenőrzöd, hogy van-e responseXML, és ha igen, akkor a body tartalmát másolod át.

Ha viszont így közelíted meg, egy rakás kérdésen el kell gondolkozni, pl ha fejlécet használsz a linkelt fájlban, használhatsz saját stílus információt is. Ami nem baj, lehetőséged van megadni pl. egy standalone.css -t, ami azt az esetet kezeli, amikor közvetlenül a linkelt fájlt nyitják meg.

Ebben is van ráció, de a korrektségnek ez a foka talán túl sok munkát jelent, ha azt vesszük, hogy az esetek kevesebb, mint egy százalékában érdekes a dolog.
10

span és beszúrás

Jano · 2006. Ápr. 10. (H), 00.17
Egyik hibája a konkrét megvalósításnak, hogy egy SPAN elembe rakja bele a külső fájlból behúzott HMTL töredéket, pedig az tartalmazhat blokk típusú elemet is, ami az inline span elembe nem megengedett. Jobb lenne alapból DIV-be pakolni és ha kinézet megkívánja CSS-ből átállítani ennek a DIV-nek a megjelenítését.

A függvény végén így első ránézésre feleslegesnek tűnik a beszúráshoz a ketté bontás aszerint, hogy van-e másik elem a link mellet vagy sem. Egyszerűen csak megkéne fordítani a sorrendet és kihasználni, hogy a link úgyis ott van és azelé beszúrni az új span (div) elemet, majd törölni.
13

jogos

vbence · 2006. Ápr. 10. (H), 10.02
Nos, mindkét pontban teljesen igazad van. A span csak amolyan próbamegoldásnak készült, aztán mivel semmi probléma nem volt vele hagytam. A div azért nem jó, mert az meg mindenképen egy új blokkot eredményez.

A beszúrással eredetileg az volt a probléma, hogy a tags[i] megváltozik beszúrás a után, ha volt A elem a beszúrt kódrészletben. Valami dinamikus kollekció avgymiafrász lesz, és ez annyira meglepett, hogy nem jutott eszembe, hogy egy "a = tags[i]" -vel az egészet át lehetne hidalni...

Valószínűleg ki fogom javítani a hibákat, amiket észrevételeztetek...
4

Hejhó

vbence · 2006. Ápr. 9. (V), 14.19
Igaz, hogy Javascript függő, meg Xmlhttp függő, de ez a kettő napjainkban (szerintem) egy és ugyanaz.
Már rendgeteg topicban leírták azt is, hogy az oldal célközönsége fontos szempont a felhasznált eszközök tekintetében. Egy divatfotós portfolióját valószínűleg kevesen akarják majd lynx-ben nézegetni :)
11

Grat

Jano · 2006. Ápr. 10. (H), 00.29
Bár itt lejjebb (feljebb) kifejtették mások, hogy miért nem tekinthető - a szerző minden igyekezete ellenére - tökéletes megoldásnak az include problémára, én szeretnék gratulálni az ötlet és a gondolatmenet publikálásáért!

A megoldás "célközönsége" pont az olyan kezdő oldal készítők akiknek fogalmuk sincs arról, hogy milyen követelményeknek kell eleget tennie egy oldalnak, de ha megtalálják ezt a megoldást és mellette a magyarázatot elolvassák, akkor az néhány új szemponttal is megismerteti őket (szabványosság, szemantikusság, keresőbarátság)!
12

Re

vbence · 2006. Ápr. 10. (H), 09.51
Köszi!