s0rr0w

Более того, "народ" напрасно рассчитывал на Вас, что:

This chapter will teach you how to trap and handle JavaScript error messages...

Я не могу, веселенькая темка. У меня стоит задача, при возникновении ошибки не генерировать никаких сообщений об ошибках. Мой код с этим справляется? Да/Нет?

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

Мдааааа... Я не думал что все настолько плохо. Бактрекинг мозиллы говорит о том, что зачастую ошибки получаются даже в якобы лишенном ошибок коде. Что трудно предугадать, где именно и какая именно возникнет ошибка, потому что система очень сложная. Если бы вы работали хоть над одним сложным проектом, то вы бы это прекрасно понимали. Но, очень похоже на то, что вы как раз не работали.

- разобрались с особенностями метасимвола b в javascript;

Это часть условно полезной информации.

- узнали, что IE ниже 6-ой версии не поддерживает special value "*";

Для меня уже как года 4 не существует IE, версий ниже 6-й. Да и 5-я начиналась с 5.5-й версии. И попытки научить людей старью, это да, очень полезное занятие.

- поняли алгоритм do-while с его обязательным разовым действием вне условий;

Еще году так в 95м.

- осознали, что скорость в циклах зависит больше от техники, чем от формы;

На самом деле, что скорость работы зависит от реализации интерпретатора. И что со временем надо перепроверять скорость, так как она может рости или уменьшаться.

- обнаружили для себя "custom scope chain" в инлайн обработчиках;

Для меня это мертвый груз. Он никак не проявляется в моих скриптах, никак на них не влияет, и никак не будет на них влиять.

- увидели, как метод окна может быть перекрыт методом документа;

Ах как лукавите. В строго определенном случае, который в силу своей специфики, почти никогда не используется. Для меня это опять же мертвый груз. Вы думаете я не думал о перекрытии названий, когда называл функцию именно так?

- поняли, как недальновидно собирать ноды в массив задом напер?д;

Да, все кину и буду собирать ноды в массивы спереди назад. Смешно.

- узнали, что переменные с именами "_" и "$" не являются синтаксическими ошибками;

Это реально полезное знание. С этим согласен.

- "неявное заведение переменных" - прямая дорога к багам IE (и частично к багам Opera);

Почему у меня их нет? Вот вы говорите прямая дорога. Покажите мне хоть один код, который приведет к этой прямой дороге. Пока что я не увидел нормального обоснования, почему так делать нельзя.

- проверка браузера пут?м выявления условно идентифицирующих срок отсекает часть пользователей;

До вас наверное не дошло, что я делаю отсечение IE от FF. Всего лишь. А вы уже учите меня, как мне надо делать. Задачу сначала изучите, потом советы давайте.

- эти же строки не являются залогом успешного использования нужного свойства/метода вообще;

Вопрос на засыпку, куда делся массив document.all при появлении дом-функций? Ответ - никуда. Пока MS не напишет браузер с нормальной поддержкой стандартов, до тех пор такое деление ( на ИЕ и не ИЕ) будет актуальным.

- "таргет события" не мешает всплывать событию, а обработчику корректно работать;

Похоже вы сами себя перехитрили. Не понял ничего.

- инлайн обработчики элементарно вызываются без бажных и непопулярных dispatchEvent и т.п.;

Опять красивые слова, но доказательства бажности диспатчЭвента я не увидел. Это раз. И второе, ваше мнение про непопулярность решений меня мало волнуют. Популярное решение то, которое позволит мне выполнить нужные мне задачи. Ваш отродоксальный подход не применим к моему способу работы. Но вы то умный, и хотите всех научить быть умным ровно таким же как и вы. Только вот я бы не сказал, что ваш ортодоксальный подход правильный.

- блоки try-catch при тотальном отсутствии проверок и контроля за скриптом - признак непрофессионализма;

И в какой это книжке написано? Там не ваше авторство случайно? Вы слишком узко мыслите.

Все варианты предусмотреть нереально. Да и не нужно. Это тратит совершенно неокупаемое время на разработку.

Вот он - лозунг российского автопрома.

Не удержался от оффтопа.

Это правда жизни. Сложность системы с каждой написанной строчкой растет, предусмотреть все места, где и какой баг у тебя вылезет нереально.

Достаточно полистать багтрекинг мозиллы, чтобы увидеть это.

Было "теги внутри ссылки", теперь - снаружи. Дружище, чтобы не признавать свои оплошности в логике вы готовы уже перетрясти скрипт - меняете ноду, не перенося обработчик, переносите класс, и ещ? до кучи прид?тся в скрипте пару изменений сделать (это к вопросу удобства). Низачот.

Бугагага. Скорее всего вам даже в голову не приходило, что такой вариант возможен. Теги внутри были нужны для того, чтобы показать как просто стайлить таб. Теги снаружи- это вариант стайлинга, где кроме ссылки активации таба могла быть еще не одна ссылка. Например закрытия таба. Но, ваш вариант этих проблем явно не имеет. Сферический конь в вакууме в принципе не может иметь проблем.

Не ясно, почему при первичной инициализации нужно делать это дважды, сначала в одном месте, потом в другом (сбор массива), когда структура уже собрана и готова к употреблению?

Ну так если вам неясно, то мои пояснения не прояснят ситуацию. Это к тому, что вам просто нравится обсасывать детали, а целого то вы и не видите.

Попробую пояснить, только это кажется не даст никакого эффекта. Вам по прежнему что-то будет непонятно.

Функция инициализации вызывается один раз. Функция активации таба - множество раз. Функция активации универсальна. Достаточно запустить механизм активации и все равно, сколько там данных собирается. Упростив что-то в одном месте вы можете нарваться на усложнение в другом. Я давно уже пришел к юниксо-подобной логике написания кода - множество мелких приложений могут быть составлены в одно большое. Может и в скорости проиграю где, зато универсализация позволит сделать ряд других выигрышей.

Контейнер может быть по-разному оформлен (ещ? один див внутри, подложка и т.п.), и мы будем вынуждены менять расположение ноды-таба, видоизменять логику для отдельного случая (или для всех), чтобы уцепиться за нужный контейнер, сделав его родителем. То же самое касается посадочного места для табов, которое тоже может содержать ноды, и метод appendChild уже не будет уже таким однозначным. В конце концов, кроме основного контент-контейнера может быть дополнительный и т.д. Ж?сткая схема "таб плюс его родитель only на момент запуска" не сильно способствет масштабу...

Я уже говорил, что некоторые вещи нужно принести в жертву, чтобы выиграть в другом месте. Насколько масштабируемый ваш скрипт мы уже все в курсе.

на мой вгляд характерый пример оплошности, когда ноды в массив собираются не в сво?м порядке, и об этом как-то забывается.

Честно говоря, этот кусок кода вообще не проверял. На таком коде смысла нет.

Скажите, пожалуйста, в каком месте срипта вы работаете с "таргетом эвента"?

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

Таргетом будет A, а options привязано к DIV.

Извините, но не понял из этого объяснения, почему вы не используете уже приготовленные вами же обработчики.

А кто сказал что обработчик будет только один? И табы будут только одни на странице. И не будет никаких скриптов, которые тоже могут работать с данным HTML?

Не проще. Попробуйте сделать сортировщик под большой массив данных, станет очевидно, насколько интерпретаторы менее оптимальны при работе с деревом/нодами по сравнению с работой со "своими" данными. Где в ноде интерпретатор разместит кастомное свойство, какой объ?м данных для перебора там уже есть, каким алгоритмом и как быстро он достанет это свойство? Вс? это вопросы скорости, важнейшего фактора при сортировке.

Я ждал этого вопроса. Покажите мне интерфейс, в котором огромное число данных выводится без постраничного вывода.

p.s. чтобы быть до конца понятым - несмотря на то, что соревнование "скрипт vs. скрипт" по моему глубокому убеждению вы слили по всем статьям, я поддерживаю вашу позицию относительно использования дивов и т.п.

Просто вы - ортодокс.

Конструкция try предполагает, что в ней будет размещен фрагмент кода, в котором есть вероятность возникновения исключительной ситуации.

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

Далее, конструкция catch предполагает обработку возникшей исключительной ситуации.

Опять же, какие мысли возникают, когда в коде нет обработки ошибок? Или же автору неизвестно, как их обработать, или же автор вообще не знает, что именно обрабатывать, не представляя, с чем он столкнется.

В общем и целом впечатление такое - конструкция try используется неумело, не к месту, а иными словами - совершенно не профессионально.

Разговоры о том, что try не нужен в "детских" скриптах, и необходим в серьезных - очередная, ставшая уже стандартной, "отмазка" на тему "FAQ по супер-разработке".

http://www.w3schools.com/js/js_try_catch.asp

Вот тут народ считает аналогично тому, как это считаю я. Выводить JS ошибки пользователю - плохо. Есть еще пару ресурсов, в которых говорится, что в идеале неплохо было бы использовать try-catch во всем проекте.

Верная мысль, что никогда не знаешь, с какой именно ошибкой можешь столкнуться при работе скриптов. Все варианты предусмотреть нереально. Да и не нужно. Это тратит совершенно неокупаемое время на разработку. При росте сложности кода растут вероятности возникновения ошибок. Некоторые ошибки тяжело предугадать. Над большим кодом обычно работает не один человек, а в команде высоки шансы возникновения ошибок. Так что можно сколько угодно считать мои слова отмазкой, я не против. Время нас рассудит.

Visual user agents generally place a line break before and after DIV elements

Это поведение всех блоков без исключения. Блок всегда начинается с "новой строки". Я немного уточню, что имелось в виду под форматированием - отступы, бордюры, шрифты, размеры, все. что может повлиять на визуальное отображение. Конечно же DIV имеет предустановленное свойство display: block.

"Правильно/неправильно" - не совсем уместно. Я бы сказал так - логически верно было бы сформировать список, используя теги, которые для этого предназначены.

Список DL предназначен для вывода списков определений. Табы ну никак не тянут на список определений. Заглавие таба не является термином. А контент - не является описанием определения. Хотя не отрицаю, данная структура вполне схожа со структурой табов. Но является ли правильным искажать предназначение тега, только потому, что его структура может подходить под определенную задачу? Так в чем же логическая "верность"?

Все-же по стандарту HTML логически правильно сделать структуру, которая не предусмотрена в HTML при помощи именно DIV'ов или SPAN'ов.

Об этом и речь. Вы настаиваете на своем "более" варианте.

Я не настаиваю. Я говорю, что на практике все многообразие тегов обычно не востребовано.

Чем тут может помочь try, если это тоже самое, что гневные письма по поводу какого-либо "не работает!"?

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

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

Не надо перевирать мои слова. Безбаговых программ не существует. Если писать детские скрипты на пару строчек кода, то шанс напороться на серьезный баг - ничтожен.

Вам присылали хоть раз гневные письма по поводу какого-либо "не работает!"? А лишали ли вас премии за JS-ошибки?

У меня два плюса напротив каждого вопроса.

Вспомните свое отношение к windows, когда вываливалась какая-либо ошибка.

Ну что у Вас за манеры? Боишься - не боишься, принимаешь участие - не принимаешь, оспоришь - не оспоришь.

Период юношеского максимализма у меня остался позади. А у Вас?

Обычно в споре можно долго кидаться какашками друг в друга, и все будет без толку. А можно аргументированно доказывать свою точку зрения. Я вот как раз пытаюсь все свести к аргументам, а не эмоциям.

Потому и присутствуют, что имеют свою логику - выделение фрагмента документа. Могут быть использованы для формирования и форматирования структуры html-документа.

Они там присутствуют для того, чтобы создавать собственные структуры, которых нет в HTML. Это универсальные теги, которые намеренно лишены какого-либо дефолтного форматирования либо ограничений по наследованию (в рамках стандартных правил), логика которых перенесена на ID и CLASS атрибуты. Теперь самый главный вопрос, почему "правильно" создавать списки при помощи UL, LI, DL, и "неправильно" - при помощи DIV + ID + CLASS?

Это ведь ваши слова:

Используя известный принцип "разделения содержания и представления" можно получить еще больше преимуществ, ведь сделано главное - создана логически верная (следовательно простая и понятная во всех отношениях) разметка.

Почему идентификация элементов по классам и id - это сложно и непонятно, мало того, логически неверно?

Табы - это не свойственная для HTML структура. Как раз более логично и понятно сделать при помощи DIV.

Могу даже подтолкнуть штрихами навскидку, чтоб начать...

А мне еще было бы интересно узнать, почему я "на каждом шагу спотыкаюсь" о конструкции try?

Внимательно надо читать ветку

Я уже писал причину, по которой я теперь пишу почти везде try-catch

Повторю, что для клиентов очень плохо показывать какие-либо сообщения об ошибках. Это формирует негативное отношение к продукту. И проще все свести к банальному "не работает", чем читать потом километровые письма ругательного характера.

Неинтересно же это вс?, поиск лучшего решения всегда тянется за горизонт, иначе бы мы так и топтались на месте, называть стремление к идеалу абсурдом э... абсурдно.

Я называю абсурдным построение сферических коней в вакууме. Можно взять прекрасную идею, довести ее до абсурда стремлением к идеалу, а потом выкинуть ее на помойку.

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

О, вот это уже больше похоже на нормальную критику.

Это решение принято немного по другим правилам. Да, отсекаются теги, в которых не может быть ссылки чайлдом. Это легко достигается примитивным облачением в DIV. Зато нет усложнения скриптовой части, дополнительных идентификаторов непосредственно для контейнера. Как видите, в передаваемых параметрах имя класса контейнера контента таба не присутствует.

для чего переменной activeTab присвоено значение switchNodesList[ 0 ],

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

для чего работает конструкция if ( !node.options ) {...},

При нажатии на ссылку, внутри которой есть какие-то другие теги, таргетом эвента не обязательно будет выступать нода A. Но свойства нам надо получить именно ноды A, это и есть поиск этой ноды, если вдруг не оказалось нужного свойства у таргета. Если есть более красивое решение - с удовольствием выслушаю.

зачем ноды-табы отсекаются по классу и собираются в массив дважды при инициализации

Не вижу особых проблем с этим. Ниже поясню почему.

зачем собирать этот массив заново при каждом клике, когда можно сохранять данные о предыдущем состоянии,

Потому что не факт, что через определенное время состояние табов сохранится именно в том виде, в котором оно было на момент инициализации.

Как я уже говорил, очень часто получается так, что над одним и тем же контентом работают несколько скриптов одновременно. У меня были варианты, когда несколько табов кочевали между несколькими разными таб-блоками. Чтобы следить за актуальностью данных потребуется написать еще один таб-контроллер, который будет следить за тем, чтобы во всех сохраненных состояниях действительно был нужный результат. HTML-код таба уже является достаточной структурой, зачем параллельно хранить данные об этой же структуре, но уже в JS?

для чего вместо вызова уже готовых функций вы затеяли dispatchEvent и fireEvent?

Как я уже говорил, переключателем состояния есть не функция, а нода. Нода хранит в себе все нужные параметры.

Обычная логика такова - "Есть какая-то JS структура данных, эта структура генерирует специфический HTML".

Ущербность данного варианта именно в том, что HTML получается или статическим, или с минимальными возможностями по трансформации HTML контента.

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

Допустим, у вас есть компонент генерации таблицы с данными из JS массива. Вам нужно добавить еще сортировку колонок. Обычно сортировку делают так. Сначала сортируют JS массив, потом перегенерируют в худшем случае или перемещают ноды в лучшем случае. Как только нужно будет переместить часть данных из одной динамической таблицы в другую, запускается механизм перемещения JS-данных, потом перемещения HTML-нод. А теперь вопрос, а не проще ли данные о каждой строке хранить непосредственно в TR? Перемещение нод будет сразу равняться перемещению данных. Если нужен будет массив - его можно получить из массива нод.

Преимущество метода заметно при одновременной работе нескольких компонент над одним и тем-же HTML кодом.

Надеюсь я ответил на вопросы.

Поэтому большая часть моих вопросов осталась без ответа.

Я не отвечаю на эмоции, тем самым еще больше раздувая флейм. Так что, будете отвечать? Или боитесь?

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

Да без проблем. Если это кому-то поможет, то почему бы и да? Можно даже документацию по использованию написать.

Вы немного путаете мелкие поделки, по типу e107, и более серьезные продукты, цена которых начинается с пятизначных цифр. Так вот, на рынке взрослых программных решений пишутся под требования заказчиков.

Речь шла про требования по функционалу, а не про требования к платформе.

В больших продуктах на это смотрят в последнюю очередь.

И оспорить вы это не сможете.

Типичное мышление мелкой розницы. Это будет играть роль на продуктах, стоимость которых невелика.

Опять же - решение мелкого и среднего бизнеса. В крупных структурах критерии оценок другие.

А тут что не нравится?

Ребят, кто-нибудь просил?

Это нужно для того, чтобы было понятно, на задачами каких уровней сложности мне приходилось работать. Именно поэтому я и говорил, что опыт очень серьезно разнится, а следовательно разнится и код и подход к коду. Я не заявлял, что нужно обязательно делать как я, так как это единственно правильный вариант и без права на обжалование. Одно из моих правил - не стоит доводить дело до абсурда. Это обычно приносит плохие плоды.

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

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

Grouping elements: the DIV and SPAN elements (это для самостоятельного ознакомления, надеюсь справитесь).

Я не просил вас отсылать меня на спецификацию. Я спросил, почему теги DIV и SPAN присутствуют в HTML, хотя они не несут выраженной логики работы, т.е. универсальны по сути? Вы сами можете ответить, свои мысли, а не прикрываться спецификацией?

Я просто повторил то что было написано где то в начале этого топика. Не забывайте, что это всего лишь скрипты. Набор скриптов. Все таки скриптов, а не чего то иного. И продукт который ориентирован на узкий сигмент рынка и не будет иметь большого комерческого успеха.

Вы немного путаете мелкие поделки, по типу e107, и более серьезные продукты, цена которых начинается с пятизначных цифр. Так вот, на рынке взрослых программных решений пишутся под требования заказчиков. Там успех уже гарантирован, так как

1. Конкуренция как правило небольшая

2. Заказчики выбирают функциональность продукта в первую очередь, а под него потом строят платформу. Но не наоборот.

И, как вам уже говорили раньше, тестирование на многих платформах может скушать приличную часть вашего бюджета, а экономического эффекта от этого будет ноль. Или даже минус.

Но нужно учитывать так же, что ваш продукт может быть отвергнуть банально из-за того что он не будет работать именно в такой, пускай и редкой, кофигурации. Качественная верстка отличается от не качетственной имено тем, что в качественной страница выглядит одинаково во всех броузерах, включая Оперу, Осликов 6, 7, Лису, Сафари 3,02 бета под виндой и сафари 2,*** под маком.

В больших продуктах на это смотрят в последнюю очередь. Главное - функционал продукта.

Тестирование продукта под все эти браузеры займет 80% разработки. Вы быстрее обанкротитесь.

Можете мне поверить добиться сего сложно, но вполне реально. Зато потом этот продукт смогут использовать подавляющее большенство клиентов и все будут довольны и репутация данной работы и ее создателя будет в разы выше из-за банального учета того самого мелкого сигмента клиентов. Просто сам факт, что вы об этом подумали будет вам самой честной и действенной рекламой. Ведь лучшая реклама продукта, когда его хвалят клиенты.

Типичное мышление мелкой розницы. Это будет играть роль на продуктах, стоимость которых невелика. Лучшая реклама продукта - его функциональность.

На счет закупки программного продукта. Вы знаете как его закупают в офисные структуры???? Скажу проще. Что понравится админу или тех директору то и купят. Начальнику важна только цена и то при должной рекламе от тех отдела можно продвинуть любой продукт. Пока что единицы структур которые покупают, перед этим обдумав это большой группой людей.

Опять же - решение мелкого и среднего бизнеса. В крупных структурах критерии оценок другие. Обычная практика - просят на тестирование продукт, чтобы определить удобство и качество работы, а также потенциальные грабли. Никто не покупает наобум продукты, стоимость которых исчисляется от 5 знаков.

Все это в двух словах будет выглядеть, как: "предлагаю проигнорировать остальные теги (все, кроме пяти)".

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

Я не призывают не использовать другие теги. Я говорю про то, что эти теги мало востребованы. Разницу чувствуете? Нет?

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

Ответьте на вопрос, что делают среди логически и функционально обоснованных тегов такие универсалы как DIV и SPAN? Ведь это теги бесполезны с точки зрения "правильной" логической разметки.

Кстати пример относительно фотошопа по меньшей мере просто абсурден. Речь идет о скрипте а не о программном продукте с уникальными функциями. Если клиенту поставить условия чего он должен а чего не должен использовать с продуктом, он скорее всего найдет другой продукт и заплатит за него больше, лишь за то чтоб он мог работать с ним в линуксе под каким нибудь эмулированным IE6 (жестокая вещь в плане понимания скриптов).

Речь идет о наборе скриптов, которые складываются в готовый продукт.

Клиенту не ставят условия. Это не тот вариант.

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

Скажите, Вас беспокоит то, как будет отображаться страница при отсутствии стилей, при отключенных скриптах?

На это в серьезных продуктах вообще никто не обращает внимание. В документации указано, что это, это, это и это должно быть включено. Нет - сами себе злобные Буратины.

Учитываете ли Вы, что может возникнуть необходимость конвертации в другой формат? Ну и наконец, достаточно ли Вам тегов DIV, SPAN, A, TABLE, IMG, поскольку остальные s0rr0w предложил игнорировать?

Не надо только перевирать мои слова. :mad: Найдите мне ссылку, в которой я говорил, что остальные теги надо именно игнорировать.

Если смысл предложения или целого абзаца непонятен, то советую перечитывать его до полного понимания.

Вот оно - стопроцентное решение. Вот она - командная работа. Вот она - единственно верная идея. Наконец-то можно с этим покончить, сделав соответствующие выводы.

Эх, молодо-зелено у вас в этом плане. Придя в одну неплохую команду, первую задачу, что передо мной поставили, было прочтение документации для разработчика. Меня там мало чего касалось, но все же было. В теории - нужно писать так, чтоб комар носа не подточил. Но это можно писать вечно. А можно упростить себе задачу, сузив многообразие влияющих факторов, и заработать деньги уже сегодня, а не послезавтра, после-послезавтра или через несколько десятков лет.

Я бы ответил так - Вам лучше вообще не писать js-код, раз уж в вашем распоряжении есть лишь информация 96-го года.

Моя информация - это всего лишь частный случай. Код работает и без этого.

В этой теме все бесполезное (я написал это еще в самом начале).

Код показывает мышление. Кто какими категориями оперирует.

У программиста есть четыре технологии, которыми он оперирует в разработке: HTML, CSS, DOM, JS. Большинство строит "однонаправленные" по логике скрипты

JS -> DOM ->HTML -> CSS (На JS скриптах строим при помощи DOM структуры для HTML, накладываем поверх CSS )

Я мыслил такими категориями года 4 назад. Крайне ущербная логика работы. Чтобы дать хоть какую-то гибкость HTML-кода, приходится очень сильно усложнять JS-код. Намного проще применять HTML-темплейтирование, когда все необходимые строительные материалы для будущей компоненты уже есть в HTML-е и CSS-е. Остается только собрать все в кучу. Мало того, ноды могут выступать контейнерами для данных, могут выступать логическими элементами в системе, нести индикативную и прочие фукнции. Перемещение нод по дереву - естественный процесс в интерфейсе. Так как нода может собой представлять самодостаточный объект в системе, то ее перемещение не вызовет проблем с фукнциональностью системы в целом.

Опять же, вернемся к эмуляции онклика на закладке таба. Ортодоксы считают, что за активацию таба должна отвечать специальная фукнция, которая должна принимать... а что она должна принимать? ID таба? Номер?

Рассмотрим первый вариант - ID ноды. Все хорошо, идея хороша, но придется городить для всего интерфейса генератор уникальных ID. Потому что табуляторов может быть не один, и не два.

Рассмотрим второй вариант - номер. Самое дурацкое решение. Опять же потому, что может возникнуть ситуация смешения нескольких разных табов их разных концов дерева HTML. Допустим, компонент состоит из уже имеющихся табов двух различных табуляторов. Номера могут совпадать, система не будет работать.

Теперь смотрим на мой вариант - есть список переключалок. Переключалка всегда знает, какую ноду она переключает, так как она была там прописана до переноса. Тот же селект работает не с ID, не с номерами, а непосредственно с нодами. Если будет перенесен какой-то таб к уже имеющемуся списку, достаточно будет отправить список нод в уже имеющуюся функцию.

Переключателем таба является не функция, а нода. Так как нода имеет достаточно данных про самоидентификацию, то она выполнит задачу переключения, запустив нужную фукнцию. Какую именно - это опять же знает только нода.

Итог, немного изменив обычный ход мыслей, получаем куда более гибкую систему в целом.

А getElementsByClassName не обновляли еще? Что, подчиненные еще не успели договориться?

А зачем мне это исправлять? Еще никто не доказал, что мой код не будет работать на новых версиях браузера. Если кому-то надо, он поправит это сам так, как ему захочется.

Пропустил ваш ответ без внимания. Исправляю ситуацию.

Q: DT, DD нельзя использовать без DL. Последствия переноса части кода в другую ветку дерева может привести к потенциальному багу с отображением.

A: Используйте методы DOM для создания, клонирования, вставки необходимых элементов.

Отлично, и сколько мне дополнительного JS-кода придется написать, чтобы провести примитивную модификацию HTML-кода? Гениальное решение. Все люди стараются переходить на темплейт-системы, а вы предлагаете генерировать HTML при помощи DOM-методов. В итоге получится миллион строк бесполезного кода.

Q: Ссылки создаются скриптом. Что делать, если понадобится уникальные коды для каждой закладки, где не только CSS будет изменен, но и отличаться HTML?

A: Перечень допустимых дочерних элементов для :

#PCDATA | TT | I | B | BIG | SMALL | EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE | ABBR | ACRONYM | A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO | INPUT | SELECT | TEXTAREA | LABEL | BUTTON )* -( A )

Зачем мне перечень дочерних элементов? Я спрашивал про другое, как стилизировать отдельные табы, если закладка состоит всего из ОДНОГО элемента. Дописывать DOM-модификаторы? Бесполезный труд.

Q: Таблицу нельзя использовать после H, так как присваивается display: block.

A: ???.

Вы в курсе, что у таблиц свойство display = table?. И какие последствия присваивания тегу свойства display?

Q: Что делать, если надо будет между контентом табов и самим переключателем вставить еще какие-то теги?

A: Если нужно вставить, надо взять и вставить.

Ага, использовать JS-функции.

Вот и оцените теперь масштабируемость вашего кода. Мое решение в подметки не годится вашему. Вы ведь делаете очень качественный код.

Естественно, придется. Только такого js-программера уволят при первой возможности, раз html-кодеру приходится думать, как и что писать, чтобы потом js-программист сумел с этим справиться.

Ах, вот оно что... В разработке самый главный кодер... Ай молодца! Я бы выгнал обоих, если бы они не договаривались между собой, что нужно сделать, чтобы всем было хорошо, а не кому-то одному. Мало того, они должны согласовать свои действия с cgi-программером, чтобы они оба не наделали никому не нужных сферических коней в вакууме.

Вместо того' date=' чтобы подшлифовать одним микродвижением свой скрипт, вы дадите кодеру пояснения о нежелательности некоторых классов???[/quote']

Хотел бы увидеть от вас это "микродвижение". Выдадите код? Уже не первый раз прошу, но, что-то мешает вам.

Надо же, стоило разжевать до каши, и первый настоящий проблеск. Логично. Не забудьте написать очередное пояснение кодеру. Про то, будет ли отловлен корректный window спрашивать не буду...

Мдааа... Интересно, почему у меня никогда не возникает проблем с моим кодом? Странно.

Во-первых, это не опус, а самое примитивное обращение к собственной функции.

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

Во-вторых, эта тема конкретно про этот идентификатор зачиналась скорее как иллюстративная ("кое-что из жизни бактерий"), если бы вы не превратили е? в разборку "а покажи, а докажи".

Потому что меня очень мало интересуют теоретические выкладки и борьба с ветряными мельницами. Все приведенные примеры не являются проблемой ( за исключением бага с do-while).

В-третьих, показываю одного из тех, кто вызывает функции с помощью инлайн-обработчиков и совершенно ничего не знает об их особенностях - это s0rr0w.

Обалдеть, оказывается что это особенность обработчиков. А раньше их называли откровенно бажными...

Было - "никаких граблей не вижу!", стало - "подумаешь, грабли!".

Опять двадцать пять. Грабли существуют в вашей теории. На практике на них наступают от силы пол процента людей. Серьезные грабли.

Так' date=' кажется я пользовался старыми данными по JS-интерпретатору. Цикл в современных браузерах уже работает на уровне do-while и while. Можно смело переписывать код.[/quote']

Беда. Я вам про то, что скорость тут вообще не при делах, а вы опять про скорость. Не в этом же дело, ну, что, по-вашему do-while реализован на уровне движков сильно отлично от while?

Ну, не работает скрипт у тех, кто соответствующим образом модифицирует юзерагент,

А что есть "соответствующий образ"? А кто сказал что он не работает?

Заметьте, он прекрасно справляется с задачей отделить IE от FF.

ну, нельзя использовать валидные имена классов

Читайте пояснение выше. Вы даете слишком много свободы разработчику. Наверное поэтому у вас вечно с чем-то грабли случаются.

, ну, используется do-while, улетающий в вечный луп при нулевом индексе,

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

ну, подвешены в воздухе конфликтные имена для IE,

Мда. Снова попытка доказать мне, что я не прав, но как всегда без реальных доказательств.

ну, размазан код в html,

Типа нельзя или плохо? Докажите сначала, что это реально плохо. Уже не первый раз слышу одно и то же, но доказательств пока что пшик. Предоставьте правильный механизм, а я уж посмотрю, насколько он эффективен.

ну, логика полудохлая...

Что не понимаю, то не принимаю... Расскажите как мне, как бы вы сделали, а лучше сделайте. И я расскажу вам, почему ваша логика - трэш.

Но, как я вижу, вы больше теоретических дел мастер.

незачем ввязываться в соревнование, если организм не справляется с болезненной реакцией на негативные оценки.

Пока что я вынес всего один правильный урок из данного "соревнования". Это про скорость циклов, мои данные серьезно устарели с Mozilla 0.8.3, и все же надо проверять полученную информацию из других источников. Остальное меня только успокаивает. Меньше конкурентов.

Являются синтаксическими ошибками? Эффектный финал. LOL

Признаю, неправ. Не проверял данную информацию с 96-го года.

А я Вам толкую о том, что прежде чем указывать, хорошенько подумайте - соответствуете ли Вы или ваш конечный результат работы этим требованиям.

Куда больше, чем ваш. Но не на все 100%, я это признаю, так как не стал еще более усложнять ( но это позволило бы лучше масштабировать ) код.

Простой пример. Вам сказано, что ваша методика работы с именами стилевых классов ошибочна. Вы пишите, что это не проблема и решается на уровне документации. И после этого Вы еще называете себя "командным игроком"?

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

Получается так - мне, как кодеру из вашей команды, мало знать стандартные правила о допустимых символах в именах классов. Перед началом своей работы (для того, чтобы впоследствии ваш сценарий работал без ошибок) мне придется обратиться еще и к вашей "псевдо-документации" и поискать в ней ответ на вопрос: "А какие символы мне разрешает использовать s0rr0w?".

Поверьте, вам придется по-любому их читать, эти правила. Их не так много, но они есть. Подумайте головой, что будет, если каждый будет делать так, как ему хочется, а не как того требует командная разработка? Один будет именовать классы вот так "x1", "vr13", другой "sBb", "bFb", третий "SuperReshenie", "MegaKomponent", а четвертый "ya_lyublyu_css", "obozhayu-ie". Это прямая дорога в банкроты той компании, в которой будут так работать такие разработчики.

При этом, найдя "запрещенные символы", я получу пояснения, что, видите ли, s0rr0w не пожелал особо вникнуть в этот вопрос, поэтому и появились эти ограничения.

Нормальная "командная работенка".

Это нормально. Особенно в больших коллективах. Если так было сделано, значит на то были причины.

А Вы задумываетесь о повторном использовании кода и т.д.?

Всегда.

А теперь подумайте о том, что произойдет после изменений в вашем html-коде если в вашу getElementsByClassName вдруг (как Вы сами писали: "вдруг") будет передан элемент, у которого длина коллекции дочерних элементов будет равна 0?

Я уже написал, что я признаю данный баг, не предусмотрел. Исправить его, чтобы не было больше вопросов? Или еще будут какие вопросы?

http://prototypejs.org/

вот вам ответ

1. стандарт организации документов (стандарты)

2. вы про cms слышали в частности про (e107)? Там это реализовано вполне удобно и есть возможность изменения скриптов подключения скриптов, удаления скриптов, при этом система работает

3. тажа cms e107 там библиотека с функциями js очень понятна, но функциональна.

4. тоже самое что и выше

5. тоже самое

6. тоже самое

там как раз совмещение нового и архаического. Но она тоже не безгрешна.

1. Отчасти.

2. Не только слышал, но смотрел функциональность. Сейчас специально скачал исходники. Но я имел в виду не подключение php-скриптов, а куски HTML, JS, кода. Внутри e107 сплошная архаика и прибивание гвоздиками.

3. Понятна и функциональна сугубо в рамках e107.

4. Не нашел.

Дальше нет смысла смотреть и разбираться. e107 как раз пример того, как не надо делать. Да. есть правильные идеи, но не более того.

Так что тут скорее спор новой реформаторской школы и консервативно-практичного подхода. Оба хороши по своему и оба плохи по своему. А задача программиста найти ту самую золотую середину и решить для себя каким путем идти ему.

Исли рассматривать сложные интерфейсы, то я вам приведу ряд факторов, которые влияют на ваш код.

1. Любой код (HTML, JS, CSS) должен быть собран в едином логическом месте. Это значит, что для редактировании кода не потребуется править десятки файлов.

2. Код должен быть написан таким образом, что добавление или убирание кода или куска кода (больше касается HTML) не должно влиять на работоспособность всей системы.

3. Код должен быть как можно более простым, чтобы упростить понимание другими разработчиками принципов работы.

4. По умолчанию брать вариант, когда любой код не статичен, количество данных и их структура не константа, все может быть упрощено или усложнено, но это не должно влиять на работоспособность системы в целом.

5. С одним и тем же кодом может работать не один компонент.

6. Каждый компонент должен иметь API по взаимодействию с другими компонентами.

Вот и найдите для этого золотую середину.