ugrás a tartalomhoz

Internet Explorer adatkapcsolások

PiG · 2004. Nov. 16. (K), 22.00
Internet Explorer adatkapcsolások
Az Internet Explorer 4.0-s verziója óta áll az adatkapcsolási technika a fejlesztők rendelkezésére. Bár az említett verzió már elég régen jelent meg, mégis viszonylag ritkán találkozhatunk olyan oldalakkal, melyek kihasználják az adatkapcsolás lehetőségeit. Ennek oka nem a technika bonyolultságában keresendő, hanem abban, hogy jelenleg más böngészők egyáltalán nem támogatják az IE által megvalósított adatkapcsolást, mivel az egyáltalán nem szabványos. A cikkben bemutatott technológiát ne használjuk az interneten!

Csatolmányok

Miről is van szó - mi az az adatkapcsolás?

Az adatkapcsolás alkalmazásával lehetőségünk nyílik különböző HTML elemek tartalmát adatforrásokban található adatokhoz kötni. Segítségével oldalunkon dinamikusan tudunk adatokat megjeleníteni, rendezni és keresni, mindezt kliens oldalon, mindenféle szerveroldali segítség (adatbázis kiszolgáló, szerveroldali scripnyelvek) igénybevétele nélkül. Az adatkapcsolásnak megvan tehát az az előnye, hogy nem kell folyton a szerver válaszára várni.

Az Internet Exploreren belül megvalósított adatkapcsoláshoz szükségünk van adatforrásra (ebben találhatók maguk az adatok) és adatfogyasztókra (ezek jelenítik meg az adatokat). Adatforrás sok minden lehet: szövegfájl, maga az adatkapcsolást megvalósító HTML fájl, külső HTML file, XML fájl, adatbázis, Excel fájl, külső alkalmazás, stb. Adatfogyasztó (adatmegjelenítő) lehet valamilyen HTML elem az oldalon belül.

Cikkemben kétféle megoldást ismertetek, az egyik esetben egy CSV fájlból nyerünk ki adatokat a Tabular Data Control vezérlő segítségével, a másik esetbeen pedig XML adatok szolgálnak adatforrásként.

Menjünk biztosra!

Mivel, mint említettem a technológia csakis IE-ben áll rendelkezésünkre olyan helyen alkalmazzuk, ahol biztosak lehetünk ezen alkalmazás meglétében! Ha Windowst használunk, akkor nap, mint nap használunk IE-t, még akkor is, ha nem tudjuk, ott van az orrunk előtt, úgy hívják: Active Desktop. A cikkben szeretnék néhány olyan alkalmazást bemutatni, melyeket eredetileg Active Desktopon való felhasználásra szántam, bár semmi akadálya, hogy ezeket webes környezetben is használjuk, de csak akkor - nem győzöm elégszer hangsúlyozni -, ha biztosak vagyunk abban, hogy felhasználóink Internet Explorert használnak (intranet, saját használatra készült oldal).

Táblázatos adatok kapcsolása

Telefonszám nyilvántartó

Példánkban az ábrán látható telefonszám nyilvántartót fogjuk létrehozni, melynek csupán az alapszerkezetét kódoljuk le a HTML fájlban, a sorok feltöltése egy külső fájlban található adatokkal történik. Minimális Javascript segítségével adatainkat tetszőlegesen rendezhetjük, kereséseket végezhetünk.

Adatfájl létrehozása

Az Internet Explorer egyes adatkapcsolási szolgáltatásainak jellemzője, hogy adatbáziskezelő szerver illetve webszerver nélküli környezetben (pl.: Windows munkaasztal) működnek. Elegendő, ha létrehozunk egy egyszerű szövegfájlt - persze megfelelően struktúrálva - és ezt használhatjuk adatforrásként. A példához a következő tartalmú fájlt használom, melyet az egyszerűség kedvéért a HTML fájllal egy mappába mentettem le telefonok.csv néven:
Nev;Telefon
Mónikasó;123456
Beszéljükmeg Barbi;987654
Balázs Segít;246802
Besenyő Pisssstabá;100000
Amint látható, az első sor tartalmazza a mezők neveit, a többi sor pedig a tényleges adatokat. Gondolom a gyakorlottabbak azt is észrevették, hogy ez bizony egy teljesen szokványos CSV fájl, azaz az egyes rekordok soronként találhatók, a mezőket pedig valamilyen elválasztó-karakterrel különítjük el egymástól. Jelen esetben a pontosvesszőt alkalmaztam. Ilyen fájlt készíthetünk Excelben, de akár Jegyzettömbben is.

Adatfogyasztó létrehozása

Nos adatfájlunk már lenne, következőként lássuk a megjelenítést végző HTML részt, azaz az adatfogyasztónkat. Az adatfogyasztóknak két fő típusa van, az egyedi értéket fogyasztó (single-valued consumer) és a táblázatos fogyasztó (tabular consumer). Az egyedi fogyasztó az éppen aktuális rekord egyetlen mezőjét jeleníti meg, míg a táblázatos fogyasztó a rendelkezésre álló teljes adatkészletet. A táblázatos fogyasztók az általuk tartalmazott elemeket sablonként használva, azokat ismételve állítják elő az oldal végleges tartalmát.

Mivel példánkban adatainkat táblázatos formában szeretnénk megjeleníteni, ezért egy táblázat sablont készítünk. Figyelem! Szabálytalan, nem W3C szabványnak megfelelő elemek és megoldások következnek:
<table datasrc="#tdc" border="0" cellspacing="0" cellpadding="2" class="lista">
<thead><tr><th>Név</th><th>Telefonszám></th></tr></thead>
<tr>
<td><span id="nev" datafld="Nev"></span></td>
<td><span id="telszam" datafld="Telefon"></span></td>
</tr>
</table>
Mint látható a table elemen belül megadunk egy datasrc nevű tulajdonságot. Ez annak az adatforrás objektumnak az azonosítója, mely a tulajdonképpeni összeköttetést valósítja meg szövegfájlunk és a HTML elemek között. Létrehozását a következő pontban mutatom be. Az azonosító bármilyen szabályos azonosító lehet, lényeg, hogy a kettő helyen egyezzen meg, valamint első karakterként mindenképp szerepeljen a # (kettőskereszt).

Vizsgáljuk meg sablonunkat közelebbről! A thead elem használata egyértelmű, persze nem kötelező, de azért példánkban jó szolgálatot fog tenni. A sablon "lelke" a tr elem és az általa közrefogott td elemek. Adatfájlunk minden sorához a tr elemen belül meghatározott szerkezetnek megfelelően fognak megjelenni adataink a generált oldalon. A td-ken belüli datafld tulajdonság határozza meg, hogy melyik mező tartalma kerüljön beillesztésre. Ezek a datafld értékek a szövegfájlunk első sorában megadott mezőneveknek felelnek meg. Tehát végeredményben adatfájlunk minden sorának egy táblázaton belüli sor fog megfelelni, minden mezőjének pedig egy táblázatcella. Ez így logikusnak tűnik, azonban hadd hívjam fel néhány óriási logikai bukfencre a figyelmet. Amint látható, nem a td elemhez rendeljük a datafld tulajdonság segítségével az adatmezőket, hanem az azon belül található span elemhez. Ennek magyarázata az, hogy a td elem nem lehet adatfogyasztó, a span viszont igen. Nos, figyelembe véve, hogy rekordkészletek megjelenítése főleg táblázatos formában történik, ez a viselkedés minimum furcsának mondható. Ugyanennyire furcsállottam a tbody viselkedését is. Persze ezek nem véletlenszerű viselkedések, a specifikációban dokumentálva vannak. Ha tbody elemet is alkalmazunk sablonunkban, akkor az is a sablon részeként fog viselkedni, tehát minden egyes adatsorunknak nem egy tr elem fog megfelelni, hanem egy tbody, azon belül pedig a tr elem. Jelen példánkban ez összesen négy tbody elemet eredményezne. Hááát, nem mondom, a nyilvánvalóan szükséges td elem nem támogatott, viszont a tbody elem, amiből - valljuk meg őszintén - egy is elegendő, az bizony ismétlődni fog. A rendszer alkotójának egy nagy gratula! Még valami: a thead és tfoot elemeken belül a tr elem sem fog ismétlődni! Ez mondjuk, jól jön.

Adatfájl és adatfogyasztó összekapcsolása

Miután rendelkezünk adatfájlal és az adatok megjelenítéséhez egy sablonnal, már csak a kapcsolatot kell felépíteni a kettő között, azaz lehetővé kell tennünk, hogy adatfogyasztónk elérhesse a fájlban tárolt adatokat. Az adatelérést egy "beépített" ActiveX vezérlő, a Tabular Data Control valósítja meg, mely vezérlő használatba vételének szándékát HTML oldalunkon jelezni kell. Ezt a "jelzést" az <object> elem segítségével tehetjük meg; tudnunk kell még, hogy kötelezően fell kell tüntetnünk az ActiveX objektum egyedi azonosítóját a classid tulajdonságban, mely minden esetben a következő:
clsid:333C7BC4-460F-11D0-BC04-0080C7055A83
Ezek után paraméterek megadásával tudjuk beállítani objektumunk megfelelő viselkedését.

<object classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83" id="tdc">
<param name="..." value="...">
<param name="..." value="...">
...
</object>
A fontosabb paraméterek a következők:

CharSet: Az adatfájlban használt karakterkészlet (értékei a szokásosak pl.: windows-1250, utf-8, iso-8859-2, stb. Bővebben a megadott forrásokban utánakereshetőek.
DataUrl: Az adatfájl URL-je, szabványos jelöléssel, teljes, vagy relatív elérési úttal (http://weblabor.hu/akarmi.csv, telefonok.csv, stb.).
FieldDelim: Az adatmezőket elválasztó karakter. Ha nem adjuk meg, alapértelmezett értéke: , (vessző).
TextQualifier: A speciális karaktereket is tartalmazó szövegeket határoló jelet adhatjuk meg. Pl.: ha FieldDelim értéke: , (vessző) és adatmezőnkben is szerepel a vessző karakter, akkor ezen határoló jelekkel kell körbevennünk a mezőnket, hogy helyesen kerüljön értelmezésre: "egy, megérett a meggy". Alpértelmezett értéke a " (idézőjel).
RowDelim: Az adatsorokat elválasztó karakter. Alapértelmezett értéke, ha nem adjuk meg: newline, azaz újsor karakter, ahogy én is tettem, szöveggel kiírva.
UseHeader: Megadja, hogy adatfájlunk első sora fejlécinformációt tartalmaz-e, vagy pedig konkrét adatot. Értéke true (van fejlécinfó) vagy false (nincs fejléc) lehet.

A működőképes oldal

Az eddigieket összerakva egy HTML oldalba, valamint a fent megadott módon létrehozott csv fájlt ugyanabban a könyvtárban telefonok.csv néven elmentve, majd Internet Explorerbe betöltve az oldalt sok minden világosabbá válik az eddigiekből. A teljes oldal kódja a következő:
<html>
<head>
<title>Telefonszámok</title>
<link rel="stylesheet" href="style/style.css"/>
</head>
<body>
<object classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83" id="tdc">
<param name="FieldDelim" value=";">
<param name="TextQualifier" value='"'>
<param name="UseHeader" value="true">
<param name="DataURL" value="telefonok.csv">
</object>
<table datasrc="#tdc" border="0" cellspacing="0" cellpadding="2" class="lista">
<thead><tr><th>Név</th><th>Telefonszám</th></tr></thead>
<tr>
<td><span id="nev" datafld="Nev"></span></td>
<td><span id="telszam" datafld="Telefon"></span></td>
</tr>
</table>
</body>
</html>

Adatok rendezése

Már korábban említettem, hogy a rendelkezésre álló adatainkat egyszerű módon sorba rendezhetjük és kereshetjük JavaScript segítségével. Lássuk először a rendezést!

A rendezéshez a Tabular Data Control Sort tulajdonságát és Reset() metódusát kell csupán felhasználnunk. A Sort tulajdonság segítségével tudjuk beállítani az elsődleges, másodlagos, stb. rendezési szempontokat, valamint a csökkenő és növekvő rendezést. Ha több szempont alapján adunk meg rendezést, akkor ezeket ; (pontosvessző) karakterrel kell elválasztani egymástól. A rendezés megadásánal az adatfájlban szereplő mezőneveket kell magadnunk. Növekvő sorrendet a + (plusz) jellel, csökkenőt a - (mínusz) jellel adthatunk meg. Ha üres értéket adunk, akkor nem lesz rendezés. A Sort tulajdonság beállításának nincs azonnali hatása, a Reset() metódust meghívva hajtódik végre maga a rendezés. Lássunk néhány példát:

Név szerinti növekvő rendezés:
tdc.Sort="+Nev"; tdc.Reset();
Telefonszám szerint csökkenő rendezés:
tdc.Sort="-Telefon";tdc.Reset();
Név szerint növekvő, azon belül telefonszám szerint csökkenő rendezés:
tdc.Sort="+Nev;-Telefon"; tdc.Reset();
Nos ennyi elmélet után lássunk neki a tényleges megvalósításnak. Mivel egyszerű és fájdalommentes megoldásra törekszünk, oldjuk meg a feladatot úgy, hogy a táblázat fejlécére kattintva a fejléc szerinti mező legyen a rendezési szempont. Ehhez az alábbi kis módosítást végezzük el táblázatunk fejlécén:

<thead><tr><th id="fej_Nev" onclick="rendezes();">Név</th><th id="fej_Telefon" onclick="rendezes();">Telefonszám</th></tr></thead>
Ezek után hozzuk létre magát a scriptet:
<script type="text/javascript">
function rendezes(){
	var rend="";
	switch (event.srcElement.id){
		case "fej_Nev":
			rend="+Nev";
			break;
		case "fej_Telefon":
			rend="+Telefon";
			break;
	}
tdc.Sort=rend;
tdc.Reset();
}
</script>
Alapértelmezett rendezettséget is megadhatunk adatainknak, ha az object elemben egy újabb paramétert veszünk fel, pl.: <param name="Sort" value="-Nev">. Ekkor adatfájlunk a betöltődés után név szerint csökkenő sorrendben fog megjelenni

Keresés, szűrés

Láthattuk, hogy a különböző szempontok alapján történő rendezéseket szinte kódolás nélkül valósíthattuk meg. Keresések esetében szintén könnyű dolgunk lesz, csupán a Tabular Data Control Filter tulajdonságát kell megfelelően beállítanunk, majd ezek után az előbbiekhez hasonlóan a Reset() metódust kell meghívnunk.

A filter tulajdonság megadásakor használhatjuk mezőneveinket, relációs jeleket (=, >, <, >=, <=, <>), logikai operátorokat (& - ÉS, | - VAGY) illetve zárójeleket, valamint a * helyettesítő-karaktert mely bármely karaktert helyettesíthet feltételünkben. Amennyiben egy kifejezésen belül használunk ÉS (&) és VAGY (|) operátorokat, akkor az egyes részkifejezések körül mindenképp használnunk kell zárójeleket. Lássunk néhány példát! A tdc objektum továbbra is a lapon található tdc azonosítóval ellátott Tabular Data Controlra hivatkozik:

Kikeresi apeh nevű kedves ismerőseinket:
tdc.Filter="Nev=apeh"; tdc.Reset();
Az "a" betűvel kezdődő nevek:
tdc.Filter="Nev=a*"; tdc.Reset();
Mindenki, akinek neve "a"-val kezdődik vagy telefonszáma 555-3331:
tdc.Filter="Nev=a* | Telefon=555-3331"; tdc.Reset();
Építsük be a fentieket példánkba! Ehhez hozzunk létre egy beviteli mezőt, ahová a feltételt írhatjuk, valamint egy nyomógombot.
<input id="txtFeltetel" style="border: 1px solid black; width: 100px;">
<input value="Keress!" type="submit" onclick="kereses();">
Ezek után scriptünket is egészítsük ki az alábbi sorokkal:

function kereses(){
tdc.Filter="Nev="+txtFeltetel.value+"* | Telefon="+txtFeltetel.value+"*";
tdc.Reset();
txtFeltetel.focus();
}
Mint láthatjuk függvényünk a beviteli mező szövege (txtFeltetel.value) alapján keres, mégpedig úgy, hogy a bevitt szöveget a Nev és a Telefon mezőkben is megtalálja a VAGY (|) kapcsolat miatt. A feltételben használt * karakter miatt ráadásul nem is kell végig beírnunk a keresett nevet vagy telefonszámot.

Aki kipróbálja tapasztalhatja, hogy a keresés érzékeny a kis-nagybetűk különbözőségére. Kényelmi megfontolásokból éppen ezért a fenti függvénybe a tdc.Reset(); sor elé szúrjuk be a tdc.CaseSensitive="false"; sort vagy az object elemen belül hozzuk létre a <param name="CaseSensitive" value="false"> bejegyzést.

XML adatszigetek

Mint bevezetőmben említettem XML adatokat is használhatunk adatforrásként. Ehhez az Internet Explorer által támogatott xml elemet kell használnunk, mely segítségével úgynevezett XML adatszigetet tudunk létrehozni a HTML oldalon belül. Nincs szükségünk külön ActiveX elemre, hogy megteremtsük a kapcsolatot az XML adatok és az adatfogyasztó HTML elemek között, mivel az XML adatok "közvetlenül fogyaszthatóak". Két lehetőségünk van:
  • közvetlenül a HTML oldalba ágyazzuk be adatainkat:
    
    ...<body>
    ...
    <xml id="xml_adat">
    <sajat_xml_tag> adatok</sajat_xml_tag>
    <sajat_xml_tag>további adatok</sajat_xml_tag>
    </xml>
    ...
    </body>...
    
  • külső fájlban helyezzük el azokat és az xml elem src tulajdonságában adjuk meg az elérési utat:
    
    ...<body>
    ...
    <xml id="xml_adat" src="xmlfile.xml"></xml>
    ...
    </body>...
    
    Fentiek alapján ismét nézzük egy példán, hogyan is tudjuk a gyakorlatban HTML elemeinket XML adatokhoz kapcsolni, milyen lehetőségeink vannak, és milyen akadályokat kell leküzdenünk!

XML adatok létrehozása

Példánkban néhány viccet ágyazunk be egy HTML oldalon elhelyezett XML adatszigetben, majd megalkotjuk adatfogyasztónkat és scriptünket, melyek segítségével bizonyos időközönként véletlenszerűen jelenítjük meg valamelyik viccet. Először egy nem működő példát mutatok be, mert úgy gondolom ebből is lehet tanulni. Persze a későbbiekben a működő megoldást is ismertetem! :)

<body>
<xml id="xml_viccek">
<viccek>
<vicc>- Két szőke nő beszélget...</vicc>
<vicc>- Fellőnek egy rendőrt és két majmot a világűrbe...</vicc>
<vicc>vicc 3</vicc>
</viccek>
</xml>
<div datasrc="#xml_viccek" datafld="vicc"></div>
</body>
Kezdjük a végén! A div elem nem táblázatos adatfogyasztó, hanem egyedi értéket fogyaszt, azaz egyszerre csak egyetlen (az éppen aktuális) rekord adatait tudja megjeleníteni. A további rekordok megjelenítéséről, a rekordok léptetéséről majd scriptben gondoskodunk. Mint látható, szándékaink szerint a vicc xml elemen belüli szöveget szeretnénk megjeleníteni. Sajnos, ebben az xml struktúrában ez nem fog sikerülni, semmi nem fog megjelenni a div elemen belül. A probléma megoldásához alakítsuk át adatszigetünket a következőképp, és módosítsuk a div datafld tulajdonságát is:

<body>
<xml id="xml_viccek">
<viccek>
<vicc><szoveg>- Két szőke nő beszélget...</szoveg></vicc>
<vicc><szoveg>- Fellőnek egy rendőrt és két majmot a világűrbe...</szoveg></vicc>
<vicc><szoveg>vicc 3</szoveg></vicc>
</viccek>
</xml>
<div datasrc="#xml_viccek" datafld="szoveg"></div>
</body>
Amint látható, egy plusz elemmel "burkoltuk be" adatainkat. Ezt a viselkedést nem láttam külön dokumentálva a Microsoft oldalain, de van rá magyarázat, s nem is olyan bonyolult: az XML szabvány megköveteli, hogy legyen egy gyökérelem, s csak egy legyen belőle.

A végleges oldal scripttel együtt


<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
<title>Viccek</title>
<script type="text/javascript">
var viccekSzama;
function init(){
viccekSzama=xml_viccek.recordset.recordCount;
myTimer=window.setInterval("mehet()",1000);
}
function mehet(){
melyik=Math.ceil(viccekSzama*Math.random());
xml_viccek.recordset.absolutePosition=melyik;
}
</script>
</head>
<body onload="init();">
<xml id="xml_viccek">
<viccek>
<vicc><szoveg>Két szőke nő beszélget:
- Mi az: hosszú és kemény?
- Nem tudom...
- Hát az általános iskola!</szoveg></vicc>
<vicc><szoveg>- Mi a különbség az okos szőke nő és az ufó között?
- Ufót már láttak!</szoveg></vicc>
<vicc><szoveg>- Mit mondasz egy szőkének, akinek két monoklija van a szeme alatt?
- Semmit. Kétszer már elmondtad.</szoveg></vicc>
</viccek>
</xml>
<div datasrc="#xml_viccek" datafld="szoveg"></div>
</body>
</html> 
Mint az előbbiekben is írtam a script segítségével választjuk ki a megjelenítendő rekordot. Amint látható a rekordkészletre az XML adatsziget recordset tulajdonságával hivatkozhatunk. Ez a tulajdonság egy ADO rekordkészlet, tehát az ADO objektummodell segítségével tudjuk azt manipulálni. A példában a recordCount tulajdonság segítségével megkapjuk az összes rekord számát, amire majd a véletlenszám-generálásnál lesz szükség, nehogy olyan számot generáljunk, aminek megfelelő indexű elem már nem található a rekordok között. A tényleges rekordra ugrást a mehet() függvény végzi. Miután meghatároztuk a kívánt rekordot a recordset absolutePosition tulajdonságával beállítjuk aktuálisnak. Figyelem: a rekordok indexelése 1-ről, és nem 0-ról indul!

HTML formázás XML adatszigeten belül

Adatkapcsolás során lehetőségünk van a az adatainkban HTML elemek elhelyezésére is. Ekkor az adatfogyasztó létrehozásakor be kell állítanunk a dataformatas="html" tulajdonságot is. Ezt megtehetjük az előzőekben ismertetett Tabular Data Control esetében is, de mivel az XML adatszigetek esetében "speciális" megoldásra van szükség, ezért most ismertetem.

Ha az xml elemen belül csak egyszerűen beírjuk a HTML elemeket a megfelelő formázás eléréséhez, akkor nagy valószínűséggel nem fogjuk látni rekordjainkat a kész oldalon, ugyanis azok nem megfelelően kerülnek értelmezésre. Lássuk az egyszerű megközelítést, ami nem jó:

<vicc><szoveg><p>- Mi a különbség az okos szőke nő és az ufó között?</p>
<p><strong>- Ufót már láttak!</strong></p></szoveg></vicc>
Nos, ebben az esetben a HTML elemeket is XML elemként próbálja értelmezni a böngésző, így a rekordszerkezet felborul. Ebből következik, hogy valamilyen módon arra kell rábírnunk az XML értelmezőt, hogy ne értelmezze tovább a szoveg elemen belül található adatokat. Ezt úgy érhetjük el, ha a teljes részt egy CDATA szekción belül helyezzük el:

<vicc><szoveg><![CDATA[<p>- Mi a különbség az okos szőke nő és az ufó között?</p>
<p><strong>- Ufót már láttak!</strong</p>]]></szoveg></vicc>
Persze ne felejtsük el az adatfogyasztó div dataformatas="html" tulajdonságát sem beállítani:

<div datasrc="#xml_viccek" datafld="szoveg" dataformatas="html">

További rekordműveletek

A teljesség igénye nélkül, tekintsünk át még néhány fontosabb rekordműveletet - ismét egy példán keresztül!

Létrehozunk egy XML adatszigetet az oldalon belül, melyben különböző eseményeket (születésnap, névnap, stb.) tartunk nyilván. Az egyes események között pedig gombok nyomkodásával lépkedhetünk előre és hátra. Lássuk mindjárt a teljes forráskódot, a magyarázatot pedig utána:

<html>  
<head>  
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
<title>Események</title>
<script type="text/javascript">
function valtas(irany){
rs=xml_esemenyek.recordset;
if (irany==1) (rs.absolutePosition<rs.recordCount)?rs.moveNext():rs.moveFirst();
else (rs.absolutePosition>1)?rs.movePrevious():rs.moveLast();
}
</script>
</head>
<body>
<xml id="xml_esemenyek">
<esemenyek>
<esemeny><tipus>születésnap</tipus><nev>Tudor</nev><datum>Március 1.</datum></esemeny>
<esemeny><tipus>születésnap</tipus><nev>Kuka</nev><datum>Május 10.</datum></esemeny>
<esemeny><tipus>születésnap</tipus><nev>Morgó</nev><datum>Szeptember 5.</datum></esemeny>
<esemeny><tipus>névnap</tipus><nev>Hapci</nev><datum>December 6.</datum></esemeny>
</esemenyek>
</xml>
<span datasrc="#xml_esemenyek" datafld="datum"></span></br>
<span datasrc="#xml_esemenyek" datafld="nev"></span>&nbsp;<span datasrc="#xml_esemenyek" datafld="tipus"></span>
<div id="vezerlok">
<input type="button" value="&lt;&lt;" onclick="valtas(-1);">
<input type="button" value="&gt;&gt;" onclick="valtas(1);">
</div>
</body>
</html>
Az XML rész nem hinném, hogy bővebb magyarázatra szorulna. Adatfogyasztóink span elemek, melyek datafld tulajdonságában állítjuk be a megjelenítendő mezőnevet. Az érdekesebb rész a scripten belül található. A valtas() függvény a gombok megnyomása után kerül meghívásra, és a következő illetve előző rekordra lépteti a rekordmutatót. Az előreléptetést a moveNext(), a visszaléptetést a movePrevious() ADO függvénnyel éjük el. Még annyit trükközünk, hogy ha a rekordmutató az utolsó rekordot elérte, akkor "körbeforgunk", és az első rekordra ugrunk a moveFirst() függvénnyel. Ugyanezt tesszük, csak fordítva a rekordkészlet elejét elérve, ekkor az utolsó rekordra ugrunk a moveLast() metódussal.

Felhasználási lehetőségek, korlátok

Mint láthattuk a technika alkalmazásával nagyon egyszerűen és gyorsan tudunk szokványos adatkezelési műveleteket végrehajtani, szinte kódolás nélkül. Mindeközben persze ne felejtsük el a korlátokat sem! Nagy méretű, gyakran változó adathalmaz kezelésére a módszert ne használjuk. Ismét hangsúlyozom, hogy jelenleg csakis Internet Explorerben működő megoldásról van szó, bár előfordulhat, hogy a jövőben más böngészők is támogatni fognak hasonló technikákat. Egyes régebbi, illetve személyre szabott IE telepítéseken sem garantált a működés, feltétel ugyanis az adatkapcsolási lehetőségek telepítése - XP-n ez alapban adott. Ha biztosak vagyunk az előbbi feltételek teljesülésében (pl.: intranetes alkalmazás, saját használatra készült oldal, Windows munkaasztalon történő alkalmazás) csak akkor bízzuk magunkat a fenti megoldásra.

További lehetőségek

Az Internet Explorer adatkapcsolási technológiáról még oldalakon keresztül lehetne írni, erre idő hiányában egyelőre nem vállalkozom. Remélem azonban, hogy aki valamennyire fogékony a téma iránt, annak az érdeklődését sikerült felkeltenem, és a források közt utánanéz a többi lehetőségnek is, úgy mint az MSHTML adatforrás, illetve a Remote Data Service (RDS) által nyújtott lehetőségek, valamint az adatkapcsoláshoz kapcsolódó eseménymodell.

Jó próbálgatást!

Források

 
1

ezt nem értem

chx · 2004. Nov. 23. (K), 16.47
miért reklámozunk ilyen technológiát? valahogy a weblabor szellemiségétől idegen az egész... és ha nem az interneten, hanem intraneten alkalmazod, akkor tök jó, még egy ok, amiért egy cég nem áll át IE-ről egy normális böngészőre.
2

IE

Bártházi András · 2004. Nov. 23. (K), 17.23
Kérdésedre két válaszunk is van: :)
  • Egyrészt szívesen fogadunk minden cikket, ha szeretnél egy másik témakörben beküldeni, megjelenhet az is.
  • Másrészt maga a technológia jó, és önmagában értékesnek tartjuk - ha egyvalakit inspirál hasonló, de szabványos megoldásra, máris megérte publikálni a cikket is.
Az Internet Explorer egy elavult, a webes szabványokat rosszul, vagy nem támogató program. Emiatt nagyon nem szeretjük. De nem szerencsés, ha valaki nem ismeri azt, ami ellen küzd, s nem képes átvenni annak előnyös lehetőségeit.

Részemről egyébként több reklamációra számítottam. :)

-boogie-
7

IE és a szabványok

Normanka · 2005. Jan. 10. (H), 11.46
Pontatlan az "Az Internet Explorer egy elavult, a webes szabványokat rosszul, vagy nem támogató program" kifejezés. A legtöbb esetben a tényleges helyzet: az IE igenis alkalmazza a szabványokat, de vonzó többletmegoldásai túlmennek azokon. Ezért az IE megjeleníti a szabványos megoldást, de ezen túl sok olyat is, ami máshol nem alkalmazható. (Ez a Microsoft jellemző üzleti magatartása: az ember nyakába önti a kínálatát, az első nem a be-, hanem a kikapcsolásuk.) Ilyen pl. az SRC, DATAFLD, DATAFORMATAS attribútum, amelyek mögött az áll, hogy a <XML SRC="külső xml-fájl"></XML> adatszigettel beolvasott külső xml-fájl automatikusan elhelyezkedik az MSXMLDOM objektumban. Ilyesmit például a Mozilla nem szolgáltat, noha ismeri a DOM-ot, és görcsös, de talpig szabványos scripteléssel az el is érhető. Az ilyesfajta megoldás mindjárt keresztplatformos, mivel az IE is hibátlanul megjeleníti.
Mivel a keresztplatformosság fontos aktualitás, a hozzá kapcsolódó ismereteknek pontosaknak kell lenniük ideologikusság helyett.
9

Re: IE és a szabványok

kmm · 2005. Jan. 10. (H), 12.08
Sajnos a fenti:
»Pontatlan az "Az Internet Explorer egy elavult, a webes szabványokat rosszul, vagy nem támogató program"«
kifejezés pontatlan,
ugyanis az explorer nem támogatja például az XHTML-t
és hibásan a CSS-t. tehát a fenti állítás miszerint "Az Internet Explorer egy elavult, a webes szabványokat rosszul, vagy nem támogató program" igaz.


--
üdv: kmm...
12

Lehet, hogy rosszul tudom, de

Normanka · 2005. Jan. 10. (H), 21.46
Lehet, hogy rosszul tudom, de az XHTML támogatása azt jelenti, hogy egy XSLT által a tagek megközelíthetők, vagyis az XML adatok beléjük konvertálhatók (főleg megfelelő névtér-hivatkozással). Ezt tudja az IE. Mennyiben nem támogatja az XHTML-t?
CSS: egyetlen belső következetlenséget találtam: egy HTML Style szegmensét az OutLook HTML-mail nem jeleníti meg jól, hanem inline style-t kell alkalmazni. Ezen túl más hibákat nem találtam a CSS-kezelésben. Az igaz, hogy amikor style formázással ellátott oldalt keresztplatformossá akartam tenni, némi redundanciára kényszerültem, de inline kóddal sikerült. Tudnál mondani példát a tényleges hibás kezelésre?


Normanka
13

re: xhtml támogatás

kmm · 2005. Jan. 10. (H), 22.28
Hát próbálj meg ie-nek szbványos xhtml headert adni, és látod, hogy nem támogatja (hacsak a save file as vagy mit rak ki azt nem így nevezzük).

CSS pl a box model, ha jol tudom az ie a szabványtól teljesen eltérően csinálja. erre szerintem találsz pár példát itt is.


--
üdv: kmm...
14

Szabványok

Bártházi András · 2005. Jan. 10. (H), 22.34
Az XHTML támogatás azt jelentené, hogy egy XHTML-ként kiszolgált oldalt (megfelelő MIME fejléccel megjelölve) az Internet Explorer kiszolgál. Nos, nem teszi.

Az Internet Explorer CSS kezelése TELE van hibával. Kezdve a doboz modelltől a CSS 2-es verziójának hiányos vagy rossz támogatásáig. A CSS 3-ból gyakorlatilag semmit sem ismer (persze jogosan, mert amikor készítették, még nem volt - most is csak tervként van). Pár link: http://css-discuss.incutio.com/?page=BrowserBugs, http://www.positioniseverything.net/explorer.html. Hidd el, nagyon sok hibája van. Amivel nem az lenne a baj, hogy van, hanem hogy időközben nem javították. :(

-boogie-
16

ie tenyleg hibas css-bol

Jano · 2005. Jan. 11. (K), 15.09
Az hogy te nem ismered a hibakat nem jelenti, hogy nincsenek. Valoszinu nem regen foglalkozol webfejlesztessel kulonben feltunt volna, hogy az egesz webfejleszto kozosseg egyutt szidja az IE-t. Es ez nem amolyan Windows-Linux flame hanem valoban megkeseriti a fejlesztok eletet az IE.

A legfontosabb hianyossagok es rossz ertelmezesek:

- Az oldal elrendezesek alapveto eszkoze a float. Ehhez kapcsolodoan egy tucat hiba szerepel az IE-ben.
(3px bug, dupla margo bug, stb amiket megtalalsz Boogie hozzaszolasaban.)

- A :hover tulajdonsagot csak link elemre ismeri, igy nem keszithetok nativ CSS lehullo menuk es hasonlo okossagok.

- nem ismeri a position:fixed tulajdonsagot igy nem keszitheto olyan elem ami mindig lathato marad az oldalon.

- nem ismeri a display:table-cell tulajdonsagot, ujabb nehezites oldal kialakitaskor.

- nem ismeri a megfelelo xhtml mime-type-ot igy kerulo megoldasok nelkul nem szolgalhato ki valos XML dokumentum a tobbi bongeszonek sem. (Egy valos XML dokumentumot sokkal gyorsabban dolgozhat fel egy azt ismero program, a szigorubb szabalyok miatt.)

- hiaba kezeli a doboz modellt - ugynevezett strict modban - helyesen az IE6, amig hasznalatba van kisebb szamu verzio.

- nem ismer nehany nagyon hasznos CSS kivalasztot, mint pl a kozvetlen gyerek kivalaszto (>), vagy az elso gyerek: :first-child


- nem ismeri azt a meretezest amikor abszolut poziconalssal top:10px, bottom:10px adod meg a meretet. Ez jo lenne nyulos oldalak kialakitasakor.

- nem ismeri min/max meretezest (nyulos oldal szinten)


- nem CSS, de nem ismeri a PNG alpha maszkot.

es akkor meg lehetne kisebb aprosagokat sorolni...
15

re: A Microsoft jellemző üzleti magatartása

kmm · 2005. Jan. 11. (K), 09.22
igazad van, a májkroszoftnak van ilyen, de ne részletezzük ezt :-)

--
üdv: kmm...
8

Egy ilyen ("sajna", IE alapú

Normanka · 2005. Jan. 10. (H), 11.56
Egy ilyen ("sajna", IE alapú) jegyzetet küldök az alábbi címen:
http://karoly.norman.terasz.hu/keret.php?page=generalnaplo&x=informatika4&jegyzet=9
Álláspontom: az IE technológiája jó, de egyedi. A keresztplatformosság akut igény. Útja a szigorú szabványosság, ami az IE esetében nem a szabványokhoz való visszatérést jelenti, hanem a szabványokra való korlátozódást. A Microsoft egydi megoldásaival azt a munkát spórolja meg a híveinek, amelyet ő maga korábban már beépített az IE-be, hogy ezzel a kényelemmel a maga platformjára szögezze az egyszerű(nek látszó) technikai megoldásokat alkalmazókat. Ezen eljárás szelleme azonos aztzal, mint amikor kiváló böngészőt oszt ingyenesen, hogy ezzel édesgesse a platformjára a dolgozót (aki majd másért busásan fizet, és ezzel megfinanszírozza a látszólag ingyeneset is). Ezzel csak az a baj, hogy a 90% nem 100%.
10

Re: egy ilyen...

kmm · 2005. Jan. 10. (H), 12.26
Szerintem az ie technologiája lehetne jó, de a megvalósítás és a minőség, biztonságosság ramaty, tehát az egész az.

A platformfüggetlenség szerintem _nagyon_ fontos. Egyre többen térnek át nem m$ platformra, sőt, az m$ saját magával _sem_ kompatibilis. Tehát az elképzelés lehet jó, de nem jó a megvalósítás.

A mozilla megoldásai esetén a megvalósítás _is_ jó.

--
üdv: kmm...
17

Mozilla-szabványossághívő

Normanka · 2005. Jan. 12. (Sze), 15.40
Mozilla-szabványossághívőktől kérdezem: mit tesz a Mozilla a disable-output-escaping="yes" beállítással (az xsl:selectben)? Másként: hogy tudok Mozillában xslt-vel xml-szövegben szereplő hiperlinket html-lapra renderelni?


Normanka
18

varj egy picit

Jano · 2005. Jan. 12. (Sze), 15.49
Egy pillanat, mielott atmennel flame-be! Nem allitottuk, hogy az IE-n kivul minden mas bongeszo vagy akar csak a Mozilla is tokeletesen szabvanyos es hibaktol mentes. Csak annyit, hogy altalaban jobban koveti a szabvanyokat es kevesebb hiba van benne, es fokent folyamatosan fejlesztik, javitjak ezeket.

A kerdesedre egyebkent azt talaltam a Google-ben, hogy ez egy opcionalis lehetoseg a szabvanyban es nem teljesen illik bele az architekturaba, ezert bizonyos programokba nem epitik be:
Mozilla and IE6 are different with disable-output-escaping="yes"

Egy picit reszletesebb leiras a problemarol:
Disable Output Escaping
19

Yeah, eszembe' sincs flame-el

Normanka · 2005. Jan. 12. (Sze), 16.27
Yeah, eszembe' sincs flame-elni. Megoldásokat keresek, és mielőtt akár a Microsoftot szidalmaznám lélekből, akár a védelmére kelve mást, magát a műszaki problémát tekintem. Ennek magva, hogy text alapú adatcserében minden karakter, a műveleti előírások mint processzálás is, meg a nyersanyag is, és ezeket komoly tautológ feladat elkülöníteni. Felületesség volna, ha bármelyik böngészőre ráhúznám a vizes lepedőt szabványügyben, mert nem annyira az üzleti sunyiság burkolt indíttatása szabja meg a műszaki megoldást, mint inkább az akut problémával való tisztességes küzdelemben elért eredmény. Ezért nem a Microsoftot védem, hanem a hangulatkeltést opponálom, miközben tényleges megoldásokat keresek. Csakhát vitamezőben élünk, amelyben a higgadt boncolászat is harci cselekménynek tűnik:-)))
Szóval: a problémám komoly, mert a fentebb említett (vezérlő kontra adatkarakterek) ellentmondás okozta tisztázatlanságban csak objektumdetektálással való böngészőlekérdezés, és ahhoz alkalmazkodó többváltozatos kiszolgálás lehetséges mint keresztplatformosság, ami beteg és technikatörténeti szempontból efemer megoldás.
Nagyon szeretnék olyan működő példát gyártani, amelyben a Mozilla az XML-textben lévő linket működő linkként megjeleníti XSLT által. Az effajta problémákat megoldottam IE-ben, bár csak scriptelt MSDOM-mal, és évek óta kifogástalanul működnek.

Normanka
20

Tudom a probléma elemzéseit

Normanka · 2005. Jan. 12. (Sze), 16.29
Tudom a probléma elemzéseit (a megoldását nem):
http://www.stylusstudio.com/w3c/xslt/disable-output-escaping.htm#disable-output-escaping

Normanka
22

Elég alapos vizsgálatokkal

Normanka · 2005. Jan. 18. (K), 08.51
Elég alapos vizsgálatokkal meggyőződtem róla: a Mozilla csöppet sem kezeli az XML-t szabványosan, külön utakon jár, megoldásai sok tekintetben kidolgozatlanok, és jelen állapotában az XML-kezelése alkalmatlan a puszta alapmegjelenítésen túlmenő, szabvány alapú kliensoldali keresztplatformosságra. Egyáltalán megoldani problémákat kliensoldalon érdemben jelenleg csak az Internet Explorerben lehet. Ez nekem most fáj, de talán már világos, hogy nem Microsoft-elkötelezettség okán, hanem a helyzet reális összefoglalásaként jelzem. Nekem azért fáj a dolog, mert egy portál-keresztplatformosság problémájának kapcsán a pozitív lehetőségek feltárásában vagyok érdekelt, nem hitvitákban, de minden tényszerű megállapításom szenvedélyválaszokba ütközik.
Tehát: a helyzet az, hogy aki Mozillában az Internet Explorerével azonos szintű XML-kezelésre akar jutni, annak vagy a Mozilla API-ját megragadva plugint kell készítenie és publikálnia, vagy maradjon a szerveroldalon, és oldja meg a szerver keresztplatformos szolgáltatását a HTML-szolgáltatásig menőleg ott (ezen ősi technológia teljesen szabványos általános kezelése a mai korban már nem kérdés, de ugye emlékszünk még a történet Mosaic-os kezdeteire). Ez semmiképp nem értékítélet, hiszen pl. a Macromedia Flash renderelő engine-jét is pluginként kell letölteni, egyelőre minden nyamvadt böngészőbe (és ez a Macromedia érdeke, ezért nem a böngészőfejlesztők szülik meg a pluginokat), nyilván ha elhatalmasodik mint szabvány, akkor majd implementálja, akinek van rá pénze és jogosítványt is vásárol ehhez. Ld. még a Java sorsát.
Ámde azért az XML-kezelés kapcsán van egy értékelő megjegyzés is ehhez. Az XML-re ráharapott a világ, már igen sok helyen (néhol egyelőre feleslegesnek látszó bonyolultság vállalásával) bevezetik ezt a miniadatbázis alapú technológiát, amely mellett igenis szólnak technológia-stratégiai érvek. Ebből egyrészt az következik, hogy holnaputánra a Mozilla (meg a Netscape, meg az Opera, meg a Konqueror, meg olyan böngészőképességű portálkliensek, amelyeket még ma nem ismerünk, mert nincsenek kereskedelmi forgalomba dobva, amilyen pl. az Oracle-é) is felnőnek a feladathoz, követve a technológia jelentőségét korábban felismerő, és saját üzleti érdekében is azt zajosan népszerűsítő Microsoftot; másrészt pedig a mainál hitelesebbé erősödik a szabványgyűjtemény. És akkor majd más aktuális vesszőparipánk lesz az IE-kontra mások hitvita céljaira :-D

Normanka
25

Alapos vizsgálatok vs. konkrétumok

Bártházi András · 2005. Jan. 18. (K), 09.41
Mit takar az "alapos vizsgálat" kifejezés nálad? Légyszi konkrétumokat, példákat, szabvány linkeket írj - engem így tudsz meggyőzni, máshogy nem, hogy az IE jó lenne. Az XML terén nem ismerem mélyen sem a Mozillát, sem az Explorert, de annyit tudok, hogy mind a kettővel meg tudtam oldani olyan dolgokat, mint XSLT transzformáció kliens oldalon. Az Internet Explorernek a DOM szabvány kapcsán ha jól emlékszem hiányosságai is voltak. Érdekel a téma, kérlek írjad le, milyen tények alapján jelentetted ki a fentieket! :)

-boogie-
26

Lássuk

kmm · 2005. Jan. 18. (K), 09.57
Lássuk azokat az alapos vizsgálatokat!
Anelkül ez az egész hosszu fejtegetes semmi.

--
üdv: kmm...
11

fejlesztes leallitasa

Jano · 2005. Jan. 10. (H), 17.31
A problema valojaban nem itt van.

Amikor kijott az IE6 mindenki hanyat volt esve es ezt tartotta a legjobb bongeszonek. Szeleskoru CSS, Javascript es DOM tamogatasa volt. Ezek mellett pedig 1-2 kenyelmi funkciot is tartalmazott amiket a MS sajat szolgaltatasi es uzletpolitikaja miatt epitett bele a bongeszobe mint peldaul a RichTextEditor.

Kozben eltelt egy kis ido es ami akkor nagyon szepnek tunt arrol kiderult, hogy bizony sokhelyen hibas, nehany dolog hianyzik.

A problema pedig az, hogy ezalatt 3 ev telt el es a MS nem adott ki javitast ezekre a problemakra. SOT kijelentett, hogy az uj windows verzio megjeleneseig nem is fog!

Ezt megteheti, megtehette mert piaci reszesede 90% korulive valt.

Azt allitod, hogy az IE tamogatja a szabvanyokat ('A' halma) csak pluszban vannak benne nem szabvanyos dolgok ('B' halmaz) is es ezert nem szeretjuk.
Valojaban a B halmazba tartozo dolgok kozul 1-2 dolgot atvett a tobbi bongeszo ('B_atvett' halmaz) (egyik reszet azert ('B_atvett_muszaj' halmaz) mert IE volt a dominans es nekik kompatibilisnek kellett lenni pl document.all, masik reszet azert mert valoban hasznosnak bizonyult (XML kezeles)).

Az IE megjelenese es mostani idokig, amig a B_atvett halmaz nem letezett ez is problemat jelentett.
Ma es a jovoben: A B halmaz at nem vett reszei nelkul tudunk elni, igy azok nem okoznak problemat. Mar csak az okoz problemat, hgy az A halmaz vagyis a szabvany altal eloirt dolgokat nem kezeli jol az IE. Ez neheziti meg leginkabb a fejlesztok eletet.
23

Minden hibája mellett és mi

Normanka · 2005. Jan. 18. (K), 09.15
Minden hibája mellett és minden általa keltett frusztráció ellenére az IE 6 jelenleg is, aktuálisan, a legjobb böngésző, sajnos. Ennek felel meg a domináló piaci részesedése, és jóval kevésbé a vitatott és vitatható Windows-integrációjának (bár vannak azért ott is tételek, pl. az Office az IE-n keresztül direkt ftp-kliens). Örvend az ember szíve annak láttán, hogy azért a Netscape se kutya; és tudna jobban is örvendeni akárki közérdekű sikerének. Nálam fél tucat böngésző fut szimultán (A főbbek Windowson a Geckók, az IE, a MyIE, Linuxon a Konqueror és a Geckók stb.), keresztplatform-problémák monitorozása céljára. Nincsen rózsa tövis nélkül.

Normanka
24

A legrosszabb böngésző az IE

Bártházi András · 2005. Jan. 18. (K), 09.35
Akárhogy próbálsz érvelni mellette, MA a legrosszabb böngésző az IE. A piaci részesedése drasztikusan csökkent az utóbbi időben, persze még mindig vezet. Nem hinném, hogy egy jó böngésző 5%-nyi részesedéseket vesztene, ha tényleg olyan jó lenne... Ja, és én meg is tudom indokolni, hogy miért rossz az IE, mint böngésző: nagyon rossz CSS támogatás, nulla XHTML támogatás. Funkciók, kiterjesztések tekintetében kevés lehetőség. Ez az, amit egy böngészőnek ma tudnia kellene. Ezt nem tudja jól, illetve sehogy sem. Számos linket és érvet felsorakoztattunk már ezen a téren, miért gondolod továbbra is, hogy az IE jó lenne? Nem az.

-boogie-
27

Tényeket

kmm · 2005. Jan. 18. (K), 10.01
Ird ide a tényeket, miert jobb.
Ne csak szavakkal vagdalodz!
amint leírod miért és miben jobb az ie, én aki linuxozom, megyek megvenni és teszem föl, persze, csak ha az érveid _igazak_ és megállnak, és nem utolsó sorban súlyuk is van.
Ilyenek, mint a nekem tetszik, meg a szerintem szebb a logoja, meg többen használják nem érdekelnek.

Tehát Tényeket ide nekünk vagy ne beszélj zöldségeket.

--
üdv: kmm...
28

rossz kovetketkeztetes

Jano · 2005. Jan. 18. (K), 18.04
A dominalo piaci reszesedese a Windows elterjedtsege miatt ekkora es nem azert mert "jo".

Mind a felhasznaloknak nyujtott funkcionalitasban, mind a fejlesztok szamara fontos mukodesben elmarad az alternativ bongeszoktol, kiemelve Mozilla Firefox, Opera (fokent funkcionalitas), Safari.

Kerlek mondjal indokokat amik miatt azt mondod, hogy az IE a "jo" bongeszo.

Az IE 6 amikor megjelent a legjobbnak szamitott es ezt nem vitatja senki, viszont a fejleszteset a MS leallitotta, igy egyszeruen a tobbi bongeszo lehagyta. En is azt kerem mondjal olyan dolgokat amikben az IE jobb mint pl a FireFox. Es ne csak egyet, hanem annyit amivel az elozoleg beirt listamat "uberelni" tudod.
3

inspiráció

Hojtsy Gábor · 2004. Nov. 23. (K), 17.52
Nos, lehet, hogy túl rózsaszínen látom a dolgokat, de jómagam sokmindennel találkozom a neten, és ezek jó része "csak" inspirációként jelentkezik, mert közvetlenül nyilván nem fogom felhasználni. Mivel nincs is Internet Explorerem, nem tudom átélni a javasolt megoldás gyönyöreit, de könnyen lehet, hogy ötleteket merítek belőle egy későbbi feladathoz. Úgy gondolom, hogy szomorú lenne, ha az érdekelné csak olvasóinkat, amiből copy-paste tudnak másolni valamit, és az rögtön megoldja egy problémájukat. Szerencsére nagyon úgy tűnik, hogy nem csak a copy-pastelhető megoldásokra van igény. :)
4

Azért, mert

PiG · 2004. Dec. 2. (Cs), 12.26
Pont az általam írt telefonkönyves a megoldást használja egy ismerősöm a munkahelyén, ugyanis kitéve a munkaasztalra mindig szem előtt van, nem foglal külön helyet, egyszerű kezelni és az erőforrás igénye sem hinném, hogy óriási lenne.
Ugyanakkor ne felejtsük el, hogy azért az IE használók még évek múlva is többségben lesznek (bár én magam sem használom, csak "vészhelyzetben").
Ha meg netán valamikor mégis lesz új IE verzió, ami szabvány szerint viselkedik, akkor el lehet rajta gondolkodni, hogy "jééé, szabványos, az emberek 80%-a használja, és tud még egy csomó többletszolgáltatást is".
Az is előfordulhat, hogy a végén még a többi böngésző is támogatni fogja az ismertetett megoldást, ugyanis a Mozilla oldalakon is találni XML adatszigetekre törénő kisérletet, bár ott elég körülményes DOM scripttel valósítják meg - ezzel persze elvész az egyszerűsége.
Egyébként írtam már pont ide a weblaborra olyant is, ami meg pont csak Mozilla-ban működik... :-)
Sziasztok:
P][G
5

IE felhasználók többsége

Bártházi András · 2004. Dec. 2. (Cs), 12.49
Ugyanakkor ne felejtsük el, hogy azért az IE használók még évek múlva is többségben lesznek (bár én magam sem használom, csak "vészhelyzetben").

Ezt én egy elhamarkodott kijelentésnek tartom. :) Nagyon dinamikusan nő a nem Internet Explorert használók száma. Persze én sem gondolom egyértelműnek és 100%-osnak, hogy az alternatív böngészők többségbe kerülnek hamarosan, de látok rá esélyt. Továbbá itt a Weblaboron az utóbbi hónapokban nem volt olyan nap, hogy az IE használók száma 50% felé lépett volna - azaz ugyan eléggé speciális környezetekben, de már ma van, ahol az IE elveszítette a többségét... :)

-boogie-
6

Céges telkönyv

paal · 2004. Dec. 9. (Cs), 09.56
Pont az általam írt telefonkönyves a megoldást használja egy ismerősöm a munkahelyén, ugyanis kitéve a munkaasztalra mindig szem előtt van, nem foglal külön helyet, egyszerű kezelni és az erőforrás igénye sem hinném, hogy óriási lenne.

Üdv,

Pont ilyen megfontolásból érdekelne engem is. Nálunk is (sajnos) IE-t használnak a cégnél (én nem ;)) de ez a "szem előtt lévő" telkönyv egészen +fogott. Érdekelne, hogy lehetne pl. sql adatbázhoz csatlakozni ill. MS-AD-ből adatokat kinyerni, mert akkor szuperül ki tudnám használni ezt a funkciót. Keresgélek, hátha van valami hasonló jó kis leírás ezekről.

Köszi!

Palkó Koma
21

Lehet, hogy hasznos további észrevételek

Anonymous · 2005. Jan. 15. (Szo), 23.16
- ActiveX vezérlők használatakor fontos a trusted site zóna.

- hta kiterjesztésű html filelal hypertext application is készíthető, melyben akár javascript segítségével is elérhető a filekezelés.(írás/olvasási műveletek)