не знаю, что это. а можно что-нибудь на эту тему дублирование контента сообразить?

ОП же сказал, что это не часть фреймворка.

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

Хочу комбобокс с выбором многих элементов - это не задача веб-фреймворка

Это задача GUI, а не фремворка, тем более веб-фреймворка

Не хочу веб-фреймворки вообще. Хватит, мать их!

Есть идеи как улучшить MVC?

Есть одна. Перестать делать всё новые и новые реализации его. Его уже столькими способами воплощали, что больше не надо. Хватит уже с нас, несчастных девелоперов, чтения манов типа «В [framework_name] вьюшка это примерно тоже, что контроллер в [framework_2_name], а модель это примерно то, что вьюшка, а вьюшка это вообще что-то такое, что мы придумали, но реализовали пока на 10 процентов.»

Пусть остаются Rails для тех, кто хочет взять и сразу работать, Джанга для тех, кто хочет поонанировать на «скорость» и Синатра для тех, кто хочет написать Rails сам))

Есть идеи как улучшить MVC?

Мне кажется тут уже нечего улучшать. Эта парадигма самодостаточна. Отход от простой идеи только усложняет все.

Запрос -> Контроллер (решает что делать и формирует среду для обработки запроса: подготавливает Модель и выбирает Представление - делегирует отображение на них)

Остальное формируется в процессе. В том числе и необходимые вспомогательные сущности. Идеально, когда части MVC очень слабо информированы друг о друге.

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

Представление в свою очередь берет уже подготовленные данные либо «вытягивает» их дополнительно у Модели или Контроллера с минимальным числом ветвлений - в основном линейный вывод и циклы, форматирование.


В современных фреймворках слишком все перегружено уже в MVC. Зачастую ошибочно, в процессе понимания разработчиков сеих фреймворков. Фактически MVC реализован уже авторами (как-то или кое-как) и приходится разбираться в этих костылях. Так что несмотря на то что идеального решения нет (и не будет) - нужно чтобы конечный разработчик имел максимальную свободу и контроль по реализации MVC, используя от фреймворка только вспомогательные компоненты и строительные блоки. Надо чтобы конечный разработчик мог сделать как-то или кое-как свою реализацию MVC. От реализации к реализации, постепенно сформируется нужный вариант. Это есть в некоторых минималистских ФВ


Так что в итоге хотелось: минимальное ядро с возможностями наращивания, пакетный менеджер, безупречный деплой (как для разработки (включая полную интеграцию с DCVS ) так и заказчикам), легкая система встраивания дизайна, управление в консоле, поддержка языков, метаданных, легкая интеграция ajax, свобода выбора реализаций сессий и бд, удобная интеграция с зоопарком веб-серверов, масштабирование, кластеризация.


Исключение составляет вариант ФВ, когда все это уже реализовано и минимальности нет. Но. Либо можно дополнять и менять под свои нужды. Либо оставить все как есть и сосредоточиться только на прикладных задачах и деплое.

P.S. Есть идеи как улучшить MVC?

В моём представлении (и у себя по мере развития реализую), задача фреймворка — взять на себя процентов 80..90 формирования модели и 100% формирования контроллера. Фактически, указываешь на источник модели и оформляешь view и «Machines should work» ©

На чём писать решил, болезный?

«веб-фреймворки» не нужны

Вы переживаете что будет еще один фреймворк? Вы очень впечатлительный

Спасибо за ответ

числом ветвлений - в основном линейный вывод и циклы, форматирование

Как тут найти reasonable default

пакетный менеджер

Почему это часть фреймворка? Это обычно часть инфраструктуры платформы или системы сборки. Когда на базе JVM кто-то городит свой пакетный менеджер, которые еще и качает библиотеки в какой-то lib - тянется рука за ружьем и билетами на поезд

метаданных

метаданным к каким данным?

реализаций сессий

где можно почитать? или хоть в каком контексте? Тоесть необходим scope объекта с хранением в произвольных местах.

Не хочется при этом получить какой-то угребищный JSF, который загадочно работает и о его lifecycle можно написать книгу

Не могу сказать, потому как это отвлечет от обсуждения вопроса )

И когда известно станет?

Когда/если мне понравится то что я написал ) А есть список пожеланий среди ЯП?

Не хочется при этом получить какой-то угребищный JSF, который загадочно работает и о его lifecycle можно написать книгу

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

Питон, очевидно же.

у меня

где «у меня»?

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

Есть непонятное говно (Мохито), коммерческое говно (Метеор), и всё остальное говно.

где «у меня»?

В https://bitbucket.org/Balancer/bors-core

Но в контексте разговора это не актуально, тут ведь спор о том, как хочется, а не о том, как где реализовано :)

числом ветвлений - в основном линейный вывод и циклы, форматирование

Как тут найти reasonable default

В принципе это то чему следует научиться как искусству. В простейшем случае это уже дает формализацию и отделение данных от их Представления. Тут приходится балансировать. Если ветвлений много в представлении - значит недостаточно формализованы данные или это индикатор что пошло что-то не так. Обычно это признак несоответствия архитектуры. Иногда помогает на пути от модели к представлению некий «трансформер». Модель отдала данные, а представление подвергает их по своему усмотрению дополнительной трансформации. Либо можно указать в запросе к модели, что требуется кастомная обработка на уровне модели. Но это уже костыли. Идеально когда Представление получает структуру формализованных данных и тупо распихивает по контейнерам ибо оно знает лучше всех как это делать. Если встречается необходимость логики и ветвлений, то надо чтобы модель уже передавала максимально «обсчитанную» информацию. Можно «разрешить» Представлению «дозапрашивать » у модели дополнительную информацию, если чего-то не хватает. Часто эту роль играют ViewHelper. Но надо помнить, что Представление это уже постфактум - за него уже все решили Контроллер и Модель. От него только требуется выполнить делегированную обязанность: обернуть (упаковать) данные в отображаемый формат (html, yaml, json, pdf, txt, doc). В каждом конкретном случае возможны различные схемы включая мини-слои, которые в свою очередь тоже мини-MVC и все это идет на уровне Представления. Аналогия: конвейеры команд. Каждая представляет собой по сути мини-слой MVC.

пакетный менеджер

тянется рука за ружьем и билетами на поезд

Вот и у меня тянется рука когда нужно с мясом вырывать или вставлять нужный кусок функциональности из вне. Для примера ПМ джавы решает свои, системные, задачи. Хотя бы мини-ПМ для плагинов - когда можно встраивать в систему без напрягов и удалять без побочных эффектов. Аналог: расширения для лисы. Это с точки зрения конченого пользователя системы. С точки зрения разработчика в этой системе: возможность вставки дополнительной библотеки и при необходимости ее правки/доработки

метаданных

метаданным к каким данным?

Ты почти сам ответил на этот вопрос)) Это не ОРМ. Это те метаданные которые формализовано описывают прикладную область. Названия колонок и полей, форматы отображений, справочники, связи, валидаторы, структуры и названия табличек и т.п.

реализаций сессий

где можно почитать? или хоть в каком контексте? Тоесть необходим scope объекта с хранением в произвольных местах.

Если под scope объекта понимается его «персистенция» то и это тоже. Но сессии еще и в понимании их стореджей и собственно обеспечении постоянства. Что это: куки, сиды в урлах, персональные сертификаты или другое. Почитать наверное по ключевым словам: session storage, session handling, session persistence. В каком контексте: объекты, авторизация, масштабирование, восстановление, безопасность, хранилище.


В общем случае на MVC можно подзабить, но помнить о том что есть слабая связанность (loose coupling) и обратно (по сути монолитный код (изменения маленькой части может вызвать крах системы)) На практике чем меньше объекты знают друг о друге тем проще обеспечить их совместную работу, скомпенсировав недостаток их знаний объектными интерфейсами. Часто такая «парадигма безразличия» дает неплохие результаты.

Есть идеи как улучшить MVC?

что там улучшать? все довольно низкоуровнево и императивненько

Контроллер (решает что делать и формирует среду для обработки запроса: подготавливает Модель и выбирает Представление - делегирует отображение на них)

Хотя бы мини-ПМ для плагинов - когда можно встраивать в систему без напрягов и удалять без побочных эффектов

Но если вернуться к джаве, то добавление jar открывает возможность спользовать какой-то класс в том же Spring. Даже в более веб-ориентированом фреймворке все равно прийдется писать хоть одну строчку кода, то разве Ivy,Maven,SBT,Gradle не хватает для доставки библиотеки?

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

Это какие-то частности. Особенно названия колонок, полей, валидаторы (а поведение валидаторов?)

Что это: куки, сиды в урлах, персональные сертификаты или другое

Тоесть в больше мере не сессия, как хранилище, но идентификация. В общем и место хранение может иметь смысл.

Нет, у меня не python )

Что бы вы хотели в хорошем веб-фреймворке?

Чтобы ты его не делал?

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

Эта парадигма самодостаточна.

Парадигма - да

Мне кажется тут уже нечего улучшать.

Инфраструктуру можно.

Ведь есть сайты типо вконтактиков, которые работают на history api. Было бы хорошо это сделать прозрачно для разработчика. Еще Comet везде невменяем. Предоставление модели в виде rest api - вообще должно быть декларативным и кратким в стиле «/api/users: expose User with All, Read, Write, Delete»

Нет, не на Java )

Но если вернуться к джаве, то добавление jar открывает возможность спользовать какой-то класс в том же Spring. Даже в более веб-ориентированом фреймворке все равно прийдется писать хоть одну строчку кода, то разве Ivy,Maven,SBT,Gradle не хватает для доставки библиотеки?

Добавление jar: да - самый вменяемый транспорт для деплоя кроме гита. НО, разработчик должен иметь контроль над этим и (что было бы идеально) добавить и опубликовать свои правки. Тут проблемы в том, что пока мои правки не опубликованы, мне нужно задействовать либо свой локальный репозитарий при моем деплое либо держать патчи на готове и всякий раз их применять. Либо неизвестный мне механизм. На мой взгляд кроме git subtree и распределенного ПМ с поддержкой DCVS + пересборка одним пинком всего проекта: очень проблемно. Это тема интересная и полезная, но уже выходит за рамки. Когда-то ставил мавен и был заинтересован в его использовании. Но увидев, сколько он тянет зависимостей еще и замаскированных и в слотах + xml-конфиги - как-то поостыл. Но все еще интересуюсь. Ivy,SBT,Gradle пока не смотрел. Написать пару строчек не проблема - главное чтобы не пришлось всякий раз потом дописывать эту пару строчек кода.

Это какие-то частности.

В том-то и дело. Всю модулярность системы сводит на нет. Посмотрите какие костыли городят ОРМ-ах и им подобных. Жесткая привязка к прикладным данным сильно снижает мобильность. Формализация таких метаданных отвязывает от необходимости писать прикладной код - все можно отобразить на уровне системы минимально дописывая некоторые части. Валидация - легко формализуется масками ввода, «прикладными констрейнами» (размер, диапазон допустимых значений, «типаж», проверка в справочнике и т.п.) Идеально для описания поведения валидаторов нужны либо визарды либо встроенный бейсик-подобный язык + легко встраиваемые js-скрипты в песочнице. В целом, если эти задачи решены, то деплой системы может быть сведен до уровня метаданных и однократной установки системы.

Что это: куки, сиды в урлах, персональные сертификаты или другое

Тоесть в больше мере не сессия, как хранилище, но идентификация.

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

которые работают на history api.

Что за апи такой?

Comet везде невменяем.

Не везде. Есть достойные реализации.

Предоставление модели в виде rest api - вообще должно быть декларативным и кратким в стиле «/api/users: expose User with All, Read, Write, Delete»

Мне тоже нравится декларативный стиль. Это кстати один из революционных подходов, реализованный в мавене как альтернатива императивности. Декларативность во многом упрощает все, но реализовать сложнее.

«/api/users: expose User with All, Read, Write, Delete»

Это все очень условно, хотя для rest-идеологии весьма актуально. REST очень многозначное толкование имеет в различных подходах. Для меня REST очень практичным кажется когда общаешься с NoSQL типа couchdb через curl из шелла

Инфраструктуру можно.

Это да. И этот процесс бесконечен, но есть риск завязнуть там. Самое простое это задать несколько наводящих простых вопросов. Типа: почему так все сложно и запутано как с этим работать правильно))

Что бы вы хотели в хорошем веб-фреймворке?

Чтобы он не требовал для работы JVM.

Хочу что-то вроде Spring MVC без завязки на Spring и проще, что-то вроде JAX-RS, но еще проще.

Guice+JAX-RS ?) У меня такой сайт на GAE крутиться. Но на практике достает делать руками декларативное security и т.д.

Ня-ня-ня, тут думать надо..
Во-первых, mvc фрэймворков действительно много.
Во-вторых, а надо ли mvc, может лучше делать некие отдельные модули для решения конкретных задач, которые бы общались друг с другом, одни могли бы требовать другие, а какие-то были бы взаимозаменимы. Т.е., например, у модуля авторизации было бы некое стандартное API, и написав другой модуль под это API, он бы мог заменить оригинальный модуль, без ущерба для приложения*
MVC действительно (как тут было сказано), низкоуровневая вещь, может быть стоит сделать что-то среднее между cms и фрэймворком. csm под которую очень удобно писать расширения, которая состоит только из расширений.
В четвертых надо помнить о том, что доля клиентского js сейчас очень велика. Я вот, например, написал DSL(под coffee) для генерации dom дерева.
Библиотеки замечательно ставятся с помощью gem, знаете ли..**
И замечательно вмораживаются в проект с помощью bundler.
Далее, мне очень нравится persistent store у maglev ruby, надо под него обязательно что-нибудь замутить.

* Тут можно сделать генерацию сразу с тестами по api.
** Вообще все ставится замечательно с помощью gem, я думаю даже js библиотеки надо ставить с помощью gem.

Т.е. немаловажная часть фрэймворка именно API для модулей с конкретным поведением, которое, возможно, будет плавно меняться от версии к версии.

Во-вторых, а надо ли mvc, может лучше делать некие отдельные модули для решения конкретных задач, которые бы общались друг с другом, одни могли бы требовать другие, а какие-то были бы взаимозаменимы. Т.е., например, у модуля авторизации было бы некое стандартное API, и написав другой модуль под это API, он бы мог заменить оригинальный модуль, без ущерба для приложения*

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

1. Не авторизация, а аутентификация.

2. Какие ещё модули? То, что ты описал — это основы ООП, а не модули какие-то. Создаём интерфейс компонента аутентификации. Его реализуют (implements) конкретные реализации для каждого метода аутентификации (OAuth, LDAP, etc.).

Более такое уже есть в любом нормальном фреймворке. Да тот-же Yii:

Базовый компонент аутентификации: http://www.yiiframework.com/doc/api/1.1/CUserIdentity
OAuth, OpenID реализация: https://github.com/Nodge/yii-eauth
LDAP реализация: http://www.yiiframework.com/wiki/62/how-to-use-ldap-in-useridentity-for-authe...

3. MVC и расширяемость вещи ортогональные (одно другому ну никак не мешает).

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

Что именно сложного в реализации уже готового интерфейса?

Сразу видно человека, который рассуждает о веб-разработке не занимаясь ей.
1. Не авторизация, а аутентификация.

Шел бы ты в пень, лол. https://www.ruby-toolbox.com/categories/rails_authentication https://www.ruby-toolbox.com/categories/rails_authorization

То, что ты описал — это основы ООП

Хочешь всех поразить знанием терминологии, лол.

Да тот-же Yii:

Не смотрел я юии, но, думаю, это аналог раилз (только хуже). Как ты мог заметить пройдя по ссылкам, у рельсов десятки модулей авторизации, но они не взаимозаменяемы (в смысле тривиально). И в целом все библиотеки для рельс довольно разрознены, при этом большая часть функционала находится в api самих рельс. Я же предлагаю сделать по другим принципам: связанность, децентрализованность, взаимозаменяемость. Тогда само понятие view может быть лишь одним из модулей.

Чуть не так: взаимозаменяемость.

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

Вы в терминологии разберитесь сначала. :)

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

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

Какие ещё модули?

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

Имелось в виду, что ТС советуют не велосипедить его смешной фреймворк ради того, чтобы написать ещё одну стотыщпятьсотую реализацию MVC, а заняться чем-то другим. Я, правда, не совсем понимаю вашего оппонента насчёт «тогда само понятие вью может быть лишь одним из модулей» (ц), думаю, манипуляция архитектурой путём подключения модулей это утопично и вообще бессмысленно.

Что за апи такой?

*facepalm*

думаю, манипуляция архитектурой путём подключения модулей это утопично и вообще бессмысленно

Не.. ну потребность в легко-расширяемой cms есть, но тут надо думать.

тогда само понятие вью может быть лишь одним из модулей

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

Во всяком случае потребность в такой cms больше чем в mvc фрэймворке)

Децентрализовать модули настолько, чтобы их можно было запускать на разных серверах ^-^ Было бы интересно..

Господи, какой же будет отклик... Хотя сам я такое использую, но в очень специфическом случае.

Доп. вопрос

Вам нравится вообще концепция пихания аттрибутов в мапу чтобы сделать их доступными на странице? Или лучше постоянно доступный набор объектов, который доступен across pages.

Еще доп. вопрос. Что из области Ajax должен делать фреймворк, а что нет?

Пока не сделаешь, не оптимизируешь - не узнаешь..

Не хочу веб-фреймворк, хочу прозрачную систему хранения с клиентами к ней, чтобы можно было сделать 5 нод, раскидать по серверам, назначить основной и резервный, а в клиенте писать file.save('/category/filename'), или file.load('/catogory/filename'), а оно прозрачно раскидывало бы файлы по нодам.

Хочу риалтайм из коробки и одностраничные приложения.