• Python программирование Что-то ни wtforms, ни джанговские формы как-то не сильно удовлетворяют современным реалиям — генерацией и работой с формами с кучей джаваскриптов всяких... Есть еще какие-то альтернативы или надо свое писать?
    ♡ recommended by @metamage

Replies (56)

  • @provaton, я в джанге или js ни бум-бум, но всё же интересно — ведь есть мега-конторы и мега-комьюнити, неужели до сих пор не закрыли все вопросы?
  • @akastargazer, Ну ты прям какой-то наивный. Вот в девятнадцатом веке тоже были мегаученые и крутые инженеры — почему не закрыли все вопросы? Прогресс на месте не стоит, регулярно появляются новые задачи, такова уж жизнь... Пять лет назад форма с валидацией на джаваскрипте была редкостью, поэтому движки для обработки форм писались для схемы — "сгенерировал ХТМЛ, принял POST, отвалидировал, если не прошло сгенерировали ХТМЛ с сообщениями об ошибках, если прошло, то записали в БД и редиректнули". А сейчас формы на джаваскрипте, там свои сложные фреймворки, валидаторы, динамические поля, и прочая хренотень. Некоторые уже даже серверную часть начали на джаваскрипте писать, чтоб легче взаимодействие с клиентской частью было. Мир меняется...
  • @provaton, А вот не надо девятнадцатый век сравнивать! Там Жюль Верн, паровые машины, всё руками делали.
    Нынче-то информационный век, работаем с предметной областью напрямую. Выходит, что компьютерные инструменты настолько убогие, что не отличаются по сути от паровых двигателей.
  • @akastargazer, Все равно время нужно, человек существо ограниченное
  • @provaton, Человек-то да, но ведь у нас под рукой аболютный исполнитель, который вычисляет с бешеной скоростью. И до сих пор ручками всё.
  • @akastargazer, Пока что мы не научили этого абсолютного исполнителя писать программы без нашего вмешательства.
  • @provaton, Была такая система Clarion, описываешь словарь БД, а потом жмешь кнопку и он сам тебе генерирует полноценное клиентское приложение, с отчётами, гуём и всем необходимым. Так это технология 1990-х. Смотрю, в XXI веке недалеко ушли.
  • @akastargazer, и много где эта система внедрена?
  • @provaton, В своё время был определённый бум. Потом большие конторы стали перехватывать технологии. Но радикального скачка не произошло, как я наблюдаю и что косвенно подтверждается твоим постом.
    С предметной областью работаем жалко и непроизводительно. Зато джаваскрипт, емае.
  • @akastargazer, А я тебе скажу почему скачка не произошло. Потому что идея вроде и классная, но на практике зачастую клиент обязательно напридумывает требований, которые сгенерированный код выполнить не сможет, и придется руками дописывать. Ладно если там пара мелочей, а бывает что надо серьезно поведение менять. И в таком серьезном случае такая система начинает только мешать и вставлять палки в колеса. И кмк именно в связи с этим произошел обратный скачок — от гигантов в которых есть встроенная автоматизация на все случаи жизни к маленьким фреймворкам типа rails или django, а от них к еще более маленьким. Идеология гибкой разработки (agile).
  • @provaton, "на практике зачастую клиент обязательно напридумывает требований"
    Я про это и говорю. Нет нормального подхода к предметной области. Все надрачивают на формальные нотации компьютерного уровня. А они недостаточны для обслуживания концепций предметки.
  • @akastargazer, ты ещё скажи, что эта технология работала. А мы посмеемся.
  • @akastargazer, Эта технология замечательно работала в сферической вакууме. В реальной жизни что-то не очень...
  • @lex2d, Она отлично работала в реальной жизни.
  • @provaton, Такие штуки как генерация кода, по схеме хранилища есть наверно в любой ерп системе, не сказать чтоб оно совсем бесполезно, но на серебряную пулю не тянет, ибо руками надо все править.
  • @qnikst, Работала, есесно. Я на ней прилады делал.
  • @akastargazer, Угу. Ох уж эти сказки, ох уж эти сказочники...
  • @lex2d, Бгг. Сразу видно поколение пепси, солома в башке
  • @lex2d, Речь не о генерации кода, которая является достижением прошлого века. А о нормальной работе с предметной областью, где мы не ушли дальше BPMN-движков.
  • @akastargazer, Show me the code.
  • @qnikst, Посмотри на видео лучше: youtube.com

    Там ютуб выдаст и ассоциативные ссылки на более поздние версии.
  • @akastargazer, И эти люди говорят про "поколение пепси"..
  • @akastargazer, Блин.. Я таки посмотрел это... Теперь я честно не вижу смысла продолжать разговор.
  • @qnikst, расписался в непонимании увиденного, ок
  • @akastargazer, От тебя, сейчас и в дальшейшем, я готов видеть только ссылки на статьи в рецензируемых источниках. Спасибо за понимание.
  • @qnikst, В крайнем случае ссылки на подробную документацию или высокоуровневые описания архитектуры проекта, в самом крпйнем полный разворот мысли опирающийся на данные источники. (Я понимаю, что со статьями могут быть проблемы и надо дать хоть какой-то шанс)
  • @qnikst, рад видеть твою готовность
  • @qnikst, ещё один представитель поколения пепси, блин.
  • @akastargazer, Детский сад в другом месте, уйди туда, пожалуйста.
  • @qnikst, От того, что ты несведущ в истории ИТ (в частности, например, истории компании SoftVelocity, кстати, они ведут своё начало от компании Clarion, и там фигурируют люди, создававшие Borland), мне ни жарко ни холодно. Ну а доказывать тебе существование кларион-технологий я не собираюсь, их время, в общем-то, уже ушло, потому что с годами майнстрим перенял и впитал многое из них.
  • @akastargazer, Чисто для закрытия контекста, я правильно помню что это ты, кто тут часто Оберон у месту и нет вспоминает?
  • @qnikst, Оо, ну-ка, поделись, причём тут Оберон?
  • @akastargazer, При составлении твоего портрета
  • @qnikst, Ну справедливости ради, ты ведь тоже на достаточно маргинальном языке работаешь...
  • @provaton, Но я не считаю этот язык тру-путем и не предлагаю смотреть видео и презентации пытаясь что-то доказать, в любом случае я сначала попытаюсь доходчиво объяснить суть и скинуть ссылки на текстовые источники, не пытаясь переходить на личности. Бывают исключения, но в случае если разговор совсем не клеится, как, например, тут.
  • @provaton, Например, если ты пишешь, что кларион это больше, чем круд, то изволь объяснить чем или дать ссылку, если жаль времени. Причём, например, вики таки пишет, что оно было крудом в первых версиях. Есть темплейтв — объясни чем это лучше composable либ. Есть предметная область — обьясни, чем это отличается от дсл и какие преимущества по сравнению с edsl. Ну и жалетельно не забывать держать в контексте область применимости, чтобы тёплое и мягкое не сравнивать.
  • @qnikst, Не забудь ещё красноквадратную аватарку прицепить к портрету
  • @qnikst, Ты, по-моему, выпал из контекста. Я не писал, что "кларион больше чем CRUD", это исключительно твоя формулировка. Где там круд я могу пояснить, только зачем?
    Темплейты, да, есть. Почему я должен тебе объяснять, чем это лучше composable lib (кстати, объясни, плиз, что это такое, а то я как-то не в курсе). Про темплейты тоже могу рассказать.
    Про предметную область, так язык Clarion изначально создавался как DSL, и теперь расскажи, в каком году появился edsl? Да и вопрос твой про предметную область плохо сформулирован, потому что вопрос "чем предметная область отличается от DSL" пахнет плохим пониманием понятия "предметная область".
    Дальше я даже боюсь идти, раз такие разночтения возникают уже в самом начале. Нет смысла заводить разговоры про предметные области, если нет понимания.
  • @akastargazer, Это политвзгляды, они сюда мало относятся.
  • @akastargazer, Почему же нет смысла разговаривать? Это ж не хохлосрач, тут консенсус вполне можно найти. Жаль, правда, что никто не высказался по оригинальной теме (обработке веб-форм в питоне)
  • @provaton, меня-то интересует состояние ИТ в общем, поэтому и приполз сюда
  • @akastargazer, /19; библиотеки построенные на таких принципах, что их легко объединять др. с другом (читаем вадлера (80-е года ещё)); концепция edsl в статьях это 2000-е, хотя использовалось и до этого; про предм область — плохо выразился, чем использование клариона отличается от создания дсл, чем занимаются все и часто и на любом языке; я не уверен, что ты можешь объективно оценивать чужие знания.
  • @qnikst, Про "композабельность" понял, это просто другое прочтение компонентности. Про "создание DSL", мне непонятно, ведь тот же кларион — DSL сам по себе, то есть, язык приближенный к предметной области. На любом языке это делать просто неудобно, ведь чем ближе нотация к железу, тем больше усилий надо предпринять, чтобы придвинуть её к предметке.
    Насчёт моих способностей оценить чужие знания, это вообще к чему? Я рассказываю про свой опыт, и гляжу на то, что происходит вокруг. И у меня складывается такое впечатление, что ИТ мало куда продвинулось в аспекте овладения предметной сложностью.
  • @provaton, В этом треде слишком много пионеров, я лично адекватных реализаций не видел. И вообще тебе rich ui надо или просто умную форму?
  • @akastargazer, Мейнстрим языки сами по себе засели глубоко в 80ых, всякие расты и свифты сделали робкие попытки прорыва. Решений позволяющих понижать предметную сложность, в принципе, немало начиная от концепций представления предметных областей в языках, до упрощения и нахождения общих тенденций в написании дсл/едсл, однако зачастую во многих областях это делается независимо друг от друга.

    Конкретно в области вопроса provaton все плохо везде, т.к. понимания принципов построения связки форма-для-юзера <-> локальное представление объектов <-> эффективное взаимодействие <-> сервер сайд проверки <-> сервер сайт представление объектов <-> маппинг на базу нет. При том что каждая двойка или тройка связей покрывается теми или иными решениями. (Дальше всего наверное gwt ушло, но может мне так кажется т.к. опыта почти нет с ним). Дополнительная проблема тут что frontend на js, причём его вид и особенности контролируются "заказчиком".

    В итоге последние 2 тренда — свести все к одному или все на js или писать все на языке и компилять результат в js.
  • @qnikst, Ну и простыня.. :)
  • @qnikst, Пионеров=питонеров, долбаная автокорректировка
  • @qnikst, Проблема-то как раз в том, что для предметной области нет подходящей математики. Нет и всё. Вон, для реляционных БД нормальную алгебру определили и сразу взлетело — попёрли хорошие инструменты, до сих пор летит.
    А в остальном пытаются сложность взять двумя способами — нотацией и индусами. Нотацией всё не ухватишь, ибо получается монстр. А батальоны индусов бодро и с огоньком может тащить только большая корпорация (см. успехи и неудачи опенсурса).
    Про связки интересно ты написал, получается, что от индусов никто не может отказаться. Берут готовые вычисления и начинают соединять между собой, получая комбинаторный взрыв.
  • @qnikst, Имей в виду, что в своё время это была бомба.
  • @qnikst, Мне вообще нужен гуй юзерский для составления форм, типа wufoo.com То есть, джаваскриптовое приложение генерирует JSON с описанием формы, серверная часть из этого JSON'а формирует классы для обработки, валидации и рендеринга. Отрендеренная форма должна содержать джаваскрипты для валидации, для поддержки условных полей (которые показываются в случае если в другие поля юзер ввел определенные значения). Еще нужно поддерживать списки, многостраничность, прием кредиток, и еще всякие там требования которые я забыл, но о которых помнит заказчик. В общем, я малость загрузился и в ступоре. Текущая реализация использует wtforms, но они уже скорее мешают чем помогают...
  • @akastargazer, Давай я дальше толькл про haskell говорить буду. Смотрим Wadler — theorems for free (1989), там описывается как в ленивых языках допускается обьединяемость без повышения сложности, сейчас Free Monad (следствие халявных теорем из CT) активно используется в дсл, грубо говоря ты находишь в описании проблемы алгебраическую структуру, аккуратно записываешь и получаешь нахаляву встроенный язык. Вообще выделение алгебраической структуры (инвариантов) очень сильно упрощает жизнь и увеличивает обьединяемость без существенного повышения сложности. Правда я знаю мало языков активно это эксплуатирующих.
    В том же Haskell благодаря весьма свободному синтаксису и выбору абстракций отделить встраиваемый язык от библиотек иногда тяжело, что опять же уменьшает сложность.

    А слежение за инвариантами полезно везде от оценок корректности и сложности до проектирования структур данных и положить эту задачу на ПК зачастую сложно.

    Однако даже если учесть вышеописанное то дать решение убирающееся необходимость в быдлокодерах нельзя.
  • @provaton, Просто бывают хотят всякие extjs и компанию (обзываетчя rich ui), где в браузере ты получаешь приложение плохо отличимое от десктопного, там основные пляски вокруг представления данных и т.п.

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

    Спросил бы на SO и рассказал тут :)
  • @qnikst, У меня в голове есть план как это сделать, выкину втформс и напишу свой аналог, но более подходящий под задачу. На всякий случай спросил, может есть еще какие-то инструменты для обработки форм кроме мне известных.
  • @qnikst, Кстати, как по твоему мнению, насколько понимание теории категорий и прочего матана помогает писать хороший код на хаскелле?
  • @provaton, Я умею в CT, считаю что пишу сносный код.
  • @qnikst, Не умею. В смысле :)