Сабджект... Понятно, что от Object. Однако, FF и Opera после создания DOM-элемента (например, div) позволяют получить в этом элементе доступ к свойству constructor и constructor.prototype (сам элемент свойства prototype не имеет). Таким образом, можно расширить стандартные DOM-объекты. Рабочий пример:



Вопрос: если div наследуется от Object:

IE:



то почему, d не видит метода setContentFromObject? И вообще, можно ли получить доступ к конструктору (и его прототипу) DOM-элемента в IE?

P.S.: всех с наступающим Новым годом, коллеги! Здоровья, счастья, успехов, побед!

В IE <div> не наследует от Object. Проверьте:



Нет, нельзя. Используемая концепция COM как-раз подразумевает обратное - объекты находятся в физически разных модулях, взаимодействующих между собой лишь посредством определенных интерфейсов. Эта концепция реализована во множестве майкрософтовсих платформ, одной из которых является IE.

уй-ё.. Вот я лажанулся-то =) Мне реально показалось, что d instanceof Object == true, а не false (и я стал создавать тему =)))



объекты в разных модулях - это имеется в виду див и его конструктор? А что это за модули? И доступа к "определенным интерфейсам" тоже не получить, чтобы связаться...

Спасибо, AKS =)

Нет, я имел ввиду jscript-объекты и элементы документа. Т.е. jscript'вский Object - это одна "песня",  и к узлам документа (к элементам, в частности) эта "песня" не имеет никакого отношения.


Доступ к интерфейсам Вы как-раз имеете. Т.е. Вы имеете в своем распоряжении некий API (интерфейс программирования приложений), позовляющий Вам получить доступ средствами одного языка программирования (в данном случае речь о jscript) к объектам, написанным на другом языке программирования. 
А вот какую функциональность предоставили Вам "гениальные" майкрософтовские кодеры - это уже другой вопрос. Получилось так, что они решили не давать Вам доступ к конструктору элемента, о котором Вы писали. Можно даже резюмировать следующим образом - все, что касается "происхождения" элементов документа, просто-напросто "скрыли в черном ящике". 
Однако винить в чем-либо разработчиков IE было бы совершенно нелепо. Они используют "привычный" для своих продуктов технологический стандарт COM, и им незачем от него отказываться (программисты, как известно, о-о-очень редко отказываются от того, что, как они любят выражаться, "итак работает" ;) ).

ну да, в общем получается для расширения DOM-объектов в IE надо пихать эту функцию (расширения) в метод получения объекта (т.е. хранить расширенные методы для каждого объекта индивидуально; ну и помечать, что объект уже расширен, чтобы не делать холостых операций каждый раз), в то время как в FF и Opera все это можно хранить в прототипе конструктора, что намного "легче" (по весу объектов, т.к. в последнем случае они ссылаются на нужный прототип):

dsCode, можно сделать несколько проще. Используя специфичные для IE HTML компоненты, можно добиться почти того же самого, что и в случае с FF/Opera (даже определить геттеры/сеттеры для элементов):
html (с кодом для FF, в котором специально написал геттер isHidden):

htc (для IE):

Это сообщение отредактировал(а) cruelangel - 2.1.2008, 19:43

прошу прощения, что долго не отвечал, я в отъезде (до сих пор) =)

AKS, cruelangel, спасибо за ответы. Кстати, насчет htc и behavior в стиле я как-то и не знаю вообще (и последней конструкции в частности - ...'*', 'behavior: expression(...) ...). Расскажите, если не трудно, что это значит для IE, ну и "пару ссылок" почитать тоже было бы неплохо =)

И еще вопрос - есть ли разница, если геттер/сеттер объявлен как "обычный метод" или через __defineGetter__ (он, вроде, доступен только в Gecko)? И если нет, то зачем эти __defineGetter__ / __defineSetter__? Для красоты?

HTC Reference
Introduction to DHTML Behaviors
behavior Attribute
setExpression Method


Разница есть, конечно же. При создании такое свойство ("виртуальное" св-во, на самом деле это ведь метод), судя по всему, получает атрибут { ReadOnly }, т.к. "переписать" такое св-во не удастся. Ну и использовать их проще - var a = myObj.get; myObj.set = a * 2;
Чаще всего можно встретить писанину, в которой показывают, как геттеры/сеттеры использовать для доступа к "приватным" св-вам. Только для ECMAScript 3 "возня" с "приватом" не столь актуальна. 
Можно, естественно, "поручить" геттерам/сеттерам и более сложную логику, что-нибудь, вроде такого:

Но, поскольку, геттеры/сеттеры пока поддерживаются только на ограниченном кол-ве платформ:

• Firefox
• Opera 9.5
• Safari 3

 особо на них рассчитывать не приходится - в других браузерах такой код станет причиной "вылета" ошибки...

AKS, ага, thx =) И еще парочка вопросов:

- часто ли кто использует htc в своих разработках? Теоретически для IE можно было бы расширить прототип ActiveXObject'a и использовать нужные методы. Или так не получилось бы и надо обязательно через htc - расширять прототип ActiveXObject'a, а потом копировать в функцию element'a (себе: вот лень самому написать проверить, надо здесь писать, да? =)))? Но вообще, конечно, понятно - от ActiveXObject'a много кто наследуется (и инстанцируется), а не только какой-то там div, поэтому "засорять" его (ActiveXObject) только для div'a - тоже мало смысла.

- насчет геттеров/сеттеров - значит единственное отличие - это ReadOnly атрибут - т.е. если не будет сеттера и написать a.b = 3 вылезет ошибка, что для этого свойства есть только геттер, а менять его нельзя, с этим понятно =) Ну и мини-вопрос - разницы между get b и __defineGetter__(...) нет, да? Я знал их и раньше, но никогда не использовал. Да собственно, и не вижу особой надобности на данном этапе. Единственное применение - какие-нибудь внутренние свойства какого-нибудь ядра (фреймворка), которое могут все использовать, но  менять свойства внутренних сущностей - нет.

Это сообщение отредактировал(а) dsCode - 8.1.2008, 15:09

Мне ничего не известно о подобной статистике. Можно обойтись одним только Jscript'ом, htc - это "навороты" немного из другой области.


Если только теоретически, поскольку расширяй-не расширяй - толку нет (элементы ничего не узнают об этих методах). Это я просто ради эксперимента его использовал, т.ч. не обращайте внимание.


Разница-то всегда должна быть, а иначе зачем разный синтаксис. __defineGetter__ можно использовать когда угодно (динамически, а не в момент инициализации объекта).

я имел в виду здешних участников форума =) ну да ладно


хех, тогда, конечно, какой смысл?! я-то думал, что они будут "видны". Тогда и смысла не было в расширении ActiveXObject.prototype  в примере с htc и можно было написать element.changeDisplayValue = function()  {...};. А вообще странно... почему не будут видны? prototype - есть, расширить можно, div - инстанс ActiveXObject'a и может достучаться (не напрямую, ибо - суть темы, а как инстанс) до (уже расширенного) прототипа..


а, ну здесь - да, конечно - да.

P.S.: и в очередной раз - спасибо, еще +1 =)

Это сообщение отредактировал(а) dsCode - 8.1.2008, 18:44

Неужели не уловили суть? ;)

представьте себе ;) наверно потому, что htc не знаю =) так что - разъяснения будут более полезны 

Просто в таком случае: element.changeDisplayValue = function()  {...};, для каждого элемента будет создаваться своя, всякий раз новая функция. И если элементов много (* { behavior:...} - т.е. вообще все эл-ты на странице), то это будет не простой процесс.
А если же создать один раз, разместив их в каком-либо "хранилище" в глобальной области видимости (я с дуру выбрал ActiveXObject.prototype ;) ), то js-функций будет создаваться значительно меньше (меньше занимаемая память, например). 
Единственное неудобство - надо явно создать "поля" у каждого элемента и присвоить им указатель на функцию. В случае с HTMLElement.prototype этого делать не надо, однако и доступ к методу будет дольше (у элемента нет такого метода - надо искать в prototype chain)...