silicoid: Вебасист это такой-же фреймворк как битрикс, или вордпресс. Наличие определенного, весьма скудного и не ахти как задокументированного, АПИ не делает его фреймворком.
И тем не менее, вебасист - фреймворк для разработки приложений, какие бы ты тут мысли не высказывал.
silicoid: Боже, о каком роутинге вообще речь идет. Тут разговор шел о том, что человек сделает верстку вместо 100 килобайт в 10. А вы уже в такие дебри полезли. Просто для него "код" это верстка, а не моторчик.
Человек все правильно говорит - под сайт визитку незачем использовать CMS.
bay_ebook: когда из-за "selector--name" приходится прогеру делать на одну а целых 3 страницы (add/updete/index) то ну его к чертям
Щито? Что за "add/update/index"? Можете изложить вашу проблему подробней, в чем она заключается?
Разброс нормальный. Есть такая поговорка: "как заплачено, так и на...чено". Главное слишком крутые студии не берите, а то будете кормить уборщицу, сторожа и его собаку. И основывайтесь на ТЗ, договорах, и портфолио, желательно пообщавшись с владельцами сайтов, указанных в портфолио.
Sly32: А вот то, что любая CMS упорядочивает написание кода - факт. И ускоряет при умелом использовании
Для сайта-визитки? Устроим гонку: верстальщик предоставил нам архив с файлами index.html, about.html, contact.html, footer.html, header.html. Кто быстрее сделает сайт визитку, я, распаковав архив и залив на хостинг, или ты, разворачивающий свою джангу или что ты там любишь?
silicoid: становится таким семиголовым шестикрылом (привет webassist-у)
Webasyst - это фреймворк, а не движок. Да и не особо то он шестикрыл, уж точно меньше чем Wordpress.
silicoid: Движок дает ровно столько, сколько ему предоставил верстальщик. Если разговор идет из серии, "а давайте поставим вот этот шаблон", то это вопросы не к cms а вопросы к тому рукожопу, который собирает сайты из готовых шаблонов.
Верстальщик может повлиять на роутинг? На загрузку конфигов к базе? PSR-7? Не смеши.
Александр И: Какое из этого удобство?
Прочти это:
Вводная часть
У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:
Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.
Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент h1.title, на него сработают все правила для тегов h1 и все правила для класса .title. Так как весь html состоит из тегов, то правил которые применяются на теги без классов будут работать на все вообще.
Соответственно назначать или переназначать стили у тегов – это примерно то же самое, что править прототипы объектов в JS, чем в свое время печально славился Prototype.js. Эти стили унаследует вообще все объекты и если их потом захочется поменять, то результат будет такой же, как если ты решил в прототипе объекта поменять результаты какого-то метода, который используют все дети этого объекта. Вероятность что-то сломать почти 100%.
Вложенные селекторы. Можно написать селекторы .nav .item {...} и .menu .item и .item в зависимости от места вывода будет показываться по-разному. Все хорошо пока тебе не нужно поместить блок menu внутрь блока nav. Тогда сайдэффекты становятся совершенно непредсказуемые. По сути аналог вложенных селекторов из программирования – это функция которая в зависимости от места где её вызывают, выдает разный результат. Например в одном месте sum(2,2) может возвращать 3, а в другом 5.
Зачем нужны методологии
Хорошая методология занимает предотвращением этих проблем. Покажу как это делает БЭМ, но CSS Modules, Polymer или всякие решения с инлайновыми стилями для Реакта тоже решают именно их, только другим способом.
Как именование классов по БЭМу помогает решать эти проблемы:
БЭМ запрещает применять стили на теги, максимум ресет. На id тоже нельзя, потому что такие элементы нельзя на странице использовать 2 раза, а сколько раз он тебе понадобится ты не всегда знаешь заранее. Все стили можно применять только к классам.
БЭМ создает для всех компонентов глобальный неймспейс – все классы которые относятся к компоненту начинаются с одного префикса. Это позволяет исправить второй пример таким образом: .nav__item, .menu__item. Если один вложить в другой не будет конфликта правил.
Под каждый компонент в БЭМ создается своя папка – это защищает тебя от конфликтов в именах компонентов и при правильном использовании дает гарантию, что в глобальном неймспейсе будет только один компонент с таким префиксом.
В БЭМ есть только один вид вложенных селекторов: модификатор > элемент. Оба начинаются с одного префикса, оба живут в одном файле, оба никак не влияют на другие компоненты.
Источник: https://gist.github.com/iAdramelk/d328b73c72cab92ef95f
SELECT adm.post_id FROM z_admitad_product_data AS adm INNER JOIN z_postmeta AS zps ON zps.post_id = adm.post_id WHERE zps.meta_key != '_wp_attached_file' OR zps.meta_key IS NULL;
Ms-Dred: Оффтоп. Интересно было бы сравнить работу базы на nosql на одном и том же сервере....
Сравнить работу базы? Ну, эээ, как вы собрались сравнить работу? Скорость работы? И как вы собрались делать ALTER TABLE на, допустим, MongoDB или CouchDB, которая document-oriented storage. Cassandra или HBase, она отчасти табличная (данные хранятся по колонкам, а не в строковом виде), отсюда ALTER TABLE будет выполнятся быстрее (намного быстрее), но дело даже не в этом, а в том, что MySQL у ТС работает как-то странно, 15 минут менять таблицу не есть норм. И да, NoSQL - Not-only SQL.
То что ваши юзеры ноют, это никак не обойти. Всегда кто-то будет ныть и писать "прощальное письмо". В свое время ebay менял цвет фона с серого на белый (или наоборот, не помню точно), и когда поменяли, то получили просто огромную волну критики. В общем, они подумали, и решили менять фон плавно на протяжении месяца, написали скрипт который двигался по градиенту от начального цвета до конечного, нужного им. В итоге, никто не заметил как произошел переход, и критики не было вообще. Конечно, с комментами такой трюк не прокатит. Тут нужно выбрать самую активную аудиторию (желательно по вовлеченности), и подстраиваться под них. Если это ВК - то оставить ВК (или сделать интеграцию с ВК).
Если спам какой-то однообразный, то может стоит попробовать прикрутить какие-то фильтры (есть ли API к системе модерации)?
Попробуйте смотивировать юзеров жмакать на спам (жаловаться), и потом вычищать почти все, что туда попадает не глядя. Хотя, если аудитория - пытливые школьники, то быстро смекут, и начнут сливать неугодных через кнопки.
В идеале, конечно, своя собственная система комментариев, со своими внутренними уведомлениями и HTML 5 Notification API, но тут поднимется вопрос базы данных и нагрузки на сервер. В таком случае, ваша задача взять в руку калькулятор, посчитать сколько вы платите текущим модераторам, и посчитать сколько будет стоить сервер по мощнее и плагин с необходимым вам функционалом (фильтры, эвристика, пороги, жалобы, etc.), и найти выгоду. Хотя, один из крупнейших западных автопорталов, использует все таки disqus. И я их отчасти понимаю.
Вебасист это такой-же фреймворк как битрикс, или вордпресс. Наличие определенного, весьма скудного и не ахти как задокументированного, АПИ не делает его фреймворком.
И тем не менее, вебасист - фреймворк для разработки приложений, какие бы ты тут мысли не высказывал.
Боже, о каком роутинге вообще речь идет. Тут разговор шел о том, что человек сделает верстку вместо 100 килобайт в 10. А вы уже в такие дебри полезли. Просто для него "код" это верстка, а не моторчик.
Человек все правильно говорит - под сайт визитку незачем использовать CMS.
когда из-за "selector--name" приходится прогеру делать на одну а целых 3 страницы (add/updete/index) то ну его к чертям
Щито? Что за "add/update/index"? Можете изложить вашу проблему подробней, в чем она заключается?
Разброс нормальный. Есть такая поговорка: "как заплачено, так и на...чено". Главное слишком крутые студии не берите, а то будете кормить уборщицу, сторожа и его собаку. И основывайтесь на ТЗ, договорах, и портфолио, желательно пообщавшись с владельцами сайтов, указанных в портфолио.
Посмотрите у меня в подписи. По тарифному плану, все зависит от количества трафика. Начните с 2ГБ. Все зависит от оптимизации.
4 раза нажать на пробел
Да, я уже глянул. Пару лет сидел на форуме, где табы через Ctrl+Space ставились. Было удобно. Думал и тут такая фича имеется, о которой я не знал.
А вот то, что любая CMS упорядочивает написание кода - факт. И ускоряет при умелом использовании
Для сайта-визитки? Устроим гонку: верстальщик предоставил нам архив с файлами index.html, about.html, contact.html, footer.html, header.html. Кто быстрее сделает сайт визитку, я, распаковав архив и залив на хостинг, или ты, разворачивающий свою джангу или что ты там любишь?
становится таким семиголовым шестикрылом (привет webassist-у)
Webasyst - это фреймворк, а не движок. Да и не особо то он шестикрыл, уж точно меньше чем Wordpress.
Движок дает ровно столько, сколько ему предоставил верстальщик. Если разговор идет из серии, "а давайте поставим вот этот шаблон", то это вопросы не к cms а вопросы к тому рукожопу, который собирает сайты из готовых шаблонов.
Верстальщик может повлиять на роутинг? На загрузку конфигов к базе? PSR-7? Не смеши.
Какое из этого удобство?
Прочти это:
У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:
Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.
Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент h1.title, на него сработают все правила для тегов h1 и все правила для класса .title. Так как весь html состоит из тегов, то правил которые применяются на теги без классов будут работать на все вообще.
Соответственно назначать или переназначать стили у тегов – это примерно то же самое, что править прототипы объектов в JS, чем в свое время печально славился Prototype.js. Эти стили унаследует вообще все объекты и если их потом захочется поменять, то результат будет такой же, как если ты решил в прототипе объекта поменять результаты какого-то метода, который используют все дети этого объекта. Вероятность что-то сломать почти 100%.
Вложенные селекторы. Можно написать селекторы .nav .item {...} и .menu .item и .item в зависимости от места вывода будет показываться по-разному. Все хорошо пока тебе не нужно поместить блок menu внутрь блока nav. Тогда сайдэффекты становятся совершенно непредсказуемые. По сути аналог вложенных селекторов из программирования – это функция которая в зависимости от места где её вызывают, выдает разный результат. Например в одном месте sum(2,2) может возвращать 3, а в другом 5.
Зачем нужны методологии
Хорошая методология занимает предотвращением этих проблем. Покажу как это делает БЭМ, но CSS Modules, Polymer или всякие решения с инлайновыми стилями для Реакта тоже решают именно их, только другим способом.
Как именование классов по БЭМу помогает решать эти проблемы:
БЭМ запрещает применять стили на теги, максимум ресет. На id тоже нельзя, потому что такие элементы нельзя на странице использовать 2 раза, а сколько раз он тебе понадобится ты не всегда знаешь заранее. Все стили можно применять только к классам.
БЭМ создает для всех компонентов глобальный неймспейс – все классы которые относятся к компоненту начинаются с одного префикса. Это позволяет исправить второй пример таким образом: .nav__item, .menu__item. Если один вложить в другой не будет конфликта правил.
Под каждый компонент в БЭМ создается своя папка – это защищает тебя от конфликтов в именах компонентов и при правильном использовании дает гарантию, что в глобальном неймспейсе будет только один компонент с таким префиксом.
В БЭМ есть только один вид вложенных селекторов: модификатор > элемент. Оба начинаются с одного префикса, оба живут в одном файле, оба никак не влияют на другие компоненты.
Источник: https://gist.github.com/iAdramelk/d328b73c72cab92ef95f
Попробуйте так.
Aisamiery, как табы ставить через браузер?
К базе коннектитесь через 127.0.0.1 или localhost?
Оффтоп. Интересно было бы сравнить работу базы на nosql на одном и том же сервере....
Сравнить работу базы? Ну, эээ, как вы собрались сравнить работу? Скорость работы? И как вы собрались делать ALTER TABLE на, допустим, MongoDB или CouchDB, которая document-oriented storage. Cassandra или HBase, она отчасти табличная (данные хранятся по колонкам, а не в строковом виде), отсюда ALTER TABLE будет выполнятся быстрее (намного быстрее), но дело даже не в этом, а в том, что MySQL у ТС работает как-то странно, 15 минут менять таблицу не есть норм. И да, NoSQL - Not-only SQL.
Простите что вмешиваюсь, но не совершайте ошибки !
1С Битрикс = выделенный сервер, и только так.
Выделенный дата-центр, чего уж там.
То что ваши юзеры ноют, это никак не обойти. Всегда кто-то будет ныть и писать "прощальное письмо". В свое время ebay менял цвет фона с серого на белый (или наоборот, не помню точно), и когда поменяли, то получили просто огромную волну критики. В общем, они подумали, и решили менять фон плавно на протяжении месяца, написали скрипт который двигался по градиенту от начального цвета до конечного, нужного им. В итоге, никто не заметил как произошел переход, и критики не было вообще. Конечно, с комментами такой трюк не прокатит. Тут нужно выбрать самую активную аудиторию (желательно по вовлеченности), и подстраиваться под них. Если это ВК - то оставить ВК (или сделать интеграцию с ВК).
Если спам какой-то однообразный, то может стоит попробовать прикрутить какие-то фильтры (есть ли API к системе модерации)?
Попробуйте смотивировать юзеров жмакать на спам (жаловаться), и потом вычищать почти все, что туда попадает не глядя. Хотя, если аудитория - пытливые школьники, то быстро смекут, и начнут сливать неугодных через кнопки.
В идеале, конечно, своя собственная система комментариев, со своими внутренними уведомлениями и HTML 5 Notification API, но тут поднимется вопрос базы данных и нагрузки на сервер. В таком случае, ваша задача взять в руку калькулятор, посчитать сколько вы платите текущим модераторам, и посчитать сколько будет стоить сервер по мощнее и плагин с необходимым вам функционалом (фильтры, эвристика, пороги, жалобы, etc.), и найти выгоду. Хотя, один из крупнейших западных автопорталов, использует все таки disqus. И я их отчасти понимаю.