LINUX.ORG.RU

новый web-framework PEF::Front

 , ,


3

5

Приветствую!

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

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

Поясню последний пункт, который, собственно, и был мотивационным. Работало 3 человека на проекте. Один делал Модель, другой делал Вид и третий Контроллеры. Писатель модели написал апи, как пользоваться, на какие запросы какие ответы приходят и вообще какова общая логика внутренних данных, писатель Вида по макетам написал хтмл-шаблоны. Писатель Контроллеров по спецификациям написал контроллеры и стали тестировать. Выясняется, что когда одного из трёх нет, то виноватого найти очень сложно. Модельер смотрит: «мне пришли не те данные», ждём контролёра. Выясняется, что данные в неправильном формате послал Вид. После разработки выясняется, что какие то куски надо продублировать по разным страницам, соответственно, это работа сразу для двух человек: один правит шаблоны, другой контроллеры. В итоге темп разработки страдает.

Это породило идею: контроллеры должны перестать быть самостоятельной сущностью и стать придаточной. Контроллеры стали декларативными. В итоге в модели MVC участие в разработке требуется только у двух (собирательный образ) человек: один пишет Модель, другой пишет Вид, а контроллеры как самостоятельный вид пропали. Это не значит, что теперь прямо из шаблонов можно делать запросы к базе данных, это не так, но добавить новый блок данных в шаблоны теперь задача только одного человека, который собственно и отвечает за внешний вид.

Дальнейшее развитие породило автоматическую валидацию параметров запросов, декларирование действий и многое другое. Запросы к Модели возможно делать ajax-ом, по submit/get-у данных или запросом данных из шаблонов.

Документация на текущий момент очень слабая, примеров мало, из плюсов простота кода и вообще подхода. Фреймворк опирается на протокол PSGI _без_ Plack, вообще внешних тяжёлых зависимостей нет. Протестирована только конфигурация на базе nginx+uwsgi, поскольку я в общем-то не вижу необходимости в других. Глубоких бенчмарков не проводилось, но по внешним признакам всё очень быстро работает.

Ссылка на (фиговую) документацию на русском языке https://github.com/pef-secure/pef-front-psgi-dist/blob/master/lib/PEF/Front/I...



Последнее исправление: pef-secure (всего исправлений: 1)
Ответ на: комментарий от pinachet

пиши vti его найдешь в нете

Похоже все пути к нему ведут, я его независимо от твоего сообщения нашёл :)

pef-secure
() автор топика

Какое квадратно-гнездовое «ненужно». Хотя админам локалхоста может понравится.

anonymous
()

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

1. Чем конкретно не устраивают существующие велосипеды a, b, и с.

2. Как эти недостатки закрываются в собственном велосипеде d

3. Какие еще вкусности кроме отсутствия имеющихся недостатков наличествуют в предлагаемом к изучению велосипеде. Толком недокументрированном и не покрытым элементарным минимумом тестов.

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

ach
()
Последнее исправление: ach (всего исправлений: 1)
Ответ на: комментарий от ach

я хоть не автор но попытаюсь ответить.

вы их не хотите слышать

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

1)довольно странно обсуждать чем не устраивает тот или иной перл веб фреймворк ведь модель разработки они «продают» одну и туже.Давайте обзовем ее классическим MVC - просто для определенности.Не устраивала в ней по большому счету всего одна мелочь - решает «что показывать» в ней всетаки бэкенд программист - именно он решает какой шаблон рендерить какие данные передать в stash шаблону. Т е отображение занимается по сути только оформлением - отвечает на вопрос «как показывать». Т е для того чтобы фронтендшику получить какие то дополнительные данные в шаблоне ему надо попросить бекендшика добавить их в рендере.Добавить рендер нового шаблона - опять таки работа для бекендшика. Или к примеру появилась необходимость делать запрос не сабмитом а ажаксом - опять бэкендшику необходимо исправлять код.Т е фронтенд программист ограничен кодом «контроллера».И в большинстве случаев когда нам надо както поправить отображение нам придется исправлять и код контроллера.

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

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

А конкретный пример работы вашего коллектива

Про коллектив это была такая метафора - это «абстрактный коллектив в вакууме» - причем похоже метафора не удачная.

Про документацию вы зря - на 2,5к строк с минимумом зависимостей документации в целом достаточно(+есть «хелловорд» приложение).Про тесты вы правы - автор уже отвечал о том почему в данный момент их нет.

alef-null
()
Ответ на: комментарий от ach

Не, ну правда. Элементарные же вещи пытаются донести, но вы их не хотите слышать.

Какие именно? Удивление что в 2014 всё ещё используется перл или «не нужно» просто из принципа?

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

Хочется, цель такая есть. Более того, я думаю, что сама предлагаемая модель выгоднее, чем существующие альтернативы, а значит, что постепенно появится аудитория. Моя неспособность донести мысль быстро мной уже осознана, я поработаю над этим, когда появится время. Пока что вот предпочитаю кодировать...

1. Чем конкретно не устраивают существующие велосипеды a, b, и с.

Это неимоверно широкая тема. Сравнение с любым из «велосипедов» потянет на большую статью с холиваром в комментариях. По большому счёту, основная моя претензия к «альтернативным» велосипедам в том, что простые вопросы они часть стараются решить сложно, либо академично, либо ещё как, вместо того, чтобы заниматься именно упрощением подходов. Некоторые решения мне не нравятся чисто эстетически. Моё стремление в том, что от мысли до реализации должно пройти как можно меньше времени и как можно меньше усилий затрачено, решение должно получиться гибким, управляемым, эффективным, легко сопровождаемым, дающим широкие возможности. Где я вижу широкие возможности, там почему-то простые вещи надо делать сложно, ну и так далее. Я бы вобщем предложил устроить какой-то контест, чтобы одна и та же задача решалась на моём фреймворке мной и каким-либо специалистом в другом фреймворке в его способом, а затем уже можно было судить по результату. Вобщем, посмотрим.

2. Как эти недостатки закрываются в собственном велосипеде d

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

3. Какие еще вкусности кроме отсутствия имеющихся недостатков наличествуют в предлагаемом к изучению велосипеде. Толком недокументрированном и не покрытым элементарным минимумом тестов.

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

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