LINUX.ORG.RU

Угадайте фигню по описанию...


0

2

Появилась у меня некая мета-идея... Но прежде чем детализировать её, создавать реализацию, хочу спросить народ, может есть уже что-то подобное, известная парадигма, подход (плз. не используем в ответах слово «Паттерн» - тошнит)

Сейчас пишу на Python/Django, и в первую очередь ниже описываемая идея относиться к ним, но и для других языков это актуально.

Короче, программирование пользовательской логики, если мы говорим о enterprise-приложениях, это заполнение каких-то форм данными, и последующее оперирование полученными данными. Причём это не всегда формы в привычном нам понимании, иногда формы прячуться за красивым ГИС-интерфейсом. Суть всегда одна и та-же, программа предоставляет пользователю некий ГУЙ, в котором пользователь должен сделать что-то, заполнить интерфейс данными. По заполнению интерфейса инициируется какой-то код, выполняющий непосредственно логику. Далее, результат отображается либо здесь-же, либо осуществляется переход к следующему интерфейсу.

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

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

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

1. Описывать какую-то логическую мета-операцию, состоящую из под-операций, и предоставлять имя для неё

2. Предоставлять требования к последовательности выполнения под-операций

3. Предоставлять требования к наличию определённых данных, перед тем как будет выполнена определенная под-операция

4. Предоставлять какие-то очень тривиальные методы использования себя. Например через декораторы для джанговских view.

ПСЕВДОКОД:


Опишем_тут_мета-операцию, (из таких-то под-операций, с такими-то требованиями к данным), с именем "Добавить клиента"

@декоратор_для_"Добавить клиента"_под-операция1

def view1(request):

    ....


@декоратор_для_"Добавить клиента"_под-операция2

def view222(request):

    ....

По итогу, view будут вызваны только если соблюдены все условия

я правильно понимаю, что ты предлагаешь вынести is_valid() в отдельную функцию? в чём новаторство?

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

или ты предлагаешь проверять форму на уровне приложения, а не внутри вьюхи?

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

Нет, не is_valid ! is_valid это фигня, она проверяет только наличие данных в одной форме.

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

Кроме того, некоторые формы бессмысленно вызывать, если нет этих предварительных данных. К примеру нельзя показывать форму редактирования какой-то модели (в джанговской терминологии), если не известен ID конкретной записи в БД. Тогда и нет смысла вызывать view, рендериь страницу, показывать её пользователю. Понятно что это можно сделать внутри view с помощью условных операторов...

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

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

Я правильно понял, что вы хотите описывать все предусловия для форм и их взаимосвязи декларативно? Если да, то мне сразу почему-то приходит на ум Spring, хотя он для другого предназначен. Но принцип похож: заводим к примеру отдельный XML, где перечисляем все формы и устанавливаем правила взаимодействия между ними: что куда можно, где какие условия должны быть выполнены и т.д. Я веб-программированием не занимаюсь, так что не знаю, может что-то подобное уже изобретено.

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

Прочитал на Вики, и таки да :) Если всё то что выполняется во view мы примем на элементарные вычисления. Тогда конструкция, которая будет определять порядок и взаимодействие этих отдельных вычислений вполне подпадает под определение «Монада в языке Haskell» из википедии :)

dmitryalexeeff ()
Ответ на: комментарий от CARS

Я правильно понял, что вы хотите описывать все предусловия для форм и их взаимосвязи декларативно? Если да, то мне сразу почему-то приходит на ум Spring, хотя он для другого предназначен. Но принцип похож: заводим к примеру отдельный XML, где перечисляем все формы и устанавливаем правила взаимодействия между ними: что куда можно, где какие условия должны быть выполнены и т.д. Я веб-программированием не занимаюсь, так что не знаю, может что-то подобное уже изобретено.

Да, декларативный формат наиболее удобен. Если язык описания прост, то декларативность позволяет понять логику «окинув взором». Но, если говорить о питоне, то , думаю, нет необходимости использовать внешний язык описания и инструментарий. В питоне будет вполне достаточно классов и рефлексии

dmitryalexeeff ()

И всё-же, господа, известны ли вам готовые инструменты, реализующие примерно такую логику для enterprise-приложений (кроме же названого spring) ?

dmitryalexeeff ()

Похоже, месье изобрёл Rule Engine вкупе с паттерном (да-да) MVC.

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