К сожалению, в реальном мире редко находится место для идеальных решений — конечно, если проводить сравнительное исследование CMS, то нужно делать именно так.
Есть несколько вопросов:
1) Разработка сайтов — не такая «денежная» отрасль, чтобы кто-то взялся проводить подобное масштабное исследование (это ведь требует серьезных затрат). Там более, если это должен быть «человек со стороны», хорошо разбирающийся в предмете.
Кто это мог бы быть?
2) Нужно ли подобное исследование кому-то кроме самих вендоров? Я, честно говоря, не знаю примеров подобных исследований в каких-то других областях… (автомобили, или какое-то оборудование, или ПО). Если в подобном исследовании «победит» одна CMS — должен ли будет проигравший посыпать голову пеплом и уйти с рынка? :) Ведь получится, что его продукт однозначно хуже продукта конкурента.
Грубо говоря, примерно также и будет выглядеть — только не в коде PHP, а в самом шаблоне.
Давайте попросим г-на aprusov привести пример XSL-кода, который выводит «1 сообщение», или «2 сообщения», или «10 сообщений» — в зависимости от заданного числа… :)
Я сам не совсем специалист по верстке, поэтому боюсь наделать ошибок и неточностей — потом кто-нибудь скопирует пример и скажет что «не работает!».
Будет что-то типа такого:
<xsl:template match="property[value=1]">
<xsl:value-of select="value" /> сообщение
</xsl:template>
<xsl:template match="property[value=2 or value=3 or value=4]">
<xsl:value-of select="value" /> сообщения
</xsl:template>
Ну и плюс к этому — можно предусмотреть возможность создания нескольких языковых версий.
Можно легко в будущем поменять эти надписи (вместо «сообщений» написать «писем», например) — при этом не нужно менять код системы, меняем только шаблон.
Число сообщений (1, 2, 3, 4) — это данные, а надпись «сообщений, сообщение, сообщения» относится к оформлению.
Соответственно, данные вы выбираете с помощью udata, а оформление задаете в шаблоне.
Преимущество XSLT как раз раскрывается в этом примере — вы можете прямо в шаблоне задать оформление в зависимости от количества сообщений, и не нужно ничего дописывать в системе.
Т.е. у вас есть блок, который выводит информацию о количестве сообщений — и вы задаете для него в XSLT несколько вариантов вывода, в зависимости от полученных через udata данных.
Я в основном говорю не о затратах на разработку сайта, а о затратах на его модернизацию — т.к. в последнее время часто приходится заниматься именно переделкой сайтов, сделанных некачественно.
Затраты на разработку сайта — это лишь небольшая часть расходов компании на сайт.
По поводу 30000 руб. — здесь я, конечно-же, говорю не о вашей работе, а привожу примеры из собственной практики — клиенты вынуждены много нам платить за ошибки битрикс-разработчиков.
Большинство проблем, связанных с «вывести какую-то совсем мелочь», легко решаются с помощью XSLT.
Когда вам дают сто рублей — не нужно раздавать технические долги, нужно адекватно оценить проблему и нормально ее решить.
Сегодня вы берете у заказчика 100 рублей и решаете проблему, не вникая глубоко в систему — а в будущем при развитии системы заказчик вынужден кому-то другому платить по 30 000 рублей, чтобы переделать вашу работу.
В этом как раз и кроются основные проблемы качества сайтов: «не люблю всякие искусственные ограничители...».
Дизайнеры, программисты… — " не люблю искусственные ограничители, ведь они не позволяют мне делать так как я умею, а заставляют делать все так как нужно".
Я думаю, сознательные разработчики должны поддерживать первые начинания некоторых вендоров в борьбе с говнокодом, а не придумывать новые поговорки типа «чем жестче ограничения, тем жестче говнокод».
Степан, ваш эксперимент не отвечает на вопрос «Какая из систем лучше для создания интернет-магазина на основе коробки с демоконтентом» — слишком сложный вопрос, чтобы можно было на него ответить с помощью такого простого исследования.
Ваше исследование только отвечает на вопрос «Какую систему предпочтут начинающие редакторы сайта, если предложить им самостоятельно установить систему и обновить немного контента».
«В топике пойдет речь о том, какая из систем (1C: Битрикс или UMI.CMS) лучше для создания Интернет-магазина на основе коробки с демоконтентом» — т.е. целью вашего исследования первоначально было именно выяснить, какая система лучше — а не выяснить, какая больше понравится начинающим «редакторам сайта с незаконченным ВО».
Соответственно — и обсуждение идет в эту сторону :)
Если это «редакторы сайта ...» — зачем включать в исследование установку системы? Нужно было тогда сразу начинать с обновления информации на сайте.
Еще хотел уточнить, насколько «таймаут-ошибки 504» в Битриксе повлияли на оценки по Битриксу? Респонденты похоже все это отнесли на «плохую погоду»…
Степан, я не критикую ваш эксперимент — я критиковал выводы, которые делаются по результатам вашего эксперимента.
Результат вашего эксперимента — «начинающие веб-разработчики выбирают Битрикс, а не Юми».
В обсуждении же этот результат интерпретируется как «Битрикс лучше чем Юми» — вот это я критикую.
По поводу ответа на вопрос «какая система лучше для бизнеса?» — на данный момент у меня есть ответ, основанный на личном опыте работы по нескольким проектам.
Также мы проводим аналитическое исследование на эту тему, надеюсь что в недалеком будущем смогу поверить свои убеждения числами.
P.S. качество CMS в целом нужно оценивать по экономии средств и снижению упущенной прибыли владельца сайта, а не по субъективным оценкам группы студентов.
В первую очередь, нужно правильно обозначить цель исследования — и исходя из этого вести обсуждение.
Цель данного исследования — выяснить, «на основе какой системы студенты хотели бы изучать работу c CMS». Соответственно, нужно и обсуждать этот вопрос — «Какая система лучше подходит для изучения студентами принципов работы с CMS?».
Вы же от этого вопроса — «какая система лучше для студентов?» — переходите к вопросу «Какая система лучше в целом?», и активно его обсуждаете на основании результатов данного исследования.
Коммерческая система управления сайтом создается не для «изучения ее студентами на основе демо-шаблона интернет-магазина», а для создания коммерческого сайта.
Оценить эффективность работы коммерческой системы управления сайтом можно только через 6-12 месяцев с момента запуска сайта. Как раз к этому времени всплывают все проблемы, связанные с возможностью добавлять произвольный PHP-код в шаблоны, проблемы с собственным шаблонизатором, проблемы с отсутствием четкой архитектуры данных.
Студент рад использовать «Битрикс», т.к. в любое место можно вставить собственный PHP-код, собрать сайт на информблоках, забив на архитектуру данных. Опять же, зачем думать об архитектуре — ведь все что нужно можно вывести с помощью PHP-кода!
Студент счастлив, он собирает сайт на «Битриксе» — а владелец сайта через 6-12 месяцев сталкивается с большими проблемами.
Коммерческая CMS — это система для коммерческого использования, и основное ее предназначение — это эффективное использование для бизнеса. Чем меньше свободы для разработчика — тем лучше будет результат, и тем меньше головной боли для владельца сайта.
Имею опыт работы с обоими системами, причем именно опыт модернизации сайтов — а не создания «с нуля». С битриксом много проблем, связанных именно со «свободой для разработчика».
Возможно, для изучения студентами Битрикс лучше, но для реальных коммерческих задач UMI.CMS однозначно предпочтительнее.
Также небольшое замечание к исследованию: мне кажется, не стоило замешивать в одну кучу удобство сайта вендора, и работу с самой системой. А то получается, «раз сайт у UMI.CMS менее удобный — значит и сама система хуже».
CMS — это платформа для создания веб-сайта.
Т.е. CMS — это платформа, просто нужно понимать, для чего эта платформа предназначена.
Есть несколько вопросов:
1) Разработка сайтов — не такая «денежная» отрасль, чтобы кто-то взялся проводить подобное масштабное исследование (это ведь требует серьезных затрат). Там более, если это должен быть «человек со стороны», хорошо разбирающийся в предмете.
Кто это мог бы быть?
2) Нужно ли подобное исследование кому-то кроме самих вендоров? Я, честно говоря, не знаю примеров подобных исследований в каких-то других областях… (автомобили, или какое-то оборудование, или ПО). Если в подобном исследовании «победит» одна CMS — должен ли будет проигравший посыпать голову пеплом и уйти с рынка? :) Ведь получится, что его продукт однозначно хуже продукта конкурента.
Количество строк не больше, чем в аналогичной функции на PHP.
Получаем из системы голое число, и выводим его так как нам нужно.
А мне кажется, логичнее решить эту задачу прямо в шаблоне — или я не прав?
Простейший способ:
Точность кода не гарантирую, особенно в случае остатка от деления — но эти функции там точно есть.
apsurov, возможно, я не прав, и лучше для этого создавать отдельную функцию в системе?
Битриксу уже скоро второй десяток стукнет, а Юми только 3 года.
То что больше программ в мире написано на Turbo Pascal чем на Python не говорит о том, что Turbo Pascal предпочтительнее…
Давайте попросим г-на aprusov привести пример XSL-кода, который выводит «1 сообщение», или «2 сообщения», или «10 сообщений» — в зависимости от заданного числа… :)
Я сам не совсем специалист по верстке, поэтому боюсь наделать ошибок и неточностей — потом кто-нибудь скопирует пример и скажет что «не работает!».
Будет что-то типа такого:
Можно легко в будущем поменять эти надписи (вместо «сообщений» написать «писем», например) — при этом не нужно менять код системы, меняем только шаблон.
Соответственно, данные вы выбираете с помощью udata, а оформление задаете в шаблоне.
Преимущество XSLT как раз раскрывается в этом примере — вы можете прямо в шаблоне задать оформление в зависимости от количества сообщений, и не нужно ничего дописывать в системе.
Т.е. у вас есть блок, который выводит информацию о количестве сообщений — и вы задаете для него в XSLT несколько вариантов вывода, в зависимости от полученных через udata данных.
Затраты на разработку сайта — это лишь небольшая часть расходов компании на сайт.
По поводу 30000 руб. — здесь я, конечно-же, говорю не о вашей работе, а привожу примеры из собственной практики — клиенты вынуждены много нам платить за ошибки битрикс-разработчиков.
Когда вам дают сто рублей — не нужно раздавать технические долги, нужно адекватно оценить проблему и нормально ее решить.
Сегодня вы берете у заказчика 100 рублей и решаете проблему, не вникая глубоко в систему — а в будущем при развитии системы заказчик вынужден кому-то другому платить по 30 000 рублей, чтобы переделать вашу работу.
Дизайнеры, программисты… — " не люблю искусственные ограничители, ведь они не позволяют мне делать так как я умею, а заставляют делать все так как нужно".
Я думаю, сознательные разработчики должны поддерживать первые начинания некоторых вендоров в борьбе с говнокодом, а не придумывать новые поговорки типа «чем жестче ограничения, тем жестче говнокод».
Ваше исследование только отвечает на вопрос «Какую систему предпочтут начинающие редакторы сайта, если предложить им самостоятельно установить систему и обновить немного контента».
Соответственно — и обсуждение идет в эту сторону :)
Если это «редакторы сайта ...» — зачем включать в исследование установку системы? Нужно было тогда сразу начинать с обновления информации на сайте.
Еще хотел уточнить, насколько «таймаут-ошибки 504» в Битриксе повлияли на оценки по Битриксу? Респонденты похоже все это отнесли на «плохую погоду»…
Это ведь не значит, что отвертка лучше чем шуруповерт?
Результат вашего эксперимента — «начинающие веб-разработчики выбирают Битрикс, а не Юми».
В обсуждении же этот результат интерпретируется как «Битрикс лучше чем Юми» — вот это я критикую.
По поводу ответа на вопрос «какая система лучше для бизнеса?» — на данный момент у меня есть ответ, основанный на личном опыте работы по нескольким проектам.
Также мы проводим аналитическое исследование на эту тему, надеюсь что в недалеком будущем смогу поверить свои убеждения числами.
Цель данного исследования — выяснить, «на основе какой системы студенты хотели бы изучать работу c CMS». Соответственно, нужно и обсуждать этот вопрос — «Какая система лучше подходит для изучения студентами принципов работы с CMS?».
Вы же от этого вопроса — «какая система лучше для студентов?» — переходите к вопросу «Какая система лучше в целом?», и активно его обсуждаете на основании результатов данного исследования.
Коммерческая система управления сайтом создается не для «изучения ее студентами на основе демо-шаблона интернет-магазина», а для создания коммерческого сайта.
Оценить эффективность работы коммерческой системы управления сайтом можно только через 6-12 месяцев с момента запуска сайта. Как раз к этому времени всплывают все проблемы, связанные с возможностью добавлять произвольный PHP-код в шаблоны, проблемы с собственным шаблонизатором, проблемы с отсутствием четкой архитектуры данных.
Студент рад использовать «Битрикс», т.к. в любое место можно вставить собственный PHP-код, собрать сайт на информблоках, забив на архитектуру данных. Опять же, зачем думать об архитектуре — ведь все что нужно можно вывести с помощью PHP-кода!
Студент счастлив, он собирает сайт на «Битриксе» — а владелец сайта через 6-12 месяцев сталкивается с большими проблемами.
Коммерческая CMS — это система для коммерческого использования, и основное ее предназначение — это эффективное использование для бизнеса. Чем меньше свободы для разработчика — тем лучше будет результат, и тем меньше головной боли для владельца сайта.
Имею опыт работы с обоими системами, причем именно опыт модернизации сайтов — а не создания «с нуля». С битриксом много проблем, связанных именно со «свободой для разработчика».
Возможно, для изучения студентами Битрикс лучше, но для реальных коммерческих задач UMI.CMS однозначно предпочтительнее.
Также небольшое замечание к исследованию: мне кажется, не стоило замешивать в одну кучу удобство сайта вендора, и работу с самой системой. А то получается, «раз сайт у UMI.CMS менее удобный — значит и сама система хуже».