-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Ну, девелоперы, колитесь!
- Автор темы pachanga
- Дата начала
Novice
Guest
Ок, уговорил, больше не буду мучить 
defresto
Guest
вернёмся к вопросу что лучше
Все сошлись на мнении, что мне цмс не нужно. Если бы было так я бы не тратил время на обсуждения этого вопроса. Просто вопрос "цена разработки" очень важен, а я ещё не видел цмс, которая должна по идее экономить деньги и время, которая была бы не просто "крутой", а справлялась бы с этой задачей
Итак прозвучали мнения, что инки енто 18 век. Что тут возразить... Да на лошадь плуг и вперёд... Зато пашет быстро и без проблем.
Отсюда предлагаю обсудить:
Для каких проектов имеет смысл использовать не инки, а что либо более накрученное?
Моё мнение:
ЦМС имеет смысл вставлять только в зверские порталы для того, чтобы можно было менять дизайн из одного места. И то использовать по возможности наиболее простую структуру.
Для проектов не претендующих на мегапортальность инки вполне подойдут так как позволяют элементарно менять дизайн и структуру отредактировав 2-3 темплейта.
Для сайтов фирм вполне можно добавить к инкам маленький
- редактор позволяющий добавлять разделы и подразделы
- визуальный дхмл редактор текстов используюя цсс сайта
Ну втолкуйте ламмеру плиз чем навороченная CMS лучше тракторных инков и нескольких готовых скриптов решающих стандартные проблемы? Ведь прикрутить готовый скрипт это 5 минут...
Если нужно сделать так, чтобы секретарша добавляла текст то добавить маленький визуальный дхмл редактор дело 15 минут... И сделав этот редактор один раз можно использовать его во всех проектах не забивая ненужными функциями.
Мне знакома одна студия, которая делала свою супер ЦМС в конце концов они пришли к тому, что для того, чтобы описать весь проект в этой ЦМС программисту приходилось тратить по 2 недели... Да! Потом всё работало супер, но цена разработки маленького сайта была слишком высока.
ИМХО любая ЦМС должна быть максимально простой и содержать минимум встроенных функций, но быть масштабируемой и иметь модули которые можно встраивать.
Лирическое отступление...
Тёма парсер, конечно хорошая штука, но чем он в корне отличается от пхп я не вижу... Парсер это тоже в своём роде язык программирования, но вопрос: зачем учить менеджеров и дизайнеров кастрированному языку ЦМС? Не настолько мы тупы, чтобы не понять элементарного синтаксиса пхп.
Я не пытаюсь убедить Вас, что инки это супер!
Я спрашиваю что лучше инков и главное почему???
Инки + пару добавочных модулей это и есть простейшая ЦМС!
ЗЫ главная проблема всех ЦМС, что если усложнять её функциональность мы получаем новый язык програмирования только с другим синтаксисом... Если не усложнять то получим что то кастрированное и малоприменимое.
Кстати то окошко в котором мы пишем здесь и есть редактор кода! Вот он! Воткнуть его и пусть сохраняет код в виде инка!
Все сошлись на мнении, что мне цмс не нужно. Если бы было так я бы не тратил время на обсуждения этого вопроса. Просто вопрос "цена разработки" очень важен, а я ещё не видел цмс, которая должна по идее экономить деньги и время, которая была бы не просто "крутой", а справлялась бы с этой задачей
Итак прозвучали мнения, что инки енто 18 век. Что тут возразить... Да на лошадь плуг и вперёд... Зато пашет быстро и без проблем.
Отсюда предлагаю обсудить:
Для каких проектов имеет смысл использовать не инки, а что либо более накрученное?
Моё мнение:
ЦМС имеет смысл вставлять только в зверские порталы для того, чтобы можно было менять дизайн из одного места. И то использовать по возможности наиболее простую структуру.
Для проектов не претендующих на мегапортальность инки вполне подойдут так как позволяют элементарно менять дизайн и структуру отредактировав 2-3 темплейта.
Для сайтов фирм вполне можно добавить к инкам маленький
- редактор позволяющий добавлять разделы и подразделы
- визуальный дхмл редактор текстов используюя цсс сайта
Ну втолкуйте ламмеру плиз чем навороченная CMS лучше тракторных инков и нескольких готовых скриптов решающих стандартные проблемы? Ведь прикрутить готовый скрипт это 5 минут...
Если нужно сделать так, чтобы секретарша добавляла текст то добавить маленький визуальный дхмл редактор дело 15 минут... И сделав этот редактор один раз можно использовать его во всех проектах не забивая ненужными функциями.
Мне знакома одна студия, которая делала свою супер ЦМС в конце концов они пришли к тому, что для того, чтобы описать весь проект в этой ЦМС программисту приходилось тратить по 2 недели... Да! Потом всё работало супер, но цена разработки маленького сайта была слишком высока.
ИМХО любая ЦМС должна быть максимально простой и содержать минимум встроенных функций, но быть масштабируемой и иметь модули которые можно встраивать.
Лирическое отступление...
Тёма парсер, конечно хорошая штука, но чем он в корне отличается от пхп я не вижу... Парсер это тоже в своём роде язык программирования, но вопрос: зачем учить менеджеров и дизайнеров кастрированному языку ЦМС? Не настолько мы тупы, чтобы не понять элементарного синтаксиса пхп.
Я не пытаюсь убедить Вас, что инки это супер!
Я спрашиваю что лучше инков и главное почему???
Инки + пару добавочных модулей это и есть простейшая ЦМС!
ЗЫ главная проблема всех ЦМС, что если усложнять её функциональность мы получаем новый язык програмирования только с другим синтаксисом... Если не усложнять то получим что то кастрированное и малоприменимое.
Кстати то окошко в котором мы пишем здесь и есть редактор кода! Вот он! Воткнуть его и пусть сохраняет код в виде инка!
Crazy
Developer
Проблема не в CMS. Проблема в том, что ты не понимаешь ее функций.
Простые вопросы: как помогут тебе инклуды в решеении следующих задач?
1. Обеспечение версионности контента. Не забываем, что параллельно нужно обеспечивать версионность, к примеру, плагинов для отображения контента.
2. Организация workflow.
3. Сбор и анализ статистики.
А на вопрос "что лучше инков и главное почему???" тебе никто не ответит, ибо вопрос лишен смысла.
Простые вопросы: как помогут тебе инклуды в решеении следующих задач?
1. Обеспечение версионности контента. Не забываем, что параллельно нужно обеспечивать версионность, к примеру, плагинов для отображения контента.
2. Организация workflow.
3. Сбор и анализ статистики.
Да. Причем "инки" здесь совершенно лишенее понятие.
А на вопрос "что лучше инков и главное почему???" тебе никто не ответит, ибо вопрос лишен смысла.
defresto
Guest
ок логично начнём с самого началане понимаешь ее функций.
CMS система управления контентом
какие ей ещё функции нужны кроме управления контентом?
космические корабли запускать?
тады давай разделим:
1. CMS - собственно система управления КОНТЕНТОМ сайта
2. CMS2 - система управления запуском космического шатла
CMS - должна позволять легко управлять контентом сайта, менять дизайн, модерить форумы и т.д. Естественно, что CMS должна решать задачи стандартные для большинства проектов. Но должна ли она иметь кучу встроенных дополнительных функций и сложную структуру?
Отсюда вопрос: какие задачи должна выполнять CMS2?
1. Обеспечение версионности контента.
ну по ламмерски приму версионность например за язык
ну и $language-$content.inc
версионность плагинов для отображения контента
инка для отоброжения недостаточно? нужен актив-х и прочая гадость? или просто это не слишком круто? или я ламмернул и не врубился про версионность контента...
2. Организация workflow.
то есть если добавить нужный модуль то на пхп реализовать всё равно никак низя? или намного сложнее воткнуть этот модуль когда нужно, а не нести его по всем страницам васей пупкиных...
3. Сбор и анализ статистики.
элементарно ставим счётчик загоняем логи в файл (если уж хостер не даёт гад логи брать) и вытаскиваем из них те параметры, которые нам нужны.
Совсем недавно делали системку, которая помимо обработки заказов и выплаты партнёрам должна была считать эффективность баннеров. Отчётов по статистике там выше крыши. Именно так и сделали. На всё про всё ушло 5 часов работает как трактор. А быстро потому что модуль счётчика и анализа был уже написан, а на то чтобы воткнуть его и сформировать нужные отчёты ушло минут 10.
[/B]Да. Причем "инки" здесь совершенно лишенее понятие.[/B]
Ну обшибся звиняете. Собственно вопрос не в инках, а в том зачем куда то дёргаться от пхп, если и так всё хорошо. Я имею ввиду: имеет ли смысл набивать все модули в одну систему или лучше держать их отдельно, прикручивая по мере необходимости?
А на вопрос "что лучше инков и главное почему???" тебе никто не ответит, ибо вопрос лишен смысла.
Ок перефразирую:
Чем навороченная CMS лучше простенькой тракторной на инках с дополнительными модулями, которые можно встраивать?
Чем фасттемплейт лучше своих темплейтов?
Чем ХМЛ-ХЛТ лучше, чем фасттемплейт?
.............................
Предлагаю следующий вопрос:
- какие функции должна выполнять CMS
- какие функции должна выполнять CMS2
- имеет ли смысл втыкать всё что может понадобиться когда либо сразу? или лучше сделать простенький каркас и добавлять к нему нужные модули как например подключаемые библиотеки?
-------------------------------------------------
Всем кто может воспринять мои посты "в штыки"
- я не пытаюсь выебнуться
- я не пытаюсь доказать, что CMS никому нафиг не нужна
Я пытаюсь понять:
- для каких проектов насколько навороченная цмс нужна
- нужна ли цмс мне
И ставлю вопрос для обсуждения:
Имеет ли смысл забивать CMS кучей функций сразу или лучше сделать простенький каркас и добавлять нужные модули?
Не лучше ли все работы по добавлению модулей оставить программистам, а секретарша пусть только тексты набивает?
Dexter
Guest
To defresto
Сори если слышется раздражение в тексте.. большинство ответов на поставленные ворпосы уже были вверх по теме.
--------------------------------
CMS снимает гораздо больше проблем по поддержанию сайта непрофессионалом, чем т.н. .inc А это бережет Ваши нервы и время.
Берегите Ваши нервы и время.
Тем, что CMS пишется 1 раз... а используется много для разных проектов. И то что она "навороченная" отнюдь не означает, что ее долго и сложно устанавливать, или она не готова к работе сразу после установки.
Необязательно жестко встраивать. Backoffice - отдельный движок. Исполняемый на front - отдельный и дергает нужные плагины в зависимости от функцилнала раздела. Последний может быть весьма маленьким и эффективным.
От аппетитов зависит и от возможностей мозговых... Чем больше идей по удалению рутины при создании веб-проектов тем большими возможностями можно наградить CMS
Я не вижу проблемы в упор. Инсталлировать новый плагин в CMS 1 мин. Тебе что - западло пагин из списка выпадающего выбирать или обязательно руками набирать. Никогда не задумывался, что человек ошибается а машина нет. Чем меньше "ручной" работы - тем выше качество результата.
х.з. незнаю.
Не знаю "навороченная" ли по твоим мерркам моя CMS, но я вчера получил от друга заказ на оч. простенький сайт. 7 страничек, вверху полоска с сылками. Я не задумываясь ему сказал... только на моем движке. Ответ: для _ЛЮБЫХ_, особенно если вы выпустили в мир много проектов и не хотите, чтобы по ночам звонили заказчики.
Повторюсь - добавить готовый модуль сможет даже школьник. это вообще не вопрос для обсуждения.
Сори если слышется раздражение в тексте.. большинство ответов на поставленные ворпосы уже были вверх по теме.
--------------------------------
CMS снимает гораздо больше проблем по поддержанию сайта непрофессионалом, чем т.н. .inc А это бережет Ваши нервы и время.
Берегите Ваши нервы и время.
Grey_EM
Guest
Я предлагаю взглянуть на дискуссию совершенно с другой стороны. Вот ты crazy и оратор, которому ты отвечаешь, по видимому совершенно не понимаете друг-друга. Дела все видимо в уровне опыта. Ситуация похожа на проблему объяснить слепому с рождения что такое красный цвет. У него нет никаких ассоциаций насчет того что ты ему говоришь. Это сказано не с целью унизить кого-то, а с целью просто поставить проблему. Может и не надо никаких сложностей реализовывать при помощи php? Может оставить php разработку "наколенных" и "write once and forget" проектов? Ведь в конце концов есть ява, прекрасно справляющаяся с разработкой сложных вэб аппликаций. (честно говоря их на ней и перле в основном и пишут ). Зачем использовать php для проектов где можно воспользоваться явой, перлом? У разработчиков ява аппликаций редко возникают вопросы нужна cms или нет. Короче где место php в вэб разработке? Стоит ли замахиваться скажем писать контентную систему на скриптовом языке, стоит ли использовать объектный подход в разработке? Не оставить ли место php в проектах 2-3 дневной длительности и описывающихся схемой "поговорил с клиентом, написал, сдал, деньги пропил - клинета забыл навсегда"?Автор оригинала: Crazy
Проблема не в CMS. Проблема в том, что ты не понимаешь ее функций.
Простые вопросы: как помогут тебе инклуды в решеении следующих задач?
1. Обеспечение версионности контента. Не забываем, что параллельно нужно обеспечивать версионность, к примеру, плагинов для отображения контента.
2. Организация workflow.
3. Сбор и анализ статистики.
Да. Причем "инки" здесь совершенно лишенее понятие.
[skip]
tony2001
TeaM PHPClub
>Зачем использовать php для проектов где можно
>воспользоваться явой, перлом?
а также C, C++, SmallTalk, Python и далее по тексту.
это вопрос надо воспринимать серьезно ?
тогда этот вопрос УЖЕ является диагнозом с направлением в желтый дом.
>Не оставить ли место php в проектах 2-3 дневной длительности...
гхм, пойду говорить клиентам, что их проекты - это проекты на два дня. думаю, что они будут очень рады =(
>воспользоваться явой, перлом?
а также C, C++, SmallTalk, Python и далее по тексту.
это вопрос надо воспринимать серьезно ?
тогда этот вопрос УЖЕ является диагнозом с направлением в желтый дом.
>Не оставить ли место php в проектах 2-3 дневной длительности...
гхм, пойду говорить клиентам, что их проекты - это проекты на два дня. думаю, что они будут очень рады =(
Dexter
Guest
To Grey_EM
Вопросик.
Не ставил яву и перл для проектов 2-3 дневной длительности или очень нравится закладываться на годы?
И еще момент... Не заглядывал в адресную строку браузера, когда писал свой постинг?
Здесь полностью сагласен. Уже об этом сам писал.
Комуто не надо... кому-очень надо. IMHO вопрос предпочтений.
Ну и ну... Без обид... А почему не ява и JSP? (перл тут как-то неожиданно появился) А почему не на Lotus Domino. Тоже оч. мощьно. Перефразирую... - зачем использовать яву и перл для проектов где можно воспользоваться php? Да потому-что огромное количество сайтов (на мой взгляд подавляющее) спокойно реализуются на РНР. Т.е. я хочу сказать что выбор PHP в подавляющем кол-ве случиев оправдан многоими причинами. Конечно есть границы его применимости... но вообще-то они стремительно расширяются.
Вопросик.
Не ставил яву и перл для проектов 2-3 дневной длительности или очень нравится закладываться на годы?
И еще момент... Не заглядывал в адресную строку браузера, когда писал свой постинг?
Dexter
Guest
То Crazy
не нужна ??? Мне? Не понял... это из каких _МОИХ_ высказываний следует? Имхо тут мистейк какойто....
Dexter
Guest
То Crazy
Вот и мне казалось - мы по одну сторону баррикад.
Вот и мне казалось - мы по одну сторону баррикад. boka
Guest
Всем привет!
Только что присоединился, а жаль - дискуссия очень интересная и животрепещущая (для меня).
С Dexter'ом полностью согласен насчет того, что с определенного количества сделанных работ начинаешь думать о том, как бы автоматизировать разработку более-менее стандартных фишек в сайтах. У меня на счету два разработанных портала и около двух десятков сайтов. Порталы штука такая, что существующими CMS'ами их реализовать невозможно, или, по крайней мере, их надо планировать изначально таким образом, чтобы можно было реализовать конкретным CMS'ом. Естественно, я имею в виду не те CMS'ы, которые стоят по миллиону долларов.
А вот для всех сайтов приходилось делать очень часто одно и то же.
Кстати, Dexter, в твоей CMS я тоже так и не нашел WYSIWYG-редактора. А иконки классные...
Хочу показать мой WYSYWYG-редактор, который я собираюсь прикрутить к разрабатываемой мной же CMS.
http://demo.eduman.ru
Сделано с использованием iframe с выставленным параметром designMode=on. Хотя собираюсь переделать под использование объекта clsid:2D360201-FFF5-11D1-8D03-00A0C959BC0A, так как он дает больше возможностей. Например, контекстные меню и др.
У меня тут есть пара тем для обсуждения, касаемых принципиальных вопросов построения CMS. Постараюсь сформулировать их завтра, а то сейчас некогда.
А пока такой вопрос. Как считаете, какой вариант лучше:
1. чтобы в админке все писалось в БД, а в самом сайте URL типа .../about/history/ разбирался на лету (вместо index.php?subject=about&action=history), и на основе собранных переменных бралась выборка из БД.
1. чтобы админка генерировала файлы index.phtml в директориях типа .../about/history/, а в самом сайте URL разбирать не нужно.
Один продвинутый человек мне советует пойти по второму пути. А мне более симпатичен первый.
Кстати читайте в свежем Компьютер-Прессе обзор зарубежных CMS (как раз те, которые по миллиону долларов).
Там наверху писали, что "а вот если клиент хочет только форму новостей, да и то textarea". Это, естественно, утрировано, так как под такую задачу никто не станет цеплять CMS. Но если задача достаточно проста, то модульная структура CMS позволит просто отключить ненужные модули (или вообще их не инсталлировать). А если не хотите дарить жадному клиенту WYSYWYG-редактор, то и опции соответствующие можно предусмотреть, включать его или нет. Это ж все элементарно, и нисколько не умаляет достоинств CMS. А такую штуковину каждая студия сейчас должна иметь. Конкурентноспособность, понимаешь, это не пустые слова.
Полазил поискал отечественные разработки. Нашел около трех десятков. Большинство их них стоят в диапазоне 1000-2500. Причем, значительное количество дорогих CMS - полное фуфло (по функциональности).
Только что присоединился, а жаль - дискуссия очень интересная и животрепещущая (для меня).
С Dexter'ом полностью согласен насчет того, что с определенного количества сделанных работ начинаешь думать о том, как бы автоматизировать разработку более-менее стандартных фишек в сайтах. У меня на счету два разработанных портала и около двух десятков сайтов. Порталы штука такая, что существующими CMS'ами их реализовать невозможно, или, по крайней мере, их надо планировать изначально таким образом, чтобы можно было реализовать конкретным CMS'ом. Естественно, я имею в виду не те CMS'ы, которые стоят по миллиону долларов.
А вот для всех сайтов приходилось делать очень часто одно и то же.
Кстати, Dexter, в твоей CMS я тоже так и не нашел WYSIWYG-редактора. А иконки классные...
Хочу показать мой WYSYWYG-редактор, который я собираюсь прикрутить к разрабатываемой мной же CMS.
http://demo.eduman.ru
Сделано с использованием iframe с выставленным параметром designMode=on. Хотя собираюсь переделать под использование объекта clsid:2D360201-FFF5-11D1-8D03-00A0C959BC0A, так как он дает больше возможностей. Например, контекстные меню и др.
У меня тут есть пара тем для обсуждения, касаемых принципиальных вопросов построения CMS. Постараюсь сформулировать их завтра, а то сейчас некогда.
А пока такой вопрос. Как считаете, какой вариант лучше:
1. чтобы в админке все писалось в БД, а в самом сайте URL типа .../about/history/ разбирался на лету (вместо index.php?subject=about&action=history), и на основе собранных переменных бралась выборка из БД.
1. чтобы админка генерировала файлы index.phtml в директориях типа .../about/history/, а в самом сайте URL разбирать не нужно.
Один продвинутый человек мне советует пойти по второму пути. А мне более симпатичен первый.
Кстати читайте в свежем Компьютер-Прессе обзор зарубежных CMS (как раз те, которые по миллиону долларов).
Там наверху писали, что "а вот если клиент хочет только форму новостей, да и то textarea". Это, естественно, утрировано, так как под такую задачу никто не станет цеплять CMS. Но если задача достаточно проста, то модульная структура CMS позволит просто отключить ненужные модули (или вообще их не инсталлировать). А если не хотите дарить жадному клиенту WYSYWYG-редактор, то и опции соответствующие можно предусмотреть, включать его или нет. Это ж все элементарно, и нисколько не умаляет достоинств CMS. А такую штуковину каждая студия сейчас должна иметь. Конкурентноспособность, понимаешь, это не пустые слова.
Полазил поискал отечественные разработки. Нашел около трех десятков. Большинство их них стоят в диапазоне 1000-2500. Причем, значительное количество дорогих CMS - полное фуфло (по функциональности).
Dexter
Guest
To boka
Велком!!!
Редактор открыввется как раз иконкой неудачной...
Приредактировании наполнения - слева от больших полей сесть серый гифчик в виде кубика. При нажатии рождает еще одно popup окошко с редакторов в которые я добавил спец функции типа очистка от "загазнений" при вставке из MSWORD т и.п.
Общий прицып позволяет восстановить весь сайт из бд (ну почти весь.. шаблоны не сможет)
Агоритм такой.
1. Главный движок обычно лежит в руте. он делает все главные запросы в БД
2. CMS при создании раздела (/about/history/ ) сама создает папку history, генерит там index.php в котором:
a) Id - pаздела в базе
б) функия определения пути до рута.
B) Вызов главного движка как include
Достигается офигенная гибкость.
Легко переименовывать папки... И переносить ветки сруктуры под любого родителя, что отражается в базе и файловой структуре сайта.
Можно менять главный движок... о плагинах я и не говорю.
Я уже вынашиваю планы радикальной переделки с принцыпиально новыми дополнениями.
С обзорами у мнея фигово. Времени не зватает. Смотрел только http://www.openeffect.com/?107
но они не сделали версию под win32 а до тех пор не буду врубатся.
Велком!!!
Спасибо на добром слове.
Редактор открыввется как раз иконкой неудачной...
Приредактировании наполнения - слева от больших полей сесть серый гифчик в виде кубика. При нажатии рождает еще одно popup окошко с редакторов в которые я добавил спец функции типа очистка от "загазнений" при вставке из MSWORD т и.п.
Я решил проблему на мой взгляд очень удачно.
Общий прицып позволяет восстановить весь сайт из бд (ну почти весь.. шаблоны не сможет)
Агоритм такой.
1. Главный движок обычно лежит в руте. он делает все главные запросы в БД
2. CMS при создании раздела (/about/history/ ) сама создает папку history, генерит там index.php в котором:
a) Id - pаздела в базе
б) функия определения пути до рута.
B) Вызов главного движка как include
Достигается офигенная гибкость.
Легко переименовывать папки... И переносить ветки сруктуры под любого родителя, что отражается в базе и файловой структуре сайта.
Можно менять главный движок... о плагинах я и не говорю.
Я уже вынашиваю планы радикальной переделки с принцыпиально новыми дополнениями.
С обзорами у мнея фигово. Времени не зватает. Смотрел только http://www.openeffect.com/?107
но они не сделали версию под win32 а до тех пор не буду врубатся.
Grey_EM
Guest
Тони только не будем начинать в holy war. Незачем это
Я собственно в контексте вэб разработок речь веду.
C, C++, SmallTalk сразу отметается.
А вот Python очень даже подходит. И скажем судя по zope подходит и для очень больших проектов. Можешь мне указать на реализацию подобную zope только на php? Ы? (сразу скажу что phpnuke не дорос еще).
угу. Я обычно смайлики ставлю в спорных местах
А по существу? Ты все-таки подумай над тем что я написал. Еще раз, в чем преимущество php в крупных проектах перед той же скажем явой. Только серьезно, без фанатизма. В крупных : более 3 человеко-лет или более 10000$ стоимостью.
Думаю общение с клиентом и реальная оценка состояния дел не одно и тоже. Ты что думаешь я не умею парить клиентов?
Grey_EM
Guest
Domino не удобно. Не то у него предназначание.
Ну как минимум потому что очень часто к php у инвесторов очень подозрительное отношение. "На чем предполагаете реализовывать? На php? А кто за ним стоит? Open-source? Понятно." Все тендер проигран, так как слово sun в данной ситуации весит гораздо больше.
[skip]
Grey_EM
Guest
Хорошо добавляем smalltalk
Dexter
Guest
Grey_EM
кпирую тему в верху данной страницы
Я же работаю в данный момент в компании, кторая создает портал с клиетским приложением на Java. Сайт сейчас на JSP.
Так вот я собираюсь переписать сайт на PHP и сделать ему CMS.
Тебе не кажется, что "клиент" с таким уровнем познаний сам все напишет. Или действительно будет использовать готовое решение за большие бабки, если речь идет о корпоративном имидже. Я уже говорил:
Ну и что... прикажете выбирать между пушкой и ракетой земля-земля идя на охоту на уток?
кпирую тему в верху данной страницы
Создайте топик "Как замечательно мне стало жить и работать, когда я вырос из коротких штанишек и забил на PHP!" и отрывайтесь там на полную.
Я же работаю в данный момент в компании, кторая создает портал с клиетским приложением на Java. Сайт сейчас на JSP.
Так вот я собираюсь переписать сайт на PHP и сделать ему CMS.