Generic CRUD admin for Flask, with WTForms? [closed]

Question

are there any generic CRUD admin for Flask based on WTForms?

Currently we are building a hybrid backend system where admin must CRUD lots of data from various source, MongoDB, Redis, ini file, ENVIRON, etc. Writing specific admin view for each of them seems a waste of time, but all Flask admin or WTForms admin solutions are based on some kind of fixed ORM, e.g. MongoEngine, AppEngine Datastore, SQLAchemy, etc.

Are there any more generic ones which allows ORM-agnostic admin to be automatically generated?

I need it to provide the following functions

• list view for a group of items, support inline editing or batch actions would be great!
• edit view for one specific item for add/edit

Just define some Form model, implement a iteration method and auto generate a full fledged admin.

Are there any reusable OSS projects like this?

Answer 1

I know this is an old question, but nowadays Flask-admin is available and is pretty awesome.

Very pluggable and easy to write your own handlers for storing/processing of the data (quick start).

Answer 2

I would suggest examining the following:

https://github.com/sbook/flask-mongoengine

https://github.com/coleifer/flask-peewee

You could take sbook's flask-mongoengine and port coleifer's admin from flask-peewee to it. I don't imagine this would be too difficult. Coleifer's admin gets extra points for its use of twitter-bootstrap and I can tell you that he is very responsive to issues.

I've worked with mongoengine on flask and also flask-peewee and both are excellent.

Answer 3

The short answer is no, as far as I know, there is no auto-generating ORM for redis or MongoDB.

Now for a more detailed explanation:

The reason why there exists CRUD generation for 'fixed' ORM's and not datastores based in free-form records is simple: the very nature of free-form records makes it difficult to create a schema.

Let's look at redis for example, say each record was a hash e.g. key 'user-{id}' with fields username, age, and registered_on. Now, what happens when you add a new field 'location' to the users? Well, redis doesn't care, you just add the field to any records as they're modified, no need to go back and add the field to every hash. Simple enough.

But now, you have your CRUD magic, which tries to figure out what fields to show. Say you decide looking at the first record to see what fields exist works, but what if user-1 is missing that new 'location' field? Now the CRUD won't generate it.

Furthermore, because redis stores every value as a string, a CRUD wouldn't know that 'age' for example only accepts an integer and registered_on is actually an ISO-formatted date string.

Oh, but you say, MongoDB has datatypes! surely, assuming we ignore the different fields per record allowance, pretending we have the same set of fields per record, it's possible to do some automagic CRUD there? Well yes, you will be able to do a bit better than with Redis, because there's e.g. a date type and integer type, but there are some discrepancies even then. Say you have a string value. How do you know if that string value requires a multi-line input (textarea) or single-line(input type=text), or is even only available from a drop-down select of a few choices?

Because of this, the only way to really do a theoretical CRUD for many free-form types would be if you defined in advance the 'schema' (via a Form definition maybe?) for each record, and maybe implemented some sort of interface class/contract that allowed a CRUD tool to list records to retrieve objects, to retrieve a single record by key, to update/create a record, and to delete a single record by key.

Such a theoretical 'pluggable' CRUD tool would be really cool, and I'd love to see someone take it on.