To je ale nudný článek, ani jsem ho nedočetl do konce. Nebyla by radši nějaká vtipná glosa? Určitě by se četla líp!
A její překlad by netrval celý den, jako tento "kvalitní obsah" ;)
To je ale nudný článek, ani jsem ho nedočetl do konce. Nebyla by radši nějaká vtipná glosa? Určitě by se četla líp!
A její překlad by netrval celý den, jako tento "kvalitní obsah" ;)
TO MARTIN HRUŠKA >> hoď sem nějaký odkaz na své články, ať se můžeme pobavit ...
Jinak moc zajímavý článek. Pro mě je přínosem. Dík autorovi :)
http://twitter.com/#!/adent/status/122743611979870208
Maritn Hruška náhodou je to výborný článok! ak tu hľadáš beletriu, horoskopy alebo erotické poviedky tak si na nesprávnej adrese. toto je web o programovaní!
Tento clanok mi prisiel vhod, lebo sa prave pokusam v CfS pisat skalovatelne (co sa kodu tyka) aplikacie. Kedze som si z Nette a PHP 5.3 zvykol na oddelovanie funkcionality do samostatnych namaspace (modulov), hladam podobne robustne riesenie aj v JS. Vsimol som si, ze CfS pouziva poslednu menovanu metodu na "schovanie" kodu pred globalnym svetom:
(function() {
// bla bla
}).call(this);
Ak si kceme predat nejaky objekt mezdi CfS subormi treba pouzit globalny objekt window, ktory je v samotnom CfS kode dostupny (vdaka horeuvedenemu) ako this. Bolo by fajn CfS kompiler donutit aby do .call() kompiloval vlastny NS.
nevím, jestli přesně toto máte na mysly, ale zkuste toto
(function(utils) {
// this == window
// utils == myNamespace.myUtils
}).call(this, myNamespace.myUtils);
Jsou to 4 roky jsem na projektu psal cisty javascript. Take jsme pouzivali vnorene jmenne prostory a objektovy literal a kdybych se nepodival zblizka na jednotlive vzory, tak bych ani nevedel, ze se tomu tak rika.
Co me ale zarazi, ze se v roce 2011 javascript stale mota okolo naprostych zakladu a predstava, ze by se na zacatku vyvoje mela resit otazka "budeme objekty vytvaret takhle nebo onak?" mi prijde uplne absurdni.
JavaScript má poměrně jasno a moc se nemotá. Jasno nemají někteří JavaScriptaři...
Ono napsat o jmen7ch prostorech v C++ článek by bylo moc jednoduché.
namespace Jmeno {
}
Jo, javascript je holt veda
Tiez mi to tak pripada :)
V JS ti nikdo nebrání jednoduše napsat:
jmeno = {
};
jmeno.b = {
};
Akorát je to prostě mimořádně ohebný jazyk, takže svádí vymýšlet ještě kulatější kola, která ve většině případů nejsou potřeba.
Jestli to chápu dobře, tak to lidi dělají aby měli robustní řešení, když v JS jde řada věcí dynamicky měnit, dokonce jde do undefined přiřadit hodnota což může rozbít skript atd. (kdyžtak mě prosím opravte)
"Jestli to chápu dobře, tak to lidi dělají aby měli robustní řešení, když v JS jde řada věcí dynamicky měnit"
Někdy se hodí si JS trochu přiohnout, ale nic by se nemělo přehánět. Kolikrát z toho vznikne v podstatě úplně nový jazyk, ve kterém se vyzná jenom autor :-).
"dokonce jde do undefined přiřadit hodnota což může rozbít skript atd"
Místo "do undefined přiřadit hodnotu" bych spíš řekl možnost vytvářet proměnné za běhu. Dynamičnost má jako všechno svoje výhody i nevýhody. Buď vím, kam můžu/nemůžu hrabat a řídím se podle toho nebo si můžu uměle vytvořit prvky jako privátní členy, atd. Každému vyhovuje něco jiného. Na věci, které se dají ohlídat, se musí myslet a když je to nutné, tak kontrolovat to, co by normálně kontroloval kompiler.
Jenže náš skript nemusí být jediný na stránce a bylo by hezké kdyby uměl fungovat i přesto, že tam jsou nějaké blbě napsané skripty.
Nevím jestli proti tomuto jde mít 100% obranu (chápu že je to chyba především toho blbého skriptu), když je JS tak dynamické...ale asi lepší jak drátem do voka
"Nevím jestli proti tomuto jde mít 100% obranu "
100% obrana není. Stačí, když nějakej mamlas napíše Math = 1; nebo Array = undefined; a můžeš mít skript napsanej sebelíp, stejně to půjde do kopru.
"Jenže náš skript nemusí být jediný na stránce a bylo by hezké kdyby uměl fungovat i přesto, že tam jsou nějaké blbě napsané skripty."
Tak nepoužívej blbě napsaný skripty :-).
:P Myslel jsem když někdo, kdo využije námi napsaný skript, použije zároveň i jiný, který bude nedobře napsaný... bylo by vhodný, kdyby to náš skript ustál
Taky možná proto že začátečníci (i když toto už nejsou ty nejtriviálnější základy viz jakpsatweb) byli, jsou a budou
Přijde mi to jako další z miliardy příspěvků "děláte to blbě, já to umím líp" = pokud to máte vyřešené, proč se nepodělíte aspoň naznačením s ostatníma? (tím spíš pokud přepokládáte že všechny články na JS mají být na vaší nebo vyšší úrovni)
.. ba ne kecám :-)
Jsem viděl titulek clanku, tak si rikam, ze se naucim neco noveho, ale po precteni clanku jsem dosel k zaveru, ze "jmenne prostory" pouzivam den co den. V podstate slozitejsi skripty bez toho ani nedelam... Akorat mi prijde clanek zbytecne dlouhy, ona to zase neni zadna veda tohle, jsou daleko slozitejsi veci.
Pro rozdělení do modulů a prostorů mi ve většině případů jako nejpoužitelnější připadá obyčejný objektový literál. Leda že by někdo chtěl stejně jako v článku zanořovat pět a více jmenných prostorů do sebe, což mi přijde jako pěkná pakárna. Podobné postupy používám spíš pro možnost jednoduché integrace funkcí z určitého prostoru s nějakým frameworkem, atd.
Díky za článek:) Jaký je rozdíl mezi: var myApplication = myApplication = myApplication || {} a var myApplication = myApplication || {}; ? Píšete, že ten první případ je důkladnější.
Podle mě je to úplně jedno. Pokud ne, tak by mě taky zajímal důvod.
Není to tím že u 1. se v případě == false přiřadí {} i do externí myApplication a ne jen do lokální?
Měl jsem za to, že to namespace se deklaruje v globálním prostoru. Jinak aby fungovalo to vytvoření/přiřazení do globální proměnné se stejným názvem, tak by to podle mě měo vypadat takhle:
var myApplication = window.myApplication = window.myApplication || {};
Což je v každém prohlížeči ekvivalentní prostému zápisu
window.myApplication = window.myApplication || {};
a pokud nebude window existovat (třeba ve WebWorkeru) tak je zase jiný problém.
Osobně mám pouze jednu globální proměnnou a jednu globální funkci a ta se mi o vše postará: https://github.com/langpavel/FastJS/blob/master/src/boot.js
Až na to, že jsme se bavili o zápisu uvnitř funkce, kde to ekvivaletní nebude...
Většina zde popisovaných věcí IIFE je taky ve zdejším starším článku http://zdrojak.root.cz/clanky/oop-v-javascriptu-i jako příklady jak to nedělat. To jste mi teď nasadili pěkného brouka do hlavy.
Držel bych se akorát zásady nezahnojit globální prostor, na provedení zase moc nezáleží, přívětivost samozřejmě potěší.
Podělím se o svoje řešení, snad mě nikdo neukamenuje :-)
"use strict";
if(typeof FastJS === 'undefined')
FastJS = {}; // vytvoř hlavní namespace, pokud neexistuje
if(typeof getFastJS === 'undefined') {
// vytvoř funkci vracející namespace, pokud není poskytnuta vlastní
var getFastJS = (function(){
var FJS = FastJS;
FJS.E = function() { /* void */ };
FJS.T = function() { return true; };
FJS.F = function() { return false; };
FJS.K = function(x) { return x; };
if(typeof FJS.debug === 'undefined')
FJS.debug = FJS.E;
return function() {
if(arguments.length === 0)
return FJS;
var nn, i;
var l=arguments.length;
var ns = FJS;
for(i=0; i<l; i++)
{
nn = arguments[i];
ns = (typeof ns[nn] === 'undefined')
? (ns[nn] = {})
: ns[nn];
}
return ns;
};
})();
}
// ulož aktuální kontext jako globální namespace (většinou window)
getFastJS()['GLOBAL'] = this;
Zajímají mě vaše názory. Zdroj: https://github.com/langpavel/FastJS/
Proč je tam ta druhá globální proměnná, když můžu rovnou udělat FastJS['GLOBAL']? A taky nechápu smysl té anonymní funkce, když se v ní přístupuje k předem definované globální proměnné.