Фреймворк веб-приложений Python для тесной связи БД / ГИП? - PullRequest
11 голосов
/ 04 сентября 2008

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

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

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

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

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

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

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

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

Ответы [ 5 ]

5 голосов
/ 13 октября 2008

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 для интернационализации.

3 голосов
/ 04 сентября 2008

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

1 голос
/ 07 сентября 2008

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

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

Шаг 1. Для каждого типа данных sqlAlchemy.types.INTEGER и т. Д. Добавьте дополнительную функцию toHtml (или многие, может быть, toHTMLReadOnly, 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. Работал без нареканий.

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

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

1 голос
/ 07 сентября 2008

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

1 голос
/ 04 сентября 2008

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

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

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

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

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

...