Přejít k navigační liště

Zdroják » Webdesign » HTML5: První krůčky s FileSystem API

HTML5: První krůčky s FileSystem API

Články Webdesign

FileSystem API řeší jeden ze zásadních problémů webových aplikací, kterým je nemožnost pracovat se soubory v uživatelově počítači. S tímto API, které nabízí zatím jen Chrome 9, může webová aplikace vytvářet, číst, procházet a zapisovat do bezpečně vymezené části uživatelova souborového systému.

Tento text je volným překladem článku Exploring the FileSystem APIs z webu HTML5Rocks. Autorem je Eric Bidelman. Článek je zveřejněn pod licencí CC-BY 3.0, zdrojové kódy pod licencí Apache 2.0.

qrcode

K článku je ukázka

K článku není k dispozici zdrojový kód

První krůčky s FileSystem API

Seznámení

Fakt, že webové aplikace nemohou číst a zapisovat soubory či adresáře, je v určitém ohledu brzdou jejich rozvoje. S přesunem od offline k online se aplikace stávají neustále složitějšími a chybějící souborové API bylo překážkou v posunu vpřed. Naštěstí tomu již tak není, díky FileSystem API. S tímto API může webová aplikace vytvářet, číst, procházet a zapisovat do bezpečně vymezené části uživatelova souborového systému.

API je rozděleno do několika částí:

  • Čtení a manipulace se soubory: File/Blob, FileList, FileReader
  • Vytváření a zapisování: BlobBuilder, FileWriter
  • Adresáře a přístup k souborovému systému: DirectoryReader, FileEntry/DirectoryEntry, LocalFileSystem

Podpora prohlížečů a současná omezení

V době psaní tohoto článku je jediná fungující implementace FileSystem API pouze v Google Chrome 9+. Prozatím neexistuje možnost nastavení file/quota parametru přímo z prohlížeče. Proto je pro využívání API nutné spustit prohlížeč s parametrem --unlimited-quota-for-files (pokud vytváříte aplikaci nebo rozšíření pro Chrome Web Store, postačí manifest soubor pro unlimitedStorage). V současné době není pro takové aplikace úložný prostor nijak omezen, ale to se má změnit. Uživatelům by se mohl nakonec zobrazit dialog pro povolení, odmítnutí, nebo zvětšení úložného prostoru pro danou aplikaci.

Získání přístupu k souborovému systému

Webová aplikace může získat přístup do vymezeného souborového systému voláním window.requestFileSystem():

window.requestFileSystem(type, size, successCallback, opt_errorCallback)
type 
Určuje zda má být úložný prostor perzistentní. Možné hodnoty jsou window.TEMPORARY nebo window.PERSISTENT. Při použití TEMPORARY mohou být data odstraněna dle uvážení prohlížeče (např. když je potřeba více prostoru). Data uložená v úložném prostoru typu PERSISTENT mohou být odstraněna pouze na popud uživatele nebo aplikace.
size
Velikost (v bajtech), kterou požaduje aplikace.
successCallback
Callback, který se vyvolá v případě uspěšného získaní souborového systému.
opt_errorCallback
Volitelný callback pro zprácování chyb, či odmítnutí přístupu. Jeho argumentem je objekt FileError.

Při prvním volání requestFileSystem je pro danou aplikaci vytvořen úložný prostor. Je nutné vzít v potaz, že přístup k tomuto souborovému systému je omezený výlučně pro danou aplikaci. Není možné přistupovat k souborům jiné aplikace. Stejně tak není možné číst a zapisovat soubory do libovolného adresáře na uživatelově pevném disku (např. Obrázky, Dokumenty, atd.).

Příklad použití:

function onInitFs(fs) {
  console.log('Opened file system: ' + fs.name);
}

window.requestFileSystem(window.PERSISTENT, 5*1024*1024 /*5MB*/, onInitFs, errorHandler);

Specifikace FileSystemAPI definuje taktéž synchronní API – rozhraní LocalFileSystemSync, které je určeno pro použití v tzv. Web Workers. V tomto článku se ale synchronním API nebudeme dále zabývat.

Ve zbytku článku budeme používat tento handler pro zpracování chyb z asynchronních volání:

function errorHandler(e) {
  var msg = '';

  switch (e.code) {
    case FileError.QUOTA_EXCEEDED_ERR:
      msg = 'QUOTA_EXCEEDED_ERR';
      break;
    case FileError.NOT_FOUND_ERR:
      msg = 'NOT_FOUND_ERR';
      break;
    case FileError.SECURITY_ERR:
      msg = 'SECURITY_ERR';
      break;
    case FileError.INVALID_MODIFICATION_ERR:
      msg = 'INVALID_MODIFICATION_ERR';
      break;
    case FileError.INVALID_STATE_ERR:
      msg = 'INVALID_STATE_ERR';
      break;
    default:
      msg = 'Unknown Error';
      break;
  };

  console.log('Error: ' + msg);
}

Tento chybový callback je velice jednoduchý, ale nic nebrání jeho pozdějšímu rozšíření o uživatelsky přívětivější hlášení.

Práce se soubory

Soubory ve vyhrazeném prostoru jsou reprezentovány rozhraním FileEntry. FileEntry obsahuje běžné atributy (name, isFile, ...) a metody (remove, moveTo, copyTo, ...) jak jsme zvyklí z běžných souborových systémů.

Atributy a metody rozhraní FileEntry:

fileEntry.isFile === true
fileEntry.isDirectory === false
fileEntry.name
fileEntry.fullPath
...

fileEntry.getMetadata(successCallback, opt_errorCallback);
fileEntry.remove(successCallback, opt_errorCallback);
fileEntry.moveTo(dirEntry, opt_newName, opt_successCallback, opt_errorCallback);
fileEntry.copyTo(dirEntry, opt_newName, opt_successCallback, opt_errorCallback);
fileEntry.getParent(successCallback, opt_errorCallback);
fileEntry.toURI(opt_mimeType);  // Currently not implemented in Google Chrome 9.

fileEntry.file(successCallback, opt_errorCallback);
fileEntry.createWriter(successCallback, opt_errorCallback);
...

Ukažme si několik příkladů běžného použití rozhraní FileEntry.

Vytvoření souboru

Pomocí metody getFile() rozhraní DirectoryEntry je možné vyhledat či vytvořit nový soubor. Po získání přistupu k souborovému systému obdrží successCallback objekt FileEntry obsahující položku DirectoryEntry (fs.root) ukazující na kořen souborového systému.

Následující kód vytvoří prázdný soubor nazvaný „log.txt“ v kořenu aplikačního souborového systému:

function onInitFs(fs) {

  fs.root.getFile('log.txt', {create: true, exclusive: true}, function(fileEntry) {

    // fileEntry.isFile === true
    // fileEntry.name == 'log.txt'
    // fileEntry.fullPath == '/log.txt'

  }, errorHandler);

}

window.requestFileSystem(window.PERSISTENT, 1024*1024, onInitFs, errorHandler);

V momentě úspěšného požadavku na souborový systém je do success callbacku předán objekt FileSystem. V těle callbacku je možné volat fs.root.getFile() se jménem souboru k vytvoření. Cesta může být jak absolutní tak relativní, ale musí být validní. Například je chybou pokoušet se vytvořit soubor, jehož nadřazený adresář neexistuje. Druhým argumentem volání getFile() je literál určující chování v případě, že soubor neexistuje. V tomto příkladu (create: true) bude vytvořen nový soubor, pokud zatím neexistuje. V případě, že již existuje, vyvolá chybu (exclusive: true). Pokud by soubor existoval a bylo nastaveno create : false, tak jej jednoduše vrátí. V obou případech nedojde k přepsáno obsahu souboru, jelikož tímto voláním se získá pouze rozhraní pro práci s daným souborem.

Čtení souboru

Následující kód získá soubor se jménem „log.txt“, přečte jeho obsah pomocí objektu FileReader a přidá jej na stránku do nové textové oblasti <textarea>. V případě že soubor log.txt neexistuje, je vyvolána chyba.

function onInitFs(fs) {

  fs.root.getFile('log.txt', {}, function(fileEntry) {

    // Get a File object representing the file,
    // then use FileReader to read its contents.
    fileEntry.file(function(file) {
       var reader = new FileReader();

       reader.onloadend = function(e) {
         var txtArea = document.createElement('textarea');
         txtArea.value = this.result;
         document.body.appendChild(txtArea);
       };

       reader.readAsText(file);
    }, errorHandler);

  }, errorHandler);

}

window.requestFileSystem(window.PERSISTENT, 1024*1024, onInitFs, errorHandler);

Zápis do souboru

Následující kód vytvoří prázdný soubor „log.txt“ (pokud již neexistuje) a vyplní jej textem ‚Lorem Ipsum‘.

function onInitFs(fs) {

  fs.root.getFile('log.txt', {create: true}, function(fileEntry) {

    // Create a FileWriter object for our FileEntry (log.txt).
    fileEntry.createWriter(function(fileWriter) {

      fileWriter.onwriteend = function(e) {
        console.log('Write completed.');
      };

      fileWriter.onerror = function(e) {
        console.log('Write failed: ' + e.toString());
      };

      // Create a new Blob and write it to log.txt.
      var bb = new BlobBuilder();
      bb.append('Lorem Ipsum');
      fileWriter.write(bb.getBlob('text/plain'));

    }, errorHandler);

  }, errorHandler);

}

window.requestFileSystem(window.PERSISTENT, 1024*1024, onInitFs, errorHandler);

V tomto případě voláme na FileEntry metodu createWriter(), která vrátí objekt FileWriter. V těle success callbacku je vytvořena obsluha událostí error a writeend. Data jsou zapsána do souboru vytvořením blobu, přidáním textu a předáním blobu do volání FileWriter.write().

Přidání dat na konec souboru

Následující kód přidá text ‚Hello World‘ na konec logovacího souboru. Pokud soubor neexistuje, je vyvolána chyba.

function onInitFs(fs) {

  fs.root.getFile('log.txt', {create: false}, function(fileEntry) {

    // Create a FileWriter object for our FileEntry (log.txt).
    fileEntry.createWriter(function(fileWriter) {

      fileWriter.seek(fileWriter.length); // Start write position at EOF.

      // Create a new Blob and write it to log.txt.
      var bb = new BlobBuilder();
      bb.append('Hello World');
      fileWriter.write(bb.getBlob('text/plain'));

    }, errorHandler);

  }, errorHandler);

}

window.requestFileSystem(window.PERSISTENT, 1024*1024, onInitFs, errorHandler);

Vytvoření kopií vybraných souborů

Následující kód umožní vybrat uživateli více souborů najednou použitím <input type="file" multiple /> a poté vytvořit jejich kopie v souborovém systému aplikace.

<input type="file" id="myfile" multiple />
document.querySelector('#myfile').onchange = function(e) {
  var files = this.files;

  window.requestFileSystem(window.TEMPORARY, 1024*1024, function(fs) {
    // Duplicate each file the user selected to the app's fs.
    for (var i = 0, file; file = files[i]; ++i) {

      // Capture current iteration's file in local scope for the getFile() callback.
      (function(f) {
        fs.root.getFile(file.name, {create: true, exclusive: true}, function(fileEntry) {
          fileEntry.createWriter(function(fileWriter) {
            fileWriter.write(f); // Note: write() can take a File or Blob object.
          }, errorHandler);
        }, errorHandler);
      })(file);

    }
  }, errorHandler);

};

Pro dosažení stejného výsledku lze místo input tagu použít i HTML5 Drag and Drop.

Jak je poznamenáno v komentáři, FileWriter.write() může zapisovat jak Blob, tak File. Je to možné díky tomu, že File je potomkem Blobu.

Smazání souboru

Následující kód smaže soubor „log.txt“.

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  fs.root.getFile('log.txt', {create: false}, function(fileEntry) {

    fileEntry.remove(function() {
      console.log('File removed.');
    }, errorHandler);

  }, errorHandler);
}, errorHandler);

Práce s adresáři

Adresáře jsou reprezentovány rozhraním DirectoryEntry, které sdílí mnoho vlastností s FileEntry (obě rozhraní dědí z rozhraní Entry). Directory entry obsahuje navíc metody pro práci s adresáři.

Atributy a metody DirectoryEntry:

dirEntry.isDirectory === true
// See the section on FileEntry for other inherited properties/methods.
...

var dirReader = dirEntry.createReader(successCallback, opt_errorCallback);
dirEntry.getFile(path, opt_flags, opt_successCallback, opt_errorCallback);
dirEntry.getDirectory(path, opt_flags, opt_successCallback, opt_errorCallback);
dirEntry.removeRecursively(successCallback, opt_errorCallback);
...

Vytváření adresářů

Pro čtení nebo vytvoření adresáře slouží metoda getDirectory(). Je možno zadat název nebo cestu.

Např. následující kód vytvoří adresář se jménem „MyPictures“ v kořenovém adresáři:

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  fs.root.getDirectory('MyPictures', {create: true}, function(dirEntry) {
    ...
  }, errorHandler);
}, errorHandler);

Podadresáře

Vytváření podadresářů se ničím neliší od vytváření adresářů. Nicméně API při pokusu o vytvoření adresáře vyvolá chybu, pokud neexistuje jeho nadřazený adresář. Řešením je postupné vytváření jednotlivých adresářů, což je s asynchronním API poněkud složitější.

Následující kód vytvoří adresářovou hierarchii (music/genres/jazz) v kořenu souborového systému aplikace rekurzivním vytvářením každého z podadresářů po tom co je vytvořen adresář nadřazený.

var path = 'music/genres/jazz/';

function createDir(rootDirEntry, folders) {
  // Throw out './' or '/' and move on to prevent something like '/foo/.//bar'.
  if (folders[0] == '.' || folders[0] == '') {
    folders = folders.slice(1);
  }
  rootDirEntry.getDirectory(folders[0], {create: true}, function(dirEntry) {
    // Recursively add the new subfolder (if we still have another to create).
    if (folders.length) {
      createDir(dirEntry, folders.slice(1));
    }
  }, errorHandler);
};

function onInitFs(fs) {
  createDir(fs.root, path.split('/')); // fs.root is a DirectoryEntry.
}

window.requestFileSystem(window.PERSISTENT, 1024*1024, onInitFs, errorHandler);

Poté co jsou adresáře „/music/genres/jazz“ na místě, je možné předat celou cestu do getDirectory() a vytvářet v daném umístění další podadresáře nebo soubory. Např.:

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  fs.root.getFile('/music/genres/jazz/song.mp3', {create: true}, function(fileEntry) {
    ...
  }, errorHandler);
}, errorHandler);

Čtení obsahu adresářů

Pro čtení obsahu adresáře je potřeba vytvořit DirectoryReader a zavolat jeho metodu readEntries(). Není zaručeno že volání této metody vrátí všechny položky adresáře. Tím pádem je nutno volat DirectoryReader.readEntries() opakovaně do doby, kdy už nevrací žádné další výsledky. Tento přístup je použit v následujícím příkladě:

<ul id="filelist"></ul>
function toArray(list) {
  return Array.prototype.slice.call(list || [], 0);
}

function listResults(entries) {
  // Document fragments can improve performance since they're only appended
  // to the DOM once. Only one browser reflow occurs.
  var fragment = document.createDocumentFragment();

  entries.forEach(function(entry, i) {
    var img = entry.isDirectory ? '<img src="folder-icon.gif">' :
                                  '<img src="file-icon.gif">';
    var li = document.createElement('li');
    li.innerHTML = [img, '<span>', entry.name, '</span>'].join('');
    fragment.appendChild(li);
  });

  document.querySelector('#filelist').appendChild(fragment);
}

function onInitFs(fs) {

  var dirReader = fs.root.createReader();
  var entries = [];

  // Call the reader.readEntries() until no more results are returned.
  var readEntries = function() {
     dirReader.readEntries (function(results) {
      if (!results.length) {
        listResults(entries.sort());
      } else {
        entries = entries.concat(toArray(results));
        readEntries();
      }
    }, errorHandler);
  };

  readEntries(); // Start reading dirs.

}

window.requestFileSystem(window.PERSISTENT, 1024*1024, onInitFs, errorHandler);

Odstranění adresáře

Metoda remove() rozhraní DirectoryEntry se chová stejně jako na FileEntry. Jediným rozdílem je, že pokus o smazání neprázdného adresáře skončí chybou.

Následující kód odstraní prázdný adresář „jazz“ z „/music/genres/“:

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  fs.root.getDirectory('music/genres/jazz', {}, function(dirEntry) {

    dirEntry.remove(function() {
      console.log('Directory removed.');
    }, errorHandler);

  }, errorHandler);
}, errorHandler);

Odstranění neprázdného adresáře

Pro smazání neprázdného adresáře slouží metoda removeRecursively(). Tato metoda odstraní adresář a jeho obsah rekurzivně.

Následující kód rekurzivně odstraní adresář „music“ a všechny v něm obsažené soubory a adresáře:

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  fs.root.getDirectory('/misc/../music', {}, function(dirEntry) {

    dirEntry.removeRecursively(function() {
      console.log('Directory removed.');
    }, errorHandler);

  }, errorHandler);
}, errorHandler);

Kopírování, přejmenování a přesunutí

FileEntry a DirectoryEntry sdílí společné operace.

Kopírování položky

Obě rozhraní mají metodu copyTo() pro vytvoření kopie. Pro adresář tato metoda provede automaticky rekurzivní kopii.

Následující kód zkopíruje soubor „me.png“ z jednoho adresáře do druhého:

function copy(cwd, src, dest) {
  cwd.getFile(src, {}, function(fileEntry) {

    cwd.getDirectory(dest, {}, function(dirEntry) {
      dirEntry.copyTo(dirEntry);
    }, errorHandler);

  }, errorHandler);
}

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  copy(fs.root, '/folder1/me.png', 'folder2/mypics/');
}, errorHandler);

Přesunutí nebo přejmenování položky

Metoda moveTo() umožňuje přesunout nebo přejmenovat soubor či adresář. Prvním argumentem je adresář do kterého se má přesunout a druhým nepovinným argumentem je nové jméno. Pokud není zadáno nové jméno, použije se jméno původní.

V následujícím příkladě dojde k přejmenování souboru „me.png“ na „you.png“ v původním umístění.

function rename(cwd, src, newName) {
  cwd.getFile(src, {}, function(fileEntry) {
    fileEntry.moveTo(cwd, newName);
  }, errorHandler);
}

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  rename(fs.root, 'me.png', 'you.png');
}, errorHandler);

Následující příklad přesune soubor „me.png“ (umístěný v kořenovém adresáři) do adresáře „newfolder“.

function move(src, dirName) {
  fs.root.getFile(src, {}, function(fileEntry) {

    fs.root.getDirectory(dirName, {}, function(dirEntry) {
      fileEntry.moveTo(dirEntry);
    }, errorHandler);

  }, errorHandler);
}

window.requestFileSystem(window.PERSISTENT, 1024*1024, function(fs) {
  move('/me.png', 'newfolder/');
}, errorHandler);

Když to dáme vše dohromady…

Ukázkové příklady naleznete v originálním článku; zde je, kvůli možnostem redakčního systému, nemůžeme zveřejnit.

Případy použití

V HTML5 existuje mnoho možností uložení dat, ale FileSystem API se odlišuje tím, že je zacíleno na splnění těch požadavků použití na straně klienta, které nejsou vhodné pro databáze. Obecně je vhodné pro aplikace, které se musí vyrovnat s rozsáhlými binárními daty anebo sdílením dat s aplikacemi mimo prostředí prohlížeče.

Specifikace uvádí několik možností použití:

1. Perzistentní uploader

  • Vybraný soubor nebo adresář je zkopírován do lokálního uložiště a uploaduje se postupně po částech.
  • Upload může být restartován v případě pádu prohlížeče, přerušení internetového připojení, apod.

2. Hry, hudební přehrávače nebo jiné aplikace se spoustou multimediálního obsahu

  • Po stáhnutí jednoho či více velkých archivů je rozbalí lokálně do adresářové struktury.
  • Není potřeba více variant archivů pro jednotlivé OS.
  • Soubory, které budou brzy potřeba, mohou být stahovány na pozadí. Tím pádem přechod do další úrovně nebo zpřístupnění nových vlastností nevyžaduje čekání na stažení.
  • Soubory jsou používány přímo z lokální cache, přimým čtením nebo odkazováním pomocí lokálních URI na obrázky či videa, loadery WebGL obsahu, apod.
  • Soubory mohou mít libovolný binární formát.
  • Na straně serveru bude mít komprimovaný archiv často menší velikost než skupina samostatně komprimovaných souborů. Taktéž jeden archiv místo 1000 malých souborů vyžaduje méně přístupů na souborový systém, ačkoliv celková velikost může být totožná.

3. Foto editor či zvukový editor s offline přístupem nebo lokální cache pro zrychlení

  • Data jsou potenciálně velké velikosti a jsou určena jak ke čtení, tak pro zápis.
  • Může být potřeba přepsat pouze část souboru (např. přepis ID3/EXIF záznamu).
  • Může být užitečné organizovat projektové soubory do hiearchie adresářů.
  • Editované soubory mohou být přístupné z aplikací na straně klienta [iTunes, Picasa].

4. Offline přehrávač videí

  • Stahování velkých souborů (>1GB) pro pozdější přehrávání.
  • Potřeba efektivního přesunování v souboru a streamování.
  • Musí být schopen dodat URI na video tag.
  • Musí umožnit přístup k částečně staženým souborům, např. pro shlédnutí první části DVD i když ještě není staženo celé DVD.

5. Offline Webový e-mailový klient

  • Stahování příloh a jejích lokální uložení.
  • Cachování příloh pro pozdější upload.
  • Musí být schopen odkazovat na cachovanou přílohu a náhledy obrázků.
  • Měl by být schopen spustit správce stahování stejně jako by komunikoval přímo se serverem.
  • Měl by umět uploadovat e-mail s přílohami jako multipart post, místo odesílání po jednotlivých souborech.

Referenční specifikace

Komentáře

Subscribe
Upozornit na
guest
54 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
ixi.80h

… „do bezpečně vymezené části uživatelova souborového systému.“

To znamena v praxi, ze to bude ukladano kam presne?

Martin

Soubory budou fyzicky na disku, ale neni se treba obavat, ze by aplikace mohla pristupovat k celemu disku. Pouze k prostoru vymezenemu pro danou aplikaci.

Joe

To se nebylo potreba obavat nikdy, ale diky chybam k tomu stejne dochazelo!

oxymoron

Chápal bych, kdyby to fungovalo podobně jako cookies, že by všechny soubory souborového systému prohlížeče byly uloženy v jednom TARu )nebo v několika TARech, přičemž každá apliakce by měla svůj TAR. V opačném případě je to zhovadilost, protože takovou „stránk-aplikaci“ by pak bylo vhodnější zkompilovat a nechat uživateli stáhnout a spustit lokálně, a opustit tak zbytečnou mezivrstvu – prohlížeč.
Pokud toto FileAPI bude umět přistupovat k souborům přímo na disku, proti běžným apliakcím budu používat mezi vrstvy dvě – kromě prohlížeče ještě virtualizovaný OS, nejlépe běžící v jiném virtualizovaném OS, aby mi prohlížeč nemohl hrabat do mých souborů.

Jerry

Tohle – a mnohem víc už umějí technologie jako Flash, Silverlight nebo Java applety – všechny uvedené technologie mají použitelné GUI, nekonečné možnosti rozšíření A HLAVNĚ chovají se ve všech prohlížečích stejně. Čili k čemu je dobré se sr..t s Javascriptem a jeho bambilionem rozšíření typu jQuery? Kdo s tím OPRAVDU pracoval a dělalo mu to radost ať hodí kamenem :)

lol

java, flash, … vsetko genialne sposoby ako vytazit jadra cpu na max tymi najprimitivnejsimi funkciami … a to sa vyplati :)

tik

Kdyz si vzpomenu, co s mym x2 amd delal HTML5 stromecek tady na vanoce, tak tohle neni ten nejlepsi argument ;)

lol

asi som tu cez vianoce nebol alebo ten stromecek bol prehliadnutelny … v kazdom pripade porovnavat html5 ktore este nema plnu podporu v prehliadacoch (o hw akceleracii ani nehovorim) a flash ktory tu je uz od roku 1996.
Odhliadnuc od toho – pouzit flash na pracu s lokalnymi subormi je ako pouzivat kamion s privesom o nosnosti 20 ton na prevazanie jedenj palety. Samozrejem ze to ide, ale to mrhanie prostriedkami…

Martin Malý

Vzpomínaný stromeček (3D rotující vánoční stromek s chumelenicí) byl především „1kB demo“ – tedy ukázka, že takovou věc lze zmáčknout do kilobajtu zdrojového kódu, nikoli ukázka použití HTML5. Tím je také dané, kam autor napřel optimalizační síly. Brát to jako příklad (nebo dokonce „typický příklad“) HTML5 je nesmysl. U reálného řešení by nikdo nepoužil takový postup a nemačkal by to do 1kB kódu, ale vzal by WebGL, a vy byste si, díky HW akceleraci, ani nevšiml, že nějaký procesor máte. :)

tik

naprosto souhlasim. Bylo to jen poukazani na nesmyslnost argumentu, ze jen ostatni technologie vytezuji procesor na 100(200, 300)%.
A protoze mi tu ted nic nehuci, jdu hledat, kde a zda mam ten procesor ;)

koroptev

takze ten interpretovany kod, ktery tusim delal neco s canvasem, nevytezuje cpu nasobne vicekrat oproti nativni aplikaci?

tom-tom

S tou optimalizací a vytížením procesoru to celkově u HTML5 nebude žádná sláva. Podle mě, buďto se zatím nikdo nesnaží optimalizovat, nebo to prostě zatím vůbec nejde.

O silverlightu toho moc nevím, instalaci pluginu do prohlížeče se zuby-nehty bráním, pokud stránka nejede bez něj, prostě ji nemusím vidět a všechny flashe, ať už jde o hry na mojehry.cz, přes flashové stránky až po ty stupidní bannery mi na obou ntb jedou, aniž by se procesor nějak výrazně zapotil.

Ukázek v HTML5 jsem vyzkoušel několik a musím říct, že z žádné jsem neměl moc dobrý pocit, co se týče zátěže systému.
A konkrétně ten vánoční stromeček, s tím mi šel procesor tak vysoko, že se mi rozběhl na notebooku ventilátor naplno, což se jinak neděje moc často.
No a ta ponorka na googlu u příležitosti narození J.Verna, ta mi na prvním notebooku jela sice plynule, ale zátěž šla hrubě nahoru a na druhém ntb, s kterým běhám po klientech, tam jsem musel změnit ten den homepage, protože ta „slideshow“ mi tak umrtvovala prohlížeč, že jsem ho musel natvrdo killnout.

A moje osobní pohnutky – ve flashi umím (poctivý actionscript, ne tahání tvarů po sandboxu :) a nedokážu si představit, že bych měl někdy totéž dělat v paskvilu, jako je HTML5, byť by měl 100% hw podporu v jádře procesoru nebo grafické karty ;)

Martin Malý

Mrkněte na EaselJS, brzy o něm napíšeme i tady. EaselJS je knihovna, která funguje podobně jako flashový API (stage a spol.) Přistupujete k němu z JS, což je v základu stejný ECMAScript jako AS.

Sice to opakuju asi už poosmé, ale holt někomu není dáno rozumět psanému textu: Vánoční stromeček je 1kB DEMO! Demonstrační kód optimalizovaný za hranici běžného použití tak, aby se vešel do 1kB! Principem 1kB dema není ukázat, co technologie umí a jak funguje, ale co umí programátor, a je jasné, že takové demo, omezené v jednom směru (1kB kódu) bude neoptimální v jiném. Zajímalo by mne – ten rozdíl proti normálnímu kódu pochopit nedokážete, nebo nechcete?

pas

Nekteří lidé mají evidentně pocit, že dobrá technologie má prostě programátorovi zakázat, aby roztočil větráček na maximum. Zvlášť, když je to vlastně jen takový jednoduchý animovaný obrázek, že? No, ruku na srdce – praxe bude často vypadat tak, že kód bude mít sice 50 KB místo 1 KB, ale nárok na výkon bude stejný. Flashaři vědí… (i tam nastupuje HW akcelerace jako ve WebGL, ale kdy se o tom dozví armáda znuděných tvůrců reklam?)

„… JS, což je v základu stejný ECMAScript jako AS.“ – přesněji řečeno jako AS1 (flashaři opět vědí… jaké pocity a vzpomínky mají vyplout na povrch… :))

tom-tom

Měl jsem přečtenou celou diskusi, než jsem něco napsal, takže mám přehled o tom, kolikrát se tady psalo, že stromeček byl demo.
Proto jsem jako druhý příklad zmínil ten google, protože tam to rozhodně demo nebylo – je rozdíl publikovat něco takového na zdrojáku a na googlu, který má podstatně větší návštěvnost, že :)

Je sice fajn, že stromeček šel natlačit do 1kB, ale k čemu je to dobrý, když je omtimalizace tímto směrem kontraproduktivní a nakonec to polovině lidí nejede. A razit to jako demonstraci, že jenom v HTML5 to jde udělat z jednoho kilobajtu, to mu moc na reputaci nepřidá.
Jasně, ve flashi by šla taková věc natlačit řekněme do 5kB, ale pojede to i na founu s androidem, nebo netbooku s Atomem.

A už vidím, jak vysvětluju zákazníkovi: „ehm, no… tak máte to v HTML5, což je dneska IN, objem dat je 5x menší než u flashe, takže se to bude rychle načítat i na mobilním internetu, ale zatím to jede plynule jen na nejrychlejším superpočítači v USA a na druhém nejrychlejším v Číně to občas zadrne… ale to se do 10ti let změní“ :)

František Kučera

+1, taky si na ten hororový stromeček pamatuji, moc dobrou reklamu HTML5 neudělal.

Co se týče Java appletů – jejich nevýhoda je trochu pomalejší start a fakt, že je to cizorodý prvek na stránce (to se týká všech pluginů), ale s výkonem a zmiňovaným vytěžováním CPU není problém.

Martin Malý

„Je to demo, je to technologické demo, je to jednokilové demo, je to technologická pikantérie, jednokilové demo, je to demo optimalizované na velikost, je to JS 1K demo, je to demo, …“ 1kB dema nejsou ukázkou technologie, ale ukázkou programátorské virtuozity, asi jako lodě v láhvi nejsou reklamou na loděnice, ale na klidnou ruku…

tom-tom

Jo takhle… tím se to vysvětluje. Omlouvám se za svůj předchozí příspěvek, kde jsem se ptal, k čemu je 1k demo dobrý.
Vím, že taková věc dala programátorovi spoustu práce.. a přitom taková blbost, že? :)

Jako, pikantérie to jistě je, ale HTML5 takové věci (prozatím) nedělají moc dobré jméno. Alespoň na tomhle se jistě shodnem.

Martin Malý

Přesně tak. Spousta práce, a přitom taková blbost… :) Vytváření podobných příkladů je cvičení pro programátory, taková frajeřinka – není to pro praktické použití, ale je to hlavolam, nad kterým ostatní programátoři řeknou Hmmm… Zajímavé jsou na tom hlavně optimalizace algoritmů, které člověk dělá.

Navíc – byly svátky, chtělo to nějakou „blbůstku“ na odlehčení.

Mimochodem, víte co je pěkné? Že celý ten stromeček byl čistě JS, z HTML5 použil jen canvas, což je vykreslování do bitmapy. Takže ti, co říkají, jak to je špatná ukázka HTML5, vlastně ukazují, že netuší o čem hovoří – protože šlo o algoritmy v JavaScriptu, ne o HTML5. Ostatně – pokud si to demo pustíte v Chrome, které má hyperrychlý JS, na problém s výkonem nenarazíte.

František Kučera

Ale to si neprotiřečí.

1) zážitek to byl „hororový“ (dobře, možná trochu expresivní slovo, ale to snad nevadí), protože mi nezvykle zatížil procesor – na jiných webech se mi tohle nestává (Flash jsem odinstaloval).

2) Moc dobrou reklamu HTML5 to neudělalo – ačkoli si teď matně vzpomínám, že to bylo 1kB demo, v první řadě ho mám spojený s HTML5 jako takovým a zjevně v tom nejsem sám – z reklamy nikdy neutkví v hlavě všechno a informace, že jde o HTML5 byla jaksi výraznější, než ten 1kB.

ondra.novacisko.cz

Mě flash vyhovuje. Lze jej vypnout

Ano, tohle je jedna z jeho nejlepších vlastností :-)

josefrichter

jenom se ani jedna z těch technologií pro web aplikace moc neosvědčila :-)

Pavel Šimerda (pavlix)

„A HLAVNĚ chovají se ve všech prohlížečích stejně“

Tedy, buď nefungují (a jde doinstalovat plugin), nebo nefungují (a plugin není).

VM

Neznám žádný rozumný důvod proč by měla webová stránka přistupovat na můj filesystém – tedy s výjimkou spyware a malware. Na posílání dat je HTTP POST (který tohle vzhledem k omezené částí FS stejně nenahradí), a když mi web chce nějaký soubor poslat, tak si ho radši uložím ručně kam chci sám.

Myslím že znásilňovat prohlížeč aby poskytoval všechny funkce operačního systému _není_ dobrý nápad.

Napadá mě jediné – až to bude ve Firefoxu, jak to vypnout?

imploder

Už nemáme jen webové stránky, máme webové aplikace. Možnost přístupu k filesystému je důležitá, bez toho je spousta aplikací jak bez ruky.

František Kučera

Bude to znít ošklivě, ale: možná je právě tohle čas naučit se programovat a dělat normální aplikace – místo ohýbání prezentační/ob­sahové platformy.

imploder

Ve webové aplikaci vidím určité výhody:

  1. bezpečnost: můžu bez rizika (pokud nemám děravý prohlížeč) pracovat i s nedůvěryhodnou aplikací
  2. nemusí se instalovat, je okamžitě k dispozici
  3. multiplatformnost: funguje, ať už uživatel používá Windows, Linux, MacOSX nebo třeba PlayStation nebo nějaký mobilní systém

Je mi jasné, že na některé aplikace je web nevhodný. Na některé jiné je ale použitelný dobře (nebo by s ne moc rozsáhlými úpravami mohl být). V současné době se hodně prosazují webové aplikace, ty 3 výhody, co jsem zmínil, můžou být podstatné. Spousta věcí se dělá jako webová aplikace. Kolik z nich nabízí dobrou integraci s offline desktopem?

Nejde jenom o upload. Některé věci se dají udělat offline v javascriptu. Prohlížeč může sloužit jenom jako zavaděč programu z internetu, se všemi třemi zmíněnými výhodami. Javascript v prohlížeči a HTML5 je určitým způsobem výhodná platforma. Pokud to má k něčemu být jako opravdová aplikační platforma, nesmí být problém s takovou trivialitou jako vzít si od uživatele soubor(y) a nějak ho/je zpracovat.

Není to o tom, v čem já umím nebo neumím programovat.

VM

Ad 1. – čím více podobných „featur“ typu přístup do filesystému, tím hůře s bezpečností. Ta stavěla hlavně na tom, že prohlížeč je záležitost prezentační nikoliv výkonná, která zpracovává hodně omezený kód. To se teď má omezovat. Prohlížeče děravé jsou, bezpečnost půjde do kytek.
Ad 2. – ano, na druhou stranu při výpadku připojení na tom jste daleko hůř než s aplikací co se musí instalovat
Ad 3. – multiplatformnost je hodně omezená – třeba popisovaná featura je pouze v Chromiu. O tom co funguje/nefunguje v IE by vývojáři mohli psát romány. Navíc závisí na pluginech, velikosti okna… Samozřejmě je to multiplatformnost přes prohlížeče, nikoliv přes OS.

Nejsem apriori proti webovým aplikacím, ale nevidím v nich žádný zásadní přínos. Jak říká Peterka, vývoj se pohybuje ode zdi ke zdi, a všechno to tu už bylo – vzpomeňte spouštění programů na dálku přes terminály a X, když se pak přešlo na programy instalované přímo na počítači, tak se to bralo jako velký pokrok – člověk měl všechno pohodlně u sebe.

imploder

S tímhle souhlasím, až na tu nevyhnutelnost bezpečnostních děr v prohlížeči. Fakt je, že webové aplikace se nedají použít zdaleka na všechno a jako aplikační platforma je web takový kočkopes, ale na některé věci je to nejlepší možná volba. HTML5 přináší vylepšení především pro webové aplikace. Pokud se rozhodneme webové aplikace celkově ignorovat, tak nemá smysl zabývat se HTML5 a číst tenhle článek.

Martin Malý

Tak zrovna nevyhnutelnost chyb mi připadá jako nejneoddiskuto­vatelnější (fuj, co jsem to napsal?) Tedy že je téměř jisté, že se nějaká chyba v implementaci objeví.

imploder

Nějaká chyba ano, ale nemusí to být chyba, která způsobí, že někdo cizí získá přístup k systému. Třeba u firefoxu jsou takové kritické chyby typicky způsobené chybnou prací s pamětí.

Proč by zrovna to, že si uživatel může vybrat soubor, který předá javascriptové aplikaci, mělo vadit? Čím je to nebezpečné?

Oxymoron

Pokud by uživatel chtěl předat Javaskriptu soubor, nemusí jakési souborové rozhranní být potřeba, na to by stačilo rozšířit INPUT TYPE=“file“ např. na INPUT TYPE=Javascrip­tfile, kdy by si prohlížeč vytvořil kopii souboru, ke které by mohl javaskript přistupovat.
Ale nechat webovou stránku hrabat na lokální disk, je zvěrstvo.

imploder

Pokud se to „hrabání“ bude dát omezit jen na čtení, tak jaký je v tom rozdíl, kromě toho, že se zamezí zbytečnému kopírování dat souboru speciálně pro skript?

pas

Přesně tak a stačí se inspirovat u flashového FileReference API, kdy uživatel jak pro čtení, tak pro zápis vybere pomocí systémového dialogu cestu k souboru a s ním pak samotné čtení/zápis provádí skript. Navíc je to posichrováno tím, že tato operace musí být vyvolána přímou interakcí uživatele (volání z click handleru, apod.), nikoliv iniciována skriptem. To přece musí (spolu s lokálním úložištěm) plně stačit pro webové aplikace.

Oxymoron

Za jak dlouho někdo přijde s tím, že je to zbytečné omezení a že by fleš měl mít plný přístup k souborovému systému? Pamatuju doby, kdy fleš byl jenom pro animace. Po té, co jsem u jedho flešového chatu viděl obraz z mojí webkamery, fleš jsem odinstaloval a od té doby ho neinstaluju.

pas

Pamatuju doby, kdy HTML bylo pro publikování článků, něco jako teletext. Od té doby, co jsem viděl v HTML Google Apps, jsem to odinstaloval. ;-)

I když není moc v módě přiznávat, že Flashem by bylo vhodné se občas inspirovat, osobně si myslím, že systém bezpečnosti a soukromí je v něm navržený velmi dobře (nemluvím o bugách, kterými je také proslulý, ale o koncepci). Například zmíněný přístup k webkameře jste zcela jistě musel osobně povolit pro danou doménu.

Martin Malý

Jak že se přesně jmenovala ta technika, která přes Flash natáhla div, takže člověk klikal, aniž by tušil, že pod tím je dialog Flashe na povolení práce s kamerou, a kvůli které je teď Flash vždy před všemi objekty na stránce? Jo, už vím – clickjacking… ;)

pas

Ano, to tak se jmenovala – jak by se dalo na takový hezký název zapomenout? :)

Oxymoron

Pak je jenom otázkou času, kdy někdo přijde s tím, že je to zbytečné omezování a přijde se zápisem. K čemu je dobré, když Javaskript bude umět přistupovat k souborovému systému? Aby Javaskript mohl prohledat můj adresář a odeslat Gůglu moje soubory?
Už dneska jsou lidé před některými stránkami varováni, protože se nechovají zcela korektně. Zatím je to dost omezující, protože takové stránky musí využít chyby prohlížeče. Ale nevidím žádný rozumný důvod, proč přístup k počítači takovýmto stránkám usnadňovat.

Mimochodem:
a) v době, kdy po netu lítají zbytečné gigabajty dat (spam, apod.), tak bych několik kilobajtíků poslaných navíc neviděl jako problém. Je to prostě cena za větší bezpečnost. Kdyby se v paketech odstranily kontrolní součty, taky by se pát megabajtů ušetřilo.
b) Javaskript se k lokálním souborům bez kopírování přes síť dostane i dnes. Stačí využít Ajax a lokální webserver. Je to rychlé, spolehlivé a bezpečnější než přímý přístup prohlížeče, uživatelé si jenom museli zvyknout, že zpracovávané soubory se musí zkopírovat do jednoho konkrétního adresáře.

imploder

Pokud si budu přát, aby mi skript prohledal adresář a odeslal Gůglu moje soubory, tak ano, bude to možné. Pokud si to přát nebudu, tak se nic takového samozřejmě nestane. Je samozřejmě potřeba to implementovat bezpečně, stejně jako zbytek prohlížeče.

Proti zápisu nic nemám, jen by se to měl od čtení rozlišovat. Ani jedno z toho (čtení ani zápis) by se nemělo dít bez vědomí uživatele a obojí by mělo s vědomím uživatele bezproblémově jít.

K bodu a:
Zbytečné lítání věcí po síti nemá s bezpečností nic společného, je to důsledek toho, že se webové technologie používají na něco, na co nejsou moc dobře uzpůsobené, protože se s takovým použitím původně nepočítalo.

K bodu b:

  1. Je to nepraktický hack. Aneb na co mít ruce, když si můžu přivázat k noze smeták a drbat se za uchem jím?
  2. Místo přímého přístupu prohlížeče máme přímý přístup skriptů na lokálním webserveru (ty mimochodem musíme nejdřív nainstalovat a musíme jim věřit). V čem je to bezpečnější? Já v tom teda vidím spíš větší nebezpečí, může se tam podělat víc věcí než jen prohlížeč.
Oxymoron

To je právě to. Bezpečná implementace neexistuje. Jediná bezpečná implementace je vlastní odstíněný souborový systém, např. v TARu nebo ZIPu.

ad a) Zbytečné lítání dat po síti je daň za bezpečnost, aby webová stránka nemohla přistupovat neomezeně k jakýmkoliv souborům, ale pouze k těm, které výslovně vybere. Navíc není přistupováno přímo k souborům, ale k jejich kopiím, což je podle mého názoru bezpečnější. Jenom je to nepohodlné. Vidím to podobně jako PIN u platební karty, bez něj by užívání karty bylo také mnohem pohodlnější.

ad b) Bezpečnější je to v tom, že onen lokální server je možné vypnout a prohlížeč tak nemůže přistupovat k ničemu. Dále onen webový server může běžet na jiném počítači. Je tak zajištěno, že webová stránka nebude přistupovat k tomu, k čemu nemá. A vzhledem k tomu, že webových serverů existuje více, těžko může nějaká webová stránka předpokládat konkrétní chybu implementace v kombinaci prohlížeč + webserver.

Mimochodem, když už prohlížeče obsahují kompiler, proč by webové aplikace nemohli fungovat tak, že by se stáhnul zdroják, vytvořil by se .exe či jiný spustitelný soubor, který by si pak uživatel manuálně spustil?

imploder

Pokud budeme potřebovat celé adresáře (ne jen jednotlivé soubory), tak bude potřeba zajistit, aby javascript nemohl z adresáře „utéct“, to je pravda. TAR nebo ZIP by šel, ale lepší by bylo řešení, kde se takový odstíněný souborový systém namapuje na kus opravdového filesystému. Tohle by asi nebylo nutné, implementace omezující přístup programů na určité soubory nebo adresáře existují, viz AppArmor.

ad a) Že stránka nemůže přistupovat k jakýmkoliv souborům, ale jen k vybraným, je snad jasné. Platilo by to i kdyby se dalo přistupovat k souborům javascriptem. Lítání po síti k bezpečnosti nepřispívá, právě naopak: přílišná komunikace s okolím bezpečnosti škodí, aplikace je pak hůř ověřitelná, má víc potenciálních vektorů napadení; dobré pro bezpečnost je omezit rozhraní s okolním světem na minimum.

ad b) Aneb výhoda modularity. V dnešní době, kdy Chrome má pro každý tab oddělený proces, by určitě nebyl problém implementovat i práci se soubory jako oddělený proces. Je to otázka implementace. Běh na jiném počítači, to je na věc sloužící k přístupu k lokálním souborům dost neobvyklý požadavek. Dává to smysl, je to dobré pro bezpečnost – tím, že se na každá data/činnost používá jiný počítač. Znamenalo by to vyhradit další počítač pro přístup javascriptů z webu – bylo by tam jen to, co je potřeba. Bezpečnost provozu jakéhokoliv programu se zlepší tím, že se mu vyhradí zvláštní počítač. Naprostá většina lidí by ale IMHO něco takového nevyužila; taky je možné řešení, že prostě člověk používá na prohlížení webu zvláštní počítač nebo aspoň zvláštní uživatelský účet – není potřeba a podle mě ani není vhodné, aby si to řešily prohlížeče nebo dokonce přímo webové aplikace sami.

Kód z webu běžící přímo jako nativní kód – takový projekt existuje, dokonce ani nepotřebuje, aby prohlížeč program z nějakého jazyka překládal. Jmenuje se to Native Client a mělo by to umožňovat spustit v bezpečném sandboxu strojový kód x86 z internetu.

Oxymoron

No … a dostali jsme se k tomu, že pokud by aplikace měla něco ukládat na lokální disk, tak je na to lepší lokální aplikace, protože dnešní OS už na věci spojené se zabezpečením nástroje má. Pokud by se uživatel bál, že program něco někam odesílá, může ho jednoduše (alespoň ve Windows) odstřihnout od sítě. Pokud by to bylo jenom o stažení zdrojového kódu a otevření ho v nějakém programu, bylo by bezproblémové.

Možná jsem ze staré školy, ale smysl webové aplikace, která by si načítala data z uživatelského počítače a výsledek mu jako soubor ukládala na jeho počítač mi uniká. Stejně tak mi uniká smysl toho, aby server podstrkával už načtené stránce, aby něco udělal.

Oxymoron

1. Bezpečnost webové aplikace jde do kytek, když apliakce může přistupovat k souborovému systému.

2. Existují i běžné programy, jteré se nemusí instalovat, stačí je pouze zkopírovat a spustit.

3. Jak už někdo psal, multiplatformnost je narušitelná odchylkami v interperetaci/kom­pilaci Javaskriptu. Takže místo požadavku na OS budou požadavky na prohlížeč. Nebo napsání více variant pro různé prohlížeče, což je ekvivalentní situaci více variant programů pro různé OS.

koroptev

zbyva doresit, aby se kazda www stranka zobrazovala v samostatnem okne a vypadala jako nativni aplikace systemu..

..a budeme zazivat vyhody toho, ze jsme se konecne dohodli na jednom globalnim celosvetovem api pro psani nejen DEMO stromecku, zel asi tak 20 vrstev nad hw

imploder

Je v plánu možnost dát uživateli na výběr, který soubor nebo adresář tomuhle API poskytne? Bez toho nejde přistupovat k souboru, který nevytvořila stejná webová aplikace. Je to hodně důležitá věc pro integraci webových aplikací a offline aplikací, které pracují se soubory ve filesystému. Zatím jediná možnost jak předat soubor z disku webové aplikaci je vybrat ho ve formuláři a poslat ho na server přes POST – to je v případě, že s těmi daty pak bude pracovat JS kód v prohlížeči, naprosto nesmyslné kolečko klient-server-klient.

Oxymoron

Na jednu stranu se brojí proti tagu FONT (ještě mi pořádně nikdo nevysvětlil, jaký je rozdíl mezi zápisem FONT COLOR=“red“ a SPAN CLASS=“red“ … obojí by dělalo to samé, jenom ta druhá varinta zabírá víc místa) a pak se přidá hrabání stránek na disk. K čemu webová prezentace potřebuje hrabat na disk?

Nox
  1. Ad font x span
    • .red je relativně univerzálnější, jde upravovat význam, třeba odstín, napříč aplikací LEČ
    • tenhle zápis je minimálně dost ošemetný ne-li špatný. To, že nevidíte rozdíl je trochu správně, takto se to totiž zapisovat nemá, nemají se volit jména tříd podle jejich momentálního vzhledu, ale podle účelu (tzn. místo .red například .highlight-strong)
  2. Tady opět je docela špatně položená otázka – jasně, webová <b>prezentace</b> se nemá hrabat v disku, jenže pokud ve své otázce smrsknete všechny weby jen na jejich prezentační vrstvu … webová aplikace už by nějaký důvod mít mohla
Oxymoron

Ad 1)
Ano souhlas – pokud je cílem červené písmo daného odstínu, tak bych viděl pojmenování red zcela v pořádku. Někdy je to ne kvůli nějakému zvýraznění ale prostě proto, že je to vzhledově lepší. Nebo třeba použití třech různých zvýraznění na stejné úrovni zvýraznění … to bych je měl pojmenovat třeba jako .zvýraznění1-silné, zvýraznění2-silné, . zvýraznění3-silné?

Ad 2) Jsou ale dvě otázky:
a) Co všechno je možné nazývat webovou aplikací:
– jakoukoliv stránku pracující s daty uživatele,
– jakýkoliv program stáhnutelný z webu (z hlediska principu je to stejné: buď se otevře nové okno prohlížeče se stránkou, která chce po uživateli nějaká data, nebo se stáhne .exe soubor, .jnlp soubor, … krerý si případně natáhne z netu nějaké další knihovny a spustí se jako lokální aplikace)?

b) jaký je rozdíl v technologii webové prezentace a webové aplikace a jak mezi nimi bude prohlížeč rozlišovat, kdy se jedná o aplikaci a kdy o prezentaci?

Nox

1) v případě, že se změní pomocí CSS barevné schéma, tak už červená být lepší nemusí, a jsme v loji – budeme mít .red{color:green} :)

2) Přišlo mi že za webovou aplikaci se považuje web, který pracuje s daty aplikace nebo obecně má alespoň rozumně rozvinutý backend, ale chápu že to není jednoznačně určeno. Uvedl jste „webová prezentace“, což mi prostě evokovalo web s minimem backendu a důrazem na frontend (firemní prezentace s nějakýma fotkama produktů, ceník a kontakt…tento styl), proto jsem tak reagoval.
Nemyslel jsem, že by se to nějak rozlišovalo ze strany prohlížeče ale to, že pokud web provadí rozsáhlejší manipulace a výpočty atd., tak by nějaký důvod pro takovéto ukládání mít mohl

Oxymoron

1) to sice ano, na druhou stranu není problém zasáhnout do HTML.

2) I tak, co mi má nějaký backend prohledávat můj disk?

petr_p

Jako využití uvádíte:

<blockquote>Soubory jsou používány přímo z lokální cache, přimým čtením nebo odkazováním pomocí lokálních URI na obrázky či videa, loadery WebGL obsahu, apod.</blockquote>

Jak tedy vypadá URI, kterým se z HTML odkážu na soubor uložený v lokálním úložišti webového prohlížeče?

Oxymoron

Co třeba takto:

file://C:/Document and Settings/Admi­nistrator/Docu­ments/Chrome/vi­rus/virus.exe

?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.