s0rr0w
-
Posts
5,139 -
Joined
-
Last visited
-
Days Won
32
Content Type
Profiles
Forums
Calendar
Store
Posts posted by s0rr0w
-
-
неужели без кода вам так сложно осо(при)знать проблему!? Через дефис в именах классов пишут на ура, это валидно, удобно (кому-то) и... просто существует в природе:
Проблему? Да нет проблемы, проблема снова же сугубо в вашем воображении. Я уже написал, что достаточно кодеру дать пояснения по поводу именования классов и не заморачиваться.
Да, кстати, а где ваш "супер-беспроблемный" код? Не надо меня отсылать куда-то там... Код, Штирлиц, код!
Теперь я думаю, вы сможете вс? это переварить, сделаете выводы и перестанете просить от меня решения, оно элементарное, ваша "библиотека" должна к нему прийти. Надеюсь, ответил, поехали дальше...Право же, не перестаете меня умилять.
Да, вызов getElementsByClassName непосредственно в inline-обработчике будет приводить к перекрытию вызова. Но никто не мешает написать window.getElementsByClassName. Да и покажите мне человека, который собирается писать javascript-опусы непосредственно в inline-обработчиках? Вызывая любую кастом-функцию внутри тела можно спокойно обращаться через getElementByClassName без указания window. Так я не понял, в чем проблема то? В перекрытии функций в очень специфических случаях? Так эта проблема есть всегда и с любым кодом.
Надеюсь и тут я ответил вполне конкретно...Да вполне. Так, кажется я пользовался старыми данными по JS-интерпретатору. Цикл в современных браузерах уже работает на уровне do-while и while. Можно смело переписывать код.
a) не увеличивать своим кодом общий объ?м мирового javascript-трэша;б) не считать себя командным результативным космокодером;
б) не лезть в спор без штанов.
а) зачем вам вообще познания в JS, если вы все равно пишете трэш-код?
б) после моего увольнения из одной команды разработчиков, на мое место до сих пор не могут найти человека.
я не считаю себя космо-кодером, но количество багов в моих кодах до сих пор минимально. В отличие от моих сокоммандников.в) это к вам относится в аналогичной мере.
-
Так вот я выполнял свою задачу - обработал предложенную мной структуру.
:cool:
Именно этого ответа я ждал. Итак, была предложена структура, структура обработана. Задача выполнена! А то, что это сферический конь в вакууме, никого не интересует.
Одно из самых простых требований к нормальному программисту - умение смотреть хотя бы на шаг вперед, а не механически выполнять задачу. Нет простых задач по определению. Вечно кроется какое-то западло в самом тривиальном месте. Именно поэтому для меня скрипт для табов куда сложнее задача, чем многим кажется.
-
AKS, прокомментируйте следующее, пожалуйста.
1. DT, DD нельзя использовать без DL. Последствия переноса части кода в другую ветку дерева может привести к потенциальному багу с отображением.
2. В вашем JS коде жестко закреплена структура. Что будет, если после H будет стоять что-то другое? Например еще один H. Вполне реальная ситуация.
3. Ссылки создаются скриптом. Что делать, если понадобится уникальные коды для каждой закладки, где не только CSS будет изменен, но и отличаться HTML?
4. Таблицу нельзя использовать после H, так как присваивается display: block.
5. Что делать, если надо будет между контентом табов и самим переключателем вставить еще какие-то теги?
6. Что будет, если контент таба будет удален или перемещен?
Ответьте на эти вопросы, только спокойно, рассудительно, без эмоций.
-
Посмотрел. Не сотрясайте воздух, отсылая меня на перечитку плиз.
Тогда мне непонятно, почему вам непонятно. Вот я и сомневался, что вы достаточно хорошо изучили принципы работы моего кода.
Про то, как отграничивать класс от класса (как и вообще слова) с помошью регулярных выражений вам нужно просто банально знать, обратитесь за примером к ближайшим к вам большим фреймворкам, если лень или недосуг изучать доки.Не надо меня отсылать куда-то там. Приведите код. Это добавит вам уважение как к человеку, который умеет доказать свои слова делом.
Правильный пример определения IE вам не нужен, опирайтесь на соответсвующие проверки нужного по месту свойства. Как минимум.Смысла в этом не вижу. Есть IE, который для меня существует всего в 2-х версиях, есть DOM-ориентированные браузеры. Зачем что-то придумывать, если можно спокойно ограничиться такой проверкой? Люди, которые сознательно идут на подмену юзерагента пусть также сознательно и сталкиваются со всеми вытекающими последствиями. Мало того, это редко распространенная практика в корпоративном секторе.
Скорость do-while разнится у браузеров, говорю ещ? раз, стараясь побороть ваше обобщение. Суть же дела не в скорости, а в бездумном использовании конструкции не к месту, как же вы упрямо не понимаете этого.Итак, я задал вопрос, какой самый быстрый цикл. В ответ я получаю про разницу в скорости. Использование конструкции как раз к месту, так как это самая быстрая конструкция. Да, немного неудобная, но зато выполняет возложенную на нее фукнцию.
Чтобы одновременно рассеять ваши заблуждения по поводу inline-обработчиков и т.н. интерфейса документа тупо приведу пример:И какие же заблуждения мои должны были рассеяться? Я скачаль альфу оперы, запустил код. Граблей не нашел вообще. Они находятся сугубо в вашем воображении. Моя функция является методом объекта window, встроенная - document'a. Где грабли? В том, что две фунции имеют одинаковое название? Это смешно. И в чем проблемы с inline-обработчиками, поясните мне темному, может я чего пропустил.
WingedFox, между нами девочками, ведь этот скрипт, который "наиболее практичное решение, идущее из опыта" - это же почти что трэш из девяностых, некачественный со всех сторон, безыдейный, с конкретными ошибками, неорганизованный, просто откровенно слабый по форме и содержанию... почему вы его защищаете для меня осталось загадкой.Ах, какие высокопарные слова. Если вы делаете по другому, то это не значит, что мой код не содержит идей.
Например, я использую обращение к элементам по имени классов. Это куда лучше обращения по ID. Я использую HTML темплейтирование, вместо создания нод при помощи createElement, и не видеть выгоду от этого считаю узостью мышления. Активация по эмуляции клика - тоже не считаю архаикой, а как раз наоборот. Да, я согласен, что на первый взгляд код кажется именно таковым, каким вы описали. Но не видел вашего супер-кода, а поэтому вообще сомневаюсь в ваших способностях. Говорить красивые слова каждый умеет
-
Dimitry Wolotko, я и не пытался даже.
-
Сейчас, кстати, проверил - в Opera уже есть этот метод.
Метод какого интерфейса? window?
-
Вс?-таки вы афишируете сво? решение на публичном форуме' date=' нужно предполагать и копипаст, и слабый анализ, а вы могли бы запросто обойтись без вычленения IE таким способом. Запросто. Не подавая другим плохой пример.[/quote']
Подайте хороший пример, напишите правильный код определения IE.
IE6 тоже старь?. IE7 в смысле BOM/DOM/Javascript почти такое же старь?. Много чего нового не держит, но нельзя же из принципа отказывать их пользователям в рабочем скрипте.Перечитайте то, что было написано мной про искусственное ограничения количества платформ. Речь идет не про сайты, а про бэк-энд системы.
Кстати, если говорить не о старье, а о потенциальном свежаке, то как насч?т занятого вами идентификатора getElementsByClassName, который в перспективе забивать не хотелось бы...Ничего не занято. В DOM будет использован в качестве интерфейса документ или нода. Но никак не window.
Не проще ли взять другой ограничитель, как это делает подавляющее большинство. Нет? Думаю, вы просто не держали этого в уме.Например? Давайте все познавать на примерах. Ваш вариант ограничителя?
Скорость циклов разнится от браузера к браузеру. Если уж это так важно, то while был бы достаточен, do предполагает разовое действие вне условий, что совершенно тут не к месту пришлось. Я не прав?Докажете, что do-while не самый быстрый, перепишу код на самый быстрый.
Поясните, конечно.Текущее положение ноды не является константой. Если привязывать данные к какому-то паренту, то при изменении структуры может быть потеряна связь. Или же наоборот, нужно принудительно терять связь у данной ноды с ее парентом. Как вариант - перемещение таба в другое место, в другой табулятор.
Тоже поясните, не заметил.Внимательно изучите код. Там уж более чем понятно все расписано.
Дописав класс, мы ж не удаляем прежний. Ищется как всегда, анализируя className, ничего необычного.А какой из них был дописан? Вы код смотрели? У меня там как раз для этого случая сделан пример
В рамках этого конкретного мира табов это константа, другое дело, что сам мир не инкапсулирован, все тяготы и лишения несут на своих плечах ноды.Это их карма
Смайлик погрустнел бы, зная вы сколько раз мне пришлось ответить по поводу этого бага.Суть изложите. В моей практике пока что не было серьезных проблем.
Бажность характеризуется наличием баговХоть один пример в студию.
нетривиальность малой распростран?нностью методов. Разве вы не можете вызвать нужную функцию переключения таба? Ни них же уже висят обработчики. Вот их и вызывайте.Чтобы вызвать функцию переключения таба, нужно будет передать все необходимые параметры, а эти параметры нужно будет привязать к опшинам. Не проще ли хранить параметры в одном месте? Вы код вообще изучали?
И я про это. Реальной проверки чего-либо нет, но есть для галочки, чтоб не пугались...Однажды меня лишили премии как раз за то, что выдавалась ошибка. Мне детально пояснили, почему я не прав. И я согласился с аргументами.
Скрипт привязан к точке, а не к событию, модификация HTML может смещать точку, нужно за эти следить и проч. отвлеч?нные предметы.Выполнение по онлоаду ничем не отличается от данного метода. Все равно запуск функций будет стековым с идентичными последствиями.
"Плохость" в том, что это слабо сочетается с такими важными словами, как "компонента", "отделение от содержания", "корректное взаимодействие обработчиков", "современный код" и т.д..Напишите метод сильного сочетания.
В любом случае за отдельный кусочек кода будет отвечать какой-то компонент. Чтобы привязаться к обработчику onclick данного компонента все равно придется выполнить передачу параметра. Нет разницы как это будет сделано, или же через идентификацию + листенер, или же прямой записью функции в тело onclick обработчика.
В общем смысле у inline-обработчиков масса малоизвестных неприятных особенностей, но они вполне себе работоспособны.Например?
Javascript вообще язык всепрощающий, можно писать допотопно, архаично, с запутанной логикой и прийти к нужному результату. В этом смысле опираться только на результат, как на критерий правильности не совсем верно, тем более на узком js-форуме, где нужно спорить идеями, логикой и качеством знаний.Давайте ваш пример кода, как модерновый, неархаичный, с чистой и прозрачной логикой и с великолепным результатом в конце. Или все так и будет на уровне светских бесед?
p.s. в принципе согласен про уровень абстракции, только на мой взгляд вы слишком расслабляете табы, им незачем так расслабляться, их роль и взаимодействие должны быть заранее определены и в какой-то степени зафиксированы...На практике все куда хуже. Табы требуют очень сильной абстракции, куда более высокой, чем в моем примере. Потому как вариантов реализации масса.
-
А писал я о том, что люди, отвергающие теорию в пользу своих "шишек", превратили веб в помойку.
Смелое заявление. Теория тем и хороша, что только теория. Практика требует куда больших уровней абстракций при работе с кодом. Что есть HTML? Всего лишь контейнер. Контейнер для данных. Количество тегов строго ограничено. А вот названия классов - нет. Именно поэтому абстракция кода на уровне классов - более масштабируемое решение по причинам отсутствия ограничивающих факторов. Это не помойка, это просто альтернативный вариант.
-
Мой оппонент изначально отверг вариант с использованием стандартной разметки и логики.
Ваш код как раз показывает, почему я ее отверг. Итак, стоит задача сделать табы разноцветными. Что нужно сделать в вашем коде? Написать новый обработчик. Нужно сделать табы в табах. Что надо сделать? Написать новый обработчик? Переписать код? Нужно усложнить HTML структуру закладки, как того требует дизайн. Что надо сделать в вашем коде? Снова написать новый обработчик. Через пару месяцев интеграции вашего кода в какой-либо интерфейс у вас будет десятка два абсолютно бесполезных обработчиков, разобраться в логике работы которых будет ой как сложно. Вот и получился выигрыш в одном месте, но это пиррова победа.
И не спешите, также как и s0rr0w, подчеркнуть свой статус. Я ни в его команду, ни в вашу не прошусь, следовательно не нужно писать, кого Вы выбираете, а кого нет. Еще раз говорю - здесь речь не об этом.Задели личное самолюбие? Ну извини тогда. На личности я переходить не люблю, поэтому пропускаю мимо ушей попытки втянуть в дискуссии такого характера.
-
Что мне не сильно нравится в коде -- отсутствие идеологии, я предпочитаю красивые решения.
Я сильно упростил решение в JS части, но в HTML - вполне себе нормальная идеология, построенная на идентификации функциональной принадлежности по классам. HTML продиктован сугубо минимизацией затрат на темплейтирование и создание более сложных вариаций и комбинаций.
-
Кроссбраузерность играет роль сугубо только для сайтов. Для корпоративных интранет и интернет систем - кроссбраузерность почти не играет роль. Попробуйте в государственный сектор продвинуть как стандарт FF.
Монополия приносит MS огромный успех.
И даже если есть хитрые, быстрые, умные, то это им мало помогает. FF как платформа в десятки раз лучше IE, но, увы, монополия делает "успех" IE. А это вообще зачем?
Показать разницу мышления при работе над конечной задачей. И, как результат, абсолютно разный код.
Основная задача, которая преследовалась, показать, что ради лучшей масштабируемости и простоты в работе над кодом можно пренебрегать логической разметкой HTML, перенеся логику на CSS-классы. Кстати, с удивлением обнаружил в коде MS POPFLY аналогичный моему подход.
-
sensor, а если прочитать задание, которое изначально ставилось, то о навигации сайтов никто и речи не вел. Речь веласть про навигацию в админке.
Наша дуэль служит хорошим примером. Авось из нее кто-нибудь вынесет чего интересного. Я в том числе.
Свой скрипт я бы не использовал, так как он построен по упрощенной схеме, мне такого функционала недостаточно.
По поводу хорошести программиста. Кроссбраузерность кода никакого отношения к качествам программиста не имеют. Когда делается покупка дорогостоящих и сложных программных продуктов, то выбирается соответствуюещая платформа под них. Покупая тот же фотошоп вы должны понимать, что вы должны еще выполнить ряд условий к платформе, на которой вы будете запускать данный продукт. Так что наличие жестких требований в продуктах - норма. Продукты - не сайты. Можно насильственно органичивать используемое ПО и железо.
-
Господа!!! У вас все в порядке? Вы вообще тут о чем?
Чего-то в обоих скриптах навигацией для сайта даже не пахнет. Вы сообсна какую именно задачу решали в вашем состязании?
Пока с трудом представляю, где и как это можно применить, ну разве что на оллимпиаде по информатике.
Любой из предложенных кодов можно спокойно применить в навигации по сайту. Или я не понимаю сути понятия "навигация по сайту"?
-
Прокомментирую-ка я некоторые грабли в вашем скрипте:
С удовольствием дам пояснения по каждому пункту.
> для отсечения IE используется банальный navigator.userAgent.indexOf("MSIE"), то есть любители по-spoof-ить свои юзерагенты заранее идут лесом;
Обычно для интерфейсов поддерживать не более 2-х браузеров. Это существенно удешевляет разработку. В требованиях к клиентам фронта серьезных продуктов всегда указывается, какими именно версиями каких именно продуктов нужно пользоваться.
> метод getElementsByTagName('*') предполагает, что IE ниже шестой версии отдыхает;
И отлично. Сама MS не поддерживает данные версии продуктов. Зачем поддерживать старье?
>метасимвол b в регулярном предполагает, что имена классов с дефисами внутри прид?тся выбирать более внимательно;
Решается на уровне проектной документации для разработчиков.
> do-while предполагает, что при начальном индексе (i), равном нулю, мы можем уплыть в светлую даль вечного loop-a, и почему именно do, и почему снизу;
Верно. Запишем как багу. Do-while самый быстрый цикл в JS.
> ноды засоряются ненужными данными, которые легко можно держать снаружи
Не очень удобно. Особенно если потребуется других компонент доступ к этим данным. Могу пояснить на примере, если надо.
> там прилинкован зачем-то свой же родитель,
Потому что прописка ноды меняется. А значит и меняется родитель.
> имя собственного же класса
Потому что никому не запрещено дописать еще классы. И как потом искать?
> да болтающийся текст activeTab
Не константа. Разные компоненты могут использовать разные классы.
> и т.д.) что чревато конфликтами в IE (возможное совпадение им?н в глобальном констексте)
Очень серьезная проблема
Никто не мешает стоить именование объектов так, как кому нравится. В больших проектах замечательно работает правило именования функций префиксами и наиболее полным отражением сути функций в ее названии. > очень сомнительна необходимость в нетривиальных и бажных dispatchEvent/fireEvent для такой примитивной задачи, как клик по табу;
В чем нетривиальность и бажность? Клик - это как раз отправная точка для действий над табами. Поэтому лучше эмулировать клик по табу, проходя стандартную функцию переключения, чем городить огород с дополнительными и универсальными функциями переключения, которым потребуется куча параметров.
> повсюду натыканы try-catch, но реальная проверка чего-либо вообще не производится;
Нужно сугубо для успокоения клиентов, дабы не раздражать их JS-error'ами, а свести все к банальному "не работает". Инценденты были. А проверку производить собственно не требуется, так как пользователю незачем видеть сообщения об ошибках.
>один кусок скрипта во внешнем файле, другой в html
Если внимательно посмотреть, то внешний файл - универсальная библиотека.
> первоначальная инициализация не по загрузке, а по месту скрипта в потоке,
Раздробите файл на куски, как это сделано во всех крупных проектах, и вы поймете, что ничего плохого в этом нет.
> обработчики заведены архаично в тегах...
И в чем плохость данного метода?
А, наверное лучше городить сверху систему идентификаторов для всех тегов, чтобы присваивать нужным тегам банальные обработчики. > общую логику даже не беру в расч?т...
Предложите ваш, самый лучший, самый идеальный вариант. А мы посидим и подумаем, чем он хорош, а чем - нет.
Если стояла задача написать качественный/reuse-ный/командный/кроссбраузерный/масштабируемый код, то вряд ли. А если ещ? и предположить, что это код коммерческий, то тут пахнет выговором от босса, как минимум...
Я сам себе выговор делать не буду. В данном примере ( на компонент это явно не тянет ) стояла задача написать простой в использовании и несложный код. Идеальный код нельзя написать в принципе, только по одной причине - всех вариантов не предусмотреть. Да и не надо это, в самом совершенном коде очень тяжело что-либо понять.
-
1. Привязка к количеству элементов. Что нужно сделать чтобы было не 3 а 4 вкладки? А если надо будет одну убрать?
2. Код закладок и контента находятся в разных местах. Если нужно будет, чтобы разные компоненты наполняли вкладки, то придется городить дополнительные параметры, чтобы все реализовать красиво. Весь HTML код для вкладки лучше все же хранить в одном месте.
3. Управление через параметр display. Не для всех элементов можно сделать display: block. Это существенно ограничивает гибкость кода.
Советую все же разобраться, как работает вариант AKS и как работает мой. Много хороших идей можно вынести.
-
Dimitry Wolotko, у меня нет холи-вора
Я давно уже ни с кем не воюю. Ветряные мельницы давно уже ушли в прошлое. AKS, итак, командный работник - этот тот работник, который заботится не о том, как выполнить свою работу хорошо, а тот, кто решает задачу так, чтобы было хорошо команде. В чем это выражается? В логике работы компонент, в API, в масштабируемости кода. Возьмем к примеру наши два кода. Мой код намного больше в JS части, но он позволяет делать те вещи, которые не предусмотрены в вашем. Например, я могу повесить на закладку собственный обработчик, не напрягаясь всего лишь дописав нужный JS-код. Как разработчик компоненты ( части ) я не привязан ни к каким тегам, мне достаточно указать имя класса и придерживаться всего лишь одного условия - заголовок таба должнен быть прямым потомком контейнера с содержимым таба. На инициализацию можно повесить любой обработчик, что позволило достаточно просто сделать селект с аналогичными свойствами. Опять же, селект уже является частью кода, поэму его просто стилизировать и работать с ним.
А теперь посмотрите на свой код? Оцените его гибкость и масштабируемость?
А где реализация второй части задания? Я ведь в задании присал "Задача: Сделать табулятор, который помимо обычных табов может переключаться селектом" Именно поэтому я задачу выполнил на 100%, сделав и табулятор, и селект. Кстати, одно из ценных свойств истинно командного разработчика - внимательно и до конца читать задачу. И на 100% ее реализовывать.
-
Я тебе не затыкал рот.
С какой же тогда целью Вы, уходя от темы, акцентируете внимание на фактах моей творческой биографии? Да они ведь Вам не были известны, не известны до сих пор, и станут известными никогда!
Так что нечего упоминать свои "заслуги перед отечеством", противопостовляя их отсутствию таковых у меня. Пишите по существу!
Я не акцентировал внимание, я констатировал факт. Можно хоть всю жизнь проработать в команде, но не быть командным работником. Можно всю жизнь наступать на одни и те же грабли, но так и не понять, почему так происходит. Чем больше опыта - тем больше приоритеты смещаются в совершенно другое русло. Это я и указал. Все остальные домыслы - плод воображения.
А теперь вернемся к нашим "баранам"
main.css
body
{
font-size: 8pt;
font-family: tahoma;
}
.hiddenBlock { display: none; }
.tabContent
{
background: #f5f5f5;
border: 1px solid #ccc;
padding: 10px;
}
.tabSwitch
{
text-decoration: none;
border: 1px solid #ccc;
border-bottom-width: 0px;
background: #e5e5e5;
padding: 0px 5px;
margin-right: 3px;
}
.superTab
{
background: #f5f5cc;
}
.activeTab
{
font-weight: bold;
background: #ccc;
}lib.js
IE = (navigator.userAgent.indexOf("MSIE") != -1);
matchClassName = function (node, className){
try {
var re = new RegExp ("b" + className + "b", "gi");
return ( node.className.match(re));
} catch ( e ) { return }
}
applyClassName = function (node, className, state ){
try {
var re = new RegExp ("b" + className + "b", "gi");
if ( state ) {
if ( !node.className.match(re) ) node.className += (" " + className);
}else{
node.className = node.className.replace(re, "");
node.className = node.className.replace(/s+/gi, " ");
}
} catch ( e ) {}
}
dispatchEventForElement = function ( node, eventType ) {
try {
if(!IE){
var evt = document.createEvent("MouseEvents");
evt.initMouseEvent(eventType, true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0, null);
node.dispatchEvent(evt)
}else{
node.fireEvent("on"+eventType);
}
} catch ( e ) {}
}
getElementsByClassName = function ( container, className ) {
var tmpArr = [];
try {
var nodeList = container.getElementsByTagName( "*" );
var i = nodeList.length;
do {
if ( matchClassName( nodeList.item( i-1 ), className ) ) tmpArr.push( nodeList.item( i-1 ) );
} while ( --i );
} catch ( e ) {};
return tmpArr;
}
getInnerText = function ( node ) {
try {
if ( IE ) return node.innerText;
else
{
var range = document.createRange( );
range.selectNodeContents ( node );
return range.toString();;
}
} catch ( e ) { }
}И сам код
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Demo</title>
<script type="text/javascript" src="lib.js"></script>
<link rel="stylesheet" type="text/css" href="main.css">
</head>
<body>
<div id="tabBox">
<div id="tabSwitchContainer"></div>
<div class="tabContent">
<a href="#" onclick="switchTab( this ); return false;" class="tabSwitch superTab"><i>Tab</i> 1</a>
Tab 1 Content
</div>
<div class="tabContent">
<a href="#" onclick="switchTab( this ); return false;" class="tabSwitch activeTab">Tab 2</a>
Tab 2 Content
</div>
</div>
<p><select id="linkedSelect" onchange="dispatchEventForElement( this.options[ this.value ].linkedNode, 'click')"><option> </option></select></p>
<script type="text/javascript">
<script type="text/javascript">
tabInit = function ( tabBoxID, tabSwitchContainerID, switchID, activityID, initHandler ) {
try {
var tabBoxNode = document.getElementById( tabBoxID );
var tabSwitchContainer = document.getElementById( tabSwitchContainerID );
var switchNodesList = getElementsByClassName ( tabBoxNode, switchID );
var activeTab = switchNodesList[ 0 ];
for ( var i = switchNodesList.length; i--; ) {
switchNodesList[ i ].options = {
linkedNode: switchNodesList[ i ].parentNode,
tabSwitchContainer: tabSwitchContainer,
switchID: switchID,
activityID: activityID
}
tabSwitchContainer.appendChild ( switchNodesList[ i ] );
if ( matchClassName ( switchNodesList[ i ], activityID ) ) activeTab = switchNodesList[ i ];
}
dispatchEventForElement ( activeTab, "click" );
if ( initHandler ) initHandler ( switchNodesList )
} catch ( e ) { alert( "Sorry, an error occured." ) }
}
switchTab = function ( node ) {
try {
if ( !node.options ) {
do{
node = node.parentNode;
} while ( !node.options )
}
var opts = node.options;
var tabSwitchList = getElementsByClassName( opts.tabSwitchContainer, opts.switchID );
for ( var i=tabSwitchList.length; i--; ) {
applyClassName ( tabSwitchList[ i ], opts.activityID, tabSwitchList[ i ] == node );
applyClassName ( tabSwitchList[ i ].options.linkedNode, "hiddenBlock", tabSwitchList[ i ] != node );
}
} catch ( e ) { alert( "Sorry, an error occured." ) };
}
fillInLinkedSelect = function ( nodeList ) {
var selNode = document.getElementById ( "linkedSelect" );
selNode.options.length = 0;
for ( var i = nodeList.length; i--; ) {
var tmpOption = new Option( getInnerText ( nodeList[ i ] ) , nodeList.length - i - 1 )
tmpOption.linkedNode = nodeList[ i ];
selNode.options [ selNode.options.length ] = tmpOption;
}
}
tabInit ( "tabBox", "tabSwitchContainer", "tabSwitch", "activeTab", fillInLinkedSelect );
</script>
</body>
</html>P.S. Я реализовал задачу на 100%. Мало того, в моем варианте абсолютно все равно, какие теги будут использоваться.
-
Для интерфейсов важно не well-formated, а дешевизна в разработке. Иногда приходится использовать свои атрибуты, которые не проходят валидацию, но с ними проще работать.
Стандартная "форумная возня". Один говорит о правильном структурировании данных, другой - совсем о другом, о дешевизне и простоте в разработке (ох уж эта меркантильность!).
Что есть правильное структурирование данных? Логичесткое представление в HTML? У меня логическое представление перенесено на классы. Смотришь на классы и видишь истинное предназначение данного блока. Чем не правильное структурирование?
Ах да, я забыл, правильно списки делать только при помощи UL, OL, DL, и ни-ни использовать что-то другое. другой затыкает собеседнику рот безотносительными фразами, типа: "ты явно не работал над реально сложными проектами" (кстати, это обязательно писать, без этого не хватает аргументов?).1. Я тебе не затыкал рот.
2. Аргументов у меня хватит, но вот будут ли мои аргументы для тебя значимы? Или будем и дальше повторять стандартные фразы из стандартных книжек?
Как в такой ситуации докопаться до истины?Очень просто. Сделать два варианта - один ортодоксальный, при помощи DL, а второй - с полным нарушением принципов HTML. Потом сравнить оба варианта. Я свой выложу последним, чтобы не было копирования идей.
-
А Вам придет в голову попытаться сложную структуру преподнести в виде табов?
Не понял вопроса.
Зачем же удалять? Для того, чтобы что-то скрыть, достаточно использовать css.Удалять нужно хотя бы потому, чтобы уменьшить количество обрабатываемых нод до минимума. Это влияет на скорость работы.
Да нет, зачем? dl.parentNode.insertBefore(tabs, dl) - возможо как-нибудь так.А в моем случае используется почти любой контейнер и самая примитивная функция appendChild.
Об этом я и пишу - выигрыш логической разметки относительно каких-то "костылей".Выигрыш как раз нулевой.
И чем больше проект, тем минимальнее становится эффект логической разметки. Выглядит вызывающе.Хочешь проверить?
На счет усложнения js-кода - это вряд ли. А разбираться должны знающие люди.Уже на одной задаче будет усложнение. А если задач несколько, и все они работают с данным кодом, то усложнение будет расти в неприличной прогрессии. Чем проще код - тем дешевле. Про разбирательство знающими людьми: ты явно не работал над реально сложными проектами. Особенно над теми, где работало несколько человек.
И именно поэтому количество well-formed документов, имеющихся в сети, ничтожно мало.Для интерфейсов важно не well-formated, а дешевизна в разработке. Иногда приходится использовать свои атрибуты, которые не проходят валидацию, но с ними проще работать.
Дабы не быть голословным и дальше, предлагаю провести мааленькое соревнование.
Задача: Сделать табулятор, который помимо обычных табов может переключаться селектом. Красивости не нужны. Сугубо функционал.
Принимаешь участие в соревновании?
-
> Наличие портфолио.
Не факт, что человек его сделал сам.
> Умение принимать решение.
Я принял решение не связываться с вами.
> Умение делать не только сайт, но и часть.
Что существенно удорожает разработку.
> Умение писать не только в Web 2.0, но и в предыдущей версии.
Да кому нужны такие продукты?
> Умение сочетать версии на одном сайте (чувство стиля).
Странное требование.
> Желание заработать, а не хапнуть.
Мое желание заработать вам будет очень дорого стоить. Ведь я не как новичек оцениваю стоимость работы.
> Понимание обязательности соблюдения сроков сдачи работы.
Но куда лучше просто умение соблюдать сроки. А то, что человек это просто понимает не улучшает качество и количество.
Итак, самый главный вопрос, а чем же собственно должен заниматься тот, кому интересна разовая удаленная работа?
-
2 из 10
Тупо две сардельки посреди монитора.
-
Через много лет программирования под HTML я пришел к одной очень простой истине. Все то многообразие тегов практически невостребовано в интерфейсах. Поясню почему. Порой сложность конструкции требует многократного вложения элементов. Порой требуется перенос содержимого с одной части дерева в другую. Все это нивелирует важность логического оформления кода, и банально начинает сводиться к нескольким тегам: DIV, SPAN, A, TABLE (и все запчасти), IMG. Логическая же часть перекладывается на классы.
AKS, в твоем варианте потребуется удалять лишние DT, а вместо них создавать A. Перенести же куском можно только в аналогичный DL. В моем варианте ничего удалять не требуется. Ты выиграешь на логике кода, зато проиграешь в скриптовой части, что создаст усложнение кода. А разбираться в нем через определенное время становится все сложнее и сложнее.
Так что готов поспорить, что предложенные варианты - лучше, удобнее для разработчика.
-
Как бы это делал я.
Самое первое правило - код одного таба должен быть описан в одном месте. Это улучшает восприятие и уменьшает количество будущих багов. Что это значит? Рассмотрим пример
<div id="tabBox">
<div id="tabSwitchContainer"></div> <!-- <= в этот контейнере будут закладки -->
<div class="tabContent">
<a href="#" onclick="switchTab(); return false;" class="tabSwitch">Tab 1</a>
Tab 1 Content
</div>
<div class="tabContent">
<a href="#" onclick="switchTab(); return false;" class="tabSwitch">Tab 2</a>
Tab 2 Content
</div>
</div>Потом создаем простую функцию инициализации нашего таба.
1. Найти контейнер с id="tabBox"
2. Найти контейнер для закладок ( id="tabSwitchContainer");
3. Найти все элементы, у которых среди имени класса встречается tabSwitch (/btabSwitchb/gi)
4. Каждой найденной ссылке присвоить параметр linkedNode, который равен parentNode ссылки. Это нужно для того, чтобы установить связь переключателя с блоком с контентом.
5. Перенести ссылку в контейнер для закладок (appendChild)
6. Функция switchTab находит все элементы, которые имеют в имени класса строку tabContent и присваивают класс hiddenBlock ( display: none ) Для элемента, который равен linkedNode, класс hiddenBlock удаляется.
В чем преимущества данного варианта
- блок монолитный, спокойно навешивается дополнительная логика в одном месте, а не в нескольких.
- не требуется сложные схемы идентификации разлычных блоков. Переключатель работает через присвоенный параметр linkedNode.
Код не привожу специально.
-
Все банально и просто. Студия - это огромный завод по производству сайтов и прочего барахла. Никакого творчества, никакого развития, только выработка человеческого ресурса. Нет никаких оптимизаций в процессе производства. Я сделал правильно, что отказался в свое время от работы там. Мой друг - работал ( в прошедшем времени ). Платят может и хорошо, но эти же деньги можно заработать и в других местах. Качественное развитие лучше получать в софтверных компаниях, которые занимаются созданием продуктов с web-интерфейсами. Создавать интерфейсы на порядок сложнее, чем собирать обтекание круглых картинок.
Да, студия Лебедева создала вокруг себя много ажиотажа. А внутри все гнило. Там работает много талантливых людей, а КПД - стремится к нулю.
Вариант навигации.
in JavaScript
Posted
В какое чувство? Человек указывает на какие-то проблемы, которые проблемами то не могут считаться. Это скорее особенности кода, чем баги.
Я не же указываю вам на то, что именование JS переменных должно происходить по правилам JS, а именно первая должна быть буква. Переменные типа "_" и "$" хоть и работают, но являются синтаксическими ошибками. Но я понимаю, что это особенности кода.
На это я и указывал во многих своих постах. Что все привыкают делать сферических коней в вакууме. Решать задачу в лоб, не задумываясь про повторное использование кода, про масштабируемость систем, про организацию гибких структур.