• Критика UMI.CMS
    +4
    Выгода очевидна — edit in place в юми, jQuery тоже использует собственные атрибуты и ничего страшного. Это удобно и по стандарту.
  • Критика UMI.CMS
    +1
    Я не говорю, что отдавать НЕ валидную верстку/код — это нормальная практика. Я говорю, что есть бага именно в w3c-валидаторе, который забивает на то, что разрешено стандартом и считает не валидным то, что на самом деле валидно.

    Вот вполне валидное определение неймспейса.
    <html xmlns="http://www.w3.org/1999/xhtml" xmlns:myns="http://myns.ru/">
    ....
    <a href="/" myns:myAttr="boo" />
    ....


    Почему я должен отказываться от того, что разрешено стандартом из-за какого-то глюка в валидаторе? как будто бы я делаю сайт для него.
  • Критика UMI.CMS
    +2
    Да это не проблема для нормального верстальщика, который знает стандарты и знает, что валидатор тоже может ошибаться.
    Это проблема касается скорее «версткодрочеров» (как их кто-то тут назвал), которые не могут спокойно дышать, когда валидатор вываливает им что верстка не валидна и не выдает им заветную кнопочку что все валидно.
  • Критика UMI.CMS
    +2
    Не нужно сваливать с больной головы на здоровую. Вы сами привели ссылку на свой ЖЖ, где перешли на личности и ткнули лицом в г… и разработчиков и руководителей.
    Я за здоровую критику, так что закончим переход на личности.

    По делу:
    Вы мне сейчас описали абстрактный пример, который демонстрирует сложность тестирования ПО, имеющего не идеальную архитектуру с зависимостями. Спасибо.
    Я же уже сказал, что не считаю архитектуру идеальной. Она требует рефакторинга.
    Кстати, подключить loC в текущую архитектуру юми не составит особого труда.
  • Критика UMI.CMS
    +1
    Я не говорил, что на фреймворках нельзя сделать визитку и я прекрасно понимаю что такое сайт-визитка, не передергивайте.
    Мой посыл в том, что всему свое применение и если вы выбрали для себя не тот инструмент, так это не проблема инструмента, а проблема выбора.
  • Критика UMI.CMS
    +1
    Нет, я не работаю в юми, но хорошо знаком с ее архитектурой. Согласен, что она не идеальна и требует рефакторинга, но она и не такая ужасная, как вы тут описывайте, а самое главное, что она вообще есть.
    Представляю, как вы прочитали умные книжки и побежали моментально рефакторить свои старые проекты конторам которые платят вам деньги.

    Если вы такой умный и опытный разработчик, как вы вообще посмотрели в сторону коробки для проекта который пришлось так сильно точить под нее, зачем?

    Ну и да, расскажите, как именно DI вам помешало реализовать кастомный функционал? И как бы оно вам помогло? Очень интересно, правда.
  • Критика UMI.CMS
    +1
    Согласен. Если бы я делал проект для себя или это было бы моей основной обязанностью на основной работе, то какие тут могут быть разговоры о CMS. Конечно же своя архитектура с IoC и девочками легкого поведения =)
    Но целевая аудитория то у CMS — не я, а студии, которым надо быстро собрать типовой проект.
  • Критика UMI.CMS
    +5
    Очень здорово что вы знаете что такое DI и читали Фаулера. Только это не единственное, что гарантирует качество продукта и говорит о «крутости» программиста.
    Вот с чем согласен точно, так это с тем, что не надо использовать CMS там, где она не применима.
    Или вы будете делать сайт-визитку на ZF или Yii. Не боитесь получить «паттерн головного мозга»?
  • Критика UMI.CMS
    +3
    Да ничего сложного, как и в реализации огромного количества галок и настроек, которые еще надо задокументировать, а пользователю не забыть включить.

    В итоге получим коллайдер, которым управлять будет не реально =)
    В любой системе есть свои преимущества и недостатки, у любого продукта есть своя концепция, что разработчики будут делать, а что никогда не будут. Это не из-за того что сложно, а из-за того что концепция такая выбрана.
  • Критика UMI.CMS
    +2
    Рассматриваю, точно так же рассматриваю ситуацию, что у главного редактора (не блондинка с правами чуть большими чем у блондинки) сопрут пароль и используют его для прямого доступа к файловой системе.
    Вы предлагаете для пользователей сделать отдельную галку: запретить XSS в админке? Коробочная CMS — общее решение. Кто-то хочет в админке писать javascript-код прямо в html-редактор, кто-то это называет необходимой фичей, кто-то уязвимостью, решать разработчикам системы, что разрешать, а что запрещать. Это просто особенность системы и надо ее учитывать.
    Вообще, для таких «не надежных» редакторов делается отдельный кабинет со стороны сайта, и доступы в админку не даются.
  • Критика UMI.CMS
    +6
    >Обратная сторона этой возможности — применение нестандартных атрибутов у html тегов (например: umi:element-id=«44» umi:region=«row» umi:field-name=«name» umi:empty=«Название раздела» umi:delete=«delete»), в результате чего получается не валидная верстка.

    Что значит «нестандартных атрибутов»? Вообще-то возможность определения своих неймспейсов в html никто не отменял. То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора — пишите им багрепорт. А по делу: не надоело делать сайты не для людей, а для роботов-валидаторов?

    Очень много спорных пунктов, например то что из админки системы можно реализовать XSS уязвимость. Зачем давать доступ в админку тем, кто будет реализовывать уязвимости? Очевидно, что имея доступ в админку можно что-то поломать.

    И последнее: «явакод» — это что такое?
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    0
    вот это уже правильно.
    А сам встроенный модуль развивается хоть как-то? А то я помню, что там даже типы полей в свое время не приходили. Все можно было только «как строки» импортировать на сайт и со справочниками беда была.
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    0
    Ну согласитесь, что настройки для Битрикса и лого в модуле как бы напоминает, что оно не совсем «общее» и универсальное.
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    0
    Ваша концепция обмена это единственная концепция (не считая танца с бубном и настройкой 1С в качестве веб сервера), предлагаемая 1С для обмена данными «из коробки».
    Если бы 1С думала немного о веб-разработчиках, они бы сделали общее решение и общий протокол обмена данными. Но им это не нужно, без этого хорошо живется без конкуренции =)
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    +2
    Все мои проблемы были исключительно с документацией формата и расхождениями «настоящего» CML, который отдает 1С и CML на сайте формата.
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    +1
    На самом деле для описания структуры как раз существуют xsd-схемы, которые позволяют разработчику не в двух словах понять что это за атрибут и на что он влияет.
    Ну тут как раз проблема в том, что xsd схема не обновляется с развитием формата и пользователю даже сообщение об ошибке не вывести, что xml документ не соответствует стандарту и по каким причинам не соответствует…

    A gzip не на каждом хостинге есть или включен)
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    +2
    Ну на мой взгляд, это стандарт должен был умереть сразу после зачатия. Уж слишком много чего не продумано в нем. Пришлось помучиться когда-то с ним основательно и поплеваться, поэтому не могу спокойно слышать что CML — это стандарт =)

    Ну а если объективно, то хорошо что хоть как-то 1С данные отдавать — принимать умеет.
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    +2
    XML сам по себе избыточен, это да. Но никто не отменяет продумывать стандарты так, чтобы они содержали как можно меньше избыточных данных.

    А называть элементы в стандарте типа «БазоваяЕдиница», а атрибуты «МеждународноеСокращение» это уж слишком…
  • Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой
    +2
    >Выглядит действительно уж очень необычно, после того, как программишь и пишешь все на английском.
    Для 1С-программистов вполне даже себе обычно и привычно работать с «русским» xml )

    Кстати, год назад отдаваемый 1С commerceML даже не проходил валидацию по xsd-схеме на сайте «стандарта».

    А расширенная версия интеграции от Битрикса «пихает» туда свои тэги, которых просто не хватает в стандарте. Как можно после этого это вообще стандартом называть??
  • Яндекс – (действительно) найдется все!
    0
    Ну да, всему свое применение. просто эту идею «сделать X без регистрации» применяют по делу и без него. В итоге пользователи не задумываются о безопасности своих данных совсем.
  • Яндекс – (действительно) найдется все!
    0
    Яндекс тут не при чем… Вообще секретный ключ передавать, присылать, хранить в открытом виде не безопасно. Вот вам и «покупка без регистрации» и прочие прелести открытого интернета =) зато как удобно!
  • Масштабируемые JavaScript приложения
    +1
    Спасибо, интересная статья. Многие рекомендации из нее можно использовать не только в клиентских js-приложениях.
  • Сайт Сколково
    0
    Еще раз для детективов, делающих необоснованные выводы:
    habrahabr.ru/blogs/internet/117202/#comment_3817917
  • Сайт Сколково
    +6
    Я, Прусов Антон Васильевич, официально заявляю что не имею отношения к нано-технологиям, а так же к 3.1 млн. руб (а жаль =))
    Это фейковый конфиг, который давался для примера установки сайта из консоли и попал в какую-то старую сборку UMI.CMS с моими данными. Данные уже давно там действительно фейковые, в том числе и фио, но история похоже осталась ))
    Кстати, это не логин пароль для входа в админку, даже если попытаться установить систему с таким паролем, она его не примет. Вобщем, этот конфиг ничего не значит и удаляется при установке, естественно.

    PS. взял за правило не писать вообще свои данные, даже в тестовых случаях, а то мало ли в чем обвинить могут не разобравшись. хороший урок на будущее )
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +3
    да, вы все правильно сделали — именно так можно сделать это на xslt и без написания собственных методов. Я просто продемонстрировал как можно писать свои методы и вызывать их из шаблона.
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +2
    промахнулся )
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +3
    Нет, далеко не на каждый чих, конечно.
    В umi есть уже системные протоколы и ресурсы, которые позволяют делать многое, но если не хватает чего-либо очень просто дописать что-либо свое и использовать многократно в своих проектах.

    Я просто продемонстрировал как работать с протоколами.
    В большинстве случаев это совершенно не нужно, чтобы например вывести не стандартное меню, не нужно писать для этого метод, можно использовать готовый ресурс и с помощью xsl-шаблона вывести и «раскрасить» меню как вздумается верстальщику.
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +2
    Это у меня он любимый, ничего личного не имел ввиду )))
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +1
    это как раз утопия. так нельзя юзать xslt ) Он не для этого придуман.
    Если вы читали книжку внимательно, там это объяснено )
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +2
    Пожалуйста, абстрагируемся от php и от umi.
    Предположим, что ваш метод items возвращает xml-документ примерно такой:
    [root]value[/root], где value — результат работы метода.
    Предположим, что у вас есть зарегистрирован протокол sheme, который умеет вызывать методы вашего класса.

    Из xsl-шаблона вы вызываете его примерно таким образом:
    <xsl:param name=«number» select=«5» /> — это для примера работы с параметром.
    <xsl:value-of select=«document(concat('sheme://items/', $param, '&one;', '&few;', '&many;', '&other;'))/value» />

    Все. При этом результат можно локализовать, используя xml-entities

    Как-то так…
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +3
    Ну да, можно чтобы ресурс возвращал сущности.
    Сами сущности подгружаются xsl-шаблоном (через DOCTYPE). Так устроена локализация админки в UMI, то же самое можно делать и с сайтом.
    Очень удобно, кстати.
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +3
    конечно упрощен, а зачем все усложнять?
    Нужна функция «перевода чисел в буквы», например — пишите простейший метод на любимом php и возвращаете результат по некоторым простым правилам. Обрабатываете входящие параметры. Число 4 в данном примере как раз и есть параметр.
    В большинстве случаев этого просто не нужно — но если есть такая задача — то пожалуйста. Просто тут четкое разделение логики и представления. Шаблоны в одном месте — php код в другом. Все логично и прозрачно.
  • 1C-Битрикс vs UMI.CMS или расово верный холивар популярных коробочных CMS
    +3
    > Из архитектурных проблем xslt: то, что протоколы должны давать данные с оформлением.

    Нет, это не архитектурная проблема XSLT.
    Протоколы ни в коем случае не должны отдавать данные с оформлением. Вы сами указываете в шаблоне каким образом их выводить. Например, дата отдается протоколами в формате UNIX Timestamp, а в шаблоне вы можете представить ее в том формате, который вам нужен. Протоколы устроены так, что отдают лишь минимальное кол-во данных, дополнительно можно запросить все что угодно, если это необходимо в конкретном шаблоне.
    Через протоколы вы так же можете запрашивать системные и собственные макросы (REST-ресурсы), которые могут выполнить какие-то действия и вернут вам результат работы. Например, для склонения числовых данных вы можете написать свой макрос, который будет «склонять числа», а затем вызывать его из шаблона примерно так:
    udata://content/formatNumber/4/
  • Другая книга про XSLT
    0
    По поводу disable-output-escaping спорить не буду, но tidy думаю стоит подключить опционально.
  • Другая книга про XSLT
    0
    За год очень многое изменилось, админка полностью переработана, скрипты переписаны, prototype+scriptaculous больше не используются, так что ваш обзор немножко устарел :)
  • Другая книга про XSLT
    0
    В config.ini есть настройка в секции [core]. Выстави ее в «1»

    property-value-mode=«1»
  • Другая книга про XSLT
    +6
    Проблема в том, что wysiwyg-поле редактируется пользователем, который чаще всего понятия не имеет о том, что такое well-formed XML. Для надежности мы его «заворачиваем» в CDATA.
    Однако, для продвинутых пользователей есть настройка в CMS, после включения которой содержимое поля wysiwyg пытается преобразоваться в XML, который можно не только выводить с помощью copy-of, но и обрабатывать как угодно.
  • Extend Grid — делаем жизнь верстальщика немного проще
    0
    А еще, для удобства, чтобы данные не приходилось вводить в каждом браузере вручную, можно сделать сериализацию в строку и давать возможность загружать сетку из строки. А так же можно это в параметр инициализации сетки вынести, чтобы вообще не заморачиваться с вводом настроек для разных браузеров )
  • Альтернативный анонс нового релиза UMI.CMS
    +2
    На мой взгляд, работать напрямую с БД любой CMS — это как раз и есть костыли.
    В любой момент архитектура БД может измениться, или даже сама БД. 1С может работать на MS SQL, а может и на Postgree SQL.…
    CMS точно так же: разработчики зачастую меняют структуру таблиц для оптимизации системы.
    Может измениться все, кроме API.

    А вот если бы у 1С был нормальный API доступа к данным проблем бы не было.
    Единственный вариант работы с данными — это 1С-Обработки, которые нужно писать на «русском языке», сертифицировать в 1С и которые обычному смертному пользователю даже установить нормально не удастся.
  • Альтернативный анонс нового релиза UMI.CMS
    +1
    PS. Импорт-экспорт в CommerceML — файлов был и есть почти у всех CMS, но интеграцией, в полном понимании этого слова, это назвать сложно.