LINUX.ORG.RU

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


1

3

... из того чего уже нет нигде, или там где есть, то фреймворк - говно.

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

Например, что не подойдет в качестве пожелания

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

Подходит

Хочу чтобы можно было построить complete rest сервисы непосредственно из доменных объектов, при этом участие фреймворка минимально, но очень сокращающее код. Тоесть он не делает это за вас, но ваше участие минимально необходимо

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

★★★★★

Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от special-k

Во-вторых, а надо ли 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 под которую очень удобно писать расширения, которая состоит только из расширений.

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

resurtm ★★★
()
Ответ на: комментарий от resurtm

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

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

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

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

Да тот-же Yii:

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

special-k ★★★★
()
Ответ на: комментарий от resurtm

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

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

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

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

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

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

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

Reaper ★★
()
Ответ на: комментарий от Reaper

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

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

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

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

special-k ★★★★
()
Ответ на: комментарий от special-k

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

special-k ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.