HTML+CSS+JavaScript

Прошу дать оценку написанной мной библиотеки на JavaScript для создания собственных компонентов на HTML. Подключается библиотека просто:

<script src="EHTMLLoader.js" include="sizedtext"></script>

В нестандартном аттрибуте include указываются имена компонентов, которые надо подключить. При использовании данной библиотеки из кода пропадают обработчики событий: onMouseover, onMouseout, etc... Пользователю достаточно скачать новый компонент, скопировать его в директорию на сайте и использовать новый компонент точно так же, как и обычный HTML. Сейчас готовлю подробную документацию и новые компоненты. Посмотреть пример работающего компонента можно на сайте, в разделе "Документация". Библиотека EHTML расположена здесь: http://ehtml.ru. Заранее спасибо за комментарии и оценку.

что-то в этом наверное есть, но вот разобраться как это работает без дока сложновато...

не могли бы Вы в качестве примера преобразовать эту строчку:

<span style="color:blue;cursor:pointer" onclick="location.href='http://site.ru'" onmouseover="this.style.textDecoration='underline'" onmouseout="this.style.textDecoration='none'">click me</span>

в эту, используя Вашу библиотеку:

<span href="http://site.ru">click me</span>

>что-то в этом наверное есть, но вот разобраться как это работает без дока сложновато...
>
>не могли бы Вы в качестве примера преобразовать эту строчку:
>

><span style="color:blue;cursor:pointer" onclick="location.href='http://site.ru'" onmouseover="this.style.textDecoration='underline'" onmouseout="this.style.textDecoration='none'">click me</span> >

>в эту, используя Вашу библиотеку:
>

><span href="http://site.ru">click me</span> >

Да, согласен, без документов сложно. То, что вы указали очень просто решается в компоненте. Да, доки надо писать - каюсь, скоро будут. То, что вы указали - вот:

function EHTMLsample(){this._init()} (function(){     EHTMLsample.prototype = {              _init: function() {             var base = new EHTMLBase();             base.setValues({                 tag: {                     span: "hreftype"                 },                 hreftype: {                     href: null,                     EHTMLCallback: this._spancode                 },                 actions: {                     click: this._go,                     mouseover: this._under,                     mouseout: this._none                 }             });             base.install();         },                  _spancode: function(param) {             for(var i=0; i<param.length; i++) {                 param[i].style.color = "blue";                 param[i].style.cursor = "pointer";             }         },                  _go: function() {             var link = this.getAttribute("href");             location.href = link;         },                  _under: function() {             this.style.textDecoration="underline";         },                  _none: function() {             this.style.textDecoration = "none";         }                  } })(); new EHTMLsample();

Написал за две минуты ровно. Применяется так, как вы указали:

<span href="http://ehtml.ru">EHTML</span>

Документация будет скоро. Также буду тестировать код для кроссбраузерности. Заработает. Спасибо, за комментарии, прошу не сомневаться - проект не брошу, он будет только развиваться

Отписался на форуме. Идея весьма интересная, но еще работать и работать.
Для начала необходимо достаточное количество вариантов использования (читай компонентов).

2 Crux. Пока эта библиотека такого применения не позволяет. Для вашего варианта подойдет класс eventHandler, который я в данный момент разрабатываю. Суть его - в избавлении от применения атрибутов обработки событий в тегах документа, сведению всех обработчиков в скрипт и удобного управления результатом. Как закончу, сообщу в этом форуме.

>Отписался на форуме. Идея весьма интересная, но еще работать и работать.
>Для начала необходимо достаточное количество вариантов использования (читай компонентов).
>
>2 Crux. Пока эта библиотека такого применения не позволяет. Для вашего варианта подойдет класс eventHandler, который я в данный момент разрабатываю. Суть его - в избавлении от применения атрибутов обработки событий в тегах документа, сведению всех обработчиков в скрипт и удобного управления результатом. Как закончу, сообщу в этом форуме.

Почему же не позволяет? Пример я привел выше. Документация будет скоро. Она позволяет очень много, в том числе и избавляться от ненужных обработчиков (эти обработчики указываются в хеше, под идентификатором actions. Кроме того, в объект обработки передается this - что избавляет программиста от нудной работы с IE. Реализовано это функцией bind в самом начале библиотеки.

Извиняюсь, загрузчик смотрел поверхностно, не сразу заметил _setAction.

Да я думаю немного переписать библиотеку. Более понятной ее сделать, что ли. Пока пилотная версия, но расширять есть куда. Когда разрабатывал нашел еще много путей для доработки. В планах даже кеширующие плагины для браузеров.

Сейчас существуют множество js-фрейворков, которые позволяют реализовывать приведённые Вами примеры ( и ещё много чего другого) красивее, быстрее, удобнее, валидние. ИМХО, одним таки больше станет в лучшем случае.

С удовольствием посмотрю и почитаю, возможно найду что улучшить. Будьте добры дайте ссылки. Библиотеку Prototype не предлагайте - уже обсуждал на X-Point (имеет и свои отрицательные стороны). Приведите примеры хороших библиотек, которые будут интересны.

Сам, например, пользуюсь решениями этой библиотеки, http://jquery.com/. Многие хвалят http://dojotoolkit.org/. Новая библиотека, http://dedchain.dustindiaz.com/ возможно тоже с будущим. А если погуглить, то можно найти ещё не один десяток, хороших и не очень.

Библиотеки отличные, хорошо знаком. Но не то. Я, когда начинал писать EHTML, стремился создать библиотеку с интерфейсом дружественным, прежде всего, пользователю. При использовании указанных вами библиотек от пользователя требуется знание JavaScript на достаточно хорошем уровне, чтобы установить сценарий, отсутствует отдельная подгрузка написанных компонент (кроме DoJo, и то в коде, что может оказаться сложным для пользователя). Я не противник этих библиотек - они удобны и практичны, но вот пользователь предпочтет понятный для НЕГО интерфейс, а не для программиста. Под пользователем я здесь понимаю HTML-кодера. Да, теряется валидность, но код приобретает интуитивную понятность. В общем спор этот бессмысленный. Я продолжаю работу над библиотекой и компонентами, а что из нее получится - увидим.

Идея хорошая, но есть несколько моментов:
1. Код становится не валидным.
2. Уже написали, что не работает под Оперой, думаю с кроссбраузерностью будет туговато.
3. Пока есть проблемы с заданием стилей.

>Идея хорошая, но есть несколько моментов:
>1. Код становится не валидным.
>2. Уже написали, что не работает под Оперой, думаю с кроссбраузерностью будет туговато.

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

>3. Пока есть проблемы с заданием стилей.

Проблемы с заданием стилей не в самой библиотеке - она стилями совершенно не заведует, здесь проблема в компоненте, который писался срочно, для примера, и вскоре будет переделан

Внесены изменения в библиотеку. Полностью поддерживаются следующие браузеры: Internet Explorer 5.0+, Mozilla Firefox 0.9+, Netscape Navigator 6.0+, Opera 7.15+
Сейчас пробую переписать код под Internet Explorer 4.0
Ну что-ж, с кроссбраузерностью проблему разрешили, заработал даже Netscape Navigator 6.0.

тормозит ужасно....
при большом количестве кода и большом количестве преобразований.

Подробнее, пожалуйста. Укажите браузер и параметры компьютера. При тестировании тормозов замечено не было.

Компьютер AMD Sempron 2600+ 1.60 Ггц. 512 ОЗУ
WindowsXP
Firefox/2.0.0.3

тестил локально,
использовал приведенный выше Вами пример EHTMLsample().

количество обрабатываемых тегов около 300.

кол-во символов в файле около 100 000.

Проверил. Это старый, известный баг Gecko, скорость работы ужасная, но вина не библиотеки - на Gecko браузеры начинают потреблять слишком много памяти (если помните этот баг очень мешал работе еще 6-го Netscape Navigator, особенно потому, что он загружал в память все свои компоненты). Internet Explorer, Opera открывают 300 элементов мгновенно (по крайней мере задержки добиться не удалось). Это первое.
Второе, страница будет грузиться из интернет, поэтому загрузка страницы будет идти постепенно, скрипт запускает себя каждые 100 миллисекунд (чтобы не грузить систему) и сканирует полученные теги в цикле, таким образом, даже на Firefox это будет не настолько критично, как при загрузке с localhost'а. Например, сто элементов того же EHTMLsample.js Firefox открывает почти без задержки. Поэтому скорость онлайн будет вполне достаточной. Ну и третье, я просто боюсь себе представить страницу, где будет хотя бы более 50 тегов EHTML. Это же получится пострашнее "профессионалов" с narod.ru.
Поэтому, с точки зрения скорости работы, библиотека очень хорошо себя оправдывает. Хм, возможно, на своем форуме, я даже выложу результаты работы тестов с компьютеров разной конфигурации. Благодарю, за подмеченный баг, надо будет подумать об ограничении скорости сканирования библиотеки для ядра Gecko, забыл я об этом старом, но не исправленном до сих пор баге.

>Это старый, известный баг Gecko, скорость работы ужасная, но вина не библиотеки...

здесь я с Вами не согласен. любая библиотека должна учитывать все достоинства и недостатки браузера.

>Ну и третье, я просто боюсь себе представить страницу, где будет хотя бы более 50 тегов EHTML.
зря боитесь.

>здесь я с Вами не согласен. любая библиотека должна учитывать все достоинства и недостатки браузера.

Согласен, но это просто жуткое потребление памяти. Учесть его невозможно - при большом количестве обработок данных на JavaScript Gecko начинает наступать себе на ноги. Обратите внимание на скорость обработки 100 тегов, она несравнимо меньше, чем 300. А если установить 1000 тегов, то боюсь, что вы просто не дождетесь результатов работы - Gecko в свое время попортил кровь многим этой ошибкой. Учитывать такой недостаток можно одним способом. Определять - если это браузер на основе Gecko (Mozilla, Firefox, Netscape) не позволять ему производить сразу большое количество обработок, давать ему порциями по 50-60 тегов, таким образом тормозить он не будет и быстренько справится с нагрузкой порциями. Попробую сделать...

>>Ну и третье, я просто боюсь себе представить страницу, где будет хотя бы более 50 тегов EHTML.
>зря боитесь.

))) Гм, это положительная оценка библиотеки и комплимент? Благодарю!