Вариант навигации.

Dimitry Wolotko · October 19, 2007

Сейчас сижу с больной головой (болею), думаю над навигацией в админке тех сайтов, что я сейчас делаю (несколько сайтов, админка одна).

Поделился со знакомцем мыслями - он мне сразу кинул (http://www.artlebedev.ru/tools/technogrette/js/tabsheets/) - идея пришлась по вкусу, но код JS раздут - ужас просто, написал свой, посмотрите, мб я что - то из функционала пропустил?

PS - мо? чудо с помощью php вполне можно и динамическим сделать.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
 <title>Untitled</title>
 <style>
 .mon2 {color:black;}
 .mon2 {color:red;}
 </style>
</head>

<body>


<script type="text/javascript" language="JavaScript">
function so2( objName1, objName2, objName3 )
{
oObj1 = document.getElementById( objName1 );
oObj2 = document.getElementById( objName2 );
oObj3 = document.getElementById( objName3 );
oObj1c = document.getElementById( objName1 + "c" );
oObj2c = document.getElementById( objName2 + "c" );
oObj3c = document.getElementById( objName3 + "c" );
oObj1.style.display = "block";
oObj1c.className = "mon3";
oObj2.style.display = "none";
oObj2c.className = "mon2";
oObj3.style.display = "none";
oObj3c.className = "mon2";
}
</script>

<div>
<span class="mon3" id="date2c" onclick='so2( "date2", "date3", "date4" );'>Вкладка 1 |</span>
<span class="mon2" id="date3c" onclick='so2( "date3", "date4", "date2" );'>Вкладка 2 |</span>
<span class="mon2" id="date4c" onclick='so2( "date4", "date2", "date3" );'>Вкладка 3 |</span>
</div>
<div style="display: block;" id="date2">
Содержимое вкладки номер один:

<table border="1">
<tr>
<td>table data</td>
<td>table data</td>

<td>table data</td>
</tr>
<tr>
<td>table data</td>
<td>table data</td>
<td>table data</td>
</tr>
</table>
</div>
<div style="display: none;" id="date3">
Содержимое вкладки номер два:

Аниме убивает ваш мозг!

</div>
<div style="display: none;" id="date4">
Содержимое вкладки номер три:

<h1>труляля</h1>
<h2>труляля</h2>
<h3>труляля</h3>
<h4>труляля</h4>
<h5>труляля</h5>
<h6>труляля</h6>
</div>

</body>
</html>

s0rr0w · October 26, 2007

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

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

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

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

AKS · October 26, 2007

Вы сами можете ответить, свои мысли, а не прикрываться спецификацией?

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

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

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

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

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

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

Ого! Простите, какими судьбами среди нас, мелких рыбешек, затесался крупный бизнесмен?

И кто просил, чтобы BIG GUN нам рассказывал о чем-то, "стоимость чего исчисляется от 5 знаков".

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

s0rr0w · October 26, 2007

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

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

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

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

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

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

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

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

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

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

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

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

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

Zeroglif · October 27, 2007

s0rr0w,

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

Вы бы для пользы дела взяли бы и разложили по полочкам логику своего скрипта, доказали бы свою правоту построчно, почему вы поступили в этом месте именно так, а не иначе. Могу даже подтолкнуть штрихами навскидку, чтоб начать - насколько масштабируемым является решение, когда нода-таб увязана с нодой-контентом своим первоначальным расположением, для чего переменной activeTab присвоено значение switchNodesList[ 0 ], для чего работает конструкция if ( !node.options ) {...}, зачем ноды-табы отсекаются по классу и собираются в массив дважды при инициализации, зачем собирать этот массив заново при каждом клике, когда можно сохранять данные о предыдущем состоянии, для чего вместо вызова уже готовых функций вы затеяли dispatchEvent и fireEvent?

AKS · October 27, 2007

Одно из моих правил - не стоит доводить дело до абсурда. Это обычно приносит плохие плоды.

Как раз несоблюдение этого правила "принесло плод" - эту тему.

Так что, будете отвечать? Или боитесь?

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

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

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

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

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

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

Хотите, чтобы Вас чтили, как "птицу высокого полета" - начните "сорить" wmz-шками.

AKS · October 27, 2007

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

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

s0rr0w · October 27, 2007

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

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

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

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

Это решение принято немного по другим правилам. Да, отсекаются теги, в которых не может быть ссылки чайлдом. Это легко достигается примитивным облачением в 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 кодом.

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

s0rr0w · October 27, 2007

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

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

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

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

AKS · October 27, 2007

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

Я уже вижу одно из правил из "J(ava)Script Cook Book" автора s0rr0w:

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

s0rr0w · October 27, 2007

Ну что у Вас за манеры? Боишься - не боишься, принимаешь участие - не принимаешь, оспоришь - не оспоришь.
Период юношеского максимализма у меня остался позади. А у Вас?

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

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

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

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

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

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

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

s0rr0w · October 27, 2007

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

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

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

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

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

AKS · October 27, 2007

теги, которые намеренно лишены какого-либо дефолтного форматирования.

Не совсем так:

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

Теперь самый главный вопрос, почему "правильно" создавать списки при помощи UL, LI, DL, и "неправильно" - при помощи DIV + ID + CLASS?

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

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

А это тут причем?

Как раз более логично и понятно сделать при помощи DIV.

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

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

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

s0rr0w · October 27, 2007

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

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

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

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

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

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

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

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

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

AKS · October 27, 2007

Я немного уточню, что имелось в виду под форматированием...

Так и будем без конца:

- Что насчет этого?

- А здесь вот так!

- Уточню, что я имел ввиду не совсем это...

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

? Остается и мне добавить .

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

Практика практике - рознь.

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

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

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

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

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

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

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

Zeroglif · October 27, 2007

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

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

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

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

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

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

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

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

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

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

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

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

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

s0rr0w · October 28, 2007

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

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

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

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

s0rr0w · October 28, 2007

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

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

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

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

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

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

Tab 1

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

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

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

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

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

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

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

Dimitry Wolotko · October 28, 2007

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

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

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

Zeroglif · October 29, 2007

s0rr0w,

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

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

Отсюда видно, что "таргет" от "не-таргета" вы не отличаете, не видите логику своей собственной конструкции - как всплывает событие, какой объект прид?т в нужную вам функцию, когда сработает обработчик, как это вс? вместе увязано. Потом видимо прозреваете ("ой, я же ссылку и передаю"), но признать ошибку ломает, и снова отмазка номер 88:

А кто вам сказал, что структура табулятора нельзя сделать например вот такой
Tab 1
Таргетом будет A, а options привязано к DIV.

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

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

Не один обработчик в ноде? Ну-ну. Скрипты, которые будут работать с одним единственным ж?стко прописанным инлайн-обработчиком? Радостно. Я уже чувствую, как скрипт участвует как минимум в сотворении мира, но детали реализации (пара сотен строк) для удобства опущены. Чтоб не отвлекали. Ну, хотя бы из (не)любви к теории, как иначе программно вызвать переключение табов?

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

Огромное не выводится, но достаточное, чтобы тормозить, выводится. Хранение кастомных данных в нодах не прибавит скорости любой сортировке, какой бы не был объ?м.

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

?

s0rr0w · October 29, 2007

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

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

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

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

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

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

s0rr0w · October 29, 2007

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

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

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

AKS · October 29, 2007

http://www.w3schools.com/js/js_try_catch.asp
Вот тут народ считает аналогично тому, как это считаю я.

А Вы ответьте сами себе - для какой аудитории пишет этот "народ"?

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

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

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

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

Как пример - поспешно внедряются новые версии javascript'а туда, где еще есть баги с допотопных версий.

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

Zeroglif · October 29, 2007

Бугага.

Бугага бугагой, а я резюмирую. В итоге всего этого разговора в стиле "моя твоя не понимай", вы вс?-таки:

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

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

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

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

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

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

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

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

- ... остальное уже не помню...

К сожалению, не удалось довести до вас то, что:

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

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

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

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

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

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

а также то, что:

- дьявол кроется в деталях;

- негоже нику бряцать опытом;

- логика должна быть логичной;

- не только s0rr0w - практик;

- не знать теорию - стыдно.

Удачи.

s0rr0w · October 29, 2007

- разобрались с особенностями метасимвола 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 при тотальном отсутствии проверок и контроля за скриптом - признак непрофессионализма;

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

s0rr0w · October 29, 2007

Более того, "народ" напрасно рассчитывал на Вас, что:
This chapter will teach you how to trap and handle JavaScript error messages...

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

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

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

Sign In

Вариант навигации.

Question

Link to comment

Share on other sites

Top Posters For This Question

Popular Days

Top Posters For This Question

Popular Days

154 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information