Коммерческие CMS и их перспективы

[VicBarrett]

Автор оригинала: itprog
+1
ZF пока тоже кубики.

Про Zend Framework я ничего и не говорю - честно говоря руки ещё не дошли посмотреть

-~{}~ 21.11.06 20:19:

Автор оригинала: HraKK
VicBarrett
Уважаемый, если вы хотите поставить мне в упрек мою молодость, то боюсь Вам этого не получится сделать.

И если Вы мне докажите верность этого утверждения:

То я лично создам топик что я осёл.

Вы хотели услышать мнение, Вы его услышали. Если же это мнение не совпадает с тем что Вы ожидали - что ж это так сказать не мои половые проблемы.

А пока предлагаю вам привести конструктивные аргументы.

-~{}~ 21.11.06 18:08:

И вообще переход на личности тут не приветствуется, поэтому прекращаем флеймить в этом направлении.

ЗЫ но аргументы я все же жду.

Я ничего не хочу поставить вам в упрёк - всего лишь желаю вам посмотреть на обсуждаемый вопрос без присущего молодости максимализма и законного желания самоутвердиться.

По поводу "CMS нужна в первую очередь разработчикам" ...

Я не буду вам это доказывать - это зависит от проекта - иногда это больше нужно разработчику иногда конечному пользователю. Хотя, будучи разработчиком я склюняюсь к тому что это действительно нужно больше нам.

Аргументы? Да сколько угодно - огромный временной выйгрыш как при создании так и при поддержке/модификации, надёжность работы и низкое число багов, богатые функциональные возможности системы, удовольствие от того что ты делаешь красиво а не лишь бы работало (лично для меня это очень важный фактор)

-~{}~ 21.11.06 20:30:

Автор оригинала: Alexandre
asp.net frameworks - только вместе со студией. Без студии - это тоже кубики. Про руби не скажу - не наю.
так что кубики- кубикам рознь. А мы вообще о чем говорим? И какая идея должна быть во фреймворке? чем phpmvc - не фреймворк, чем плоха архитектура? Какая есть идея в asp.net frameworks ? наличие серверных элементов ( аналог тегов JSP) - то это было уже, слизанная идея. Наличие серверных обработчиков WEBForms? для пхп - это тяжеловато пока...пхп - интерпретируемый язык, это надо встраивать в ядро. в чем идея asp.net frameworks ?

Александр мне действительно очень сложно вот так вот в двух словах объяснить что хорошего в ASP.net - я очень посоветовал бы вам поработать на нём - создать несколько проектов - уверен возвращаясь к PHP проектам вы сможете преимствовать большое колличество красивых решений и подходов. Как пример, из того что преимствовал я - до моего опыта работы с дот нет маркеры темплейтового движка принимают строчный параметр (подстановки), после они принимаю также и объекты (с параметрами которые можно задать в описании маркера) а объект уже рендериться согласно логике, праметрам и т.д.

К вопросу а фрэйворк ли это вообще - безусловно. Аsp.net формирует стиль, подход и методологию работы.

 

[HraKK]

No comment.
Я такие аргументы даже не хочу коментировать. Понимаю что они проудут мимо ушей. ладно меня тут не было.

 

[Alexandre]

что хорошего в ASP.net - я очень посоветовал бы вам поработать на нём

второй год как работаю, так что есть с чем сравнивать

Аsp.net формирует стиль, подход и методологию работы

+1 согласен, однако и Вы, VicBarrett не можете согласиться со мной, что ASP.net без студии - это ничего особенного и много гемороя.

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

две идеалогически разные системы, ну не вижу я идей для взаимствования из ASP.net . Была у меня год назад идея написать класс аналог __VIEWSTATE. На большее фантазии не хватило, вернее, чего хотелось бы - надо переписывать ядро пхп, как я уже говорил... а Прадо, по этой причине - жутко тормозит. Идея Контролов - частично реализована в смарти. А я вообще хочу использовать только модульный шаблонизатор (ищу разные решения).

до моего опыта работы с дот нет маркеры темплейтового движка принимают строчный параметр (подстановки), после они принимаю также и объекты

Если поглубже познакомиться с объектами в пхп - то они реализованны как обычные хештаблицы. В силу тормознутности пхп-движка при работе с объектами, возможно это решение при больших нагрузках не оптимально.
Хотя всегда должен быть компромич удобно/производительно.