wildhind

Используйте api bing. Почему-то google закрыл свой api

явно указанный ID инфоблока. Часто обращаются терпящие бедствие владельцы магазинов, которые убивают инфоблок каталога, прочитав где-то такую инструкцию, загружают новый каталог из 1С, выбирают в параметрах компонента новый инфоблок, но всё рушится. в 95% случаев причина в этом: где-то в коде ID инфоблока прописан жёстко. Не надо так делать, когда этот ID есть в $arParams. Нужно его брать оттуда. Судя по тому, что вёрстка намешана с логикой, видно, что всё это безобразие творится в template.php. Время от времени этот файл открывается на редактирование в визуальном редакторе. И это нормально. Сотрудник заказчика должен иметь возможность добавить розовую блямбу в шаблон не будучи программистом. Но что в таком случае станет с кодом php — лотерея. Может и не выжить. Именно для избежания такой ерунды и сделано разделение логики и оформления. В битриксе оно сделано довольно неплохо, можно разделить весьма жёстко. Минус битрикса только в том, что можно и понаписать логики в шаблоны, а оформления в ядро. И штатная функция ShowImage(), применённая здесь, тому яркий пример. В этом плане мне куда более симпатичны шаблоны джанго, где возможности логики в шаблонах урезаны до реально необходимого минимума. Про всякие мелкие некритичные недочёты вроде get-параметров &set_filter=Подобрать&set_filter=Y я не говорю Они ничего не натворят плохого, но как-то это не очень красиво что ли А вот этот момент: <a href="?arrFilter_pf[VENDOR]='.$arItem["ID"] — значительно хуже. Он исключает альтернативную фильтрацию. Например, есть фильтрация или сортировка по цене, но нужно наложить ещё и эту фильтрацию по производителям. Такая формулировка в url перечеркнёт все параметры, установленные до этого. ShowImage($arItem["PREVIEW_PICTURE"], 100, 100, "border='0'") — тоже не айс. Почему размеры картинки не вынесены в параметры компонента? Для изменения размеров нужно лезть в код. Это неправильно. А рамка и вовсе должна в css задаваться.

Отвечу по порядку. Хотелось бы узнать какие решения более правильные: 1) В рамках обёртки .container содержатся .header и .main, мне казалось что последний и логически, и структурно объединяет основное содержание, отделённое от Хеад. Вы считаете, что .container достаточно? Если да, вполне соглашусь. Было б логично сделать три основных блока: хэдер, основно контент и футер. Встречается схема, при которой хэдер и основной контент завёрнуты в один блок, а футер вынесен отдельно. Такое бывает например когда нужно прибить футер к низу страницы при любом количестве контента и любой высоте окна. Но наоборот не вижу обоснований. Ширина задана любому списку в контентной области. Делая меню списком даже без класса, применяя специфичные стили для всех списков, вы тем самым лишаете себя возможности использовать списки в своём изначальном значении: как списки. Я бы применила решение, рекомендованное спецификацией: тэг nav для навигации. Нужно использовать класс, по которому можно однозначно узнать главное меню. И стили нужно применять именно к элементу nav с этим классом, а не ко всем спискам на странице. 6 (подчёркнутый многострочный текст) — допустим, к дизайнеру. Хотя называть его дизайнером после такого вряд ли можно. Но 5 — это грубая ошибка вёрстки. Представьте себе, что это не учебный пример, а реальная вёрстка, которую затем отдаёте программисту для интеграции с CMS. К слову, без этого в вёрстке нет ни малейшего смысла. Лента новостей в любой CMS является цельным функционалом, обеспечивается единым компонентом с собственным шаблоном. Что должно пойти в этот шаблон? Рваные конструкции? Открывающие тэги без закрывающих и закрывающие без открывающих? Что будет при отключении этого компонента или использовании его в другом месте? Это основы юзабилити. Часть пользователей гарантированно будет тыкаться в картинку и удивляться, почему не срабатывает. Нажав F12, я увеличиваю громкость. А порядок оказывает влияние. Существуют мнения о том, что поисковым роботам ближе то, что ближе к началу страницы, но этот вопрос я лучше оставлю специалистам по SEO, если таковые здесь имеются. Зато есть реальная вероятность, что на не самых лучших каналах (а известно ли вам о том, что доля мобильных браузеров с мобильной же связью весьма существенна уже, а качество этих каналов по прежнему оставляет желать лучшего?) отобразится ненужная информация, а нужной придётся долго ждать. Нет, не знаю. У меня и шестой IE поддерживает header, footer и всё остальное. Но не следует их использовать вместо классов. Те же header и footer вопреки распространённому среди начинающих мнению могут использоваться в любом месте страницы. А вот вам и всё разнообразие тэгов с описанием их применения: http://htmlbook.ru/html

да вообще-то участник со статусом «новичок» сказал правильно. И при чём тут статус… Несколько вопросов: Каково значение блока div.main? Зачем всем спискам в этом блоке задана ширина 940px, а все элементы этих списков сделаны инлайновыми? Почему основная навигация не имеет селектора, по которому её можно однозначно идентифицировать? Почему основная навигация отцентрована, но одно слово падает на вторую строку, разрывая пункт меню на две противоположные части страницы? Почему ссылка, логически относящаяся к списку новостей, вдруг попала в футер? Зачем четырёхстрочный текст подчёркнут? Как его читать? Хотя это скорее к дизайнеру. Почему в списке новостей картинка не является ссылкой? Почему ссылкой не является вся плашка новости? Почему второстепенная, менее значимая, информация идёт в коде перед основной, более значимой? Какие вам известны тэги кроме div,ul,li,a?

Видимо всё же не забыл, а не захотел засорять код лишними элементами Читайте документацию, чтобы в следующий раз не сесть в лужу Кстати, а с чем поздравляют-то? Дата ведь не найдена:

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

Какую часть неправильно конвертирует, и что стоит в настройках subsettings при этом?

Зачем указывать явно то, что есть в $arParams? Зачем указывать явно то, что есть в $arResult? Файл result_modifier.php создаётся в каталоге шаблона компонента. В случае его наличия массив $arResult модифицируется в соответствии с логикой, описанной в этом файле. в template.php попадает уже модифицированный массив $arResult. http://dev.1c-bitrix.ru/api_help/iblock/classes/ciblockelement/getlist.php

Почти так. Само по себе различие отображения в разных браузерах не есть зло. Однако дефолтное отображение может противоречить идее дизайна. Например, та же высота строки чаще всего должна быть вполне определённой для соответствия дизайну. Тогда пишем в начале css именно нужную высоту, а не абстрактный line-height: 1 ради ненужного причёсывания под одну гребёнку. Текст, ссылки должны быть определённых цветов. Задаём эти цвета, а не определяем background:white;color:black непонятно ради чего с тем, чтобы следующей строкой всё равно указать нужные цвета. border у img — да, сбрасываем. display:block для header,footer,section,etc — да, ставим. Это исправление неожиданного поведения, приведение поведения к ожидаемому. Маркеры у списков не убираем. Маркеры у списков ожидаемы. Можно их переопределить, если дизайнером задуман альтернативный вид. Можно сделать что-нибудь в духе input:focus { box-shadow: none }. В отдельных случаях характерное для вебкитов подсвечивание поля в фокусе резко не сочетается с дизайном. То есть, всё очень зависит от дизайна. В нормальном макете указаны стили для заголовков любого уровня, ссылок, списков, элементов форм. Это и нужно задавать как стили по умолчанию, а не бездумное обнуление всего и вся.

Списки в навигации — достаточно удачное (пусть и не бесспорное) решение для многоуровневых меню.

Александр, вы испорчены здравым смыслом

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

как в европах Удачно найти хорошего сотрудника! Непростое это дело.

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

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

Да вот беда. Разработка-то ведётся на нормальных современных компьютерах, достаточно мощных. У заказчика тоже нормальный компьютер. Протестировать на не самых мощных компах или на виндах зачастую бывает проблематично. И уже не первый раз в такую идиотскую ситуацию попадаем

Да, от неё и были основные тормоза. Беда в том, что заказчик уже принял. Надо будет теперь как-то незаметно переделать, чтобы самим не было стыдно за такую работу.

ID инфоблока известен? ID раздела известен? полагаю, да. Это же в компоненте каталога всё происходит? Тогда в result_modifier.php пишется выборка на основе ID инфоблока и ID раздела, и добавляется в $arResult.

так а если не завязываться на $arResult["ITEMS"]? Конечно же в нём только те элементы, которые будут выведены на этой странице.

коллеги, у кого тормоза наблюдались, скажите пожалуйста, сейчас они остались? напомню адрес: http://steel.wildhind.ru/ Здесь ещё поднялся вопрос насчёт сброса стилей. Предлагаю обсудить его здесь

В другой теме поднялся вопрос, почему сброс стилей — это плохо. У некоторых он даже шаблоны порвал, а некоторые предположили, что это очередной модный тренд. Здесь хочу пояснить, почему это плохо, и ответить на оставшиеся вопросы. Всё очень просто: после завершения работ над сайтом в студии, управление сайтом передаётся заказчику. Сотрудники заказчика должны иметь возможность наполнения сайта контентом, при этом стандартные элементы разметки должны иметь ожидаемый вид. Например, размещает сотрудник заказчика в тексте новости список, и этот список должен отобразиться списком, а не голым текстом со сброшенными стилями. Если этого не происходит, студия получает претензию от заказчика, техподдержка получает неоплачиваемую работу, которую могла бы не получить, если бы всё было изначально сделано правильно. При этом, в зависимости от характера заказчика, возможно осложнение отношений. Прошу заметить, на ровном месте. Ничего не мешает вместо сброса стилей определить стили по умолчанию. Если есть ещё вопросы по этой теме, прошу задавать.

Если вы хотите работника в офис, не забывайте указывать город. А то можно подумать, будто вы в Москве.

1С7.7? Тогда ещё не было и речи об интеграции. Ну и битрикс древний седьмой версии, ещё не обученный интеграции с 1с. Ясное дело, что сделано через как. Иначе тогда и нельзя было сделать. В самых простых случаях интеграция стоила пары недель головной боли и была ничуть не проще, чем в какой-нибудь джумле.

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

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