Re: И все таки CMS для сайтов это УГ.

Не все УГ, но для весьма посещаемых проектов требуют допилки или переделывания. Конечно, можно потратить газиллион времени и сделать с нуля, но для proof of concept CMS очень неплохи.

Re: И все таки CMS для сайтов это УГ.

>Как считаете?
Да так и считаем. Только стоит учесть, что бывают ситуации, когда очень надо что-то быстро сделать, а времени нет. Потому некоторые берут CMS.

Впрочем, обычно потом это всё равно создаёт проблемы.

Re: И все таки CMS для сайтов это УГ.

> бывают ситуации, когда очень надо что-то быстро сделать, а времени нет. Потому некоторые берут CMS.
Это "что-то" ведь тоже будет CMS, так чем уже готовая и отлаженная хуже..

Re: И все таки CMS для сайтов это УГ.

>Это "что-то" ведь тоже будет CMS, так чем уже готовая и отлаженная хуже..
Они обычно отлажены только в том виде, в котором их хотели видеть разработчики. Как только появляется требование сделать что-нибудь не так, возникают проблемы. Иногда надо кучу основного кода переписать, чтобы сделать какую-нибудь простую штуку, которая в "самописном" проекте была бы сделана легко.

Некоторые CMS без костылей не позволяют сделать даже достаточно распространённые вещи. А костыли - это проблемы в будущем, тем более времени на всё это тратится иногда поболее, чем на написание с нуля.

P.S. "С нуля" - я не имею ввиду совсем с нуля, естественно, нужно и полезно использовать чего-то готовое, отлаженное и проверенное:)

Re: И все таки CMS для сайтов это УГ.

>Это "что-то" ведь тоже будет CMS, так чем уже готовая и отлаженная хуже..
Да любой сайт с админкой, который работает с контентом через web интерфейс, а не забиваешь данные вручную в БД уже полноценная CMS по своей сути. Но если проект небольшой, то зачем на сервер селить универсального, неповоротливого и тормозного монстра, в котором так или иначе но придется разбираться во всех тонкостях, если проще набыдлокодить сразу под свои нужды, начиная от дизайна, заканчивая нужно функциональностью под определенный проект.

А с готовой CMS начинаются проблемы сразу, во первых дизайн, шаблон который подходит для проекта как правило не найдешь из готовых они все или по разметке и колонкам не подходят под твои нужды, или которые тебе понравятся как назло фиксированные по ширине, или вообще по дизайну не подойдут, как правило сразу же нужно писать свой шаблон, а писать свой шаблон это уже изучение тонкостей CMS начинается, а если какую-то свою функциональность добавить в готовую CMS, то тут начинается вообще кошмар.

Re: И все таки CMS для сайтов это УГ.

> Иногда надо кучу основного кода переписать, чтобы сделать какую-нибудь простую штуку, которая в "самописном" проекте была бы сделана легко.
Легко только потому, что ты знаешь как он устроен, а чужую систему ещё изучать надо. А лет через пять поди вспомни что ты там почти снуля наываял в том проекте.. Особенно наверное трудно профессиональным сайтолепильщикам, что гонят десятки сайтов в месяц чтобы прокормиццо - всяко это должно вырождаться в создание универсальной системы.

> "С нуля" - я не имею ввиду совсем с нуля
Во, а где проходит граница?

Re: И все таки CMS для сайтов это УГ.

> проще набыдлокодить сразу под свои нужды
Уж больно много быдлокодить каждый раз

> во первых дизайн, шаблон
Берёшь тот, что поближе к тому, что тебе надо и модифицируешь - это быстрее чем писать его снуля.

> писать свой шаблон это уже изучение тонкостей CMS начинается
Шаблоны для того по идее и сделаны, чтобы отделять код от представления.. Правда да, я чота не вспомню ни в одной CMS хорошей доки о том, как их писать, определяющей как их писать - какие объекты и их свойства доступны и т.п.. Может просто не попадалось.

Re: И все таки CMS для сайтов это УГ.

>Легко только потому, что ты знаешь как он устроен, а чужую систему ещё изучать надо.
Ну так знание кода - тоже плюс. А также написать то можно по-разному, поэтому часто даже знание чужой архитектуры не помогает, она просто может не подходить.

Вот одна популярная отечественная CMS не может обрабатывать разные свойства у одного товара при покупке в интернет-магазине. Приходится создавать два товара для, например, двух разных цветов. Но пользователь так не хочет, он хочет один. Приходится лепить костыль для этого, но у костыля есть недостатки. А чтобы сделать по-человечески, надо переписывать всё ядро этой системы. Со временем оно обрастает костылями так, что становится страшно.

>Во, а где проходит граница?Во, а где проходит граница?
В зависимости от привязанности компонента к внешним условием. Идеально - когда это библиотека. Тогда вкручивай её куда угодно. А многие готовые решения грешат отсутствием модульности.

Re: И все таки CMS для сайтов это УГ.

>Берёшь тот, что поближе к тому, что тебе надо и модифицируешь - это быстрее чем писать его снуля.
Чтобы сделать кроссбраузерную вёрстку под чьё-нибудь дизайнерское творение, нужно дофига труда и страния. Особенно если надо ещё и ориентироваться на то, что где-то пользователь потом влепит картинку, а где-то движок может выводить тэги только в определённом порядке.

Причем даже мелочь в дизайне может заставить вёрстку под этот дизайн отличаться от похожей очень значительно. А может и не заставить:) И всё из-за сраных браузеров, которые не могут соблюдать стандарт, и из-за дизайнеров, которые иногда рисуют полное непотребство.

Re: И все таки CMS для сайтов это УГ.

> Приходится создавать два товара для, например, двух разных цветов. Но пользователь так не хочет, он хочет один. Приходится лепить костыль для этого, но у костыля есть недостатки.
Ну плохая, не расширяемая система. В идеале было бы сделать тип, производный от типа "Товар", наследующий всё, что уже реализовано и добавляющий к нему атрибут цвета. Интересно, в каких-нить пыховых CMS это можно сделать по-простому, кстати? Пых же худо-бедно объектный нынче и с этим, как его, с рефлекшеном штоле.

> В зависимости от привязанности компонента к внешним условием. Идеально - когда это библиотека. Тогда вкручивай её куда угодно.
Не идеально :) Допустим это это некая библиотека, реализующая некую специфическую функциональность. Что тебе нужно сделать чтобы встроить в свою систему? Перепахать всю систему!!! Просто потому, что эта библиотека независимая и знать ничего не хочет об устройстве твоего велосипеда чтобы автоматически развесить там нужные хуки и подсунуть куда надо темплейты для своих виджетов. Она и с системой контроля доступа будет работать только через костыли, которые тебе придётся писать под неё.

> А многие готовые решения грешат отсутствием модульности.
Наколенные велосипеды тем более. Кроме того, в них реже устраняются ошибки и хромает документация :)

Re: И все таки CMS для сайтов это УГ.

Кроссбраузерность никуда не денется от того, будешь ты писать шаблон снуля или модифицируешь готовый.. Про "движок может выводить тэги только в определённом порядке" не понял. Должен выводить как в шаблоне указано же.

Re: И все таки CMS для сайтов это УГ.

>Ну плохая, не расширяемая система. В идеале было бы сделать тип, производный от типа "Товар", наследующий всё, что уже реализовано и добавляющий к нему атрибут цвета.
Просто такие системы пишутся как и всё изначально самописное - люди реализовывали то, что им было нужно, поэтому в готовом продукте есть какие-то совершенно малопонятные возможности, которые кому-то из клиентов когда-то понадобились. А что понадобится другим - не сделано. А ещё нарастает груз обратной совместимости, который, кстати, очень мешает.

>Интересно, в каких-нить пыховых CMS это можно сделать по-простому, кстати? Пых же худо-бедно объектный нынче и с этим, как его, с рефлекшеном штоле.
А хз. Reflection вроде как есть, но я его ни разу не видел в жизни. Он там с пятой версии, а пхп-кодеры не торопятся прощаться с четвёртой.

>Допустим это это некая библиотека, реализующая некую специфическую функциональность. Что тебе нужно сделать чтобы встроить в свою систему? Перепахать всю систему!!! Просто потому, что эта библиотека независимая и знать ничего не хочет об устройстве твоего велосипеда чтобы автоматически развесить там нужные хуки и подсунуть куда надо темплейты для своих виджетов.
Это всё от архитектуры системы зависит, и от задачи библиотеки. Например, библиотека по формированию csv файлов совершенно не должна знать, как я этот файл пользоваетелю отдаю. Я просто вызываю из неё какие-то функции, получаю ответ и засовываю вместо хтмл-я в вывод движка. Модульность же:)

Всё от архитектуры. В идеальной системе написание собственных хандлеров на все случаи жизни должно быть предусмотрено по-дефолту. Тогда и интегрировать чужой код можно легко.

>Наколенные велосипеды тем более. Кроме того, в них реже устраняются ошибки и хромает документация :)
Это да, поэтому надо знать меру, и, например, использовать фреймворки.

Re: И все таки CMS для сайтов это УГ.

>Кроссбраузерность никуда не денется от того, будешь ты писать шаблон снуля или модифицируешь готовый..
Денется. Есть какая-нибудь мерзкая картинка в углу. На исходном её нет. По условию она обязательно должна растягиваться по определённым правилам и висеть на определённом уровне. Когда начинаешь добавлять её в исходный шаблон, понимаешь, что надо убрать часть старой вёрстки, так как она мешает. И тут то возникают проблемы - убирая вёрстку всё рушится:) Особенно в каком-нибудь IE6. Внешняя похожесть щаблона не гарантирует, что он подойдёт под дизайн.

Тут ещё много зависит от того, для кого это делается. Когда делаешь для себя, можешь простить некоторое несоответствие дизайна и получившейся вёрстки. А когда с тебя требуют конкретно так и так, то приходится извращаться

>Про "движок может выводить тэги только в определённом порядке" не понял. Должен выводить как в шаблоне указано же.
Бывает, что из-за особенностей вёрстки какой-нибудь заголовок засунут не в "тело" страницы, а где-нибудь отдельно в углу. А движок не может на данной странице в ту область залезть. И, соответственно, заголовок вывести не может. Иногда сложно "достучаться" до определённых мест страницы из разного кода, поэтому надо сразу знать, какая часть страницы будет меняться движком при определённом запросе.

Особенно если шаблонизатор не умеет наследование шаблонов (вложенность), или не может из более нижнего куска обращаться к более верхнему.

Также бывает, что блоки надо выводить в определённом порядке, а движок так вывести не может. Проще бывает подвинуть блоки вёрсткой, чем крутить движок. А лучше всего сразу учитывать что может движок, а что нет.

Re: И все таки CMS для сайтов это УГ.

> например, использовать фреймворки
CMS - это фреймворк верхнего уровня предназначенный для построения веб-приложения :)

Re: И все таки CMS для сайтов это УГ.

> Когда начинаешь добавлять её в исходный шаблон, понимаешь, что надо убрать часть старой вёрстки, так как она мешает. И тут то возникают проблемы
Значит этот шаблон тебе не подходит, ищешь другой или пишешь снуля если совсем уж ничего нет.. А в старые подглядываешь куда какие данные откуда они берут, если reference нет.

> Иногда сложно "достучаться" до определённых мест страницы из разного кода, поэтому надо сразу знать, какая часть страницы будет меняться движком при определённом запросе.
Код и не должен никуда лазать и что-то там писать. За это же шаблон отвечает. Хотя.. При таком подходе шаблону может потребоваться собственный код, которому потом ещё и собственные шаблоны потребуются, которым опять же со временем потребуется собственный код - и так до бесконечности :)

> А лучше всего сразу учитывать что может движок, а что нет.
Ну сначала нужно определиться с движком, выбрать наиболее идеальный подход к разработке и под него побирать движок.

Re: И все таки CMS для сайтов это УГ.

>Значит этот шаблон тебе не подходит, ищешь другой или пишешь снуля если совсем уж ничего нет..
Если дизайн сделан не из скриншота щаблона, то можно долго искать. Тем более большинство шаблонов какие-то совсем ужасные - они почти всегда фиксированные, а хтмл-код в них внушает ужас. А ведь этот код потом движку генерировать. Ведь удобнее вывести два div-а, чем городить циклы и считать разделители для вложенных таблиц. И поддерживать "чистый" код проще.

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

>Код и не должен никуда лазать и что-то там писать. За это же шаблон отвечает. Хотя.. При таком подходе шаблону может потребоваться собственный код, которому потом ещё и собственные шаблоны потребуются, которым опять же со временем потребуется собственный код - и так до бесконечности :)
Я подразумевал код, который уже в шаблоне что-то там выводит. MVC это прекрасно, но иногда логика в шаблоне всё равно остаётся, тут уж никуда. И чем проще будет вёрстка - тем меньше этой логики.

>Ну сначала нужно определиться с движком, выбрать наиболее идеальный подход к разработке и под него побирать движок.
Это только в идеальном мире, где заказчик сразу знает, что он хочет, и на свете существуют идеальные движки:) А по жизни иногда приходится поддерживать write-only код.

Re: И все таки CMS для сайтов это УГ.

> Если дизайн сделан не из скриншота щаблона, то можно долго искать. Тем более большинство шаблонов какие-то совсем ужасные - они почти всегда фиксированные, а хтмл-код в них внушает ужас. А ведь этот код потом движку генерировать. Ведь удобнее вывести два div-а, чем городить циклы и считать разделители для вложенных таблиц. И поддерживать "чистый" код проще.
Ну не знаю, мне тут как раз недавно пришлось подравнять морду одному серверу. Не ключевой компонент системы, просто подкрашивали под дизайн клиента для демки. Удивился как просто и удобно это делается в совершенно незнакомом движке: нашёл где там в нём темплейты лежат, выкинул нахуй файл с основным layout'ом страницы и сделал новый - туда вставил таблицу 100%х100%, одна строка на меню, нижняя строка на подвал с цопырихтом, средняя строка - на всё оставшееся место. Посмотрел - вроде работает. Затем выдрал соответствующие куски из старого layout'а и рассовал их по местам. Всё. Даже вьюхи нижнего уровня не трогал. Ну вторым проходом переопределил стили.. Работы меньше чем на день, при этом учитывая, что большая часть ушла на чтение справочника по хэтэмээлю и евоному стайл-всякому-шиту. А стал бы делать темплейт снуля, со всеми вьюхами - хер знает сколько бы убил на это дело и сточил бы клавиатуру до стола, но перед этим действительно прищлось бы поизучать и движок и есык на котором он написан, при том что ни движок ни евоный есык мне нах не впёрлись ибо врядли на протяжении срока забывания мне эти знания пригодятся ещё раз.

> Всё определяется наличием грамотного верстальщика. Если он есть, то он за день-два сверстает всё что надо, красиво и ровно. А если умеет программировать, то может и js напишет. А если верстальщика нет - тогда да, надо мучать шаблоны.
Что в свою очередь опять же зависит от того чего мы хотим достичь - изредка клепать веб-морды для своих нужд или поставить сайты на поточное производство. В первом случае грамотный верстальщик и дизайнер отсутствуют, ибо нормально не востребованы, а во втором случае всё равно будет некая система управления контентом, шаблонные движки и библиотеки заготовок.

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

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

> Это только в идеальном мире, где заказчик сразу знает, что он хочет, и на свете существуют идеальные движки:)
А я не говорил про идеальные движки. Я говорил про наиболее подходящие к подходу к разработке, который ты считаешь наиболее близким к идеальному.

Re: И все таки CMS для сайтов это УГ.

>Ну не знаю, мне тут как раз недавно пришлось подравнять морду одному серверу. Не ключевой компонент системы, просто подкрашивали под дизайн клиента для демки.
Это значит, что тебе повезло - ты наткнулся на ту систему, которую хорошо написали с нуля в своё время:) И с вёрсткой повезло. Потому что достаточно часто встречается такая вёрстка, что её изменение приводит к ужасным последствиям. Особенно если творческий верстальщик возомнил себя хакиром и наделал модных костылей, отрицательных отступов и прочего. Его творение работает на честном слове до первого вмешательства.

И всё, кстати, потому, что люди верстают совершенно не думая о последствиях и не изучая теорию:)

>нашёл где там в нём темплейты лежат, выкинул нахуй файл с основным layout'ом страницы и сделал новый - туда вставил таблицу 100%х100%, одна строка на меню, нижняя строка на подвал с цопырихтом, средняя строка - на всё оставшееся место. Посмотрел - вроде работает. Затем выдрал соответствующие куски из старого layout'а и рассовал их по местам.
Ну у тебя немного не то, о чём я говорил. Я говорил о том, когда есть нарисованый дизайн, который существует только в картинке. В этом случае проще именно верстать заново, чем искать похожий и брать его шаблон.

>Что в свою очередь опять же зависит от того чего мы хотим достичь - изредка клепать веб-морды для своих нужд или поставить сайты на поточное производство. В первом случае грамотный верстальщик и дизайнер отсутствуют, ибо нормально не востребованы, а во втором случае всё равно будет некая система управления контентом, шаблонные движки и библиотеки заготовок.
В принципе да. Когда дизайн не является одной из основных особенностей продукта, можно многое упростить. Лишь бы выглядело прилично на глаз, да функциональность была в порядке.

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

Re: И все таки CMS для сайтов это УГ.

> тебе повезло - ты наткнулся на ту систему, которую хорошо написали с нуля
Да не, система меня как раз не поразила продуманностью..

> Особенно если творческий верстальщик возомнил себя хакиром и наделал модных костылей,
Это не считается, поскольку форс-мажорные обстоятельства :)

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

> Я говорил про то, что иногда движок уже выбран за тебя, с ним надо будет долго работать, и придётся учитывать все его нюансы. И даже в близком к идеальному движке есть эти проклятые нюансы.
Зато лучше все эти нюансы однократно познать, чем помнить все нюансы всех своих велосипедов..