Здравствуйте, adontz, Вы писали:

A>Владимир, уж простите за мой лексикон, я вас уважаю, но не страдайте хернёй. Если это сайт про Nemerle, то не надо движок сайта тоже делать на Nemerle. Сайты про C++ хостяться на PHP и никто из этого трагедию не делает. Вам шашечки или ехать? Возьмте Друпал или Джумлу и сделайте сайт которым можно пользоваться. Лучше сайт на неправильной технологии, который есть, чем сам на правильной, которого нет.

Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине. Джумлу — я пробовал, равно как и медиавики, если уж на то пошло. Эту феерию я еще долго буду помнить, у меня левый глаз потом дергался несколько недель. А заводить под nemerle.org отдельный сервер как-то не вставляет, если честно. Это во-первых. Во-вторых, требования, предъявляемые к сайту nemerle (обязательная интеграция, хотя бы с форумом на RSDN и всей инфраструктурой проекта на гугло коде), означают достаточно глубокое погружение в нутря любой используемой CMS и разработку под нее дополнительных модулей/расширений, либо серьезную правку уже существующих. В случае и джумлы и друпала — это PHP, поэтому увольте. Я на этом языке последний раз писал что-то ощутимо большое около 2 лет назад, и опять этим займусь разве что только под дулом пистолета (да и то, если убить угрожающего не получится). Надеюсь, мое отношение к этому языку я выразил достаточно четко. В разрезе данной задачи, мне представляется более целесообразным (в долгосрочной перспективе) использовать не CMS, а CMF, т.к. повторюсь, только во втором случае будет достаточно пространства для маневров и каких-либо существенных доработок и расширения функционала.

С другой стороны, на Django я реализую необходимый функционал за 2-3 недели в одиночку и в выборе этого фреймворка есть определенный смысл, т.к. его можно закрутить на хостинге GAE и вообще забыть про проблемы с платформой. Эта идея мне нравится намного больше, если бы не одно но:

у нас есть действительно неплохой фреймворк NRails, но нет приложений на нем (в паблике, по крайней мере). Так почему бы не совместить приятное с полезным и наглядно не продемонстрировать мощь языка, реализовав весь необходимый функционал на нем? Тем более, что в любом другом варианте из озвученных выше, мозголожства будет не меньше, а возможно и больше, просто проблемы придется решать не в плоскости функционирования CMS или CMF, а в плоскости ее доработок и интеграции с существующими ресурсами.

Подчеркну — с моей стороны, выбор NRails является достаточно обдуманным и взвешенным, я рассматривал варианты и со сторонними CMS/CMF, учитывая по-возможности все факторы, которые были очевидны на тот момент. И преимуществ от их использования, которые бы перевесили недостатки в данной, конкретной задаче, я не вижу

Здравствуйте, Flem1234, Вы писали:

F>Чем дадут тем и будет стрелять, хоть палкой
F>Только, пожалуйста, не Enterprise Library или правку xml конфигов.

=) на самом деле рутина везде нас найдет

F>Хм, и на всякий случай предупреждаю, что в парсинге не силен, так что лучше мне давать что-то несрочное и несложное.
F>Еще и вопросами достану по ходу решения)

парсер уже есть, только я не уверен насчет комментариев. MainParser называется. Макры и синтаксис оно найдет. Насчет комментариев тут подскажут как лучше поступить.

Здравствуйте, Ziaw, Вы писали:

Z>=) на самом деле рутина везде нас найдет

Без боя не сдамся))

F>>Хм, и на всякий случай предупреждаю, что в парсинге не силен, так что лучше мне давать что-то несрочное и несложное.
F>>Еще и вопросами достану по ходу решения)

Z>парсер уже есть, только я не уверен насчет комментариев. MainParser называется. Макры и синтаксис оно найдет. Насчет комментариев тут подскажут как лучше поступить.

Ок. Попробую на выходных. Если что, буду в форум вопросы постить.

Здравствуйте, adontz, Вы писали:

A>Владимир, уж простите за мой лексикон, я вас уважаю, но не страдайте хернёй. Если это сайт про Nemerle, то не надо движок сайта тоже делать на Nemerle. Сайты про C++ хостяться на PHP и никто из этого трагедию не делает. Вам шашечки или ехать? Возьмте Друпал или Джумлу и сделайте сайт которым можно пользоваться. Лучше сайт на неправильной технологии, который есть, чем сам на правильной, которого нет.

Аналогия некорректна. Никто не пишет CMS на С++ не потому, что есть PHP, а потому, что язык не предназначен для этого. Nemerle подходит для веб разработки совершено не хуже C#, это обычный dogfooding.

Что касается NRails, он ничего не навязывает кроме блтулкита, который и так бы использовался и спарка, который, за неимением поддержки razor является наиболее удобным view engine на текущий момент.

Здравствуйте, Ziaw, Вы писали:

Z>Грузить в память структуры из сотен объектов на каждый запрос? А потом их еще клонировать? GC не треснет?

Не. Для него это не нагрузка. Объекты которые живут не долго стоят очень дешево. К тому же замену можно сделать ленивой, что позволит даже обходиться без загрузки всех данных в память (если это понадобится).

Z>А у меня будет:
Z>

Z><ul>
Z>  <li each="article in Model">${article}</li>
Z></ul>
Z>

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

Z>Все, система выберет лэйаут по умолчанию

Во, во, во "система выберет". На фиг! На фиг выбор который неясно как происходит и неясно где производится. На фиг систему которая требуется для примитивных действий.

Еще раз повторюсь, не надо создавать сложности на ровным месте. Их и так хватит. Код должен быть просто как пробка. Тогда его будет просто расширять и понимать.

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

Вот не надо чтобы были какие-то шибко умные сущности которые куда-то сами смотрят и что-то сами делают. Потом кто-то другой придет и будет долго думать кто же подставляет этот долбанный сайдбар? Где же это место в котором надо подправить строчку чтобы добавить ссылку в этом сайдбаре?

Все должно быть очень просто. У нас есть базовый шаблон. Мы можем поместить какое-то начальное значение сайтбара в него. Если для ряда страниц нам нужно изменить сайтбар, то мы тупо вводим для них базовый класс и в его конструкторе (или каком-то методе) клонируем шаблон и меняем в нем сайтбар (клонирование можно автоматизировать). Все страницы (представления) унаследованные от данного класса будут работать уже с измененным шаблоном.

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

Z>Могу вынести этот сайбар в контрол.

О! Еще одна на фиг не нужная сущность! Вот об этом я и говорю.
Не нужны эти твои "контролы". Есть просто функции (локальные/методы, не суть). На входе параметры, на выходе результат.
Нужно формировать сайдбары с помощью сложной логики? Не вопрос, создаем функцию с параметрами и пусть она их создает.

Z>

Z><view content='sidebar'>
Z>   <SideBar lst="[3, 4]">
Z></view>
Z><ul>
Z>  <li each="article in Model">${article}</li>
Z></ul>
Z>

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

Z>При этом я правлю только фронтэнд, я не трогаю логику.

Ты размазываешь логику по шаблонам. Все эти "<SideBar lst="[3, 4]">", "<li each="article in Model">${article}</li>" — это код засунутый внутрь шаблонов контента.

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

Z>Откуда в твоем темплейте появился SetArticleList? ArticleList есть только в одной view, в остальных отображаются свои данные. Что делать, если экшен может рендерить несколько разных вьюх в зависимости от чего угодно?

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

Z>А вот не надо отказываться от контроллеров, ибо эта пара со временем вполне способна постепенно вырасти до нескольких десятков.

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

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

Z> Да и вообще, лазить в БД из view за данными еще можно, но менять их уже совсем криво.

Все зависит от объема кода и сложности задачи. Возможно, что операция что ты делаешь вообще будет стандратная и ее просто надо вынести в функцию. А раз мы просто вызываем одну функцию, то что нам даст контроллер? Лишний файл?

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

Z>Они как раз уменьшают сложность, аякс контент, аяск джейсон, xml и простой http запрос возвращают одни и те же данные в разных видах. При отказе, код доставания придется дублировать, либо плодить костыль -однострочный метод.

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

VD>>Чудес не бывает. Логика будет там или тут. Ты можешь размазать ее по классам, переместить в шаблон (сделав его программой, а не текстом) и т.п. Но ты получишь все то же решение, если конечно у тебе не возникнет дублирование.

Z>Все то же решение я не получу по одной простой причине, код будет более связан, придется выдумывать механизмы развязывания (IoC).

Знаешь, я бы пионером IoC и других финтефлюшек. Еще когда об этом на Руси никто не слышал я старался впихнуть в наши журналы статьи об IoC и других Спрингах. Но когда я познакомился и освоил Немерл, то почему-то я вообще перестал думать об IoC. Более того когда я сейчас вижу применение IoC, то очень часто меня это коробит, так как я вижу другие, более простые пути достичь того же самого.

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

Я думаю, что прототип у нас не займет много времени. Ну, а далее сделаем пару тестовых страниц и оценим, что получилось.

Z> Придется реализовывать систему подгрузки шаблонов.

Это элементарно.

Z>Еще дофига чего. А плюсов я так и не увидел, кроме заявлений о типизации. Так у меня тоже типизация, прикинь? Зачастую утиная, что рулит в вебе безбожно.

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

Я почему-то уверен, что полученное решение будет проще, быстрее и гибче. И при этом мы еще избавимся от лишней зависимости, получим интеллисенс, и возможность наращивать интеллектуальность нашего движка (код же будет целиком наш!).

VD>>В твоем случае ты размазываешь код по шаблонам и делаешь эти самые шаблоны огромными простынями с огромным количеством дублирования.

Z>Ты делаешь очень смелые предположения о моих шаблонах.

Возможно. Ну, что попробуем?

Здравствуйте, _Eter_, Вы писали:

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

Вот и я думал о чем-то таком. Просто страничка с рекламой мне не нравится.

Здравствуйте, kochetkov.vladimir, Вы писали:

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

Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.

Здравствуйте, Ziaw, Вы писали:

Z>Аналогия некорректна. Никто не пишет CMS на С++ не потому, что есть PHP, а потому, что язык не предназначен для этого. Nemerle подходит для веб разработки совершено не хуже C#, это обычный dogfooding.

ИМХО и C# не особо-то предназначен, ну да ладно.

Z>Что касается NRails, он ничего не навязывает кроме блтулкита, который и так бы использовался и спарка, который, за неимением поддержки razor является наиболее удобным view engine на текущий момент.

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.
A>Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.

Угу. Как на никсовом VDS будем делать билд-сервер?

Здравствуйте, VladD2, Вы писали:

Z>>А у меня будет:
Z>>

Z>><ul>
Z>>  <li each="article in Model">${article}</li>
Z>></ul>
Z>>

VD>Этот код будет внутри того что у меня было бы шаблоном. Т.е. нарушение правил разделения дизайна и контента.

Где ты тут увидел дизайн? Это чистый контент. Это представление контента в виде списка, никакого дизайна. А вот дизайн уже этому списку назначит роль, это может быть выпадающее выпадающее меню или табы.

VD>Плюс это простой случай. В моем случае нет никаких проблем сделать набор рекурсивных функций которые будут формировать контент любой сложности. Ты же снова, по привычке, хочешь запихать весь код в один большой файл. Причем это файл где контент перемешан с кодом.

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

Z>>Все, система выберет лэйаут по умолчанию

VD>Во, во, во "система выберет". На фиг! На фиг выбор который неясно как происходит и неясно где производится. На фиг систему которая требуется для примитивных действий.

Что конкретно тебе не ясно? У сайта есть дефолтный лэайут, лежит в "Views/Layouts/Application.spark". Это то, куда я могу засунуть дизайн от Кочеткова и обойтись косметическими правками всего остального сайта.

VD>Еще раз повторюсь, не надо создавать сложности на ровным месте. Их и так хватит. Код должен быть просто как пробка. Тогда его будет просто расширять и понимать.

Только я уже привел кучу простых как пробка примеров, а у тебя ни одного полного, а даже отрывки сложны для понимания того, что там происходит внутри и что выдается наружу.

VD>Вот не надо чтобы были какие-то шибко умные сущности которые куда-то сами смотрят и что-то сами делают. Потом кто-то другой придет и будет долго думать кто же подставляет этот долбанный сайдбар? Где же это место в котором надо подправить строчку чтобы добавить ссылку в этом сайдбаре?

Не надо тут думать, надо пойти в лейаут и посмотреть, кто отвечает за рендер сайдбара.

VD>Все должно быть очень просто. У нас есть базовый шаблон. Мы можем поместить какое-то начальное значение сайтбара в него. Если для ряда страниц нам нужно изменить сайтбар, то мы тупо вводим для них базовый класс и в его конструкторе (или каком-то методе) клонируем шаблон и меняем в нем сайтбар (клонирование можно автоматизировать). Все страницы (представления) унаследованные от данного класса будут работать уже с измененным шаблоном.

Во, ты наконец пришел к лейаутам. Осталось понять, что ничего клонировать не надо, в них уже есть механизм оверрайда секций.

VD>Получается простая логика которая не удивляет программиста и при этом обеспечивает очень компактный и хорошо поддерживаемый код.

Давай код, сравним простоту. Только весь код, все файлы, я тебе привел уже все файлы, некоторые даже в нескольких сценариях.

Z>>Могу вынести этот сайбар в контрол.

VD>О! Еще одна на фиг не нужная сущность! Вот об этом я и говорю.
VD>Не нужны эти твои "контролы". Есть просто функции (локальные/методы, не суть). На входе параметры, на выходе результат.
VD>Нужно формировать сайдбары с помощью сложной логики? Не вопрос, создаем функцию с параметрами и пусть она их создает.

Чем контрол отличается от функции с параметрами?

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

Безумное оно только в твоем понимании.

VD>Ты размазываешь логику по шаблонам. Все эти "<SideBar lst="[3, 4]">", "<li each="article in Model">${article}</li>" — это код засунутый внутрь шаблонов контента.

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

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

Что конкретно я не могу? Все мои сущности нужные.

Z>>Откуда в твоем темплейте появился SetArticleList? ArticleList есть только в одной view, в остальных отображаются свои данные. Что делать, если экшен может рендерить несколько разных вьюх в зависимости от чего угодно?

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

Создаю, когда понимаю, что данный код должен быть в другом слое.

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

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

Z>> Да и вообще, лазить в БД из view за данными еще можно, но менять их уже совсем криво.

VD>Все зависит от объема кода и сложности задачи. Возможно, что операция что ты делаешь вообще будет стандратная и ее просто надо вынести в функцию. А раз мы просто вызываем одну функцию, то что нам даст контроллер? Лишний файл?

Влад, ты в предмете разберись. Мы всегда вызываем контроллер. Если ему надо рендерить что-то сложное, у тебя будет темплейт и у меня будет темплейт. Не надо — ну и не надо.

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

Во! Именно ты ее и хочешь размазать. У меня все разделено, контроллер достал данные, отображение их их отобразило. А твои рассуждения про то, что все надо просто распихать по фукнциям и будет зашибись — гроша ломаного не стоят без реальных примеров. Пусть даже для игрушечных респонсов, пример которого я привел.

VD>>>Чудес не бывает. Логика будет там или тут. Ты можешь размазать ее по классам, переместить в шаблон (сделав его программой, а не текстом) и т.п. Но ты получишь все то же решение, если конечно у тебе не возникнет дублирование.

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

VD>Я думаю, что прототип у нас не займет много времени. Ну, а далее сделаем пару тестовых страниц и оценим, что получилось.

Да не надо никаких фреймворков, ты просто распиши, как ты видишь и я укажу тебе слабые места.

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

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

VD>Возможно. Ну, что попробуем?

Как я могу попробовать что-то, концепции чего я до сих пор не увидел? Скоро год уже, как мы первый раз переломили копья на эту тему. Но я так и не понял, как это все должно работать в стандартных сценариях. Не говоря уже о сложных. Мысль я понимаю, но у меня не складывается общей картины дизайна, она тут же ломается обо все частные случаи.

Здравствуйте, adontz, Вы писали:

Z>>Аналогия некорректна. Никто не пишет CMS на С++ не потому, что есть PHP, а потому, что язык не предназначен для этого. Nemerle подходит для веб разработки совершено не хуже C#, это обычный dogfooding.

A>ИМХО и C# не особо-то предназначен, ну да ладно.

На мой взгляд особо предназначены только рор и джанго. Только я привык к статике, писать на динамике очень ломает, ибо поддерживать потом это надо, причем иногда людям которые в разработке участия не принимали. Писать код на динамике легче. Читать — труднее.

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

Что ты предлагаешь-то? MVC фреймоврк уже есть, его не надо особо писать. Сайт в таком виде оставлять нельзя, это же кошмар полный. Из него и складывается впечатление о проекте. Надо релизить немерл и пиарить его, а пиарить сейчас тупо вредно, такой сайт закроет сразу 80% посещающих. Остальные не будут пробовать язык, до того как почитают о нем, а столкнувшись с тем, что половина ссылок битая, половину найти сложно и вообще непонятно что тут читать уйдут остальные 20%. Потому и получается, что язык юзают только те, кому уши о нем прожужжали и они пересилили себя.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.
A>>Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.
KV>Угу. Как на никсовом VDS будем делать билд-сервер?

А почему всё должно быть на одном сервере? Что за мания такая.

Здравствуйте, Ziaw, Вы писали:

Z>Что ты предлагаешь-то?

Взять готовую CMS и получить гарантированный результат за разумное время с минимальными усилиями.

Z>MVC фреймоврк уже есть, его не надо особо писать.

Фреймворк есть в виде какой-то первой версии. Его надо будет обкатывать и доделывать. ASP.NET MVC не с певрого раза получился, аж три версии. Почему у вас должно быть лучше? Потом, фреймворк — не сайт, сайт писать таки надо. Да, я понимаю, Немерле есть великая экономия сил, но всё же надо смотреть на это с точки зрения руководителя проекта, а не программиста-энтузиаста. Надо разделить задачи на важные и второстепенные и решать их в соответсвии с приоритетами. Важно ли чтобы сайт был красивым? Да! Важно ли чтобы он был на Немерле? Нет!

Z>Сайт в таком виде оставлять нельзя, это же кошмар полный. Из него и складывается впечатление о проекте. Надо релизить немерл и пиарить его, а пиарить сейчас тупо вредно, такой сайт закроет сразу 80% посещающих.

Да, сайт — говно. Я с этим и не спорю. Но это вопрос дизайна и только дизайна. К движку или языку на котором написан движок он отношения не имеет. Если это так уж волнует, скиньтесь и на каком-нибудь free-lance.ru вам баксов за 200-300 сделают замечательный дизайн. Мне всю символику (логотип, наклейки на автомобили, сайт, майки) нарисовали не так давно за 500. Программисты, занимайтесь программированием.

Здравствуйте, adontz, Вы писали:

A>Взять готовую CMS и получить гарантированный результат за разумное время с минимальными усилиями.

Какую конкретно? Все что я знаю гуано, которое расширять стоит больших денег. Сайт то не простой, там много док, в том числе тех которые будут генериться. Все остальное совсем не сложно сделать руками.

A>Фреймворк есть в виде какой-то первой версии. Его надо будет обкатывать и доделывать. ASP.NET MVC не с певрого раза получился, аж три версии. Почему у вас должно быть лучше?

Ну это же не фреймворк с нуля, это хелперы к MVC.

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

Писать все равно придется. Ты пойми, что CMS даст тут ровно ничего. Дизайн придется превращать в шаблон для этой CMS, бороться с ее собственным дизайном и т.д. Готовые компоненты которые можно взять это вики и блог. Только и то и другое придется допиливать. Блог делается за полдня-день, мирор гугловой вики на файлах — чуть дольше. Допиливание займет больше, это точно

Z>>Сайт в таком виде оставлять нельзя, это же кошмар полный. Из него и складывается впечатление о проекте. Надо релизить немерл и пиарить его, а пиарить сейчас тупо вредно, такой сайт закроет сразу 80% посещающих.

A>Да, сайт — говно. Я с этим и не спорю. Но это вопрос дизайна и только дизайна. К движку или языку на котором написан движок он отношения не имеет. Если это так уж волнует, скиньтесь и на каком-нибудь free-lance.ru вам баксов за 200-300 сделают замечательный дизайн. Мне всю символику (логотип, наклейки на автомобили, сайт, майки) нарисовали не так давно за 500. Программисты, занимайтесь программированием.

Далеко не только дизайн. Да и совсем несложный там сайт получается. Все что сложное (приведение доки в порядок, создание автогенератора док) делать придется все равно.

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

Здравствуйте, adontz, Вы писали:

A>Программисты, занимайтесь программированием.

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

P.S: Предупреждая следующий вопрос — нет, крестиком я вышивать не умею

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.
A>>>Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.
KV>>Угу. Как на никсовом VDS будем делать билд-сервер?

A>А почему всё должно быть на одном сервере? Что за мания такая.

Потому что админить их придется мне, хотя бы. И обеспечивать взаимодействие между VDS, гуглокодом и RSDN4 — тоже. А, учитывая, что контингент участников проекта Nemerle не пестрит никсовыми админами и программерами на динамике, встает также вопрос о том, кто будет все это дорабатывать и развивать? Мы обсуждали с Владом вариант с переносом сайта с сервера поляков на VDS непосредственно перед переносом, но пришли к мнению, что целесообразнее держать все на одном сервере. По причинам, которые я уже озвучил.

Напомню, что RSDN (как движок) появился на свет именно из-за того, что его создателей не устраивали имеющиеся на тот момент движки форумов. В каком месте бы сейчас он был, возьми они что-то готовое — хз. В этом движке также заинтересован IT, он нужен ему для булкита, кроме того, Игорь обещал помочь с архитектурой и осуществлять методическую помощь, так сказать. В конечном итоге, подобный движок мог бы стать и альтернативным онлайн-клиентом для RSDN. Так почему бы и нет?

Здравствуйте, Ziaw, Вы писали:

Z>Я помню эти общие мазки. Новый rsdn выглядит пугающе.

почему, если не секрет?

Z>Чем смогу помогу конечно,

Я не был в курсе того, что ты "отдаешь в хорошие руки" NRails, в смысле — не имеешь возможности заниматься им. Я как-то пропустил этот момент осенью. Это по прежнему так, или что-то поменялось?

Z>мой логин в скайпе alex_zimin.

Мой vladmir.v.kochetkov, но я там в плане голоса смогу быть только по своему возвращению

Z>Со временем тоже не очень, но на рсдн пока есть, значит и на движок найдется

Ок, супер, спасиб Есть ли в NRails какие-либо нерешенные задачи/проблемы, нереализованный функционал и прочие вопросы, которые бы стоило закрыть до того, как начать работать над движком?

Здравствуйте, Ziaw, Вы писали:

Z>Я помню эти общие мазки. Новый rsdn выглядит пугающе.

почему, если не секрет?

Z>Чем смогу помогу конечно,

Я не был в курсе того, что ты "отдаешь в хорошие руки" NRails, в смысле — не имеешь возможности заниматься им. Я как-то пропустил этот момент осенью. Это по прежнему так, или что-то поменялось?

Z>мой логин в скайпе alex_zimin.

Мой vladmir.v.kochetkov, но я там в плане голоса смогу быть только по своему возвращению

Z>Со временем тоже не очень, но на рсдн пока есть, значит и на движок найдется

Ок, супер, спасиб Есть ли в NRails какие-либо нерешенные задачи/проблемы, нереализованный функционал и прочие вопросы, которые бы стоило закрыть до того, как начать работать над движком?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV> почему, если не секрет?

объемом замысла

KV>Я не был в курсе того, что ты "отдаешь в хорошие руки" NRails, в смысле — не имеешь возможности заниматься им. Я как-то пропустил этот момент осенью. Это по прежнему так, или что-то поменялось?

Тогда у меня кончился вебпроект в котором я юзал рельсы и начались не веб Было не очень понятно, что делать с фреймворком дальше. Выдумывать фичи просто так, не хотелось, писать свою версию интеграции для спарка тоже. Стал актуален 3й MVC, но на 4м фреймворке. Я решил сделать паузу до второй версии немерла для избавления от проблем с интеграцией и перехода на 3 MVC.

KV>Мой vladmir.v.kochetkov, но я там в плане голоса смогу быть только по своему возвращению

Я обычно без микрофона, просто чат зачастую удобнее форума.

KV>Ок, супер, спасиб Есть ли в NRails какие-либо нерешенные задачи/проблемы, нереализованный функционал и прочие вопросы, которые бы стоило закрыть до того, как начать работать над движком?

Одну я уже назвал, в спарковских вьюхах нет интелисенса. Мне удалось заставить его заработать, https://github.com/Ziaw/spark, но для нормальной инсталляции аддина, требуется его подписать. А подпись майкрософта мне так и не удалось получить тогда, было похоже на то, что их вообще перестали выдавать. Еще одна проблема там — в инсталяцию пришлось включить сами рельсы, так что вьюха компилируется для интелисненса версией рельс, отличной от текущей. Надо бы перейти на позднее связывание, но я чето утонул там в дизайне интеграции.

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

Здравствуйте, Ziaw, Вы писали:

Z>Какую конкретно? Все что я знаю гуано, которое расширять стоит больших денег. Сайт то не простой, там много док, в том числе тех которые будут генериться. Все остальное совсем не сложно сделать руками.

Тем не менее, больиснтво сайтов, в том числе много сложных, на готовых движках.

Z>Писать все равно придется. Ты пойми, что CMS даст тут ровно ничего. Дизайн придется превращать в шаблон для этой CMS, бороться с ее собственным дизайном и т.д. Готовые компоненты которые можно взять это вики и блог. Только и то и другое придется допиливать. Блог делается за полдня-день, мирор гугловой вики на файлах — чуть дольше. Допиливание займет больше, это точно

Нормальный блог не делает за пол дня. За пол-дня делается простыня сообщений.

Z>Далеко не только дизайн. Да и совсем несложный там сайт получается. Все что сложное (приведение доки в порядок, создание автогенератора док) делать придется все равно.

Эти задачи к сайту отношения не имеют.

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

Вот именно что пришли. Я не думаю что первый сайт о Питоне был написан на Питоне. Руби, прости, но фанатики какие-то, они даже свой нарошный веб-сервер написали. Будете писать свой веб-сервер?