Vlákno názorů k článku Zpracování událostí při skriptování výkresů SVG od kkl2401 - Muzu se zeptat, odkud (napr. ze ktere specifikace)...

Muzu se zeptat, odkud (napr. ze ktere specifikace) plyne to volani evt.getTarget().getOwnerDocument()? Neco takoveho mi v ECMAScriptu prijde maximalne podezrele. Kdyz se podivam na specifikaci DOM 2 Events, tak tam v te jejich IDL definici ma napriklad interface Event vlastnost target (typu EventTarget), coz pro ECMAScript znamena (dle language-binding), ze se k tomu dostanu zapisem evt.target (tedy primym pristupem k polozce objektu), zatimco treba v Jave to bude evt.getTarget() (tedy volanim metody) - oboji plyne primo ze specifikace. Najednou tu ale mame zjevne nejake rozsireni tohoto rozhrani Event, ktere pridava pro ECMAScript metodu getTarget() (u ktere plyne otazka, cim by byla implementovana v Jave, kde uz je metoda getTarget() obsazena), ktera vraci neco, na cem lze volat getOwnerDocument. Je nekde popsano, odkud se tyhle veci vzaly (a proc jsou udelany pro ECMAScript tak atypicky)?

To volani pres gettery se provadi zejmena kvuli kompatibilite se starsimi prohlizeci (webovymi), napriklad s NN<6, kde se v JavaScriptu nepracovalo s properties, ale pouze se settery a gettery (jako v Jave). Zapis do properties vytvorel v objektu novou promennou, cteni vracelo null. Misto evt.getTarget().getOwnerDocument() je samozrejme korektnejsi psat evt.target.ownerDocument, ale se zpetnou kompatibilitou to bude horsi (zde nezalezi ani tak na implementaci SVG ale spise JavaScriptu/ECMAScriptu).

namatkou (google :-) o tom pise napriklad Adobe, history na strankach http://www.cs.helsinki.fi/u/takerblo/ReadMe.html

No, neco jsem se nascriptoval i pro Netscape 4 a ani tehdy se v JavaScriptu nepouzivalo getteru a setteru, ostatne neco takoveho je proste proti tomu, jak byl cely JavaScript myslen, a ten pokud vim prisel budto s Netscape 3.0 nebo dokonce mozna uz 2.0 (hledat se mi to nechce). Krom toho vyrazne pochybuju o tom, ze by v Netscape 4 ci nizsim sla jakkoliv rozbehnout podpora SVG (nebo snad ano?), takze i v tomhle smeru mi ta souvislost unika. Nicmene pokud skutecne getTarget() je pouze (zbytecne) volani funkce, ktere jenom vrati polozku target, a obdobne tak i getOwnerDocument(), tak budiz.

Sice jsem to nezkousel (NN4 jsem nikdy nemel v lasce, byl jsem ho nucen docela dlouho pouzivat na SGI, kde nic lepsiho nebylo), ale podle nekterych dokumentu by mel jit Adobacky prohlizec v Netscape rozjet:

http://www.ikaros.cz/node/1330/print
http://interval.cz/clanky/smil-animace-a-prezentacni-efekty/diskuse/
http://www.grafika.cz/art/webdesign/clanek224161341.html

Dneska se IMHO nema moc cenu timto prohlizecem a jeho problemy s kompatibilitou zabyvat, dokonce nekteri autori povazuji prave ono getTarget().getOwnerDocument() za pricinu moznych problemu v novych prohlizecich a misto toho doporucuji pristup pres properties (viz predchozi prispevky).

S filozofii setteru a getteru je to zajimava myslenka. Mam dojem, ze poslednich par let se preferuji oproti "teckove notaci" (vliv Javy?), alespon co se tyce znameho getElementById() oproti jinym variantam.

Ne ne, v ECMAScriptu se gettery/settery urcite nepreferuji, nedava to tam tak dobry vyznam jako treba v te Jave uz jenom proto, ze neexistuje viditelnost (public/private/protected) polozek objektu. getElementById() je neco trochu jineho, to neni normalni getter, spis by se ta metoda dala pripodobnit k sahnuti to nejake (hash)mapy, coz bude ostatne asi jeji obvykla implementace. Tam jde o to, ze dava lepsi smysl umistit na interface Document jednu metodu getElementById, ktera pro predane id vrati Element, nez prohlasit, ze objekt implementujici Document obsahuje polozku pro kazdy XML element, ktery ma nastaveno nejake id, to zbytecne zahlcuje jmenny prostor (ony to bohuzel prohlizece kvuli zpetne kompatibilite dodnes delat stejne museji).