Рамка веб-приложений python для жесткой связи DB/GUI?

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

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

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

Теперь мне нужно найти структуру веб-приложения, которая естественно подходит для SQLAlchemy (или эквивалента) и, возможно, даже с моим аппетитом к соединению. С "инфраструктурой веб-приложений" я имею в виду продукты/проекты, такие как Pyhons, Django, TurboGears, web2py и т.д.

Например, он должен идеально иметь возможность:

  • автоматически выберите подходящий виджет формы для ввода данных в указанный столбец, если ему это сказали; например, если столбец имеет внешний ключ для столбца с 10 различными значениями, виджет должен отображать 10 возможных значений в качестве раскрывающегося списка
  • автоматически создать код проверки формы JavaScript, который дает обратную связь с быстрой ошибкой конечного пользователя, если строка вводится в поле, которое должно закончиться в столбце INTEGER, и т.д.
  • автоматически создайте виджет календаря для данных, которые будут в столбце DATE
  • намекнуть NOT NULL ограничения как javascript, который жалуется на пустые или пробельные данные в соответствующем поле ввода
  • создать код проверки JavaScript, который соответствует соответствующим (простым) ограничениям CHECK
  • упростить избежать SQL-инъекций, используя подготовленные операторы и/или проверку внешних данных
  • упростить избежать межсайтового скриптинга, автоматически удаляя исходящие строки, когда это необходимо
  • использовать имена ограничений, чтобы генерировать несколько удобных сообщений об ошибках в случае нарушения constrataint.

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

Существует ли такая основа для Python (или для любого языка, если на то пошло)? Если нет: какая из нескольких фреймворков веб-приложений Python будет наименее мерой, если я должен сам добавить части этих функций?

Ответ 1

web2py делает большую часть того, что вы спрашиваете:

На основе типа поля и его валидаторов он отобразит поле с соответствующим виджетами. Вы можете переопределить с помощью

db.table.field.widget=...

и используйте сторонний виджет.

web2py имеет js, чтобы заблокировать пользователя от ввода нецелого числа в целочисленном поле или не двойного в двойном поле. поля времени, даты и даты и времени имеют свои собственные сборщики. Эти проверки js работают с (не вместо) проверки на стороне сервера.

Существует IS_EMPTY_OR(...) валидатор.

DAL предотвращает SQL-инъекции, так как когда-либо выйдет в БД, все еще происходит.

web2py предотвращает XSS, потому что в {{= variable}} "переменная" экранируется, если не указано иное {{= XML (переменная)}} или {{= XML (переменная, sanitize = True)}}

Сообщения об ошибках являются аргументами валидаторов, например

db.table.field.requires=IS_NOT_EMPTY(error_message=T('hey! write something in here'))

T для интернационализации.

Ответ 2

Вы должны взглянуть на django и особенно на newforms и admin. Модуль newforms обеспечивает хорошую возможность проверки на стороне сервера с автоматическим формированием сообщений об ошибках/страниц для пользователя. Добавление проверки ajax также возможно

Ответ 3

Я считаю, что модели Django не поддерживают составные первичные ключи (см. документация). Но, возможно, вы можете использовать SQLAlchemy в Django? A google search указывает, что вы можете. Я не использовал Django, поэтому не знаю.

Я предлагаю вам взглянуть на:

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

Что касается фреймворков веб-приложений для Python, я рекомендую TurboGears 2. Не то, чтобы у меня был какой-либо опыт работы с любой другой инфраструктурой, мне просто нравится TurboGears...

Если автор исходного вопроса находит решение, которое работает хорошо, обновите или ответьте на эту тему.

Ответ 4

TurboGears в настоящее время использует SQLObject по умолчанию, но вы можете использовать его с SQLAlchemy. Они говорят, что следующий крупный выпуск TurboGears (1.1) по умолчанию будет использовать SQLAlchemy.

Ответ 5

Я знаю, что вы специфика просите фреймворк, но я подумал, что дам вам знать, что я здесь делаю. Я только что претерпел преобразование своего веб-приложения моей компании из пользовательского внутреннего слоя ORM в sqlAlchemy, поэтому я далек от эксперта, но что-то, что пришло мне в голову, это то, что sqlAlchemy имеет типы для всех атрибутов, которые он отображает из базы данных, поэтому почему бы используйте это, чтобы помочь вывести правильный html на страницу. Поэтому мы используем sqlAlchemy для back-end и шаблонов Cheetah для внешнего интерфейса, но все между ними в основном является нашим собственным.

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

Шаг 1. Для каждого типа данных sqlAlchemy.types.INTEGER и т.д. Добавьте дополнительную функцию toHtml (или многие, возможно, вHTMLReadOnly, toHTMLAdminEdit) и просто верните шаблон для html, теперь вам даже не нужно обратите внимание на то, какие типы данных отображают, если вы просто хотите выплюнуть целую таблицу, которую вы можете просто сделать (в качестве шаблона гепарда или того, что когда-либо было в вашем шаблоне).

Шаг 2

<table>

<tr>

#for $field in $dbObject.c:

<th>$field.name</th>

#end for

</tr>

<tr>

#for $field in dbObject.c:

<td>$field.type.toHtml($field.name, $field.value)</td>

#end for

</tr>

</table>

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

Шаг 3 Обнаружил необходимость третьего шага только в пятницу, захотел выгрузить файлы, которые, как вам известно, больше, чем только текстовое поле данных типов данных varchar. Нет пота, я просто переопределял класс строк в своем определении таблицы из VARCHAR в FilePath (VARCHAR), где единственное различие заключалось в том, что у FilePath был другой метод toHtml. Работала безупречно.

Все, что сказал, если есть термоусадочная пленка, которая делает то, что вы хотите, используйте это.

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