s0rr0w

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

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

- разобрались с особенностями метасимвола 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 при тотальном отсутствии проверок и контроля за скриптом - признак непрофессионализма; И в какой это книжке написано? Там не ваше авторство случайно? Вы слишком узко мыслите.

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

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

Я уже говорил, что некоторые вещи нужно принести в жертву, чтобы выиграть в другом месте. Насколько масштабируемый ваш скрипт мы уже все в курсе. Честно говоря, этот кусок кода вообще не проверял. На таком коде смысла нет. А кто вам сказал, что структура табулятора нельзя сделать например вот такой Tab 1Таргетом будет A, а options привязано к DIV. А кто сказал что обработчик будет только один? И табы будут только одни на странице. И не будет никаких скриптов, которые тоже могут работать с данным HTML? Я ждал этого вопроса. Покажите мне интерфейс, в котором огромное число данных выводится без постраничного вывода. Просто вы - ортодокс.

http://www.w3schools.com/js/js_try_catch.asp Вот тут народ считает аналогично тому, как это считаю я. Выводить JS ошибки пользователю - плохо. Есть еще пару ресурсов, в которых говорится, что в идеале неплохо было бы использовать try-catch во всем проекте. Верная мысль, что никогда не знаешь, с какой именно ошибкой можешь столкнуться при работе скриптов. Все варианты предусмотреть нереально. Да и не нужно. Это тратит совершенно неокупаемое время на разработку. При росте сложности кода растут вероятности возникновения ошибок. Некоторые ошибки тяжело предугадать. Над большим кодом обычно работает не один человек, а в команде высоки шансы возникновения ошибок. Так что можно сколько угодно считать мои слова отмазкой, я не против. Время нас рассудит.

Это поведение всех блоков без исключения. Блок всегда начинается с "новой строки". Я немного уточню, что имелось в виду под форматированием - отступы, бордюры, шрифты, размеры, все. что может повлиять на визуальное отображение. Конечно же DIV имеет предустановленное свойство display: block. Список DL предназначен для вывода списков определений. Табы ну никак не тянут на список определений. Заглавие таба не является термином. А контент - не является описанием определения. Хотя не отрицаю, данная структура вполне схожа со структурой табов. Но является ли правильным искажать предназначение тега, только потому, что его структура может подходить под определенную задачу? Так в чем же логическая "верность"? Все-же по стандарту HTML логически правильно сделать структуру, которая не предусмотрена в HTML при помощи именно DIV'ов или SPAN'ов. Я не настаиваю. Я говорю, что на практике все многообразие тегов обычно не востребовано. Это я пояснять в который раз уже не буду. Если в практике такого не было, то пояснить о том, почему это плохо или хорошо - бесполезная работа.

Не надо перевирать мои слова. Безбаговых программ не существует. Если писать детские скрипты на пару строчек кода, то шанс напороться на серьезный баг - ничтожен. Вам присылали хоть раз гневные письма по поводу какого-либо "не работает!"? А лишали ли вас премии за JS-ошибки? У меня два плюса напротив каждого вопроса. Вспомните свое отношение к windows, когда вываливалась какая-либо ошибка.

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

А мне еще было бы интересно узнать, почему я "на каждом шагу спотыкаюсь" о конструкции try? Внимательно надо читать ветку Я уже писал причину, по которой я теперь пишу почти везде try-catch Повторю, что для клиентов очень плохо показывать какие-либо сообщения об ошибках. Это формирует негативное отношение к продукту. И проще все свести к банальному "не работает", чем читать потом километровые письма ругательного характера.

Я называю абсурдным построение сферических коней в вакууме. Можно взять прекрасную идею, довести ее до абсурда стремлением к идеалу, а потом выкинуть ее на помойку. О, вот это уже больше похоже на нормальную критику. Это решение принято немного по другим правилам. Да, отсекаются теги, в которых не может быть ссылки чайлдом. Это легко достигается примитивным облачением в DIV. Зато нет усложнения скриптовой части, дополнительных идентификаторов непосредственно для контейнера. Как видите, в передаваемых параметрах имя класса контейнера контента таба не присутствует. Нужно же сделать какой-то таб активным, если не был указан параметр. В данном случае оставлен последний. Надо будет сделать первый - могу исправить код. При нажатии на ссылку, внутри которой есть какие-то другие теги, таргетом эвента не обязательно будет выступать нода A. Но свойства нам надо получить именно ноды A, это и есть поиск этой ноды, если вдруг не оказалось нужного свойства у таргета. Если есть более красивое решение - с удовольствием выслушаю. Не вижу особых проблем с этим. Ниже поясню почему. Потому что не факт, что через определенное время состояние табов сохранится именно в том виде, в котором оно было на момент инициализации. Как я уже говорил, очень часто получается так, что над одним и тем же контентом работают несколько скриптов одновременно. У меня были варианты, когда несколько табов кочевали между несколькими разными таб-блоками. Чтобы следить за актуальностью данных потребуется написать еще один таб-контроллер, который будет следить за тем, чтобы во всех сохраненных состояниях действительно был нужный результат. HTML-код таба уже является достаточной структурой, зачем параллельно хранить данные об этой же структуре, но уже в JS? Как я уже говорил, переключателем состояния есть не функция, а нода. Нода хранит в себе все нужные параметры. Обычная логика такова - "Есть какая-то JS структура данных, эта структура генерирует специфический HTML". Ущербность данного варианта именно в том, что HTML получается или статическим, или с минимальными возможностями по трансформации HTML контента. Например, нужно внести изменения в таб. Это надо изменить данные, запустить функции по изменению HTML-я, вызвать все функции других модулей, чтобы произвести изменения. Если HTML будет как раз и хранилищем, и форматированием данных, то сокращается количество взаимодействий компонент. Допустим, у вас есть компонент генерации таблицы с данными из JS массива. Вам нужно добавить еще сортировку колонок. Обычно сортировку делают так. Сначала сортируют JS массив, потом перегенерируют в худшем случае или перемещают ноды в лучшем случае. Как только нужно будет переместить часть данных из одной динамической таблицы в другую, запускается механизм перемещения JS-данных, потом перемещения HTML-нод. А теперь вопрос, а не проще ли данные о каждой строке хранить непосредственно в TR? Перемещение нод будет сразу равняться перемещению данных. Если нужен будет массив - его можно получить из массива нод. Преимущество метода заметно при одновременной работе нескольких компонент над одним и тем-же HTML кодом. Надеюсь я ответил на вопросы.

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

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

Вы немного путаете мелкие поделки, по типу e107, и более серьезные продукты, цена которых начинается с пятизначных цифр. Так вот, на рынке взрослых программных решений пишутся под требования заказчиков. Там успех уже гарантирован, так как 1. Конкуренция как правило небольшая 2. Заказчики выбирают функциональность продукта в первую очередь, а под него потом строят платформу. Но не наоборот. И, как вам уже говорили раньше, тестирование на многих платформах может скушать приличную часть вашего бюджета, а экономического эффекта от этого будет ноль. Или даже минус. В больших продуктах на это смотрят в последнюю очередь. Главное - функционал продукта. Тестирование продукта под все эти браузеры займет 80% разработки. Вы быстрее обанкротитесь. Типичное мышление мелкой розницы. Это будет играть роль на продуктах, стоимость которых невелика. Лучшая реклама продукта - его функциональность. Опять же - решение мелкого и среднего бизнеса. В крупных структурах критерии оценок другие. Обычная практика - просят на тестирование продукт, чтобы определить удобство и качество работы, а также потенциальные грабли. Никто не покупает наобум продукты, стоимость которых исчисляется от 5 знаков.

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

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

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

Эх, молодо-зелено у вас в этом плане. Придя в одну неплохую команду, первую задачу, что передо мной поставили, было прочтение документации для разработчика. Меня там мало чего касалось, но все же было. В теории - нужно писать так, чтоб комар носа не подточил. Но это можно писать вечно. А можно упростить себе задачу, сузив многообразие влияющих факторов, и заработать деньги уже сегодня, а не послезавтра, после-послезавтра или через несколько десятков лет. Моя информация - это всего лишь частный случай. Код работает и без этого. Код показывает мышление. Кто какими категориями оперирует. У программиста есть четыре технологии, которыми он оперирует в разработке: HTML, CSS, DOM, JS. Большинство строит "однонаправленные" по логике скрипты JS -> DOM ->HTML -> CSS (На JS скриптах строим при помощи DOM структуры для HTML, накладываем поверх CSS ) Я мыслил такими категориями года 4 назад. Крайне ущербная логика работы. Чтобы дать хоть какую-то гибкость HTML-кода, приходится очень сильно усложнять JS-код. Намного проще применять HTML-темплейтирование, когда все необходимые строительные материалы для будущей компоненты уже есть в HTML-е и CSS-е. Остается только собрать все в кучу. Мало того, ноды могут выступать контейнерами для данных, могут выступать логическими элементами в системе, нести индикативную и прочие фукнции. Перемещение нод по дереву - естественный процесс в интерфейсе. Так как нода может собой представлять самодостаточный объект в системе, то ее перемещение не вызовет проблем с фукнциональностью системы в целом. Опять же, вернемся к эмуляции онклика на закладке таба. Ортодоксы считают, что за активацию таба должна отвечать специальная фукнция, которая должна принимать... а что она должна принимать? ID таба? Номер? Рассмотрим первый вариант - ID ноды. Все хорошо, идея хороша, но придется городить для всего интерфейса генератор уникальных ID. Потому что табуляторов может быть не один, и не два. Рассмотрим второй вариант - номер. Самое дурацкое решение. Опять же потому, что может возникнуть ситуация смешения нескольких разных табов их разных концов дерева HTML. Допустим, компонент состоит из уже имеющихся табов двух различных табуляторов. Номера могут совпадать, система не будет работать. Теперь смотрим на мой вариант - есть список переключалок. Переключалка всегда знает, какую ноду она переключает, так как она была там прописана до переноса. Тот же селект работает не с ID, не с номерами, а непосредственно с нодами. Если будет перенесен какой-то таб к уже имеющемуся списку, достаточно будет отправить список нод в уже имеющуюся функцию. Переключателем таба является не функция, а нода. Так как нода имеет достаточно данных про самоидентификацию, то она выполнит задачу переключения, запустив нужную фукнцию. Какую именно - это опять же знает только нода. Итог, немного изменив обычный ход мыслей, получаем куда более гибкую систему в целом.

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

Пропустил ваш ответ без внимания. Исправляю ситуацию. Отлично, и сколько мне дополнительного JS-кода придется написать, чтобы провести примитивную модификацию HTML-кода? Гениальное решение. Все люди стараются переходить на темплейт-системы, а вы предлагаете генерировать HTML при помощи DOM-методов. В итоге получится миллион строк бесполезного кода. Зачем мне перечень дочерних элементов? Я спрашивал про другое, как стилизировать отдельные табы, если закладка состоит всего из ОДНОГО элемента. Дописывать DOM-модификаторы? Бесполезный труд. Вы в курсе, что у таблиц свойство display = table?. И какие последствия присваивания тегу свойства display? Ага, использовать JS-функции. Вот и оцените теперь масштабируемость вашего кода. Мое решение в подметки не годится вашему. Вы ведь делаете очень качественный код.

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

Мдааа... Интересно, почему у меня никогда не возникает проблем с моим кодом? Странно. Это притянутый за уши вариант. Приведите хоть один осмысленный код, который можно сделать при помощи данной функции непосредственно в inline-обработчике. Потому что меня очень мало интересуют теоретические выкладки и борьба с ветряными мельницами. Все приведенные примеры не являются проблемой ( за исключением бага с do-while). Обалдеть, оказывается что это особенность обработчиков. А раньше их называли откровенно бажными... Опять двадцать пять. Грабли существуют в вашей теории. На практике на них наступают от силы пол процента людей. Серьезные грабли. А что есть "соответствующий образ"? А кто сказал что он не работает? Заметьте, он прекрасно справляется с задачей отделить IE от FF. Читайте пояснение выше. Вы даете слишком много свободы разработчику. Наверное поэтому у вас вечно с чем-то грабли случаются. Повторение как мантры не приводит к нужному результату. Обновил код. Сейчас такого бага нет. Мда. Снова попытка доказать мне, что я не прав, но как всегда без реальных доказательств. Типа нельзя или плохо? Докажите сначала, что это реально плохо. Уже не первый раз слышу одно и то же, но доказательств пока что пшик. Предоставьте правильный механизм, а я уж посмотрю, насколько он эффективен. Что не понимаю, то не принимаю... Расскажите как мне, как бы вы сделали, а лучше сделайте. И я расскажу вам, почему ваша логика - трэш. Но, как я вижу, вы больше теоретических дел мастер. Пока что я вынес всего один правильный урок из данного "соревнования". Это про скорость циклов, мои данные серьезно устарели с Mozilla 0.8.3, и все же надо проверять полученную информацию из других источников. Остальное меня только успокаивает. Меньше конкурентов. Признаю, неправ. Не проверял данную информацию с 96-го года.

Куда больше, чем ваш. Но не на все 100%, я это признаю, так как не стал еще более усложнять ( но это позволило бы лучше масштабировать ) код. Она не ошибочна, она имеет ряд ограничений, а это разные вещи. Решение на уровне предпроектной документации имеет место во всех крупных проектах. Разработчики договариваются между собой, что и как они будут делать, а чего не делать. Это игра компромисов. Если программист не будет выполнять общие договоренности, то он сделает только себе хуже, ему придется переделывать свой код. Есть такая вещь как целесообразность. Делать что-то сверх того кода, что написан мной, считаю не целесообразным. Поверьте, вам придется по-любому их читать, эти правила. Их не так много, но они есть. Подумайте головой, что будет, если каждый будет делать так, как ему хочется, а не как того требует командная разработка? Один будет именовать классы вот так "x1", "vr13", другой "sBb", "bFb", третий "SuperReshenie", "MegaKomponent", а четвертый "ya_lyublyu_css", "obozhayu-ie". Это прямая дорога в банкроты той компании, в которой будут так работать такие разработчики. Это нормально. Особенно в больших коллективах. Если так было сделано, значит на то были причины. Всегда. Я уже написал, что я признаю данный баг, не предусмотрел. Исправить его, чтобы не было больше вопросов? Или еще будут какие вопросы?

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