Как стать автором
Обновить

Комментарии 23

Спасибо за статью, сам недавно начал подумывать об использовании BASE, но, предполагая наличие засад (вроде пунктов 4 и 5), пока воздерживался.

Что касается остальных пунктов - как раз там я принципиальных проблем не вижу: имя хоста можно динамически вставлять при обработке шаблона в BASE из $ENV{HTTP_HOST}, а психологические проблемы "свежего" верстальщика надуманы - во-первых пусть учит что такое BASE, а во-вторых он даже не зная ничего о BASE отлично вставит новые картинки по аналогии с тем, как выглядит код для существующих картинок.
Думайте не об одном проекте, а о 70 в год. На 12 разных движках. Тогда вы поймете, почему я об этом написал.

Новый верстальщик, зная, что картинки лежат в /images/, a страница, с которой он будет работать, видна по адресу http://example.com/products/wiring/page3…, скорее применит мой метод, чем относительную адресацию. Base именно тем и вреден психологически, что тебе нужно знать о его существовании. Метод «полуабсолютных» путей позволяет забить на всех и работать нормально, вне зависимости от подобных «внешних» условий.
Адресация от корневой папки - это ваш метод? ИМХО, это единственно приемлемый метод.

ИМХО, движки должны быть так сделаны, чтобы верстальщик не ломал голову, что и в какой папке у него должно лежать. Все необходимые адреса должен генерировать|преобразовывать сам движок.
Неплохо бы. Но это не всегда случается.
Ну это тогда надо контору закрывать, если "не всегда случается" ;-)
в чем проблема использовать заранее определенные переменные basePath (для путей картинок и т.п.) и baseUrl (для путей всех ссылок) ?
или у верстальщика не хватит знаний чтобы вставлять перед каждой картинкой &lt?php echo BASE_URL ?&gt ?
У верстальщика не хватит терпения. Я сам верстальщик.
И к тому же, аналогично предыдущему комментатору, вы предлагаете нагружать этой задачей сервер, когда я показываю, что и клиент неплохо справится.
Сервер не будет грузиться, ибо движок после обработки шаблона закэширует его.
это вы сейчас о каком движке говорите? :)
А что, только я один предварительно преобразовываю шаблоны и кэширую их?
Кстати, кэширование «прокачанных» движком ссылок опять ставит нас перед проблемой нескольких доменов/протоколов.
А разве абсолютные ссылки должны "прокачиваться"?

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

Я думал вы об этом говорите. Похоже, тут внутренние ссылки получаются абсолютные, чего я также никогда не любил.
Там php код был, посмотрите выше
А можно чуть подробнее о пункте номер 4? У меня никаких проблем не возникает - используется base, в css прописан float(как right, так и left). И в осле все спокойно выделяется. Может быть коллизия заключается при выполнении еще каких-то условий(вложенность элементов особенная или еще что-то)?
ЗЫ: сам недавно натолкнулся на багу в шестом осле - при использовании определенных комбинаций float'ов и clear'ов можно создавать блоки, текст которых виден только при повторной отрисовке(допустим, после выделения мышью и снятия выделения или прокрутке страницы)
Нет, в моем случае на коллизию не похоже, когда убил base, всё стало ок. Но вот еще свидетельство авторитетного источника: http://www.456bereastreet.com/archive/20…
НЛО прилетело и опубликовало эту надпись здесь
Да! При чём, в моей теме оформления ЖЖ именно так: victorgr.livejournal.com/friends

Интересно, в чём здесь проблема? Как такого избежать?
Я уже давно использую тег и всегда рад. Значение href я делаю динамически, с ые проблем нет, конечно лучше делать относительно корневой папки, но тогда нельзя уставновить двиг например в site.com/demo . все ссылки будут ссылаться на site.com. тем болие у меня дома отдельно AMP и все делаю через localhost. имхо base полезен
было время сталкивался с подобными проблемами. не смотря на все слухи о неправильности использования абсалютных путей сделал выбор именно в их сторону.
все ссылки на ресурсы в моих проектах имеют полный путь. достигаеться это использование php по назначению - обработка текста. все css файлы при помощи .htaccess помечены как php скрипты и в путях к фоновым изображениям и т.д. прописываеться значение константы определенной в конфигурационном файле. в JS присутсвует строчка определяющая глобалюную переменную site_addr. таким образом я давно забыл про проблемы с ЧПУ, относительными путями и т.д.
такой метод позволяет быстро переместить проект с одного адреса на другой. так же по воле профессии приходиться часто работать с чужим кодом, в котором используються относительные пути, так вот к чему я это: бесит когда ставяться относительные пути относительно корня сервера! потому как переместить проект допустим в http://example.com/another/project/ становиться невозможно.
А автозамена не помогает? Это можно выполнить один раз статически, после чего всё работает. Не нужно напрягать сервер.
Думаешь что это то место на котором нужно экономить? если ты пишешь сайт под сервер с 133 процом и структурой в пару страниц то согласен. В реальных же проектах есть куда более загружающие куски кода. Да и в конце концов если не для манипуляций с текстом то для чего создан PHP? имхо в данном случае он применяеться вполне по назначению.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации