Я не говорю, что отдавать НЕ валидную верстку/код — это нормальная практика. Я говорю, что есть бага именно в w3c-валидаторе, который забивает на то, что разрешено стандартом и считает не валидным то, что на самом деле валидно.
Вот вполне валидное определение неймспейса. <html xmlns="http://www.w3.org/1999/xhtml" xmlns:myns="http://myns.ru/">
....
<a href="/" myns:myAttr="boo" />
....
Почему я должен отказываться от того, что разрешено стандартом из-за какого-то глюка в валидаторе? как будто бы я делаю сайт для него.
Да это не проблема для нормального верстальщика, который знает стандарты и знает, что валидатор тоже может ошибаться.
Это проблема касается скорее «версткодрочеров» (как их кто-то тут назвал), которые не могут спокойно дышать, когда валидатор вываливает им что верстка не валидна и не выдает им заветную кнопочку что все валидно.
Не нужно сваливать с больной головы на здоровую. Вы сами привели ссылку на свой ЖЖ, где перешли на личности и ткнули лицом в г… и разработчиков и руководителей.
Я за здоровую критику, так что закончим переход на личности.
По делу:
Вы мне сейчас описали абстрактный пример, который демонстрирует сложность тестирования ПО, имеющего не идеальную архитектуру с зависимостями. Спасибо.
Я же уже сказал, что не считаю архитектуру идеальной. Она требует рефакторинга.
Кстати, подключить loC в текущую архитектуру юми не составит особого труда.
Я не говорил, что на фреймворках нельзя сделать визитку и я прекрасно понимаю что такое сайт-визитка, не передергивайте.
Мой посыл в том, что всему свое применение и если вы выбрали для себя не тот инструмент, так это не проблема инструмента, а проблема выбора.
Нет, я не работаю в юми, но хорошо знаком с ее архитектурой. Согласен, что она не идеальна и требует рефакторинга, но она и не такая ужасная, как вы тут описывайте, а самое главное, что она вообще есть.
Представляю, как вы прочитали умные книжки и побежали моментально рефакторить свои старые проекты конторам которые платят вам деньги.
Если вы такой умный и опытный разработчик, как вы вообще посмотрели в сторону коробки для проекта который пришлось так сильно точить под нее, зачем?
Ну и да, расскажите, как именно DI вам помешало реализовать кастомный функционал? И как бы оно вам помогло? Очень интересно, правда.
Согласен. Если бы я делал проект для себя или это было бы моей основной обязанностью на основной работе, то какие тут могут быть разговоры о CMS. Конечно же своя архитектура с IoC и девочками легкого поведения =)
Но целевая аудитория то у CMS — не я, а студии, которым надо быстро собрать типовой проект.
Очень здорово что вы знаете что такое DI и читали Фаулера. Только это не единственное, что гарантирует качество продукта и говорит о «крутости» программиста.
Вот с чем согласен точно, так это с тем, что не надо использовать CMS там, где она не применима.
Или вы будете делать сайт-визитку на ZF или Yii. Не боитесь получить «паттерн головного мозга»?
Да ничего сложного, как и в реализации огромного количества галок и настроек, которые еще надо задокументировать, а пользователю не забыть включить.
В итоге получим коллайдер, которым управлять будет не реально =)
В любой системе есть свои преимущества и недостатки, у любого продукта есть своя концепция, что разработчики будут делать, а что никогда не будут. Это не из-за того что сложно, а из-за того что концепция такая выбрана.
Рассматриваю, точно так же рассматриваю ситуацию, что у главного редактора (не блондинка с правами чуть большими чем у блондинки) сопрут пароль и используют его для прямого доступа к файловой системе.
Вы предлагаете для пользователей сделать отдельную галку: запретить XSS в админке? Коробочная CMS — общее решение. Кто-то хочет в админке писать javascript-код прямо в html-редактор, кто-то это называет необходимой фичей, кто-то уязвимостью, решать разработчикам системы, что разрешать, а что запрещать. Это просто особенность системы и надо ее учитывать.
Вообще, для таких «не надежных» редакторов делается отдельный кабинет со стороны сайта, и доступы в админку не даются.
>Обратная сторона этой возможности — применение нестандартных атрибутов у html тегов (например: umi:element-id=«44» umi:region=«row» umi:field-name=«name» umi:empty=«Название раздела» umi:delete=«delete»), в результате чего получается не валидная верстка.
Что значит «нестандартных атрибутов»? Вообще-то возможность определения своих неймспейсов в html никто не отменял. То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора — пишите им багрепорт. А по делу: не надоело делать сайты не для людей, а для роботов-валидаторов?
Очень много спорных пунктов, например то что из админки системы можно реализовать XSS уязвимость. Зачем давать доступ в админку тем, кто будет реализовывать уязвимости? Очевидно, что имея доступ в админку можно что-то поломать.
вот это уже правильно.
А сам встроенный модуль развивается хоть как-то? А то я помню, что там даже типы полей в свое время не приходили. Все можно было только «как строки» импортировать на сайт и со справочниками беда была.
Ваша концепция обмена это единственная концепция (не считая танца с бубном и настройкой 1С в качестве веб сервера), предлагаемая 1С для обмена данными «из коробки».
Если бы 1С думала немного о веб-разработчиках, они бы сделали общее решение и общий протокол обмена данными. Но им это не нужно, без этого хорошо живется без конкуренции =)
На самом деле для описания структуры как раз существуют xsd-схемы, которые позволяют разработчику не в двух словах понять что это за атрибут и на что он влияет.
Ну тут как раз проблема в том, что xsd схема не обновляется с развитием формата и пользователю даже сообщение об ошибке не вывести, что xml документ не соответствует стандарту и по каким причинам не соответствует…
Ну на мой взгляд, это стандарт должен был умереть сразу после зачатия. Уж слишком много чего не продумано в нем. Пришлось помучиться когда-то с ним основательно и поплеваться, поэтому не могу спокойно слышать что CML — это стандарт =)
Ну а если объективно, то хорошо что хоть как-то 1С данные отдавать — принимать умеет.
>Выглядит действительно уж очень необычно, после того, как программишь и пишешь все на английском.
Для 1С-программистов вполне даже себе обычно и привычно работать с «русским» xml )
Кстати, год назад отдаваемый 1С commerceML даже не проходил валидацию по xsd-схеме на сайте «стандарта».
А расширенная версия интеграции от Битрикса «пихает» туда свои тэги, которых просто не хватает в стандарте. Как можно после этого это вообще стандартом называть??
Ну да, всему свое применение. просто эту идею «сделать X без регистрации» применяют по делу и без него. В итоге пользователи не задумываются о безопасности своих данных совсем.
Вот вполне валидное определение неймспейса.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:myns="http://myns.ru/">
....
<a href="/" myns:myAttr="boo" />
....
Почему я должен отказываться от того, что разрешено стандартом из-за какого-то глюка в валидаторе? как будто бы я делаю сайт для него.
Это проблема касается скорее «версткодрочеров» (как их кто-то тут назвал), которые не могут спокойно дышать, когда валидатор вываливает им что верстка не валидна и не выдает им заветную кнопочку что все валидно.
Я за здоровую критику, так что закончим переход на личности.
По делу:
Вы мне сейчас описали абстрактный пример, который демонстрирует сложность тестирования ПО, имеющего не идеальную архитектуру с зависимостями. Спасибо.
Я же уже сказал, что не считаю архитектуру идеальной. Она требует рефакторинга.
Кстати, подключить loC в текущую архитектуру юми не составит особого труда.
Мой посыл в том, что всему свое применение и если вы выбрали для себя не тот инструмент, так это не проблема инструмента, а проблема выбора.
Представляю, как вы прочитали умные книжки и побежали моментально рефакторить свои старые проекты конторам которые платят вам деньги.
Если вы такой умный и опытный разработчик, как вы вообще посмотрели в сторону коробки для проекта который пришлось так сильно точить под нее, зачем?
Ну и да, расскажите, как именно DI вам помешало реализовать кастомный функционал? И как бы оно вам помогло? Очень интересно, правда.
Но целевая аудитория то у CMS — не я, а студии, которым надо быстро собрать типовой проект.
Вот с чем согласен точно, так это с тем, что не надо использовать CMS там, где она не применима.
Или вы будете делать сайт-визитку на ZF или Yii. Не боитесь получить «паттерн головного мозга»?
В итоге получим коллайдер, которым управлять будет не реально =)
В любой системе есть свои преимущества и недостатки, у любого продукта есть своя концепция, что разработчики будут делать, а что никогда не будут. Это не из-за того что сложно, а из-за того что концепция такая выбрана.
Вы предлагаете для пользователей сделать отдельную галку: запретить XSS в админке? Коробочная CMS — общее решение. Кто-то хочет в админке писать javascript-код прямо в html-редактор, кто-то это называет необходимой фичей, кто-то уязвимостью, решать разработчикам системы, что разрешать, а что запрещать. Это просто особенность системы и надо ее учитывать.
Вообще, для таких «не надежных» редакторов делается отдельный кабинет со стороны сайта, и доступы в админку не даются.
Что значит «нестандартных атрибутов»? Вообще-то возможность определения своих неймспейсов в html никто не отменял. То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора — пишите им багрепорт. А по делу: не надоело делать сайты не для людей, а для роботов-валидаторов?
Очень много спорных пунктов, например то что из админки системы можно реализовать XSS уязвимость. Зачем давать доступ в админку тем, кто будет реализовывать уязвимости? Очевидно, что имея доступ в админку можно что-то поломать.
И последнее: «явакод» — это что такое?
А сам встроенный модуль развивается хоть как-то? А то я помню, что там даже типы полей в свое время не приходили. Все можно было только «как строки» импортировать на сайт и со справочниками беда была.
Если бы 1С думала немного о веб-разработчиках, они бы сделали общее решение и общий протокол обмена данными. Но им это не нужно, без этого хорошо живется без конкуренции =)
Ну тут как раз проблема в том, что xsd схема не обновляется с развитием формата и пользователю даже сообщение об ошибке не вывести, что xml документ не соответствует стандарту и по каким причинам не соответствует…
A gzip не на каждом хостинге есть или включен)
Ну а если объективно, то хорошо что хоть как-то 1С данные отдавать — принимать умеет.
А называть элементы в стандарте типа «БазоваяЕдиница», а атрибуты «МеждународноеСокращение» это уж слишком…
Для 1С-программистов вполне даже себе обычно и привычно работать с «русским» xml )
Кстати, год назад отдаваемый 1С commerceML даже не проходил валидацию по xsd-схеме на сайте «стандарта».
А расширенная версия интеграции от Битрикса «пихает» туда свои тэги, которых просто не хватает в стандарте. Как можно после этого это вообще стандартом называть??