Grey_EM
Guest
Можно спросить зачем?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Ну, девелоперы, колитесь!
- Автор темы pachanga
- Дата начала
Можно спросить зачем?
Dexter
Guest
О!... докопались.
IMHO ООП не нужено для сайт-приложений по той простой причине, что всемя жизни прцесса - мгновения.
Мне лично проще оперировать функциями и данными, чем объектами и методами. Стиль PHP как языка больше отражает суть программирования для создания HTML.
Считайте, что эта моя субьективная особенность.
Мне не хочется создавать объект стринг... Мне удобнее и понятнее переменная (в PHP она сразу в 3х типах создается)
и передавать ее функциям специально разработанным для работы с HTML.
А с JSP я столкнулся и ужаснулся.
C большим трудом я внес изменения в JSP файл созданный не мной, попутно узнав что делая split строке я должен был подключить каке-то модули... и контролировать дляну строки до того как сделать ей split. Ну с этим я смирился, но когда я узнал, что там используются какие-то "JAVA-бины" которые осуществляют доступ к базе (а мне понадобились дополнительные данные). Их нужно отдельно гдето исправлять.. потом хрен знает как публиковать... но это делать сейчас нельзя т.к. у всех пользователей полетят встроенные в JSP сессии.... тут я понял... что.. наверно JSP штука мощьная и производительная, но не меня. Я никак не могу назвать разработку в подобной системе удобной. Нужно быть слишком программистом, чтобы понимать все преимущества JAVA. А большиство разработчиков на PHP не профессиональные программисты. Им понравилась простота с одной стороны - и большая мощьность с другой. Приемлимая производительность и скорсть.
Да - опенсорс... все понятно... Но интересная вешь.
В одной компании нужен был движок для E-commerce.
Было решено с FREE ни в коем случае не связываться...
Они считали - да мы за юникс для веб-сервера, но не линух, а BSDi . Т.е. четко следовали логике что free - только сами знаете где. И купили не очень дорогой... но коммерческий пакет.. поддержка .. все дела... Чем все кончилось.... они устали биться с тех-поддержкой... они не смогли купить более позднюю весию продукта когда она вышла потому, что сильно изменились условия ее дистриуции. и т. д. и т. п. Нашли коммерческий пакет на PHP и поставили его.
Их системщик из сказал: "По крайней мере это OPEN Sourse и мы сами сможем исправить и сами сможем дополнить." Это я к тому, что OPEN Sourse - это становится знаком качества и порой больших гарантий чем закрытые коммерческие системы.
О монстрах по 250K$ мы надеюсь не говорим.
P.S. В PHP я полностью контроллирую сессии и не боюсь вносить никакие изменеия в код на "живом" сайте...
P.P.S. Я крайне мало знаком с JAVA и с JSP, но когда я впервые закомился с php я испылывал радость и удовольствие от процесса. Думаю эта особенность и привлекает все новых поклонников этого языка. До этого много писал на Си и не смог перейти на C++ . Встреча с JSP мне показалась кошмаром. То-же касается Perl. Наверно не случайно Вы упомянули именно perl & Java.
defresto
Guest
to boka
Глянул твой ДХТМЛ-редактор... Супер это лучшее из того что я видел.
to Dexter
Предложенная тобой структура классная
У меня тот же вопрос что у боки:
Чем использование 404 для выкройки параметров хуже (кроме мусора в логах), чем прегенерация реальных папок и индекс файлов?
Никто не знает примера цмски, которая оптимально решала бы следующую базовую задачу:
чтобы хтмл-кодер мог самостоятельно создать шаблоны и добавить в них элементы меню и сабменю?
Со структурой всё ясно. Дейвствительно предложненый Декстером вариант даёт максимальную простоту.
Осталась проблема базовой задачи как кодеру создать каркас?
Глянул твой ДХТМЛ-редактор... Супер это лучшее из того что я видел.
to Dexter
Предложенная тобой структура классная
У меня тот же вопрос что у боки:
Чем использование 404 для выкройки параметров хуже (кроме мусора в логах), чем прегенерация реальных папок и индекс файлов?
Никто не знает примера цмски, которая оптимально решала бы следующую базовую задачу:
чтобы хтмл-кодер мог самостоятельно создать шаблоны и добавить в них элементы меню и сабменю?
Со структурой всё ясно. Дейвствительно предложненый Декстером вариант даёт максимальную простоту.
Осталась проблема базовой задачи как кодеру создать каркас?
boka
Guest
Есть такой вариант (одна знакомая студия делает). В качестве шаблонов позволяет задать только шапку и подвал. Все, что между ними - одинаково для всех сайтов, особенности задаются только использованием CSS.
Я обдумывал такой вариант интерфейса для работы с шаблонами. Создается сверстанная страница, потом заходим в админку, в разделе создания шаблонов вставляем всю эту верстку полностью, от <html> до </html>, в textarea. Потом кнопочками в тулбаре вставляем в нужные нам места типа-теги. Например, {page}, {news} и т. д. А все эти типа-теги парсются при выводе страницы, и вместо них подставляется соответствующее содержимое.
Таким образом, имеем возможность склеивать с CMS дизайн любой сложности. Кроме того, можно постоянно расширять библиотеку модулей и типа-тегов.
Я обдумывал такой вариант интерфейса для работы с шаблонами. Создается сверстанная страница, потом заходим в админку, в разделе создания шаблонов вставляем всю эту верстку полностью, от <html> до </html>, в textarea. Потом кнопочками в тулбаре вставляем в нужные нам места типа-теги.
Например, {page}, {news} и т. д. А все эти типа-теги парсются при выводе страницы, и вместо них подставляется соответствующее содержимое.Таким образом, имеем возможность склеивать с CMS дизайн любой сложности. Кроме того, можно постоянно расширять библиотеку модулей и типа-тегов.
defresto
Guest
Ну с {page} всё ясно include page тоже не проблема любому кодеру сделать.
Самое сложное сделать меню...
Ведь меню бывают разных типов:
- раскрывающиеся вниз/вверх
- с выпадашкой вниз/вверх
- с выпадашкой вбок
енто проблема раз
проблема два, это то что при активности пункта меню/сабменю тоже должно кое-чего происходить...
В общем над этой проблемкой я сегодня и бился
ни одногой цмс, которая могла бы нормально решить эту проблему я пока не видел.
Как мы выяснили цель цмс автоматизировать работу,
а если у сайта меню нет, то зачем ему нафиг цмс. Отсюда первая проблема, которую нужно решить - это сделать это автоматизировать процесс создания меню.
Если создание меню при помощи цмс окажеться задачкой посложней, чем на пхп это ясный план не катит.
В общем буду думать...
Как чего-то стоящее придёт в голову напишу
Самое сложное сделать меню...
Ведь меню бывают разных типов:
- раскрывающиеся вниз/вверх
- с выпадашкой вниз/вверх
- с выпадашкой вбок
енто проблема раз
проблема два, это то что при активности пункта меню/сабменю тоже должно кое-чего происходить...
В общем над этой проблемкой я сегодня и бился
ни одногой цмс, которая могла бы нормально решить эту проблему я пока не видел.
Как мы выяснили цель цмс автоматизировать работу,
а если у сайта меню нет, то зачем ему нафиг цмс. Отсюда первая проблема, которую нужно решить - это сделать это автоматизировать процесс создания меню.
Если создание меню при помощи цмс окажеться задачкой посложней, чем на пхп это ясный план не катит.
В общем буду думать...
Как чего-то стоящее придёт в голову напишу
Flying
Guest
Читаю тут вашу переписку, родилось несколько замечаний. Но сначала по поводу меню.
Самое первое замечание - ты путаешь различные вещи вместе и отсюда получаешь проблему. То, как меню создается и то, как оно будет потом выглядеть - вещи между собой не связанные (по крайней мере они должны таковыми быть). Т.е. по сути это 2 различных куска кода один из которых подготавливает данные, а второй их отображает. Само по себе меню (в большинстве случаев) является древовидной структурой и может быть достаточно эффективно сохранено в базе данных или в XML. При этом набор опций для каждого элемента меню описывается вполне четко и однозначно. Как только ты уяснишь для себя эти простые вещи - вопросы, заданные тобой смогут разрешиться намного легче.
Теперь по поводу вопроса о CMS как таковой. Все знают, что CMS - это Content Management System, т.е. система управления данными, находящимися на сайте. Объясните мне, глупому, почему вы все как один рветесть упихать туда редактирование внешнего вида? Покажите мне серьезный, крупный ресурс, который менял бы свой дизайн чаще чем раз в полгода-год. Нет таких (ну или почти нет). Потому что люди, которые ходят на ваш сайт привыкают к его виду, знают где и что нажать, чтобы получить нужную им информацию и смена дизайна их только собьет с толку, т.е. вызовет отрицательные эмоции, чего в отношении постоянных посетителей допускать никак нельзя. Но несмотря на это похоже, что вы рассматриваете задачу визуального редактирования внешнего вида в CMS как одну из важнейших его функций. Реально это не так и самой важной функцией является возможность быстрого добавления (реже - редактирования) контента на сайт. Прочие вещи, типа того же редактора содержимого меню обычно используются крайне редко. Ну сами вспомните, часто ли вам это нужно в процессе поддержки работающего сайта?
Еще одно замечание по поводу проскакивавших здесь идей о динамической генерации дерева директорий, а также об использовании обработчика Error 404 для реализации "красивых" URL. По поводу первого могу привести в пример www.lenta.ru или что-нибудь еще в том же духе. Неужели вы считаете, что там реально регенриуются все эти сотни тысяч каталогов? Да ничего подобного! Кроме того создание такого количества файлов очень неблагоприятно скажется на быстродействии файловой системы сервера, что соответствующим образом отразится на общей производительности.
Обработка же через Error 404 вообще ничего хорошего кроме ощутимых тормозов не даст, поскольку в данном случае получается ни много ни мало двойная нагрузка на сервер (ведь практически каждый запрос порождает еще один запрос). При повышении количества посетителей например до 10.000 человек в день это уже может стать очень серьезной проблемой. Реально же подобные вещи реализуются через апачевский mod_rewrite (или подобный модуль для IIS). Немного сложнее, согласен, зато быстро и эффективно.
boka
Guest
Речь идет о том, чтобы сделать современный, удобный, а самое главное, конкурентноспособный продукт. Мы ведь занимаемся бизнесом, правда? А не народным творчеством. Визуальный редактор в системе контент-менеджмента является одним из факторов, обеспечивающих конкурентноспособность. Попробуйте предложить заказчику на выбор: систему с возможностью редактирования контента а-ля MS Word, и без таковой. Что он выберет?
Именно поэтому визуальный редактор важен. Конечно, разработчикам хочется максимально ограничить самодеятельность "секретарш", чтобы не портить свой портфолио. Но бить их по рукам не всегда экономически эффективно. Когда ваши конкуренты предлагают что-то более технологичное и заманчивое для заказчика, поневоле задумаешься о прогрессе.
boka
Guest
Насчет ленты.ру и сотен тысяч каталогов, тормозящих систему - это хороший аргумент. Мне как-то он в голову не приходил, когда я дискутировал с тем товарищем.
Спасибо.
Значит, буду делать через mod_rewrite.
Насчет менюшек в CMS...
Ведь можно использовать включения в шаблон PHP-скриптов. Сделать так, чтобы у разработчиков была возможность работы с шаблонами, а у юзеров нет. Тогда можно валить в шаблоны любой PHP-код, в том числе и генерацию менюшек.
defresto
Guest
Предлагаю всё таки разделить на CMS и CMS2
Обсуждение технологий это конечно хорошо, но зачем нужен любой тип CMS? Чтобы экономить деньги!!!
- на разработку сайта
- на поддержку сайта
Я смотрю на всё несколько через другую призму:
Меня интересует не как создать крутую универсальную систему, а иметь в багаже готовые решения, чтобы в конечном итоге съэкономить ДЕНЬГИ!
Поэтому предлагаю всё таки разделить:
CMS1 - для стандартных корпоративных страничек со стандартным джентельменским набором. Система расчитаная на то, чтобы веб-дизайн студия не имеющая в своей команде программиста (это ОЧЕНЬ частое явление особенно для запада) могла легко создавать стандартные небольшие сайтики с возможностью редактирования и добавления контента.
чтобы система была конкурентноспособной:
- человек ХОРОШО знакомый с хтмл должен быть в состоянии легко и быстро сделать шаблоны и каркас
- время разработки шаблонов и каркаса не должно быть больше, чем создавать весь сайт втупую в хтмл
- время на обучение не должно превышать 4 часа
CMS2 - система управления контентом крупных порталов.
Система, которой управляет ПРОГРАММИСТ. Задача: сделать всё максимально топорно и гибко. Съэкономить время программиста работающего над созданием и поддержкой проекта.
Чтобы система была конкурентоспособной она должна:
- быть сырцом, который можно максимально просто настроить
- не жрать ресурсов сервера больше чем в 1.5 раза, чем пхп
- иметь большое кол-во модулей
- время на подключение и настройку модуля не должно превышать 40 минут
Давайте сначала разберёмся с тем что мы все понимаем под CMS... Если у кого-то есть возражения по классификации предложенной мной прошу предложить другие варианты, а затем продолжим разговор уже ссылаясь на конкретный класс системы.
То, как меню создается и то, как оно будет потом выглядеть - вещи между собой не связанные
Естесственно. Но для CMS1 обязательно нужна простая система построения меню. Для CMS2 она только помешает это легче и надёжнее сделать вручную.
[/B]крупный ресурс, который менял бы свой дизайн[/B]
Естественно нет. Но рано или поздно такой момент обязательно настанет!!! И если изначально не продумать вопрос смены дизайна ресурса с более 50 подпорталами это превратиться в ад кромешный. Я работаю как раз с контент порталами и уже наступал на такие грабли... Структура крупного сайта, хотя бы частично, меняется постоянно. Просто изменения незначительны и их не видно если не ходишь на ресурс ежедневно.
[/B]Прочие вещи, типа того же редактора содержимого меню[/B]
продать CMS1 без этой вещи нереально, а кроме того подобная штука снижает время разработки.
Error 404
я спецом спросил у двух программистов оба сказали, что серваку пофигу какой ответ дать. Обработать ответ конечно нужно, но по сравнению с модреврайт это мелочь.
лента.ру
ну по поводу того, что на ленте.ру стоит руку на отсечение не дам, но знаком с механизмом одного из топ 5 новостных сайтов:
Прегенерация ХТМЛ на новостных сайтах только уменьшит нагрузку на сервер!!! Даже простой инклюд это уже нехилая нагрузка.
1. поставили крутую интеллектуальную цмс 2 сервака при 60 000 посетителей в день трещали по швам
2. сделали свою топорную с ПРЕГЕНЕРАЦИЕЙ ПОЛНЫХ ХТМЛ ФАЙЛОВ - один сервак стал справлялся без проблем. Лёгкость управления ухудшилась, но не настолько значительно, чтобы выкидывать более 2000 в месяц на второй навороченный сервак
название сайта и название цмс не называю, чтобы за зря не порочить разработчика. может на других проектах их цмс круто работала
Меня здесь упрекают в том, что я не понимаю назначение цмс.
Может быть... Я знаю только одно назначение: экономить деньги или время!
1. Если вы разработали цмс за 150 часов, а за год она вам съэкономила 50 часов, то хреновая это была идея.
2. Если вы хотите сделать даже простенькую цмс на продажу это не меньше 300 часов (учитывая и работу мэнеджеров, дизайнеров и т.д.) Сделать из разработки коммерческий продукт, который хорошо продаётся это высший пилотаж. А раз все профессионалы то цена такой разработки... Её окупить надо и минимум в 3 раза. Ещё риски есть.
........................................................
Давайте сначала:
1. сформулируем классификацию цмс
2. обсудим структуру и необходимый функционал каждой из них
3. разберёмся с технологиями
Тогда каждый из нас что то подчерпнёт для себя из этой дискуссии.
Обсуждение технологий это конечно хорошо, но зачем нужен любой тип CMS? Чтобы экономить деньги!!!
- на разработку сайта
- на поддержку сайта
Я смотрю на всё несколько через другую призму:
Меня интересует не как создать крутую универсальную систему, а иметь в багаже готовые решения, чтобы в конечном итоге съэкономить ДЕНЬГИ!
Поэтому предлагаю всё таки разделить:
CMS1 - для стандартных корпоративных страничек со стандартным джентельменским набором. Система расчитаная на то, чтобы веб-дизайн студия не имеющая в своей команде программиста (это ОЧЕНЬ частое явление особенно для запада) могла легко создавать стандартные небольшие сайтики с возможностью редактирования и добавления контента.
чтобы система была конкурентноспособной:
- человек ХОРОШО знакомый с хтмл должен быть в состоянии легко и быстро сделать шаблоны и каркас
- время разработки шаблонов и каркаса не должно быть больше, чем создавать весь сайт втупую в хтмл
- время на обучение не должно превышать 4 часа
CMS2 - система управления контентом крупных порталов.
Система, которой управляет ПРОГРАММИСТ. Задача: сделать всё максимально топорно и гибко. Съэкономить время программиста работающего над созданием и поддержкой проекта.
Чтобы система была конкурентоспособной она должна:
- быть сырцом, который можно максимально просто настроить
- не жрать ресурсов сервера больше чем в 1.5 раза, чем пхп
- иметь большое кол-во модулей
- время на подключение и настройку модуля не должно превышать 40 минут
Давайте сначала разберёмся с тем что мы все понимаем под CMS... Если у кого-то есть возражения по классификации предложенной мной прошу предложить другие варианты, а затем продолжим разговор уже ссылаясь на конкретный класс системы.
То, как меню создается и то, как оно будет потом выглядеть - вещи между собой не связанные
Естесственно. Но для CMS1 обязательно нужна простая система построения меню. Для CMS2 она только помешает это легче и надёжнее сделать вручную.
[/B]крупный ресурс, который менял бы свой дизайн[/B]
Естественно нет. Но рано или поздно такой момент обязательно настанет!!! И если изначально не продумать вопрос смены дизайна ресурса с более 50 подпорталами это превратиться в ад кромешный. Я работаю как раз с контент порталами и уже наступал на такие грабли... Структура крупного сайта, хотя бы частично, меняется постоянно. Просто изменения незначительны и их не видно если не ходишь на ресурс ежедневно.
[/B]Прочие вещи, типа того же редактора содержимого меню[/B]
продать CMS1 без этой вещи нереально, а кроме того подобная штука снижает время разработки.
Error 404
я спецом спросил у двух программистов оба сказали, что серваку пофигу какой ответ дать. Обработать ответ конечно нужно, но по сравнению с модреврайт это мелочь.
лента.ру
ну по поводу того, что на ленте.ру стоит руку на отсечение не дам, но знаком с механизмом одного из топ 5 новостных сайтов:
Прегенерация ХТМЛ на новостных сайтах только уменьшит нагрузку на сервер!!! Даже простой инклюд это уже нехилая нагрузка.
1. поставили крутую интеллектуальную цмс 2 сервака при 60 000 посетителей в день трещали по швам
2. сделали свою топорную с ПРЕГЕНЕРАЦИЕЙ ПОЛНЫХ ХТМЛ ФАЙЛОВ - один сервак стал справлялся без проблем. Лёгкость управления ухудшилась, но не настолько значительно, чтобы выкидывать более 2000 в месяц на второй навороченный сервак
название сайта и название цмс не называю, чтобы за зря не порочить разработчика. может на других проектах их цмс круто работала
Меня здесь упрекают в том, что я не понимаю назначение цмс.
Может быть... Я знаю только одно назначение: экономить деньги или время!
1. Если вы разработали цмс за 150 часов, а за год она вам съэкономила 50 часов, то хреновая это была идея.
2. Если вы хотите сделать даже простенькую цмс на продажу это не меньше 300 часов (учитывая и работу мэнеджеров, дизайнеров и т.д.) Сделать из разработки коммерческий продукт, который хорошо продаётся это высший пилотаж. А раз все профессионалы то цена такой разработки... Её окупить надо и минимум в 3 раза. Ещё риски есть.
........................................................
Давайте сначала:
1. сформулируем классификацию цмс
2. обсудим структуру и необходимый функционал каждой из них
3. разберёмся с технологиями
Тогда каждый из нас что то подчерпнёт для себя из этой дискуссии.
defresto
Guest
Я говорил о CMS1 где:
- разработчик знает хтмл, но незнает остального
- или разработчику просто нужно съэкономить время, а не делать в 125 раз меню где гаснет надпись при активном пункте
- юзер это секретарша, которой ненужно давать интерфейса меню вообще (дизайн-студиям денежка за поддержку нужна)
- юзер может только добавить новость или новый товар уже по готовому шаблону
вообще по поводу визуальных редакторов:
нафиг секретарше давать выбирать цвета?
там конечно очень красиво всё получиться...
может лучше только CSS и набор кнопок выбирающих готовый стиль?
Flying
Guest
Очевидно ты неправильно меня понял. Я не возражаю против визуального редактора "a la M$ Word" для редактирования документов (хотя я терперь не могу IE-only решения и в моей системе это будет реализовано по-другому). Но речь шла не об этом редакторе, а о редакторе визуального отображения сайта или по-другому о редакторе шаблонов. Вот он-то как раз видится мне вещью, отнюдь не необходимой, поскольку его создание с приемлемым набором функциональности обойдется очень дорого (в плане трудо- и времязатрат), а реально использоваться он будет очень редко . Проще и выгоднее иметь хорошую документацию на систему визуализации или (что еще лучше) - контракт на поддержку.
Flying
Guest
Если использовать включения в шаблон PHP-скриптов, то пропадает сам смысл использования шаблонов
Посмотри этот же thread немного раньше, этот вопрос уже поднимался.Flying
Guest
Re: Предлагаю всё таки разделить на CMS и CMS2
Соответственно, если первый раз это было сделано, то и редизайн впоследствии можно будет сделать теми же средствами.
Через mod_rewrite:
1. Apache получает запрос
2. Запускается mod_rewrite и переделывает URL запроса
3. По этому URL вызывается PHP и генерирует страницу
4. Страница отдается клиенту
Через Error 404:
1. Apache получает запрос
2. Определяется, что такой страницы нет, отдается Error 404
3. Для того, чтобы отдать Error 404 - запускается PHP, который парсит полученный запрос и отдает HTTP Header 'Location'
4. Apache получает новый запрос
5. По этому URL вызывается PHP и генерирует страницу
6. Страница отдается клиенту
Неужели ты считаешь, что двойной запуск PHP+обработка Apache'м повторного запроса съедят меньше времени, чем mod_rewrite?
Первый раз такой вопрос встает во время разработки сайта, согласен?
Соответственно, если первый раз это было сделано, то и редизайн впоследствии можно будет сделать теми же средствами.Странные программисты.... Ладно, объясню на пальцах:
Через mod_rewrite:
1. Apache получает запрос
2. Запускается mod_rewrite и переделывает URL запроса
3. По этому URL вызывается PHP и генерирует страницу
4. Страница отдается клиенту
Через Error 404:
1. Apache получает запрос
2. Определяется, что такой страницы нет, отдается Error 404
3. Для того, чтобы отдать Error 404 - запускается PHP, который парсит полученный запрос и отдает HTTP Header 'Location'
4. Apache получает новый запрос
5. По этому URL вызывается PHP и генерирует страницу
6. Страница отдается клиенту
Неужели ты считаешь, что двойной запуск PHP+обработка Apache'м повторного запроса съедят меньше времени, чем mod_rewrite?
Не только include(), а даже просто запуск любого обработчика - это уже нехилая загрузка для крупных порталов. Поэтому прегенерация HTML там, где это возможно, а также использования различного вида proxy значительно снижает нагрузку на сервер. Однако то, что подходит к примеру для новостных порталов отнюдь не подходит к примеру для интернет-магазинов и здесь существуют другие способы оптимизации нагрузки.
boka
Guest
Я не совсем понял, что ты имеешь в виду. Я как раз и говорю о том, что в систему контент-менеджмента должен быть включен визуальный редактор. Это надо делать (помимо других прочих причин) даже по той причине, что такой продукт более выигрышно выглядит по сравнению с продуктами, не имеющими визуального редактора. По-моему, все очень просто.
Мы ведь говорим об CMS, работающих на тонком клиенте. Как можно использовать внешний редактор XMetal в таком случае? И можно ли ставить секретаршам на компьютеры какой-то отдельный внешний редактор, если в самом начале этой темы обсуждалось, что даже лишний ActiveX лень ставить.
boka
Guest
В таком случае:
во-первых, это уже будет не законченный продукт, а лишь какой-то набор модулей;
во-вторых, любое изменение функциональности потребует перепахивания исходников.
Из твоих слов не видно, что ты подразумеваешь под CMS. На мой взгляд, CMS должна обеспечивать решение трех основных задач:
1. структурное построение ресурса;
2. шаблонирование стандартных элементов дизайна;
3. редактирование контентной части.
В первый пункт входит и подключение различных модулей типа новостных лент, форумов, опросов и т. д.
В принципе, если разработчик считает, что фирма сама не справится с 1-м и 2-м пунктами, то тогда можно ставить вопрос о договоре на обслуживание. 1-й и 2-й пункты обслуживаются разработчиками (через некий привилегированный аккаунт), а 3-й пункт отдается на поругание секретутке.
Но ведь совсем не обязательно вы делаете сайты компаниям, в которых всеми информационными технологиями занимаются секретарше, верно? Более-менее крупные компании, банки и др. содержат своих спецов по автоматизации, которые обслуживают бухгалтерии, компы, сети и все такое. Как правило, такие люди и первые странички для своих компаний кропают. Им то вполне под силу грамотно сопровождать сайт, когда компания созреет до серьезного подхода к сайтостроительству?
А основной целевой аудиторией CMS как раз и являются такие заказчики. Потому что те, в которых информационными технологиями заведует секретарша, вряд ли разорятся на профессиональное решение - предпочтут нанять студентов.
В принципе, я основной проблемой в построении CMS вижу следующую. Каким образом построить пользовательский интерфейс, чтобы было можно через CMS подключать различные сервисы в сложные дизайны, например, многоколоночные. Представьте себе: слева колонка с менюшкой и опросом, в центре - приветствие компании, справа - лента новостей и какие-нибудь анонсы.
Я не иею возможности ознакомиться с решениями за сотни тысяч долларов, как они там все это реализуют, а в более приземленных решениях я еще не встречал ни одного удобного, либо такое вообще отсутствует.
Лично я для себя обозначил такое решение, о котором уже говорил: создается где-нибудь в Dreamweaver сверстанная страница с тремя колонками, засовывается в качестве шаблона в соответствующее место в CMS, в него вставляются нужные функциональности в виде {news}. Другие страницы на этом же ресурсе, например, двухколоночные, создаются аналогично, только используется другой шаблон.
Flying
Guest
Не согласен. Или есть некий официальный документ, расписывающий обязательную функциональность для подобных систем? Нету такого (по крайней мере мне не попадался), а следовательно законченность продукта определяется заказчиком или разработчиками.
Не путай, пожалуйста, исходники (а точнее - код), реализующий логику работы системы и данные, определяющие визуальное отображение данных, генерируемых системой (в данном случае - шаблоны). Если система имеет правильную архитектуру, то изменение данных (в допустимых пределах) должно быть возможно без изменения кода системы. А уж изменение непосредственно логики работы системы все равно потребует редактирования кода, реализующего эту логику, тут иначе никак.
Я подразумеваю 1+3 по твоему списку. 2 не имеет смысла реализовывать, я это уже не раз повторил.
Со пунктом 2 вообще может справиться только человек, имеющий соответствующую подготовку и знания. В противном случае тебе просто стыдно будет указать этот работающий сайт в своем портфолио - не зная, можно таких дров наломать, что прям страшно. Поэтому повторяю еще раз - реализация редактирования именно данных, отвечающих за визуализацию не нужна и может быть даже вредна. Ну вот вашему дизайнеру было бы приятно, если бы он увидел сайт с его дизайном, но перекрашенный в какие-нибудь дикие цвета, с измененными фрифтами и т.п. ? Стал бы ты показывать такой сайт своим заказчиком как пример работы вашего дизайнера? Практически уверен, что нет. А ведь именно такой результат и будет в большинстве случаев, когда неподготовленным людям доверяется изменение внешнго вида. Надеюсь теперь понятно объяснил?
Я бы мог показать тебе сайт, который я сделал для одной питерской фирмы (в которой в то время работал) и которая занимается не чем-нибудь а именно разработкой софта, в том числе и для web. Так что можешь не сомневаться, специалистов там хватает. Но не покажу, потому что мне будет стыдно - он совсем не похож на то, как он выглядел вначале именно по причине кривых рук этих "специалистов". А во многих других случаях результат может быть еще хуже.
Кстати, вот тебе пример: небезызвестная тебе корпорация Micro$soft выполнила редизайн сайта своего российского отделения. Казалось бы у них проблем со специалистами вообще нет, однако делали редизайн не они, а студия Лебедева. Странно, не правда ли? Что же, у Micto$oft денег нет на покупку нормального CMS? Есть конечно, да и свой собственных CMS я думаю у них очень неслабый, чтобы такой портал контролировать. Тогда в чем дело? Ведь судя по твоим доводам они легко могли все сделать сами. Подумай...
А это уже от маркетинга зависит.
У тебя какие-то проблемы с терминологией... Из-за этого, наверное, и непонимание. То, что ты сейчас описал, это layout страницы, а не дизайн. Дизайн - это то, как визуально отображается каждый элемент страницы, это цветовая гамма, это шрифты. Layout тоже относится к общему дизайну, но грамотный дизайн может позволять менять layout, если есть такая необходимость.
Как я уже сказал - это именно layout. А дизайн - это то, что у тебя внутри "тега" {news}