Dmitriy_2014 : На многих сайта видел ссылки, кнопки и другие элементы которые не подсвечиваются, не меняют цвет, не анимируются, да и вообще ничего не происходит, когда к ним мышка подводится.
Точно на многих? 😀
Наверное, речь о том, что ссылки изначально хорошо выделены. Но это в основном подчеркивание и яркий цвет. А подчеркивание - это старая школа 😉
Если везде одинаковый тип, не считая статических файлов, можно настроить в конфигурации сервера. Иначе "глубже". Можно везде использовать одинаковый тип, включая статические файлы, т.е. без слэша. Только нужно отключить автоматическую переадресацию сервером для (статических) каталогов.
Влияет на относительные адреса ссылок и куки разделов, если в параметре куки присутствует завершающий слэш. Сейчас для обычных сайтов это практически неактуально. Адреса начинаются как минимум со слэша (или используется тег base).
Я никого не унижал и вам написал, что можете продолжать называть это "своей нишей", очень узкой нишей. Так можно сказать почти про любое творение с множеством ограничений и проблем: просто у него своя ниша. Пусть разработчикам будет приятно 😊
Aisamiery#: Все равно фигня получится, это будет типа '%LIKE%'?
plab#: Я сразу сказал, что речь идет о статических статейника.
Статические по определению не используют базу данных (во время работы). Поэтому тот вопрос был странный.
Сами по себе статические сайты морально устарели, даже если их генерировать. К тому же придется "шаманить" с директивами сервера или использовать специализированный хостинг, чтобы хотя бы немного "причесать" сайт, например убрать из адресов страниц .html, устранить дубли страниц.
plab#: Вы тут же на локальном компе генерите статические страницы и заливаете их на хостинг.
Решили вспомнить первое поколение генераторов? Это еще хуже, чем я думал.
Сейчас сайты другие. Слишком часто меняются отдельные блоки страниц. Вам как минимум нужно будет много кода на клиентском JS, чтобы загружать "дополненное содержимое" на статические страницы. И загружать скорее всего придется не из статических файлов. Про появление (и исчезновение) целых страниц, необходимость серверного рендеринга для поисковых систем и устаревших клиентов уже молчу. Про такие функции, как поиск по сайту, тоже уже писали.
В общем кэширование (разных видов) - более продвинутая технология. И при этом не нужно делить сайт на статическую и динамическую составляющие.
Попробуйте сделать то же, что делает СУБД, другим способом, мнение быстро изменится. Кроме того, базы данных бывают очень разные. У некоторых "резидентность" (размещение в памяти всех или наиболее актуальных данных) - одно из ключевых свойств.
plab#: Она может быть нужна при разработке самого сайта, но потом если делать по уму, надо нагенерить статических html - чтобы траф не лез в БД. Она ему не нужна. При изменении БД...
При каком изменении БД, если она уже не нужна сайту? 😊
plab#: надо автоматом перезаписывать измененные страницы на сервере.
В какой момент планируете "полсайта" перезаписывать? 😊
br.almighty #: Зачем она нужна? Для чего? Что без файловой CMS нельзя сделать, что она нужна? Я именно это спрашиваю, а не интересуюсь о том, что это такое.
В предыдущем сообщении вы так сформулировали мысль, что возникло подозрение о непонимании того, что это такое. Это CMS, разработчики которых боятся как огня обычных баз данных (реляционных, документооринтированных). В связи с чем имеют множество ограничений и проблем в своих творениях.
На многих сайта видел ссылки, кнопки и другие элементы которые не подсвечиваются, не меняют цвет, не анимируются, да и вообще ничего не происходит, когда к ним мышка подводится.
Точно на многих? 😀
Наверное, речь о том, что ссылки изначально хорошо выделены. Но это в основном подчеркивание и яркий цвет. А подчеркивание - это старая школа 😉
Если везде одинаковый тип, не считая статических файлов, можно настроить в конфигурации сервера. Иначе "глубже". Можно везде использовать одинаковый тип, включая статические файлы, т.е. без слэша. Только нужно отключить автоматическую переадресацию сервером для (статических) каталогов.
Влияет на относительные адреса ссылок и куки разделов, если в параметре куки присутствует завершающий слэш. Сейчас для обычных сайтов это практически неактуально. Адреса начинаются как минимум со слэша (или используется тег base).
бизнес сайтов
Это что визитки что ли? Уже в простых витринах "кластеризация" используется по полной, если это не "наваленные кучи" /products, /works, etc.
просто авторов cms унизить попытались
Все равно фигня получится, это будет типа '%LIKE%'?
Я сразу сказал, что речь идет о статических статейника.
Статические по определению не используют базу данных (во время работы). Поэтому тот вопрос был странный.
Сами по себе статические сайты морально устарели, даже если их генерировать. К тому же придется "шаманить" с директивами сервера или использовать специализированный хостинг, чтобы хотя бы немного "причесать" сайт, например убрать из адресов страниц .html, устранить дубли страниц.
Вы тут же на локальном компе генерите статические страницы и заливаете их на хостинг.
Решили вспомнить первое поколение генераторов? Это еще хуже, чем я думал.
Сейчас сайты другие. Слишком часто меняются отдельные блоки страниц. Вам как минимум нужно будет много кода на клиентском JS, чтобы загружать "дополненное содержимое" на статические страницы. И загружать скорее всего придется не из статических файлов. Про появление (и исчезновение) целых страниц, необходимость серверного рендеринга для поисковых систем и устаревших клиентов уже молчу. Про такие функции, как поиск по сайту, тоже уже писали.
В общем кэширование (разных видов) - более продвинутая технология. И при этом не нужно делить сайт на статическую и динамическую составляющие.
Основные тормоза исходят от базы данных.
Попробуйте сделать то же, что делает СУБД, другим способом, мнение быстро изменится. Кроме того, базы данных бывают очень разные. У некоторых "резидентность" (размещение в памяти всех или наиболее актуальных данных) - одно из ключевых свойств.
Она может быть нужна при разработке самого сайта, но потом если делать по уму, надо нагенерить статических html - чтобы траф не лез в БД. Она ему не нужна. При изменении БД...
При каком изменении БД, если она уже не нужна сайту? 😊
надо автоматом перезаписывать измененные страницы на сервере.
В какой момент планируете "полсайта" перезаписывать? 😊
Какую то глупость сморозили, у файловых CMS просто своя ниша.
"Своя ниша" - это "смороженная мной глупость", завернутая в более деликатную форму. Можете продолжать деликатничать. Но по-моему это еще глупее.
Это не так работает. Для редактирования указанных сущностей вовсе не требуется редактировать шаблоны.
Зачем она нужна? Для чего? Что без файловой CMS нельзя сделать, что она нужна? Я именно это спрашиваю, а не интересуюсь о том, что это такое.
В предыдущем сообщении вы так сформулировали мысль, что возникло подозрение о непонимании того, что это такое. Это CMS, разработчики которых боятся как огня обычных баз данных (реляционных, документооринтированных). В связи с чем имеют множество ограничений и проблем в своих творениях.