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

3

5

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?

Frink answered 12/12, 2011 at 3:18 Comment(1)
It shouldn't be very difficult to create some software that takes in your documents, and on a per document basis, generates a WTForm class for each document (being that each document can have different sets of data on them even if they are meant to represent similar objects -- the flexibility of no-sql and all...). Then you could use a blueprint in flask to register a view function that would grab an object, generate the form and display the form to the user. Introspecting what form widget and validation you need would be the difficult part, as the answer below indicates though.Propagandize
S
2

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.

Stevenstevena answered 12/12, 2011 at 22:11 Comment(1)
Thanks for the reply. "would be if you defined in advance the 'schema' (via a Form definition maybe?)" This is exactly what I meant. I predefine a Form (aka schema and data type), with CRUD methods, then auto generate validated admin.Frink
M
5

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).

Masonry answered 8/4, 2013 at 23:35 Comment(0)
C
3

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.

Cherri answered 20/12, 2011 at 23:16 Comment(4)
Thanks for the tips, but the point of ORM-agnostic is to build admin on top of schema-less data, such as k-v db, json, etc. Peewee and MongoDB has fixed backends.Frink
I'm not sure what you mean when you say MongoDB has "fixed backends"? For what you describe, you may want to look at minimongo: github.com/slacy/minimongo It would be light work to wrap a wtform or flatland fields into setattr/getattr with minimongo. Just an idea.Cherri
I mean flask-mongoengine is fixed backend with MongoDB. I don't need an access wrapper around MongoDB, I need auto generate CRUD admin for hybrid backends.Frink
Having admin interface like flask-peewee (rails_admin analogue) is something is really missing in flask-mongoengine. With such auto-generated admin interface flask-mongoengine would be much more interesting for lazy developers :-)Stereophotography
S
2

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.

Stevenstevena answered 12/12, 2011 at 22:11 Comment(1)
Thanks for the reply. "would be if you defined in advance the 'schema' (via a Form definition maybe?)" This is exactly what I meant. I predefine a Form (aka schema and data type), with CRUD methods, then auto generate validated admin.Frink

© 2022 - 2024 — McMap. All rights reserved.